From exim@www1.ietf.org Sat Nov 1 14:16:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12749 for ; Sat, 1 Nov 2003 14:16:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG1Em-0003Tb-V6 for ipv6-archive@odin.ietf.org; Sat, 01 Nov 2003 14:16:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1JGeHE013357 for ipv6-archive@odin.ietf.org; Sat, 1 Nov 2003 14:16:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG1Em-0003TM-Or for ipv6-web-archive@optimus.ietf.org; Sat, 01 Nov 2003 14:16:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12725 for ; Sat, 1 Nov 2003 14:16:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AG1Ej-0004QD-00 for ipv6-web-archive@ietf.org; Sat, 01 Nov 2003 14:16:37 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AG1Ej-0004Q9-00 for ipv6-web-archive@ietf.org; Sat, 01 Nov 2003 14:16:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG1EA-0003Na-7z; Sat, 01 Nov 2003 14:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG1DV-0003Mr-15 for ipv6@optimus.ietf.org; Sat, 01 Nov 2003 14:15:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12686 for ; Sat, 1 Nov 2003 14:15:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AG1DS-0004PQ-00 for ipv6@ietf.org; Sat, 01 Nov 2003 14:15:18 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak1a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AG1DS-0004PM-00 for ipv6@ietf.org; Sat, 01 Nov 2003 14:15:18 -0500 Received: from 132.235.232.96 by pm2 (PureMessage); Sat Nov 1 14:14:44 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak3a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hA1JEgOk2005711 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 1 Nov 2003 14:14:43 -0500 (EST) Date: Sat, 01 Nov 2003 14:14:18 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Thoughts on the draft-hinden last call Message-ID: <1377410906.1067696058@hkruse2003a> In-Reply-To: <3F9665EC.4010508@innovationslab.net> References: <3F9665EC.4010508@innovationslab.net> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=IIIII, Probability=5%, Report='IN_REP_TO, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm2) X-PMX-Start: Sat Nov 1 14:14:43 2003 X-PMX-Stop: Sat Nov 1 14:14:44 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here are my current thoughts on the last-call discussion going on regarding the unique local addressing: It seems to me that three subjects are going around: (1) There have been a few comments of the "we just don't need this type of address" kind. I respect that point of few, and firmly disagree. Further, I cannot agree with any of the scenarios that attempt to attach "they will cause damage" labels to local addresses; here is why: We have sufficient needs/requirements/scenario descriptions to reasonably deduce that network managers today, tomorrow, and in the foreseeable future will be faced with requirements that they will choose to satisfy with some form of local addressing. (The fact that many requirements can at some point in the future be addressed by better technical means does not change this statement). The strength of the Internet is its flexibility and the fact that there is no "design police" constraining deployments. If the WG defines a unique/near-unique address format for this purpose, we will at least know that the risk of prefix collisions is minimized, and we can recognize (and filter) these addresses if they leak. Without this definition, one of two things will happen: If we are really lucky, the network manager will pick the old site-local prefix. Some applications will still "know" these as different, and may behave in unexpected ways, but we can at least recognize these addresses for what they are and filter them. They cannot be traced back, and they are very likely not unique, creating all sorts of additional problems. If the network manager instead hijacks a prefix, things get really bad. If the hijacked addresses leak, you have to deal with them on a case-by-case basis, and they may collide with a legitimately assigned prefix, making debugging and filtering a nightmare. All in all, I prefer to have a recognized prefix. (2) The only technical issue seems to be address selection. (BTW, if you are tempted to reply with "we don't know how to do this so we should not create this type of address", see (1) above). We could attempt to write up suggestions for special handling of local addresses in APIs and apps, mostly based on MAY and SHOULD. On the other hand, if apps treat local addresses as global (which they are, just not routable beyond some point), these will work fine in the majority of the deployment scenarios where hosts have only one address. The mixed/multiple addressing case is where failures will happen, but we may want to simply outline the issues and let network managers and/or app designers decide if/how they want to handle these cases. In any case, lets pick an approach, write the text, and move on. (3) The registry setup seems to be the third issue. I have very little expertise in this area, but from the technical end, I think the draft needs to at a minimum: * require that IANA delegate the local prefix to one and only one registry; * require that the agreement with the registry contain an escrow provision * require that the agreement with the registry mandates a one-time fee structure * require that the agreement with the registry cap the one-time fee at a level considered by IANA to be reasonable and non-descriminatory * require that the agreement with the registry require a non-zero one time fee or an IANA-approved anti-hording mechanism if the fee is zero. Do we need anything else from a technical perspective? 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 2 00:03:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24571 for ; Sun, 2 Nov 2003 00:03:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAOp-0004pS-QK for ipv6-archive@odin.ietf.org; Sun, 02 Nov 2003 00:03:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA253d00018563 for ipv6-archive@odin.ietf.org; Sun, 2 Nov 2003 00:03:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAOp-0004pK-IN for ipv6-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 00:03:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24551 for ; Sun, 2 Nov 2003 00:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGAOn-0001sr-00 for ipv6-web-archive@ietf.org; Sun, 02 Nov 2003 00:03:37 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGAOm-0001so-00 for ipv6-web-archive@ietf.org; Sun, 02 Nov 2003 00:03:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGANH-0004ho-7T; Sun, 02 Nov 2003 00:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAMI-0004f2-4o for ipv6@optimus.ietf.org; Sun, 02 Nov 2003 00:01:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24469 for ; Sun, 2 Nov 2003 00:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGAMF-0001o9-00 for ipv6@ietf.org; Sun, 02 Nov 2003 00:00:59 -0500 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1AGAME-0001ng-00 for ipv6@ietf.org; Sun, 02 Nov 2003 00:00:59 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 5DC042B0 for ; Sun, 2 Nov 2003 00:00:28 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 02 Nov 2003 00:00:28 -0500 Message-Id: <20031102050028.5DC042B0@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.84% | 19 | 16.51% | 122278 | ftemplin@iprg.nokia.com 12.16% | 18 | 12.03% | 89104 | pekkas@netcore.fi 7.43% | 11 | 8.83% | 65437 | jrh@it.uc3m.es 6.76% | 10 | 5.66% | 41897 | erik.nordmark@sun.com 6.08% | 9 | 4.39% | 32485 | h.soliman@flarion.com 4.05% | 6 | 5.09% | 37733 | brc@zurich.ibm.com 3.38% | 5 | 2.88% | 21349 | moore@cs.utk.edu 2.70% | 4 | 3.11% | 23012 | alain.durand@sun.com 2.70% | 4 | 3.06% | 22660 | iljitsch@muada.com 2.70% | 4 | 2.59% | 19220 | alh-ietf@tndh.net 2.70% | 4 | 2.55% | 18887 | brian@innovationslab.net 2.70% | 4 | 2.24% | 16629 | suresh.krishnan@ericsson.ca 2.03% | 3 | 2.36% | 17514 | jim.bound@hp.com 2.03% | 3 | 1.92% | 14220 | huitema@windows.microsoft.com 2.03% | 3 | 1.79% | 13263 | michel@arneill-py.sacramento.ca.us 2.03% | 3 | 1.79% | 13254 | sebastien.roy@sun.com 2.03% | 3 | 1.76% | 13044 | jari.arkko@kolumbus.fi 2.03% | 3 | 1.41% | 10473 | jinmei@isl.rdc.toshiba.co.jp 1.35% | 2 | 1.45% | 10731 | greg.daley@eng.monash.edu.au 1.35% | 2 | 1.42% | 10485 | internet-drafts@ietf.org 1.35% | 2 | 1.21% | 8977 | dthaler@windows.microsoft.com 1.35% | 2 | 1.18% | 8732 | itojun@itojun.org 1.35% | 2 | 1.08% | 7995 | john.loughney@nokia.com 1.35% | 2 | 0.97% | 7194 | ipv6@c753173126e0bc8b057a22829880cf26.nosense.org 1.35% | 2 | 0.78% | 5761 | iesg-secretary@ietf.org 0.68% | 1 | 1.32% | 9762 | olnrao@samsung.com 0.68% | 1 | 1.25% | 9250 | skylane@etri.re.kr 0.68% | 1 | 0.97% | 7149 | kruse@ohio.edu 0.68% | 1 | 0.76% | 5647 | athene@sait.samsung.co.kr 0.68% | 1 | 0.72% | 5369 | gih@telstra.net 0.68% | 1 | 0.68% | 5023 | mohamed.kassilahlou@francetelecom.com 0.68% | 1 | 0.59% | 4399 | j.schoenwaelder@iu-bremen.de 0.68% | 1 | 0.58% | 4288 | stig.venaas@uninett.no 0.68% | 1 | 0.56% | 4163 | dhaskin@axiowave.com 0.68% | 1 | 0.55% | 4087 | chirayu@chirayu.org 0.68% | 1 | 0.54% | 4031 | vijayd@iprg.nokia.com 0.68% | 1 | 0.54% | 4002 | msa@burp.tkv.asdf.org 0.68% | 1 | 0.53% | 3957 | itojun@iijlab.net 0.68% | 1 | 0.49% | 3652 | tim@mentat.com 0.68% | 1 | 0.49% | 3624 | tjc@ecs.soton.ac.uk 0.68% | 1 | 0.48% | 3560 | crawdad@fnal.gov 0.68% | 1 | 0.47% | 3490 | matthew.ford@bt.com 0.68% | 1 | 0.40% | 2982 | zefram@fysh.org --------+------+--------+----------+------------------------ 100.00% | 148 |100.00% | 740769 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 2 02:02:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28829 for ; Sun, 2 Nov 2003 02:02:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGCFD-0001Oq-Sh for ipv6-archive@odin.ietf.org; Sun, 02 Nov 2003 02:01:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA271pYU005380 for ipv6-archive@odin.ietf.org; Sun, 2 Nov 2003 02:01:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGCFD-0001Oh-CN for ipv6-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 02:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28251 for ; Sun, 2 Nov 2003 02:01:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGCF9-0002wi-00 for ipv6-web-archive@ietf.org; Sun, 02 Nov 2003 02:01:47 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGCF9-0002wf-00 for ipv6-web-archive@ietf.org; Sun, 02 Nov 2003 02:01:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGCEQ-0001Ij-Ad; Sun, 02 Nov 2003 02:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGCDs-0001GE-Bc for ipv6@optimus.ietf.org; Sun, 02 Nov 2003 02:00:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26746 for ; Sun, 2 Nov 2003 02:00:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGCDo-0002wA-00 for ipv6@ietf.org; Sun, 02 Nov 2003 02:00:24 -0500 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AGCDn-0002w7-00 for ipv6@ietf.org; Sun, 02 Nov 2003 02:00:24 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3B7545FB0 for ; Sun, 2 Nov 2003 02:00:23 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 2 Nov 2003 02:00:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Authors Section on recyle clarifications to 2461and 2462 Date: Sun, 2 Nov 2003 02:00:22 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1F3@tayexc13.americas.cpqcorp.net> Thread-Topic: Authors Section on recyle clarifications to 2461and 2462 Thread-Index: AcOhDwAIqA/BfTbhTCKXsyYBgXxY0g== From: "Bound, Jim" To: X-OriginalArrivalTime: 02 Nov 2003 07:00:22.0887 (UTC) FILETIME=[FC2C1F70:01C3A10E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable As we recycle 2461 and 2462 specifications I suggest that no additional names be added to the authors names for two reasons. First its not "honorable" as nothing has been discussed nor I perceive currently will be learned that adds any architectural value of "significance" to these widely deployed and important IPv6 specifications. The current authors worked for many years and earned their names on this spec. Second I believe new editors should be put at the bottom of the spec under recycle acknowledgements per the IETF new rule to reduce author names on all specifications. My .50 cents, /jim --------------------------------------------------------- "You want to spread rumors and gossip about me? You want to question my honor and integrity? You want to insult me to my face? Okay...go right ahead. But, don't expect me to walk away. Don't expect me to take it. Hell, don't expect me to hire a lawyer to do my fighting for me. Some people are inherently peaceful. They're capable of swallowing their anger or letting the legal system take its course. Maybe they believe in some sort of Judgement Day, when we all have to account for our transgressions. Me? I am not that patient." Chuck Zito from "Street Justice"=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 00:12:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07021 for ; Mon, 3 Nov 2003 00:12:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGX0O-0004XV-W5 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 00:11:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA35BuN3017443 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 00:11:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGX0O-0004XG-O4 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 00:11:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06989 for ; Mon, 3 Nov 2003 00:11:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGX0M-0007k9-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 00:11:54 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGX0M-0007k5-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 00:11:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGWzW-0004Q6-FO; Mon, 03 Nov 2003 00:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGWzM-0004PX-O2 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 00:10:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06954; Mon, 3 Nov 2003 00:10:40 -0500 (EST) From: elizabeth.rodriguez@dothill.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGWzK-0007jk-00; Mon, 03 Nov 2003 00:10:50 -0500 Received: from mail.dothill.com ([155.254.128.7] helo=dothill.com) by ietf-mx with esmtp (Exim 4.12) id 1AGWzJ-0007jg-00; Mon, 03 Nov 2003 00:10:49 -0500 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id hA358qrT003840; Sun, 2 Nov 2003 21:08:54 -0800 (PST) Received: by exchange.artecon.com with Internet Mail Service (5.5.2653.19) id <42RVMVX4>; Sun, 2 Nov 2003 20:58:52 -0800 Message-ID: <6E76A781C4D7D511A0C000105A209B59048494DD@exchange.artecon.com> To: imss@ietf.org Cc: ipv6@ietf.org, t11_3@t11.org, cds@andiamo.com, black_david@emc.com, Margaret.Wasserman@nokia.com, bwijnen@lucent.com Subject: IMSS: Working Group last call on IPv6 over Fibre Channel Draft Date: Sun, 2 Nov 2003 20:58:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hello, I would like to announce the IETF IMSS Working Group last call on the IPv6 over Fibre Channel draft. The draft may be found at http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel- 00.txt The last call period will end at 9pm EST on Monday, November 24, 2003. Please address any technical comments to the IMSS mailing list at imss@ietf.org. Editorial comments may be made directly to the draft author, Claudio DeSanti, at cds@andiamo.com. Please copy me at elizabeth.rodriguez@dothill.com and our technical coordinators for this draft, David Black (black_david@emc.com) and Margaret Wasserman (margaret.wasserman@nokia.com). Summary: Draft: IPv6 over Fibre Channel Draft URL: http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel- 00.txt WGLC ends: Monday, November 24, 2003 at 9pm EST Technical comments to: imss@ietf.org Editorial comments to: Claudio DeSanti (cds@andiamo.org), David Black (black_david@emc.com), Margaret Wasserman (margaret.wasserman@nokia.com) and Elizabeth Rodriguez (elizabeth.rodriguez@dothill.com) Thank you, Elizabeth Rodriguez IMSS Chair IMSS Charter: http://www.ietf.org/html.charters/imss-charter.html To subscribe to the IMSS mailing list, see https://www1.ietf.org/mailman/listinfo/imss -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 01:39:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08910 for ; Mon, 3 Nov 2003 01:39:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGYN2-0008Uu-S9 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 01:39:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA36dODI032658 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 01:39:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGYN2-0008Ue-O1 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 01:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08857 for ; Mon, 3 Nov 2003 01:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGYMz-0000rB-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 01:39:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGYMy-0000r8-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 01:39:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGYMf-0008Pu-Lb; Mon, 03 Nov 2003 01:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGYLl-0008P4-DJ for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 01:38:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08839 for ; Mon, 3 Nov 2003 01:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGYLi-0000qF-00 for ipv6@ietf.org; Mon, 03 Nov 2003 01:38:02 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AGYLh-0000qB-00 for ipv6@ietf.org; Mon, 03 Nov 2003 01:38:01 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:13ff::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C62E915210; Mon, 3 Nov 2003 15:37:52 +0900 (JST) Date: Mon, 03 Nov 2003 15:37:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: j.schoenwaelder@iu-bremen.de Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-scoping-arch-00.txt In-Reply-To: <20031028144912.GA2088@iu-bremen.de> References: <20031028144912.GA2088@iu-bremen.de> 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 28 Oct 2003 15:49:12 +0100, >>>>> Juergen Schoenwaelder said: > I have reviewed and have the > following two comments: Thanks for the comments, and sorry for not responding sooner. > a) I think it would be helpful if the document would refer to > in places where it > explains why it does not cover site-local unicast addresses. I agree. > b) I have a more serious issue with the default zone. The text says in > several places that the zone index zero might be used to indicate > the default zone but it explicitely allows to use other values. In > section six, it says: > Similarly, an implementation may choose an index value other > than zero to represent the default zone. > I am not sure why this is helpful. Is there a particular reason why > we can not just say that the default zone is indicated by a zone > index which MUST (or SHOULD if we have to compromise) be zero? Hmm, from a quick re-read of the draft, I don't see a particular reason for not using a stronger word. Perhaps the intention was the choice is purely local to the node. Even so, if using a specific requirement helps the MIB work, I think it is reasonable to use a strong word. So, could you tell me the MIB document that can be clearer if we use MUST or SHOULD to specify the default zone ID? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 04:29:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24919 for ; Mon, 3 Nov 2003 04:29:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGb19-0000ew-J8 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 04:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA39SxeS002534 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 04:28:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGb19-0000en-9u for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 04:28:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24852 for ; Mon, 3 Nov 2003 04:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGb16-0002Xl-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 04:28:56 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGb16-0002Xi-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 04:28:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGb0E-0000Qq-P0; Mon, 03 Nov 2003 04:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGazi-0000PC-S1 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 04:27:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24792 for ; Mon, 3 Nov 2003 04:27:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGazf-0002WM-00 for ipv6@ietf.org; Mon, 03 Nov 2003 04:27:27 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGaze-0002Vz-00 for ipv6@ietf.org; Mon, 03 Nov 2003 04:27:26 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA39Qub29362 for ; Mon, 3 Nov 2003 11:26:56 +0200 Date: Mon, 3 Nov 2003 11:26:55 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: WGLC comments about scoping-arch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, Below are my LC comments on the scoping-arch document. In general, I think the document is in a pretty good shape, but can be improved slightly. I think it should be possible to send the document to the IESG after a revision. Two major points to note: - the ICMPv6-bis document is stalled and blocks the progress of this work as its currently written, and - in the usage examples section, we should be double careful not to give an impression that the applications should need to deal with scope indexes, etc. stuff beyond the address itself. There may be some disagreement about this in the WG, but getting a neutral rewording for "application assumptions" seems to be necessary. substantial ----------- 1) the number of authors is too many (6). No more than 5 is allowed. I'd suggest removing one, or putting everyone except the current document editor as only authors and list only one editor of the document. 2) there is some really, really weird text in section 4 about address scopes: [1] defines IPv6 addresses with embedded IPv4 addresses as part of global addresses. Thus, those addresses have global scope, with regards to the IPv6 scoped address architecture. However, an implementation may use those addresses as if they had other type of scopes for convenience. For instance, [7] assigns link-local scope to IPv4 auto-configuration addresses, and converts those addresses into IPv4-mapped IPv6 addresses in order for destination address selection among IPv4 and IPv6 addresses. This would implicitly mean IPv4-mapped addresses correspondent to IPv4 auto-configuration addresses have link-local scope. This document does not preclude such a usage, as long as it is limited within the implementation. ==> that is, there are no "IPv4 auto-configuration" addresses. This probably tries to refer to DHCP link-local addresses / zeroconf addresses, but those are actually *very* far from the intent here. Further, note that the second-last paragraph is not suitably clear about the connection of the link-local mapped addresses and the equivalent IPv4 addresses. Also note "in order for destination ...", should be "in order to perform destination...". This section is probably a result of getting rid of RFC1918 + site-local scoping, but failing to reword it appropriately. I'd suggest e.g. something like: [1] defines IPv6 addresses with embedded IPv4 addresses as part of global addresses. Thus, those addresses have global scope, with regards to the IPv6 scoped address architecture. However, an implementation may use those addresses as if they had other type of scopes for convenience. For instance, [7] assigns link-local scope to IPv4 auto-configured link-local addresses (the addresses from the prefix 169.254/16 [X]), and converts those addresses into IPv4-mapped IPv6 addresses in order to perform destination address selection among IPv4 and IPv6 addresses. This would implicitly mean the IPv4-mapped IPv6 addresses equivalent to the IPv4 link-local auto-configuration addresses have link-local scope. This document does not preclude such a usage, as long as it is limited within the implementation. .. where [X] is informational reference to: [9] S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local Addresses", Work in Progress. 3) I think this statement in section 5 needs to be spelled out a bit more: Each interface belongs to exactly one zone of each possible scope. .. that is, this could be read either as it's probably intended ("no interface must belong to more than one zone"), or as "each interface must be in a zone of each scope, even if it would have no addresses etc. from that scope". If the intent is the latter, this needs to be spelled out a bit more, if the former, a different wording should be used. 4) I'm not sure whether I see the immediate need for the unique subnet multicast scope assignment, as below: Furthermore, to avoid the need to perform manual configuration in most cases, an implementation should, by default, initially assign zone indices as follows, and only as follows: [...] o A unique subnet (multicast "scop" value 3) index for each interface ==> this seems mostly like a flawed concept anyway, because you don't really don't have a multicast "subnet" to begin with, because you don't assign multicast addresses on interfaces anyway. So, I'd consider removing this automatic default and requiring the subnet scope be configured manually. 5) In the section 7, "sending packets", IMHO it would be useful to actually describe the process of how the outgoing interface is identified, or refer to a section describing this (if it's in the default zone, no problem, but if you have e.g. two link-local interfaces....): Although identification of an outgoing interface is sufficient to identify an intended zone (because each interface is attached to no more than one zone of each scope), that is more specific than desired in many cases. 6) In the section 9, "Forwarding", I think the text about picking the destination address zone could be enhanced a bit: o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hop interface is chosen by looking up the destination address in a (conceptual) routing table specific to that zone. That routing table is restricted to refer only to interfaces belonging to that zone. ==> that is, this does not seem to spell out whether the routing table could include more than just the interfaces of destination address zone -- i.e., in the case of a global destination address, the "interfaces belonging to that zone" is a bit confusing :-) 7) In the section 9, "Forwarding", the second rule about sending an ICMP DU is specified. Has it already been considered whether this applies to multicast destination addresses as well? In the past, we've been a bit more hesitant to send replies to the source of multicast packets (e.g. consider an almost-global multicast scope that leaks and the source would get e.g. thousands of "beyond the scope" packets..) ? o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded and an ICMP Destination Unreachable message [4] with Code 2 ("beyond scope of source address") is sent to the source of the packet. 8) multicast routing in section 10 is rather weak. This is a direct resolution of switching from unicast site-locals to multicast organization-local addresses. However, with multicast addresses, it is appropriate to use the terms "prefixes" to refer to multicast traffic. The multicast routing is so different from unicast, and the term is not qualified to convey the intended message here. Some rewording is needed, maybe express this using (*,G) or (S,G) state creation where the limits are placed on the group G. [...] information on five interfaces. The information exchanged is as follows (for simplicity, multicast scopes smaller or larger than organization except global are not considered here): o Interface 1 * All global prefixes * All organization prefixes learned from Interfaces 1, 2, and 3 9) I think the EBGP peering example should be removed from section 11.4. It seems just an incredibly bad idea to use just link-locals in an IX. This would cause serious problems e.g. if someone didn't include "next-hop-self" in their config. Further, this particular problem has already been solved by making IX-based addressing available through RIR's. So, IMHO, the paragraph should be removed: Another example is an EBGP peering. When two IPv6 ISPs establish an EBGP peering, using a particular ISP's global addresses for the peer would be unfair, and using their link-local addresses would be better in a neutral IX. In such a case, link-local addresses should be specified in a router's configuration file and the link for the addresses should be disambiguated, since a router usually connects to multiple links. 10) Similar bad ideas are described in section 11.7, about how to use IPv6 addresses in URL's. The text seems to say that the apps should then strip the zone index and be able to parse it.. This would imply that apps handling URL's should be made aware of link-local addresses and the zone index parsing. This seems like a very, very wrong way to go: The preferred format for literal IPv6 addresses in URL's are also defined [9]. When a user types the preferred format for an IPv6 non- global address whose zone should be explicitly specified, the user could use the format for the non-global address combined with the preferred format. However, the typed URL is often sent on a wire, and it would cause confusion if an application did not strip the portion before sending. Also, the format for non-global addresses might conflict with the URI syntax [10], since the syntax defines the delimiter character (%') as the escape character. Hence, this document does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses. As for the conflict issue with the URI format, it would be better to wait until the relationship between the preferred format and the URI syntax is clarified. In fact, the preferred format for IPv6 literal addresses itself has same kind of conflict. In any case, it is recommended to use an FQDN instead of a literal IPv6 address in a URL, whenever an FQDN is available. ==> suggestion either revise the text significantly or add reword the middle sentence: However, the typed URL is often sent on a wire, and it would cause confusion if an application did not strip the portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the portion of the address. Also, the format for non-global addresses might conflict with the URI syntax [10], since the syntax defines the delimiter character (%') as the escape character. 11) Note that there is a normative reference to the ICMPv6-bis document, which has been pretty much stalled for the last 2 years or so. This document cannot be published before ICMPv6-bis is also published. The ICMPv6-bis seems integral to this specification, so I think the options are either to revise the text about sending ICMP DU "beyond the scope of source address" messages (removing it), or kicking off the effort for getting ICMPv6-bis out of the door: [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for the Internet Protocol Version 6 (IPv6)", Internet Draft draft- ietf-ipngwg-icmp-v3-02.txt, November 2001. editorial --------- Though the current specification [1] defines unicast site-local addresses, the IPv6 working group decided to deprecate the syntax and ==> s/current/current address architecture/ (to be clear not to confuse with this spec :-) The terms link, interface, node, host, and router are defined in [3]. The definitions of unicast address scopes (link-local and global) and multicast address scopes (interface-local, link-local, etc.) are contained in [1]. ==> I'd try to find a different word than "contained", but that's ~OK as well. Two interfaces to the same Ethernet, ==> s/Ethernet/Ethernet link/ o The zone of the new destination address is determined by the scope of the next address in the Routing Header and arrival interface of the packet. The next-hop interface is chosen just like the first bullet of the rules above. ==> reword to something like below, to spell out what the next address was: (also, add "the" before arrival): o The zone of the new destination address is determined by the scope of the next address in the Routing Header (the original destination address of the received packet) and the arrival interface of the packet. The next-hop interface is chosen just like the first bullet of the rules above. ... Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary. ==> I'd be a bit more explicit than this.. the convey in this case means that a link-local address is encapsulated in the "next address" field but is not going to be used. Try e.g.: Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary in the previously-used next address field, similar as one can convey the information in the protocol payloads as well. (could also omit from "similar.." not sure if that's good..) ... For example, consider a case where a link-border node (e.g., a router) receives a packet with the destination being a link- local address. ==> continute the last sentence like: local address, and the source address a global address. Note: since unicast site-local addresses are deprecated, and link- local addresses does not need routing, the discussion in this section ==> s/does/do/ o Interface 3 * All global prefixes * All organization prefixes learned from Interface 1, 2, and 3 ==> s/Interface/Interfaces/ identify a particular zone of the address' scope. Although a zone ==> s/address'/address's/ When an implementation interprets the format, it should construct the "full" zone ID, which contains the scope type, from the part and the scope type specified by the
part. ==> unless I have completely misunderstood the spec, the first "scope type" should actually be "scope zone" :-) Here is a concrete example. Consider a multi-linked router, called "R1", that has at least two point-to-point interfaces (links). Each of the interfaces is connected to another router, called "R2" and "R3", respectively. Also assume that the point-to-point interfaces are "unnumbered", that is, they have link-local addresses only. ==> this is an "ipv6-centric" definition of unnumbered. Classically, unnumbered interfaces have no addresses *at all*. So, I'd use a different wording than "unnumbered", or maybe "globally unnumbered" would be good enough even though it sounds odd.. here, since R1 has more than one link and hence the telnet command cannot detect which link it should try to connect. Instead, we should type the link-local address with the link index as follows: ==> s/try to connect/try to use for connecting/ !! (one doesn't connect to a link.. :-) -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 05:20:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26257 for ; Mon, 3 Nov 2003 05:20:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbol-0003XM-GL for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 05:20:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3AKFM7013597 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 05:20:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGbol-0003XB-2U for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 05:20:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26214 for ; Mon, 3 Nov 2003 05:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGboh-0003BV-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 05:20:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGboh-0003BP-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 05:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGboY-0003RC-N8; Mon, 03 Nov 2003 05:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGboV-0003QW-6k for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 05:19:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26202 for ; Mon, 3 Nov 2003 05:19:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGboR-0003B9-00 for ipv6@ietf.org; Mon, 03 Nov 2003 05:19:55 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AGboR-0003Ar-00 for ipv6@ietf.org; Mon, 03 Nov 2003 05:19:55 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA3AJiXO019081; Mon, 3 Nov 2003 12:19:44 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) id hA3AJi0S019077; Mon, 3 Nov 2003 12:19:44 +0200 Date: Mon, 3 Nov 2003 12:19:44 +0200 Message-Id: <200311031019.hA3AJi0S019077@burp.tkv.asdf.org> From: Markku Savela To: pekkas@netcore.fi CC: ipv6@ietf.org In-reply-to: (message from Pekka Savola on Mon, 3 Nov 2003 11:26:55 +0200 (EET)) Subject: Re: WGLC comments about scoping-arch References: Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Minor comment on comments.. > From: Pekka Savola > 4) I'm not sure whether I see the immediate need for the unique subnet > multicast scope assignment, as below: > > Furthermore, to avoid the need to perform manual configuration in > most cases, an implementation should, by default, initially assign > zone indices as follows, and only as follows: > [...] > o A unique subnet (multicast "scop" value 3) index for each > interface > > ==> this seems mostly like a flawed concept anyway, because you don't really > don't have a multicast "subnet" to begin with, because you don't assign > multicast addresses on interfaces anyway. So, I'd consider removing this > automatic default and requiring the subnet scope be configured manually. I need this default, because I have zone ids are implemented as an array of 16 id's on the interface, and each much have sensible default, without requiring manual configuration (yes, the delivered code has full support of site locals, or any other scope you might want). This may be left as implementation issue, but any text with "MUST" and manual configuration won't do. Besides, I'm experimenting with a kind of "multilink subnets", and I'm using this scope to indicate group of interfaces that need to be "bridged". Thus, the subnet index must by default be different, or bridging starts to happen... (if I manage to get it to work :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 05:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26670 for ; Mon, 3 Nov 2003 05:34:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc2L-0004MS-8e for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 05:34:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3AYHkU016760 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 05:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc2L-0004MF-1D for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 05:34:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26634 for ; Mon, 3 Nov 2003 05:34:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc2H-0003NS-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 05:34:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGc2H-0003NP-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 05:34:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc25-0004GT-CD; Mon, 03 Nov 2003 05:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGc1F-0004Fc-Cc for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 05:33:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26617 for ; Mon, 3 Nov 2003 05:32:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc1B-0003Mn-00 for ipv6@ietf.org; Mon, 03 Nov 2003 05:33:05 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGc1B-0003MR-00 for ipv6@ietf.org; Mon, 03 Nov 2003 05:33:05 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA3AWZg30177 for ; Mon, 3 Nov 2003 12:32:36 +0200 Date: Mon, 3 Nov 2003 12:32:35 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: Re: WGLC comments about scoping-arch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Clarifying two comments (maybe I should have proof-read them more carefully).. On Mon, 3 Nov 2003, Pekka Savola wrote: > 7) In the section 9, "Forwarding", the second rule about sending an ICMP DU > is specified. Has it already been considered whether this applies to > multicast destination addresses as well? In the past, we've been a bit more > hesitant to send replies to the source of multicast packets (e.g. consider > an almost-global multicast scope that leaks and the source would get e.g. > thousands of "beyond the scope" packets..) ? > > o After the next-hop interface is chosen, the zone of the source > address is considered. As with the destination address, the zone > of the source address is determined by the scope of the address > and arrival interface of the packet. If transmitting the packet > on the chosen next-hop interface would cause the packet to leave > the zone of the source address, i.e., cross a zone boundary of the > scope of the source address, then the packet is discarded and an > ICMP Destination Unreachable message [4] with Code 2 ("beyond > scope of source address") is sent to the source of the packet. Actually, the scenario I described above should not be a problem, as this bullet is about the scope of the _source_ address, not the destination address.. and as the only non-global source address is the link-local, sending back a message should not be a problem. Could still be spelled out explicitly though.. > 8) multicast routing in section 10 is rather weak. This is a direct > resolution of switching from unicast site-locals to multicast > organization-local addresses. However, with multicast addresses, it is > appropriate to use the terms "prefixes" to refer to multicast traffic. The this should have been "it is *NOT* appropriate".. .. sorry.. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 08:03:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00343 for ; Mon, 3 Nov 2003 08:02:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeLu-0003b6-Au for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 08:02:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3D2cGs013822 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 08:02:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeLu-0003ar-5O for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 08:02:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00308 for ; Mon, 3 Nov 2003 08:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGeLt-0005Ai-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:02:37 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGeLs-0005Af-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:02:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeLK-0003Q6-Sv; Mon, 03 Nov 2003 08:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeKP-0003PT-3h for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 08:01:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00239 for ; Mon, 3 Nov 2003 08:00:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGeKO-00058s-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:01:04 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AGeKN-00058f-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:01:03 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id CCA1B7B5F2; Mon, 3 Nov 2003 14:00:31 +0100 (CET) Received: from james (unknown [212.201.47.4]) by merkur.iu-bremen.de (Postfix) with ESMTP id 17D711AD17; Mon, 3 Nov 2003 14:00:30 +0100 (CET) Received: by james (Postfix, from userid 1000) id 201408517; Mon, 3 Nov 2003 14:00:28 +0100 (CET) Date: Mon, 3 Nov 2003 14:00:28 +0100 From: Juergen Schoenwaelder To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-scoping-arch-00.txt Message-ID: <20031103130028.GA2238@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , ipv6@ietf.org References: <20031028144912.GA2088@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, Nov 03, 2003 at 03:37:47PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > > I am not sure why this is helpful. Is there a particular reason why > > we can not just say that the default zone is indicated by a zone > > index which MUST (or SHOULD if we have to compromise) be zero? > > Hmm, from a quick re-read of the draft, I don't see a particular > reason for not using a stronger word. Perhaps the intention was the > choice is purely local to the node. Even so, if using a specific > requirement helps the MIB work, I think it is reasonable to use a > strong word. So, could you tell me the MIB document that can be > clearer if we use MUST or SHOULD to specify the default zone ID? The document in question is and it says in several places that 0 refers to the default zone. It would be nice if the scoping architecture could actually back this up by at least saying the default zone SHOULD be identified by the zone index 0. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 08:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00732 for ; Mon, 3 Nov 2003 08:17:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeZx-0004RZ-4B for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 08:17:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3DH9MC017075 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 08:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeZw-0004RK-TV for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 08:17:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00701 for ; Mon, 3 Nov 2003 08:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGeZv-0005LR-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:17:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGeZv-0005LO-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeZq-0004Nh-3k; Mon, 03 Nov 2003 08:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeZL-0004MC-PY for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 08:16:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00667 for ; Mon, 3 Nov 2003 08:16:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGeZK-0005Kt-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:16:30 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AGeZJ-0005KG-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:16:30 -0500 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 hA3DFwV17874; Mon, 3 Nov 2003 05:15:58 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hA3DJ7tX002049 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 3 Nov 2003 05:19:10 -0800 Message-ID: <3FA654D1.4070509@innovationslab.net> Date: Mon, 03 Nov 2003 08:14:57 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: "JINMEI Tatuya / ?$B?@L@C#:H" , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-scoping-arch-00.txt References: <20031028144912.GA2088@iu-bremen.de> <20031103130028.GA2238@iu-bremen.de> In-Reply-To: <20031103130028.GA2238@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Juergen's suggestion as well. The scoped addr arch should mandate the use of 0 as the default zone ID. Brian Juergen Schoenwaelder wrote: > On Mon, Nov 03, 2003 at 03:37:47PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>> I am not sure why this is helpful. Is there a particular reason why >>> we can not just say that the default zone is indicated by a zone >>> index which MUST (or SHOULD if we have to compromise) be zero? >> >>Hmm, from a quick re-read of the draft, I don't see a particular >>reason for not using a stronger word. Perhaps the intention was the >>choice is purely local to the node. Even so, if using a specific >>requirement helps the MIB work, I think it is reasonable to use a >>strong word. So, could you tell me the MIB document that can be >>clearer if we use MUST or SHOULD to specify the default zone ID? > > > The document in question is and > it says in several places that 0 refers to the default zone. It would > be nice if the scoping architecture could actually back this up by at > least saying the default zone SHOULD be identified by the zone index 0. > > /js > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 08:22:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00897 for ; Mon, 3 Nov 2003 08:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeen-00054f-OF for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 08:22:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3DM9eQ019499 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 08:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeen-00054Q-JT for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 08:22:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00859 for ; Mon, 3 Nov 2003 08:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGeem-0005O8-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:22:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGeem-0005O5-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGeef-0004vs-Tt; Mon, 03 Nov 2003 08:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGedl-0004vX-W8 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 08:21:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00854 for ; Mon, 3 Nov 2003 08:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGedk-0005O1-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:21:04 -0500 Received: from october.skynet.be ([195.238.3.58]) by ietf-mx with esmtp (Exim 4.12) id 1AGedk-0005Ny-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:21:04 -0500 Received: from tsn (29.208-201-80.adsl.skynet.be [80.201.208.29]) by october.skynet.be (8.12.9/8.12.9/Skynet-OUT-2.21) with ESMTP id hA3DKuon004295 for ; Mon, 3 Nov 2003 14:20:56 +0100 (envelope-from ) Message-Id: <200311031320.hA3DKuon004295@october.skynet.be> From: "Mario Goebbels" To: Subject: Subnetting question Date: Mon, 3 Nov 2003 14:20:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Thread-Index: AcOiDUcEbndWcBVmRxq3NSTWRq8/jA== X-RAVMilter-Version: 8.4.3(snapshot 20030212) (october.skynet.be) Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi! I need a clarification on the question if I can use the very first = subnet in a network. Means if I would get assigned 2001:1234:5678::/48 from a RIR, if I can = use 2001:1234:5678:0::/64 within my own network, or if the same rules as = in IPv4 subnetting apply (first and last one aren't usable). Thanks -mg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 08:59:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02030 for ; Mon, 3 Nov 2003 08:59:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfEi-0006bQ-L0 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 08:59:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3DxGl5025378 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 08:59:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfEi-0006bF-Ay for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 08:59:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01966 for ; Mon, 3 Nov 2003 08:59:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfEg-0005uA-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:59:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGfEg-0005u7-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 08:59:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfEU-0006Sa-5W; Mon, 03 Nov 2003 08:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfER-0006SL-1S for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 08:58:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01961 for ; Mon, 3 Nov 2003 08:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfEP-0005u0-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:58:57 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AGfEO-0005tZ-00 for ipv6@ietf.org; Mon, 03 Nov 2003 08:58:56 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA3DwEls013541; Mon, 3 Nov 2003 22:58:15 +0900 (KST) Message-ID: <02b601c3a213$9dde8470$ec2f024b@tyre> From: "JinHyeock Choi" To: "Soliman Hesham" , "'Pekka Savola'" Cc: References: <748C6D0A58C0F94CA63C198B6674697A01922E4B@ftmail.lab.flarion.com> Subject: Re: RFC 2461- issue list: Prefixes with L=0 Date: Mon, 3 Nov 2003 23:06:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBIZXNoYW0NCg0KU29tZXRoaW5nIGFib3V0IHByZWZpeGVzIHdpdGggTD0wIGFyZSBjb25m dXNpbmcgdG8gbWUuIEtpbmRseSBzZWUNCmJlbG93LiAgDQoNCjEuIFRoZSBwcmVmaXhlcyB3aXRo IEwgYml0IG9mZi4gDQotIFRoZSBtZWFuaW5nLyBwdXJwb3NlIG9mIHByZWZpeGVzIHdpdGggTD0w IGlzIG5vdCBleGFjdGx5IGNsZWFyIA0KICAgdG8gbWUuIFdoYXQncyB0aGUgdXNlIG9mIG5vbi1v bi1saW5rIHByZWZpeGVzIGZvciBhIG5vZGU/IA0KDQoyLiBUaGUgcHJlZml4ZXMgYXNzaWduZWQg dG8gbW9yZSB0aGFuIG9uZSBsaW5rcy4NCi0gQWNjb3JkaW5nIHRvIFJGQyAyNDYxLCBpdCdzIGxl Z2l0aW1hdGUgdG8gYXNzaWduIGEgcHJlZml4ICh3aXRoIEw9MCkgDQogICB0byB0d28gc2VwYXJh dGUgbGlua3MuIEJ1dCBpdCdzIG5vdCBjbGVhciB0byBtZSBvbiB3aGF0IGNvbmRpdGlvbiANCiAg IGNhbiB3ZSBkbyB0aGlzLiAgIA0KDQogSSB3aXNoIHdlIGNsYXJpZnkgdGhlIGFib3ZlLiBUaGUg cHJlZml4ZXMgd2l0aCBMPTAgbWFrZXMgRE5BIHdvcmsgDQpjb21wbGljYXRlZC4gVGhvdWdoIHRo ZXkgYXJlIHRyb3VibGVzb21lLCBJIGFtIGFmcmlhZCB0aGF0LCBpbiB3aXJlbGVzcw0KZW52aXJv bm1lbnQsIHdlIGNhbid0IGF2b2lkIHRoZW0uDQoNCkJlc3QgcmVnYXJkcw0KDQpKaW5IeWVvY2sN Cg0K -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 09:13:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02495 for ; Mon, 3 Nov 2003 09:13:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfSH-0007qW-NS for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 09:13:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3EDH2f030154 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 09:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfSH-0007qH-J0 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 09:13:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02445 for ; Mon, 3 Nov 2003 09:13:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfSG-00066B-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 09:13:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGfSF-000668-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 09:13:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfS1-0007kc-VN; Mon, 03 Nov 2003 09:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfRg-0007kK-K3 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 09:12:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02419 for ; Mon, 3 Nov 2003 09:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfRf-00065p-00 for ipv6@ietf.org; Mon, 03 Nov 2003 09:12:39 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AGfRe-00065j-00 for ipv6@ietf.org; Mon, 03 Nov 2003 09:12:38 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Nov 2003 09:12:04 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E67@ftmail.lab.flarion.com> From: Soliman Hesham To: "'JinHyeock Choi'" , "'Pekka Savola'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list: Prefixes with L=0 Date: Mon, 3 Nov 2003 09:11:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Something about prefixes with L=0 are confusing to me. Kindly see > below. > > 1. The prefixes with L bit off. > - The meaning/ purpose of prefixes with L=0 is not exactly clear > to me. What's the use of non-on-link prefixes for a node? > > 2. The prefixes assigned to more than one links. > - According to RFC 2461, it's legitimate to assign a prefix > (with L=0) > to two separate links. But it's not clear to me on what condition > can we do this. => Actually, I think the L flag is a really powerful feature. Basically when it indicates that a prefix is not on-link it is informing hosts that they should send their traffic to the default router. This is useful for the case you mentioned where a prefix is assigned to more than one link (e.g. multi-link subnets/ND proxying devices). > > I wish we clarify the above. The prefixes with L=0 makes DNA work > complicated. Though they are troublesome, I am afriad that, > in wireless > environment, we can't avoid them. => If it is found that in some deployment cases the L=0 causes problems, the network admin is free to configure the routers accordingly and always use on-link prefixes. This is completely under the control of the admin. I think Fred Templin sent a question some time ago on this and Thomas explained how hosts should handle the case where the L flag is set to zero. We can add this clarification in the new revision if that helps. If there are other scenarios where this is problematic please send them to the list. Thanks, Hesham > > Best regards > > JinHyeock > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 09:36:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03536 for ; Mon, 3 Nov 2003 09:36:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfoS-0000Uj-OG for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 09:36:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3EaCGQ001902 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 09:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfoS-0000Ub-CU for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 09:36:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03487 for ; Mon, 3 Nov 2003 09:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfoQ-0006UK-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 09:36:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGfoQ-0006UG-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 09:36:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfoJ-0000Qm-7l; Mon, 03 Nov 2003 09:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfnr-0000QC-Jm for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 09:35:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03482 for ; Mon, 3 Nov 2003 09:35:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfnp-0006U7-00 for ipv6@ietf.org; Mon, 03 Nov 2003 09:35:33 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AGfno-0006U0-00 for ipv6@ietf.org; Mon, 03 Nov 2003 09:35:33 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA3EYmls016354; Mon, 3 Nov 2003 23:34:48 +0900 (KST) Message-ID: <02e001c3a218$b918a220$ec2f024b@tyre> From: "JinHyeock Choi" To: "Soliman Hesham" , "'Pekka Savola'" Cc: References: <748C6D0A58C0F94CA63C198B6674697A01922E67@ftmail.lab.flarion.com> Subject: Re: RFC 2461- issue list: Prefixes with L=0 Date: Mon, 3 Nov 2003 23:42:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBIZXNpYW0NCg0KVGhhbmtzIGZvciB5b3VyIHByb21wdCByZXBseS4gDQoNCj4gPT4gQWN0 dWFsbHksIEkgdGhpbmsgdGhlIEwgZmxhZyBpcyBhIHJlYWxseSBwb3dlcmZ1bCBmZWF0dXJlLg0K PiBCYXNpY2FsbHkgd2hlbiBpdCBpbmRpY2F0ZXMgdGhhdCBhIHByZWZpeCBpcyBub3Qgb24tbGlu aw0KPiBpdCBpcyBpbmZvcm1pbmcgaG9zdHMgdGhhdCB0aGV5IHNob3VsZCBzZW5kIHRoZWlyIHRy YWZmaWMNCj4gdG8gdGhlIGRlZmF1bHQgcm91dGVyLiBUaGlzIGlzIHVzZWZ1bCBmb3IgdGhlIGNh c2UgeW91IG1lbnRpb25lZA0KDQpJZiB0aGUgcHVycG9zZSBvZiBwcmVmaXhlcyB3aXRoIEw9MCBp cyB0byBpbmZvcm0gaG9zdHMgdG8gc2VuZCB0cmFmZmljIA0KdG8gdGhlIGRlZmF1bHQgcm91dGVy LCB3aHkgbm90IG9taXQgdGhvc2UgcHJlZml4ZXMgYWx0b2dldGhlciBmcm9tIA0KUkFzLiBIb3N0 IHdpbGwgc2VuZCB0aGUgcGFja2V0cyBkZXN0aW5lZCB0byB1bmtub3duIHByZWZpeGVzIHRvIGEg DQpkZWZhdWx0IHJvdXRlciBhbnl3YXkuICANCiANCj4gPT4gSWYgaXQgaXMgZm91bmQgdGhhdCBp biBzb21lIGRlcGxveW1lbnQgY2FzZXMgdGhlIEw9MCANCj4gY2F1c2VzIHByb2JsZW1zLCB0aGUg bmV0d29yayBhZG1pbiBpcyBmcmVlIHRvIGNvbmZpZ3VyZQ0KPiB0aGUgcm91dGVycyBhY2NvcmRp bmdseSBhbmQgYWx3YXlzIHVzZSBvbi1saW5rIHByZWZpeGVzLg0KPiBUaGlzIGlzIGNvbXBsZXRl bHkgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGFkbWluLiANCg0KSSB3b25kZXIgdGhhdCB0aGVy ZSBtYXkgYmUgc29tZSB3aXJlbGVzcyBsaW5rcyBvbiB3aGljaCBhZG1pbiBjYW4ndCANCmFzc2ln biBvbi1saW5rIHByZWZpeGVzLiBGb3IgZXhhbXBsZSwgYSBsaW5rIHdpdGggaGlkZGVuIG5vZGUg cHJvYmxlbSANCmxpa2UgODAyLjExIGIgYWQtaG9jIG1vZGUgb3IgYmx1ZXRvb3RoLiAgDQoNCj4g SSB0aGluayBGcmVkIFRlbXBsaW4gc2VudCBhIHF1ZXN0aW9uIHNvbWUgdGltZSBhZ28NCj4gb24g dGhpcyBhbmQgVGhvbWFzIGV4cGxhaW5lZCBob3cgaG9zdHMgc2hvdWxkIGhhbmRsZSB0aGUNCj4g Y2FzZSB3aGVyZSB0aGUgTCBmbGFnIGlzIHNldCB0byB6ZXJvLiBXZSBjYW4gYWRkIHRoaXMgY2xh cmlmaWNhdGlvbg0KPiBpbiB0aGUgbmV3IHJldmlzaW9uIGlmIHRoYXQgaGVscHMuDQogDQpGcmVk IFRlbXBsaW4gcmFpc2VkIHRoZSBpc3N1ZSB3aGV0aGVyIGl0J3MgcG9zc2libGUgdG8gYWR2ZXJ0 aXNlIGEgcHJlZml4IA0Kd2l0aCBMPTAgYW5kIEE9MSBhbmQgVGhvbWFzIHNhaWQgc28uIElzIHRo aXMgd2hhdCB5b3UgaGF2ZSBpbiBtaW5kPyANCkFuZCBJIHRoaW5rIHRoZSBwcmVmaXggd2l0aCBM PTAgYW5kIEE9MSBtYXkgY2F1c2UgdW5ub3RpY2VkIGFkZHJlc3MgDQpkdXBsaWNhdGlvbi4gDQoN CkJlc3QgcmVnYXJkcw0KDQpKaW5IeWVvY2sNCg0K -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 09:42:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03825 for ; Mon, 3 Nov 2003 09:42:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfuJ-0001HF-44 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 09:42:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3EgFKD004903 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 09:42:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfuI-0001H0-Vn for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 09:42:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03766 for ; Mon, 3 Nov 2003 09:42:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfuD-0006ZF-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 09:42:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGfuD-0006ZB-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 09:42:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfu5-00018R-Ta; Mon, 03 Nov 2003 09:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGftp-00017t-9w for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 09:41:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03743 for ; Mon, 3 Nov 2003 09:41:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGftn-0006Ys-00 for ipv6@ietf.org; Mon, 03 Nov 2003 09:41:43 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AGftn-0006Yp-00 for ipv6@ietf.org; Mon, 03 Nov 2003 09:41:43 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B4D35142C0; Mon, 3 Nov 2003 09:41:42 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21296-07; Mon, 3 Nov 2003 09:41:41 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id D7E3B142B4; Mon, 3 Nov 2003 09:41:40 -0500 (EST) Date: Mon, 3 Nov 2003 08:36:50 -0500 From: Keith Moore To: Pekka Savola Cc: moore@cs.utk.edu, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031103083650.67297afd.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Having looked at this again, I'm firmly convinced that: - if address family is set to AF_UNSPEC, getaddrinfo() should by default attempt both IPv4 and IPv6 lookups - even if the local system is not capable of communicating on both IPv4 and IPv6. it can be useful to do A lookups even if the local system doesn't support IPv4, and it can be useful to do AAAA lookups even if the local system doesn't support IPv6. the job of an API is to do what the application tells it to do, not to guess what the application needs. when getaddrinfo() tries to be too clever (as it does on some platforms) it gets in the way and makes it difficult just to do simple DNS lookups. this implies that a feature to avoid A or AAAA lookups on systems that cannot communicate on v4 or v6 (respectively) should be optional, as AI_ADDRCONFIG is. - It's highly desirable to avoid unnecessary DNS queries. DNS is too slow and unreliable for single queries; multiple queries only makes this worse. There are various ways that DNS could be updated to return the same information in fewer round-trips, but none of them would obviate the need for hosts to do multiple concurrent queries in the near term. - AI_ADDRCONFIG is an imperfect heuristic, not a reliable indicator of whether an address can be used. that doesn't mean that it's useless, but it does mean that people need to be aware of its limitations and not rely on it to do magic - in particular, it will not do a perfect job of either avoiding unnecessary lookups and connection attempts, or (due to race conditions) of finding all usable addresses. - getaddrinfo SHOULD ONLY DO DNS QUERIES. LLMNR/mDNS, NIS/NIS+, netinfo, WINS and local file lookups only serve to cause divergence between platforms and problems for apps that need a consistent view of DNS. (Note: I don't expect to get consensus for this view, so I'll offer a less radical view: Apps whose behavior is defined based on "what DNS says", rather than some other name lookup service, need a portable and reliable way to find out "what DNS says" without having to supply their own DNS lookup routines. e.g. maybe there needs to be a AI_DNS_ONLY flag for getaddrinfo?) - if AI_ADDRCONFIG is set, the decision of whether to do DNS lookups for a particular address family should ignore link-local addresses as well as loopback addresses. This is in keeping with the notion that AI_ADDRCONFIG is an imperfect heuristic. The configuration of only link-local addresses for a particular address family is a good (though imperfect) indicator that DNS queries for that address family will not yield usable results. OTOH, if getaddrinfo() is set up (against my better judgement) to do queries from services other than DNS, the choice of whether to query other services might not want to ignore link-local addresses. For example, on a host with only a v4 link-local address configured it might make sense to query LLMNR for A records. - IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to coerce apps into behaving well. So even though apps shouldn't be using link-local addresses, and even though people shouldn't list link-local addresses in DNS, getaddrinfo() should not try to hide such addresses from apps if they happen to appear in DNS. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 10:18:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06519 for ; Mon, 3 Nov 2003 10:18:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgTN-0003F1-Ro for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 10:18:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3FITZR012458 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 10:18:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgTN-0003Er-MQ for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 10:18:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06490 for ; Mon, 3 Nov 2003 10:18:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgTL-00076s-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 10:18:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGgTL-00076p-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 10:18:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgSw-00037a-Ds; Mon, 03 Nov 2003 10:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgRy-00035p-JY for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 10:17:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06336 for ; Mon, 3 Nov 2003 10:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgRw-00075M-00 for ipv6@ietf.org; Mon, 03 Nov 2003 10:17:00 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AGgRv-00075G-00 for ipv6@ietf.org; Mon, 03 Nov 2003 10:16:59 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id hA3FGQpI032667; Mon, 3 Nov 2003 16:16:26 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hA3FGQR7021499; Mon, 3 Nov 2003 16:16:26 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hA3FGQDI021498; Mon, 3 Nov 2003 16:16:26 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 3 Nov 2003 16:16:26 +0100 From: Stig Venaas To: Keith Moore Cc: Pekka Savola , v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031103151626.GB21430@sverresborg.uninett.no> References: <20031103083650.67297afd.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031103083650.67297afd.moore@cs.utk.edu> User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , [...] > - IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to > coerce apps into behaving well. So even though apps shouldn't be using > link-local addresses, and even though people shouldn't list link-local > addresses in DNS, getaddrinfo() should not try to hide such addresses from > apps if they happen to appear in DNS. I can sympathize with your opinions. I think two things are needed: o A standard call that most applications can use in a simple way. IMHO it should query DNS, other name services, /etc/hosts etc. o A standard call that applications can use to check what is in DNS The first should IMHO be something like getaddrinfo() where applications simply try the addresses in the order they are returned. I also think it should be possible for an administrator to define which name services should be used, which type of addresses should be returned, and the order. Another matter is what the API should be. Most IPv6 enabled applications today use getaddrinfo(), while specialized DNS applications like "host" use their own resolver routines. So I would say that getaddrinfo() without special arguments would be good for the general applications. For the DNS applications one could use getaddrinfo() with a new option, or a completely new call. It's easier to change the few DNS applications that are out there. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 10:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07608 for ; Mon, 3 Nov 2003 10:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGguD-0005Cp-LL for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 10:46:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3FkDgK020009 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 10:46:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGguD-0005CU-FU for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 10:46:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07563 for ; Mon, 3 Nov 2003 10:46:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGguB-0007W7-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 10:46:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGguA-0007W4-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 10:46:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgu2-00056n-71; Mon, 03 Nov 2003 10:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgtJ-00055k-Ca for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 10:45:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07528 for ; Mon, 3 Nov 2003 10:45:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgtG-0007VA-00 for ipv6@ietf.org; Mon, 03 Nov 2003 10:45:14 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AGgtG-0007V7-00 for ipv6@ietf.org; Mon, 03 Nov 2003 10:45:14 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5F1AF142D6; Mon, 3 Nov 2003 10:45:14 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29204-03; Mon, 3 Nov 2003 10:45:13 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id BF92214240; Mon, 3 Nov 2003 10:45:12 -0500 (EST) Date: Mon, 3 Nov 2003 10:42:02 -0500 From: Keith Moore To: Stig Venaas Cc: moore@cs.utk.edu, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031103104202.08e7a1a3.moore@cs.utk.edu> In-Reply-To: <20031103151626.GB21430@sverresborg.uninett.no> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [...] > > - IMHO, getaddrinfo()'s job should be to report what is in DNS, not > > to try to > > coerce apps into behaving well. So even though apps shouldn't be > > using link-local addresses, and even though people shouldn't list > > link-local addresses in DNS, getaddrinfo() should not try to hide > > such addresses from apps if they happen to appear in DNS. > > I can sympathize with your opinions. I think two things are needed: > > o A standard call that most applications can use in a simple way. IMHO > it should query DNS, other name services, /etc/hosts etc. > > o A standard call that applications can use to check what is in DNS > > The first should IMHO be something like getaddrinfo() where > applications simply try the addresses in the order they are returned. I don't think that we should be defining getaddrinfo() in terms of "whatever lookup service happens to be around" because it's very difficult to get reliable and repeatable behavior that way. > I also think it > should be possible for an administrator to define which name services > should be used, which type of addresses should be returned, and the > order. I disagree. Different apps have different needs, and no single host-wide or site-wide policy can accomodate the needs of the variety of apps in use. Also, apps often cross administrative boundaries, which creates problems when different nodes of those apps are subjected to the whims of different administrators. > Another matter is what the API should be. Most IPv6 enabled > applications today use getaddrinfo(), while specialized DNS > applications like "host" use their own resolver routines. It's not just specalized DNS applications that need to know what really is in DNS. Many apps need consistent views of DNS without having to second-guess the local host API implementation, brain-damaged sysadmins, etc. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 11:46:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09874 for ; Mon, 3 Nov 2003 11:46:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGhqU-0000J9-O6 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 11:46:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3GkQbo001177 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 11:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGhqU-0000Iu-Hq for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 11:46:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09833 for ; Mon, 3 Nov 2003 11:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGhqT-0000bX-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 11:46:25 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGhqT-0000bU-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 11:46:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGhq6-0000Ct-KV; Mon, 03 Nov 2003 11:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGhpS-0000Bx-Og for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 11:45:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09788 for ; Mon, 3 Nov 2003 11:45:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGhpQ-0000aU-00 for ipv6@ietf.org; Mon, 03 Nov 2003 11:45:20 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AGhpP-0000aR-00 for ipv6@ietf.org; Mon, 03 Nov 2003 11:45:19 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3GjHPh009179; Mon, 3 Nov 2003 09:45:18 -0700 (MST) Received: from lillen (vpn-129-156-97-50.EMEA.Sun.COM [129.156.97.50]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA3GjFS20499; Mon, 3 Nov 2003 17:45:15 +0100 (MET) Date: Mon, 3 Nov 2003 16:08:43 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Thoughts on the draft-hinden last call To: Hans Kruse Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <1377410906.1067696058@hkruse2003a> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Do we need anything else from a technical perspective? I think I and Keith Moore commented on the application impact, and to the extent that the current document doesn't state the application impact very accurately. Once that application impact is better known one could and should discuss the cost/benefit tradeoffs. Since you missed the above rather major point, I wouldn't be surprised if your summary misses other points that have been made. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 12:48:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12325 for ; Mon, 3 Nov 2003 12:48:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGioW-0003zG-9k for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 12:48:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3HmSR8015320 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 12:48:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGioW-0003z1-3K for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 12:48:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12274 for ; Mon, 3 Nov 2003 12:48:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGioU-0001c6-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 12:48:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGioU-0001c3-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 12:48:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGio5-0003pH-QA; Mon, 03 Nov 2003 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGiAG-0001VK-H8 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 12:06:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10871 for ; Mon, 3 Nov 2003 12:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGiAF-00010N-00 for ipv6@ietf.org; Mon, 03 Nov 2003 12:06:51 -0500 Received: from castlerea.stdlib.net ([212.13.199.152]) by ietf-mx with esmtp (Exim 4.12) id 1AGiAE-00010G-00 for ipv6@ietf.org; Mon, 03 Nov 2003 12:06:50 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.20) id 1AGi9V-0006Ns-Mr; Mon, 03 Nov 2003 17:06:05 +0000 Date: Mon, 3 Nov 2003 17:06:05 +0000 From: Colm MacCarthaigh To: Keith Moore Cc: Stig Venaas , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031103170605.GA24355@castlerea.stdlib.net.> Reply-To: colm@stdlib.net References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20031103104202.08e7a1a3.moore@cs.utk.edu> User-Agent: Mutt/1.3.28i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA10872 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > I don't think that we should be defining getaddrinfo() in terms of > "whatever lookup service happens to be around" because it's very > difficult to get reliable and repeatable behavior that way. =20 Isn't the DNS a lookup service that happens to be around ? The purpose of getaddrinfo is to perform network address and service translation. Whilst a portable, granular, interface to DNS would be=20 very much welcome - getaddrinfo should not be it. > > I also think it > > should be possible for an administrator to define which name services > > should be used, which type of addresses should be returned, and the > > order. >=20 > I disagree. Different apps have different needs, and no single > host-wide or site-wide policy can accomodate the needs of the variety o= f > apps in use. A large ammount of apps have common needs; a very common need is to translate network and service names into numbers. The vast majority of these apps should not care whether it comes from lookupd/nscd, a=20 hosts file, dns, WINS or another source. =20 > Also, apps often cross administrative boundaries, which > creates problems when different nodes of those apps are subjected to th= e > whims of different administrators. Indeed, but to remove responsibility from administrators is to remove power from administrators. Many administrators cherish and understand their ability to define a search-order, over-ride domains, cache lookups. Others misunderstand and abuse these facilities, but the primary fault lies with those administrators - not elsewhere. Resolving only DNS would even hinder an administrators ability to fix these problems. Many sites have RFC1918 bogons in their zones (forward and reverse), some even listed as MX. It can ocasionally be useful to over-ride such sillyness locally. I'm not saying administrators should have to work around other's problems, de-incentivising the need to really fix them, but ocasionally we do. > It's not just specalized DNS applications that need to know what really > is in DNS. I would argue that really only an application with specialised DNS functionality (for instance an SMTP implementation) needs to know what really is in DNS. Certainly more applications than host/dig and so on=20 need to know what's really is in DNS, but I don't think the term "specialised" is unsuited. A the issue of link-locals in DNS, I agree that they should be returned by getaddrinfo, for the same reason I cite below.=20 > Many apps need consistent views of DNS without having to > second-guess the local host API implementation, brain-damaged sysadmins= , > etc. Whilst it's extremely desirable that apps not have to deal with API implementation inconsistency, the application writers sense of priorities should come much lower than the local administrators IMO. --=20 Colm MacC=E1rthaigh Public Key: colm+pgp@stdlib.ne= t -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 14:03:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14924 for ; Mon, 3 Nov 2003 14:03:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjz9-0007jD-NZ for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 14:03:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3J3VaF029708 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 14:03:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjz9-0007j5-0m for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 14:03:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14886 for ; Mon, 3 Nov 2003 14:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGjz6-0002cV-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 14:03:28 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGjz5-0002cS-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 14:03:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjyg-0007ZL-Ix; Mon, 03 Nov 2003 14:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjxz-0007Z0-Sp for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 14:02:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14867 for ; Mon, 3 Nov 2003 14:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGjxx-0002be-00 for ipv6@ietf.org; Mon, 03 Nov 2003 14:02:17 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AGjxw-0002bb-00 for ipv6@ietf.org; Mon, 03 Nov 2003 14:02:17 -0500 Message-ID: <021b01c3a23d$0407a320$9f6015ac@dclkempt40> From: "James Kempf" To: "Bound, Jim" , References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1F3@tayexc13.americas.cpqcorp.net> Subject: Re: Authors Section on recyle clarifications to 2461and 2462 Date: Mon, 3 Nov 2003 11:02:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jim, Are there any precedents? What has IETF done in other cases where specs have been rev-ed? The only case I personally know of is Mobile IPv4, in which the author/editor name was not changed when a new revision was put out, but perhaps there are others where different procedures were followed. jak ----- Original Message ----- From: "Bound, Jim" To: Sent: Saturday, November 01, 2003 11:00 PM Subject: Authors Section on recyle clarifications to 2461and 2462 > As we recycle 2461 and 2462 specifications I suggest that no additional > names be added to the authors names for two reasons. First its not > "honorable" as nothing has been discussed nor I perceive currently will > be learned that adds any architectural value of "significance" to these > widely deployed and important IPv6 specifications. The current authors > worked for many years and earned their names on this spec. Second I > believe new editors should be put at the bottom of the spec under > recycle acknowledgements per the IETF new rule to reduce author names on > all specifications. > > My .50 cents, > /jim > > --------------------------------------------------------- > "You want to spread rumors and gossip about me? You want to question my > honor and integrity? You want to insult me to my face? Okay...go right > ahead. But, don't expect me to walk away. Don't expect me to take it. > Hell, don't expect me to hire a lawyer to do my fighting for me. Some > people are inherently peaceful. They're capable of swallowing their > anger or letting the legal system take its course. Maybe they believe in > some sort of Judgement Day, when we all have to account for our > transgressions. Me? I am not that patient." Chuck Zito from "Street > Justice" > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 14:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15951 for ; Mon, 3 Nov 2003 14:27:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkMA-0000ru-45 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 14:27:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3JRIos003332 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 14:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkM9-0000rf-T3 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 14:27:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15913 for ; Mon, 3 Nov 2003 14:27:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGkM7-0002x2-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 14:27:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGkM6-0002ww-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 14:27:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkLt-0000iE-D8; Mon, 03 Nov 2003 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkLf-0000he-Ai for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 14:26:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15892 for ; Mon, 3 Nov 2003 14:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGkLb-0002wS-00 for ipv6@ietf.org; Mon, 03 Nov 2003 14:26:43 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak1a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AGkLa-0002wP-00 for ipv6@ietf.org; Mon, 03 Nov 2003 14:26:42 -0500 Received: from 132.235.74.191 by pm4 (PureMessage); Mon Nov 3 13:20:01 2003 Received: from dhcp-074-191.cns.ohiou.edu (dhcp-074-191.cns.ohiou.edu [132.235.74.191]) (authenticated bits=0) by oak3a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hA3IJwOk1837005 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 3 Nov 2003 13:20:00 -0500 (EST) Date: Mon, 03 Nov 2003 13:19:58 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <2147483647.1067865598@dhcp-074-191.cns.ohiou.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm4) X-PMX-Start: Mon Nov 3 13:20:00 2003 X-PMX-Stop: Mon Nov 3 13:20:01 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My question regarding "need anything else" referred only to the registry requirements. And I think we really need to delineate those requirements. I do not appreciate your personal attack; reading either this specific message or the archive should make it clear that I did not "miss this major issue", I just do not agree with Keith and you that "outlawing" local addresses will accomplish anything to solve those issues. Please explain to me how the job of applications gets any easier if the local addressing is done with a hijacked prefix.... --On Monday, November 3, 2003 16:08 +0100 Erik Nordmark wrote: >> Do we need anything else from a technical perspective? > > I think I and Keith Moore commented on the application impact, > and to the extent that the current document doesn't state > the application impact very accurately. > > Once that application impact is better known one could and should discuss > the cost/benefit tradeoffs. > > Since you missed the above rather major point, I wouldn't be surprised > if your summary misses other points that have been made. > > Erik > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 14:50:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17281 for ; Mon, 3 Nov 2003 14:50:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkiX-0002D8-1f for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 14:50:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3JoPEG008498 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 14:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkiV-0002Cz-FZ for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 14:50:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17244 for ; Mon, 3 Nov 2003 14:50:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGkiS-0003QL-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 14:50:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGkiR-0003QF-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 14:50:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkiB-00026z-OZ; Mon, 03 Nov 2003 14:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGkhh-00025q-7t for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 14:49:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17202 for ; Mon, 3 Nov 2003 14:49:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGkhe-0003PJ-00 for ipv6@ietf.org; Mon, 03 Nov 2003 14:49:30 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AGkhd-0003Oj-00 for ipv6@ietf.org; Mon, 03 Nov 2003 14:49:29 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA3Jmfj23940; Mon, 3 Nov 2003 11:48:41 -0800 X-mProtect: <200311031948> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIw90Ec; Mon, 03 Nov 2003 11:48:40 PST Message-ID: <3FA6B276.3030201@iprg.nokia.com> Date: Mon, 03 Nov 2003 11:54:30 -0800 From: Fred 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: Soliman Hesham CC: "'JinHyeock Choi'" , "'Pekka Savola'" , ipv6@ietf.org Subject: Re: RFC 2461- issue list: Prefixes with L=0 References: <748C6D0A58C0F94CA63C198B6674697A01922E67@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > I wish we clarify the above. The prefixes with L=0 makes DNA work > > complicated. Though they are troublesome, I am afriad that, > > in wireless > > environment, we can't avoid them. > >=> If it is found that in some deployment cases the L=0 >causes problems, the network admin is free to configure >the routers accordingly and always use on-link prefixes. >This is completely under the control of the admin. >I think Fred Templin sent a question some time ago >on this and Thomas explained how hosts should handle the >case where the L flag is set to zero. We can add this clarification >in the new revision if that helps. > Thomas' explaination did indeed clear my confusion on this subject. A clarification in the new revision would seem to put the issue to rest, IMHO. Fred ftemplin@iprg.nokia.com >If there are other scenarios where this is problematic >please send them to the list. > >Thanks, >Hesham > > > > > Best regards > > > > JinHyeock > > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 16:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22655 for ; Mon, 3 Nov 2003 16:27:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmE9-00084A-Do for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 16:27:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3LR9QI031000 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 16:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmE9-00083t-6z for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 16:27:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22585 for ; Mon, 3 Nov 2003 16:26:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGmE5-00051m-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 16:27:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGmE5-00051j-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 16:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmE1-0007v8-8u; Mon, 03 Nov 2003 16:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmDE-0007tj-MV for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 16:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22523 for ; Mon, 3 Nov 2003 16:26:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGmDC-00050F-00 for ipv6@ietf.org; Mon, 03 Nov 2003 16:26:10 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AGmDC-00050A-00 for ipv6@ietf.org; Mon, 03 Nov 2003 16:26:10 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 28A791417F; Mon, 3 Nov 2003 16:26:10 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11783-09; Mon, 3 Nov 2003 16:26:08 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0B05F1409E; Mon, 3 Nov 2003 16:26:08 -0500 (EST) Date: Mon, 3 Nov 2003 16:22:55 -0500 From: Keith Moore To: colm@stdlib.net Cc: moore@cs.utk.edu, Stig.Venaas@uninett.no, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031103162255.61563fcb.moore@cs.utk.edu> In-Reply-To: <20031103170605.GA24355@castlerea.stdlib.net.> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > > I don't think that we should be defining getaddrinfo() in terms of > > "whatever lookup service happens to be around" because it's very > > difficult to get reliable and repeatable behavior that way. > > Isn't the DNS a lookup service that happens to be around ? DNS is a specific lookup service. not a random one that just might happen to be around. > The purpose of getaddrinfo is to perform network address and service > translation. Whilst a portable, granular, interface to DNS would be > very much welcome - getaddrinfo should not be it. Perhaps. But if getaddrinfo isn't the service that does DNS lookups, then at least some apps should not be using it. > > > I also think it > > > should be possible for an administrator to define which name services > > > should be used, which type of addresses should be returned, and the > > > order. > > > > I disagree. Different apps have different needs, and no single > > host-wide or site-wide policy can accomodate the needs of the variety of > > apps in use. > > A large ammount of apps have common needs; a very common need is to > translate network and service names into numbers. The vast majority > of these apps should not care whether it comes from lookupd/nscd, a > hosts file, dns, WINS or another source. That's simply insane. Apps (and users) often care if the results from whatever lookup service getaddrinfo/gethostname happens to use are not consistent with reality. Apps sometimes care if the results of those lookups at different points in the network are not consistent with one another. People are often claiming that apps should not use IP addresses for referrals - that they should use DNS names instead. Indeed, it would be nice for apps to be able to do that, but that would imply (among other things) that a name means the same thing from all points of the application - NOT whatever some random lookup service or stale host file happens to return to a particular host. Every additional oracle that attempts to provide name to address translation is another potential source of variation and error. Every additional configuration knob that attempts to choose which source of name lookup should be used (whether it be an API, a config file, or a DHCP option) is yet another knob that can be set wrong. All of this garbage makes applications that ought to be portable from one host to another and one network to another, overly sensitive to host and site configuration. It causes bugs that are often difficult to troubleshoot. > > Also, apps often cross administrative boundaries, which > > creates problems when different nodes of those apps are subjected to the > > whims of different administrators. > > Indeed, but to remove responsibility from administrators is to remove > power from administrators. It removes the power to screw things up. I don't see this as a bad thing. Administrators can already set the meanings of DNS names in the zones that they control. Why do they need multiple ways to screw things up ? > Many administrators cherish and understand > their ability to define a search-order, over-ride domains, cache lookups. And many administrators should be terminated with extreme prejudice, too. > Resolving only DNS would even hinder an administrators ability to fix > these problems. Many sites have RFC1918 bogons in their zones (forward > and reverse), some even listed as MX. It can ocasionally be useful to > over-ride such sillyness locally. I'm not saying administrators should > have to work around other's problems, de-incentivising the need to really > fix them, but ocasionally we do. Okay, fine. Maybe admins need a way to work around occasional problems that occur. But we don't need a hodgepodge of different lookup methods and APIs and configuration mechanisms that interact with each other in arbitrary ways that vary from one host or site to another. > > It's not just specalized DNS applications that need to know what really > > is in DNS. > > I would argue that really only an application with specialised DNS > functionality (for instance an SMTP implementation) needs to know what > really is in DNS. You're wrong, of course. > A the issue of link-locals in DNS, I agree that they should be returned > by getaddrinfo, for the same reason I cite below. Well, link-local addresses should never be in DNS in the first place. My argument is not that link-local addresses should be returned by getaddrinfo() , it is that getaddrinfo() should be transparent. It shouldn't be yet another layer (in addition to all of the ones mentioned above) that is getting in the way of the app finding out what the DNS name means. > > Many apps need consistent views of DNS without having to > > second-guess the local host API implementation, brain-damaged sysadmins, > > etc. > > Whilst it's extremely desirable that apps not have to deal with API > implementation inconsistency, the application writers sense of priorities > should come much lower than the local administrators IMO. Quite often local administrators forget that their purpose is to support users, that those users need to run apps, and that for the apps to run reliably they need a reliable and predictable environment. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 16:42:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23201 for ; Mon, 3 Nov 2003 16:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmSf-0000bG-RY for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 16:42:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Lg9t9002300 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 16:42:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmSf-0000b1-NQ for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 16:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23130 for ; Mon, 3 Nov 2003 16:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGmSd-0005EX-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 16:42:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGmSd-0005EU-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 16:42:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmSZ-0000Uh-VB; Mon, 03 Nov 2003 16:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmRi-0000Rq-0J for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 16:41:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23104 for ; Mon, 3 Nov 2003 16:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGmRf-0005Di-00 for ipv6@ietf.org; Mon, 03 Nov 2003 16:41:08 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AGmRf-0005DN-00 for ipv6@ietf.org; Mon, 03 Nov 2003 16:41:07 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hA3LebYb026841; Mon, 3 Nov 2003 15:40:37 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Nov 2003 15:39:31 -0600 Received: from [142.133.72.18] (142.133.72.18 [142.133.72.18]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WF877YDY; Mon, 3 Nov 2003 16:40:34 -0500 Date: Mon, 3 Nov 2003 16:38:37 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Mario Goebbels cc: ipv6@ietf.org Subject: Re: Subnetting question In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830BD62950@eammlex037.lmc.ericsson.se> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830D90E39A-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, 3 Nov 2003, Mario Goebbels wrote: Hi Mario, This is theoretically allowed. Check out section 2 of RFC3513 "In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain, or end with, zero-valued fields." I really don't know what issues you might encounter though.One issue I see right away is the subnet-router anycast address (section 2.6.1 of RFC3513) would be the same for both the /48 and the /64. Regards Suresh >Hi! > >I need a clarification on the question if I can use the very first subnet in a network. > >Means if I would get assigned 2001:1234:5678::/48 from a RIR, if I can use 2001:1234:5678:0::/64 within my own network, or if the same rules as in IPv4 subnetting apply (first and last one aren't usable). > >Thanks > >-mg > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 17:21:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28009 for ; Mon, 3 Nov 2003 17:21:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn4n-0003v5-E5 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 17:21:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3MLXbH015064 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 17:21:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn4n-0003ut-6D for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 17:21:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27966 for ; Mon, 3 Nov 2003 17:21:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGn4k-0006dV-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:21:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGn4k-0006dS-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:21:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn4I-0003pB-RZ; Mon, 03 Nov 2003 17:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGn3s-0003nB-Jj for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 17:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27932 for ; Mon, 3 Nov 2003 17:20:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGn3q-0006cY-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:20:34 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AGn3o-0006bT-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:20:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA3MJea10818; Mon, 3 Nov 2003 14:19:40 -0800 X-mProtect: <200311032219> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5aJRaH; Mon, 03 Nov 2003 14:19:39 PST Message-ID: <3FA6D5DB.6090700@iprg.nokia.com> Date: Mon, 03 Nov 2003 14:25:31 -0800 From: Fred 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: Pekka Savola CC: Hans Kruse , ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Mon, 3 Nov 2003, Hans Kruse wrote: > > >>Please explain to me how the job of applications gets any easier if the >>local addressing is done with a hijacked prefix.... >> >> > >Why exactly should we care if party X's internal applications break >because it hijacks a prefix? > Because simply allowing internal apps to break is in clear violation of the robustness principle. (e.g., if two disconnected/intermittently-connected sites that have somehow hijacked the same prefix encounter one another we have what Data would call: "a simple matter/anti-matter reaction".) For plenty of scenarios that call for local communications within sites, see: http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-localcomm-03.txt Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 17:29:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28856 for ; Mon, 3 Nov 2003 17:29:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnC6-0004tQ-3G for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3MT6le018802 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 17:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnC5-0004tB-VB for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 17:29:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28816 for ; Mon, 3 Nov 2003 17:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnC3-0006ye-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:29:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGnC3-0006yb-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnC1-0004mX-DM; Mon, 03 Nov 2003 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnBU-0004lo-5I for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 17:28:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28803 for ; Mon, 3 Nov 2003 17:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnBR-0006yF-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:28:25 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak1a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AGnBR-0006yB-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:28:25 -0500 Received: from 132.235.232.96 by pm2 (PureMessage); Mon Nov 3 16:48:40 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hA3Lmcnq724080 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 3 Nov 2003 16:48:39 -0500 (EST) Date: Mon, 03 Nov 2003 16:48:09 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <1559442296.1067878089@hkruse2003a> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm2) X-PMX-Start: Mon Nov 3 16:48:39 2003 X-PMX-Stop: Mon Nov 3 16:48:40 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We don't, and that is my point. The draft in question improves on that situation by creating a prefix that the rest of the network can easily deal with. Internal apps may still break, although I would argue that the local addressing prefix opens some options to make that a little less likely... --On Monday, November 03, 2003 23:19 +0200 Pekka Savola wrote: > On Mon, 3 Nov 2003, Hans Kruse wrote: >> Please explain to me how the job of applications gets any easier if the >> local addressing is done with a hijacked prefix.... > > Why exactly should we care if party X's internal applications break > because it hijacks a prefix? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 17:46:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00279 for ; Mon, 3 Nov 2003 17:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnSb-00070H-NQ for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 17:46:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Mk9MY026915 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 17:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnSb-000702-Gr for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 17:46:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00244 for ; Mon, 3 Nov 2003 17:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnSY-0007WP-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:46:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGnSY-0007WM-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnST-0006uU-Rt; Mon, 03 Nov 2003 17:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnRu-0006tt-T0 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 17:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00211 for ; Mon, 3 Nov 2003 17:45:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnRs-0007VZ-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:45:24 -0500 Received: from castlerea.stdlib.net ([212.13.199.152]) by ietf-mx with esmtp (Exim 4.12) id 1AGnRr-0007VW-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:45:23 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.20) id 1AGnO7-000733-5s; Mon, 03 Nov 2003 22:41:31 +0000 Date: Mon, 3 Nov 2003 22:41:31 +0000 From: Colm MacCarthaigh To: Keith Moore Cc: Stig.Venaas@uninett.no, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031103224131.GA26982@castlerea.stdlib.net.> Reply-To: colm@stdlib.net References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20031103162255.61563fcb.moore@cs.utk.edu> User-Agent: Mutt/1.3.28i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA00213 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2003 at 04:22:55PM -0500, Keith Moore wrote: > > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > > > I don't think that we should be defining getaddrinfo() in terms of > > > "whatever lookup service happens to be around" because it's very > > > difficult to get reliable and repeatable behavior that way. =20 > >=20 > > Isn't the DNS a lookup service that happens to be around ? >=20 > DNS is a specific lookup service. not a random one that just might hap= pen > to be around. NIS is a specific lookup service, as is WINS, and well I could go on ... DNS may be more standardised, more widely-deployed and frankly - more tasteful, but it is no more specific. It's not the only show in town :) I don't mean to be facetious here, of course I regard DNS as the "standar= d" name to number resolver, but I'm a long long way from thinking it should=20 be the only means allowed for applications to resolve names. > > The purpose of getaddrinfo is to perform network address and service > > translation. Whilst a portable, granular, interface to DNS would be=20 > > very much welcome - getaddrinfo should not be it. >=20 > Perhaps. But if getaddrinfo isn't the service that does DNS lookups, > then at least some apps should not be using it. Could you give some specific examples of the type of apps you're talking about? > > A large ammount of apps have common needs; a very common need is to > > translate network and service names into numbers. The vast majority > > of these apps should not care whether it comes from lookupd/nscd, a=20 > > hosts file, dns, WINS or another source. =20 >=20 > That's simply insane. >=20 > Apps (and users) often care if the results from whatever lookup service > getaddrinfo/gethostname happens to use are not consistent with reality. When you say "reality", do you really mean - "DNS"? If so, what makes DNS more authorative than the decisions of the local administrator ?=20 What about site to site inconsistencies in DNS ? =20 I don't think many people would argue that Global DNS names should be broken by local administrators. But is making that slightly harder worth heavily impairing their ability to have site-local name resolution? > Apps sometimes care if the results of those lookups at different points= =20 > in the network are not consistent with one another. Certainly, but since this can (and frequently does) happen with DNS on it= s=20 own, surely the problem should be resolved more generally? I don't see ho= w the problem of distributed applications needing to agree on a network num= ber is solved by only using DNS to resolve network names.=20 > People are often claiming that apps should not use IP addresses for > referrals - that they should use DNS names instead. Indeed, it would=20 > be nice for apps to be able to do that, but that would imply (among > other things) that a name means the same thing from all points of=20 > the application - NOT whatever some random lookup service or stale > host file happens to return to a particular host. I disagree. And there are many examples of when people consider it useful for domains to return inconsistent results. Many end-users wish to blackh= ole the domains of web-banner advertiser; integral to many testing and stagin= g=20 procedures is the ability to spoof production domains; users of RFC1918 space frequently wish to resolve to different addresses depending on scop= e. =20 Whilst all of this is possible with control over a resolving name-server (assuming there is one), it very much removes power from the administrato= r which they find useful. > Every additional oracle that attempts to provide name to address transl= ation > is another potential source of variation and error. Every additional=20 > configuration knob that attempts to choose which source of name lookup = should > be used (whether it be an API, a config file, or a DHCP option) is yet > another knob that can be set wrong. All of this garbage makes applicat= ions > that ought to be portable from one host to another and one network to a= nother, > overly sensitive to host and site configuration. It causes bugs that a= re often=20 > difficult to troubleshoot. Agreed, however I view the alternative as worse. I've been involved in th= e IPv6 development of widely-deployed applications, and have experience dealing with obsure user problems, extremely tenous getaddrinfo bugs and other such madness, and I can't think of many such problems occuring. On the other hand, I've been saved by the ability to quickly over-ride local name resolution more than once. > > > Also, apps often cross administrative boundaries, which > > > creates problems when different nodes of those apps are subjected t= o the > > > whims of different administrators. > >=20 > > Indeed, but to remove responsibility from administrators is to remove > > power from administrators. >=20 > It removes the power to screw things up. I don't see this as a bad thi= ng. >=20 > Administrators can already set the meanings of DNS names in the zones t= hat > they control. Why do they need multiple ways to screw things up ? Because local administrators arn't always in control of their DNS names. All that would happen is that more local administrators would run local DNS resolvers. It just gets you right back to square one :) > > I would argue that really only an application with specialised DNS > > functionality (for instance an SMTP implementation) needs to know wha= t > > really is in DNS.=20 >=20 > You're wrong, of course. Could you provide an example ? Personally I consider lookup-agnosticism as a good feature of getaddrinfo. It will take a lot to persuade me=20 otherwise. "really in DNS" and "globally consistent" are not equatable statements,=20 because well ... they're not. Unless you're arguing for a global=20 short-list of resolvers ? The problems seen with name-resolsution inconsistency are the result of stupid operators - they arn't going to go away. They're just going to be stupid with DNS instead :) > Quite often local administrators forget that their purpose is to suppor= t > users, that those users need to run apps, and that for the apps to run > reliably they need a reliable and predictable environment.=20 Totally, but it is not for an API to dictate to local administrators how best to achieve this. Extra lookup methods can be part of providing a more reliable and predictable environment. =20 --=20 Colm MacC=E1rthaigh Public Key: colm+pgp@stdlib.ne= t -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 17:56:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00608 for ; Mon, 3 Nov 2003 17:56:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGncH-0007kW-NB for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 17:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Mu91Y029781 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 17:56:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGncH-0007kG-Ij for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 17:56:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00563 for ; Mon, 3 Nov 2003 17:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGncE-0007f4-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:56:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGncE-0007f1-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 17:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGncA-0007dH-Nr; Mon, 03 Nov 2003 17:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnbR-0007bN-T0 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 17:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00546 for ; Mon, 3 Nov 2003 17:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnbP-0007eW-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:55:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGnbM-0007eK-00 for ipv6@ietf.org; Mon, 03 Nov 2003 17:55:14 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA3MsYR11199; Tue, 4 Nov 2003 00:54:35 +0200 Date: Tue, 4 Nov 2003 00:54:28 +0200 (EET) From: Pekka Savola To: Hans Kruse cc: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call In-Reply-To: <1559442296.1067878089@hkruse2003a> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I'll combine two answers in message.. [me:] > > Why exactly should we care if party X's internal applications break > > because it hijacks a prefix? On Mon, 3 Nov 2003, Hans Kruse wrote: > We don't, and that is my point. The draft in question improves on that > situation by creating a prefix that the rest of the network can easily deal > with. Internal apps may still break, although I would argue that the local > addressing prefix opens some options to make that a little less likely... No, the point is that when someone hijacks a prefix, they intentionally do something they know they should not do, and they "deserve" their applications to get broken. If we specify a mechanism for local addressing that "just about works", but still breaks apps, we've "blessed" a mechanism that doesn't work. That's even worse :-) [Fred:] > Because simply allowing internal apps to break is in clear violation of the > robustness principle. (e.g., if two disconnected/intermittently-connected > sites that have somehow hijacked the same prefix encounter one another > we have what Data would call: "a simple matter/anti-matter reaction".) Yes, but the site who hijacked a prefix is lost beyond redemption. Again, why should we care if their apps break? (We certainly care about apps not breaking in "valid" deployment scenarios..) -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 18:51:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04322 for ; Mon, 3 Nov 2003 18:51:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGoTl-0002tL-KZ for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 18:51:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3NpPjn011110 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 18:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGoTk-0002t7-LY for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 18:51:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04273 for ; Mon, 3 Nov 2003 18:51:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGoTh-0000ux-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 18:51:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGoTh-0000uu-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 18:51:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGoTO-0002jV-QU; Mon, 03 Nov 2003 18:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGoST-0002i5-Md for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 18:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04207 for ; Mon, 3 Nov 2003 18:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGoSQ-0000tL-00 for ipv6@ietf.org; Mon, 03 Nov 2003 18:50:02 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AGoSP-0000tH-00 for ipv6@ietf.org; Mon, 03 Nov 2003 18:50:02 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4B7B915214; Tue, 4 Nov 2003 08:50:00 +0900 (JST) Date: Tue, 04 Nov 2003 08:49:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Subject: implementation reports for rfc246[01]bis (Re: RFC 2461- issue list) In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA17F@tayexc13.americas.cpqcorp.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 24 Oct 2003 09:41:35 +0300 (EEST), >>>>> Pekka Savola said: > My initial thought is also that we should not make RFC 2461bis (or > 2462bis) include every extension specified since 1998. Those can stay > very well in separate drafts. Of course, we should still consider whether > we want to enable the base spec to give more flexibility (e.g., the > solicitation timers etc.) for those extensions. There is a clear > distinction between these two, IMHO. > Another thought: if we recycle RFC2461bis to DS, I think we should re-do > the implementation reports if we changed the code (not sure whether new > reports is _required_..). This may not be a bad thing, as the current > implementation reports should (IMHO) be a bit more detailed than that.. (I'm writing this since I don't think I've seen a message replying to this part. But if I miss it, please just ignore this one.) Yes, we're planning to call for implementation reports when rfc246[01]bis are ready to be recycled to DS. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 19:08:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04837 for ; Mon, 3 Nov 2003 19:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGok3-0003tg-MK for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 19:08:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA408FGC014974 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 19:08:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGok3-0003tR-HK for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 19:08:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04807 for ; Mon, 3 Nov 2003 19:08:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGok0-000198-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 19:08:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGojz-000195-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 19:08:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGojs-0003m0-9s; Mon, 03 Nov 2003 19:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGojj-0003kY-9o for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 19:07:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04780 for ; Mon, 3 Nov 2003 19:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGojf-00018k-00 for ipv6@ietf.org; Mon, 03 Nov 2003 19:07:51 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AGojf-00018e-00 for ipv6@ietf.org; Mon, 03 Nov 2003 19:07:51 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9742E15214; Tue, 4 Nov 2003 09:07:50 +0900 (JST) Date: Tue, 04 Nov 2003 09:07:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: greg.daley@eng.monash.edu.au Cc: ipv6@ietf.org Subject: Re: RFC 2461- issue list In-Reply-To: <3FA1C04E.2010903@eng.monash.edu.au> References: <748C6D0A58C0F94CA63C198B6674697A01922E4B@ftmail.lab.flarion.com> <3FA1C04E.2010903@eng.monash.edu.au> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 31 Oct 2003 12:52:14 +1100, >>>>> Greg Daley said: > The difficulty comes when an RS comes from a global > source address which is not directly connected to > a router. > Based on RS processing rules, the host which sent > the RS is within a hop of the router, but has asked for > an RA from an address which doesn't exist locally. It is not very clear what "an address which doesn't exist locally" means. I guess you probably mean, e.g., an address that belongs to a prefix that the receiving router does not configure as on-link. RFC2461 clearly (IMO) says that such an address must be regarded as on-link: on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on- link if: (snip) - any Neighbor Discovery message is received from the address. (Section 2.1 of RFC2461) Note that in this case a neighbor discovery message (router solicitation) is received from the address. > Does the router reply to a message which has a source > address not believed to be on this link? So, again, it is not clear what "a source address not believed to be on this link" means, but if the question is, e.g., Does the router reply to a message which has a source address that belongs to a prefix that the receiving router does not configure as on-link? then the answer is yes. > Does it only reply with a multicast destination? No, a unicasted response is also valid. > What do current implementations do in this case? This doesn't help your question here, but FWIW, the KAME/BSD implementation only supports for multicast router advertisement. So, the implementation always replies with a multicast destination, whether the source of the solicitation is link-local or global. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 19:19:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05194 for ; Mon, 3 Nov 2003 19:19:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGoue-0004q8-42 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 19:19:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA40JC3b018593 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 19:19:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGoud-0004pR-S7 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 19:19:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05105 for ; Mon, 3 Nov 2003 19:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGouc-0001Jn-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 19:19:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGoub-0001Jk-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 19:19:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGouT-0004e7-OM; Mon, 03 Nov 2003 19:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGotU-0004KZ-Dn for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 19:18:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05027 for ; Mon, 3 Nov 2003 19:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGotS-0001I5-00 for ipv6@ietf.org; Mon, 03 Nov 2003 19:17:58 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AGotR-0001Hr-00 for ipv6@ietf.org; Mon, 03 Nov 2003 19:17:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA40H2X04359; Mon, 3 Nov 2003 16:17:02 -0800 X-mProtect: <200311040017> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd03Wh5z; Mon, 03 Nov 2003 16:17:00 PST Message-ID: <3FA6F15C.90805@iprg.nokia.com> Date: Mon, 03 Nov 2003 16:22:52 -0800 From: Fred 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: jinmei@isl.rdc.toshiba.co.jp CC: Pekka Savola , ipv6@ietf.org Subject: Re: implementation reports for rfc246[01]bis (Re: RFC 2461- issue list) References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA17F@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Don't you mean rfc246[12]bis? (Or, are you planning to revise rfc2460 as well?) Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 19:54:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06254 for ; Mon, 3 Nov 2003 19:54:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpSj-00073f-Gs for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 19:54:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA40sP1M027127 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 19:54:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpSj-00073S-32 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 19:54:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06224 for ; Mon, 3 Nov 2003 19:54:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGpSh-0001ss-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 19:54:23 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGpSg-0001sp-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 19:54:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpSM-0006xd-Oj; Mon, 03 Nov 2003 19:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpSC-0006wt-FG for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 19:53:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06205 for ; Mon, 3 Nov 2003 19:53:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGpSA-0001sc-00 for ipv6@ietf.org; Mon, 03 Nov 2003 19:53:50 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak1a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AGpSA-0001sZ-00 for ipv6@ietf.org; Mon, 03 Nov 2003 19:53:50 -0500 Received: from 132.235.232.96 by pm4 (PureMessage); Mon Nov 3 18:48:36 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hA3NmYnq612024 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 3 Nov 2003 18:48:35 -0500 (EST) Date: Mon, 03 Nov 2003 18:48:05 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <1566638078.1067885285@hkruse2003a> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm4) X-PMX-Start: Mon Nov 3 18:48:35 2003 X-PMX-Stop: Mon Nov 3 18:48:36 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK, this is going to go around endlessly, so please re-read my original message where I said that there are some who simply do not agree that local addressing is needed -- I know that is your position and I respect it. I also said that I firmly disagree and suggest that we have plenty of scenarios that suggest otherwise. Lets not waste further bits on this argument. --On Tuesday, November 04, 2003 00:54 +0200 Pekka Savola wrote: > I'll combine two answers in message.. > > [me:] >> > Why exactly should we care if party X's internal applications break >> > because it hijacks a prefix? > > On Mon, 3 Nov 2003, Hans Kruse wrote: >> We don't, and that is my point. The draft in question improves on that >> situation by creating a prefix that the rest of the network can easily >> deal with. Internal apps may still break, although I would argue that >> the local addressing prefix opens some options to make that a little >> less likely... > > No, the point is that when someone hijacks a prefix, they intentionally > do something they know they should not do, and they "deserve" their > applications to get broken. > > If we specify a mechanism for local addressing that "just about works", > but still breaks apps, we've "blessed" a mechanism that doesn't work. > That's even worse :-) > > [Fred:] >> Because simply allowing internal apps to break is in clear violation of >> the robustness principle. (e.g., if two >> disconnected/intermittently-connected sites that have somehow hijacked >> the same prefix encounter one another we have what Data would call: "a >> simple matter/anti-matter reaction".) > > Yes, but the site who hijacked a prefix is lost beyond redemption. > Again, why should we care if their apps break? (We certainly care about > apps not breaking in "valid" deployment scenarios..) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 20:14:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06850 for ; Mon, 3 Nov 2003 20:14:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGplw-0008N8-Fg for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 20:14:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA41EG06032176 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 20:14:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGplv-0008MR-Cn for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 20:14:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06801 for ; Mon, 3 Nov 2003 20:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGplt-000283-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 20:14:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGpls-000280-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 20:14:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpli-0008DM-DE; Mon, 03 Nov 2003 20:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpl9-0008CO-SQ for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 20:13:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06772 for ; Mon, 3 Nov 2003 20:13:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGpl7-00027J-00 for ipv6@ietf.org; Mon, 03 Nov 2003 20:13:25 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AGpl7-000270-00 for ipv6@ietf.org; Mon, 03 Nov 2003 20:13:25 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Nov 2003 17:12:55 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 Nov 2003 17:12:55 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 3 Nov 2003 17:13:16 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Nov 2003 17:12:13 -0800 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.3790.1069); Mon, 3 Nov 2003 17:12:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Thoughts on the draft-hinden last call Date: Mon, 3 Nov 2003 17:12:58 -0800 Message-ID: Thread-Topic: Thoughts on the draft-hinden last call thread-index: AcOiblG+I9JRo30tTmyDKnSTA3TVZAAAXHUw From: "Christian Huitema" To: "Hans Kruse" , X-OriginalArrivalTime: 04 Nov 2003 01:12:54.0073 (UTC) FILETIME=[C6231290:01C3A270] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > OK, this is going to go around endlessly, so please re-read my original > message where I said that there are some who simply do not agree that > local > addressing is needed -- I know that is your position and I respect it. I > also said that I firmly disagree and suggest that we have plenty of > scenarios that suggest otherwise. Lets not waste further bits on this > argument. Hans, You have clearly stated your point. You, and several others, believe that local addressing is not needed. However, I don't believe that the working group should heed your opposition. Something is needed if a significant part of the community believes they need it; unanimity is definitely not required, and even majority is not required.=20 In the case in point, there is a significant constituency who believes that they need a replacement for site local addresses, and that "draft-hinden" is a reasonable way to obtain this replacement. You are indeed free to not use such addresses and never deploy them within the networks that you manage, but that does not change the needs of others. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 20:21:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07264 for ; Mon, 3 Nov 2003 20:21:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpse-0000bP-UJ for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 20:21:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA41LCF8002309 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 20:21:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpse-0000bA-Od for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 20:21:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07230 for ; Mon, 3 Nov 2003 20:21:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGpsb-0002Ff-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 20:21:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGpsa-0002Fa-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 20:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpsV-0000SK-Hg; Mon, 03 Nov 2003 20:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGps6-0000RJ-A1 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 20:20:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07215 for ; Mon, 3 Nov 2003 20:20:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGps3-0002FJ-00 for ipv6@ietf.org; Mon, 03 Nov 2003 20:20:35 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AGps3-0002FG-00 for ipv6@ietf.org; Mon, 03 Nov 2003 20:20:35 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C3A5315218; Tue, 4 Nov 2003 10:20:33 +0900 (JST) Date: Tue, 04 Nov 2003 10:20:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Fred Templin Cc: ipv6@ietf.org Subject: Re: implementation reports for rfc246[01]bis (Re: RFC 2461- issue list) In-Reply-To: <3FA6F15C.90805@iprg.nokia.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA17F@tayexc13.americas.cpqcorp.net> <3FA6F15C.90805@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 03 Nov 2003 16:22:52 -0800, >>>>> Fred Templin said: > Don't you mean rfc246[12]bis? (Or, are you planning to > revise rfc2460 as well?) Oops, sorry, of course I meant rfc246[12]bis. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 20:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07364 for ; Mon, 3 Nov 2003 20:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGptV-0000vB-8I for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 20:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA41M55g003535 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 20:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGptV-0000uw-26 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 20:22:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07306 for ; Mon, 3 Nov 2003 20:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGptS-0002H8-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 20:22:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGptS-0002H2-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 20:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGptS-0000nQ-MY; Mon, 03 Nov 2003 20:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpsd-0000az-0o for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 20:21:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07223 for ; Mon, 3 Nov 2003 20:21:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGpsa-0002FZ-00 for ipv6@ietf.org; Mon, 03 Nov 2003 20:21:08 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AGpsZ-0002FP-00 for ipv6@ietf.org; Mon, 03 Nov 2003 20:21:08 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2MTITW6F68ZP5BW@vaxh.its.monash.edu.au> for ipv6@ietf.org; Tue, 4 Nov 2003 12:18:10 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id A35CB39C003; Tue, 04 Nov 2003 12:18:10 +1100 (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 904DD2DC004; Tue, 04 Nov 2003 12:18:10 +1100 (EST) Date: Tue, 04 Nov 2003 12:18:10 +1100 From: Greg Daley Subject: Re: RFC 2461- issue list To: =?ISO-8859-1?Q?JINMEI_Tatuya_/_=3F=3F=3F=3F?= Cc: ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FA6FE52.8080309@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: <748C6D0A58C0F94CA63C198B6674697A01922E4B@ftmail.lab.flarion.com> <3FA1C04E.2010903@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Dear Jinmei-san, JINMEI Tatuya / ???? wrote: >>>>>>On Fri, 31 Oct 2003 12:52:14 +1100, >>>>>>Greg Daley said: >>>>> > >>The difficulty comes when an RS comes from a global >>source address which is not directly connected to >>a router. > > >>Based on RS processing rules, the host which sent >>the RS is within a hop of the router, but has asked for >>an RA from an address which doesn't exist locally. > > > It is not very clear what "an address which doesn't exist locally" > means. I guess you probably mean, e.g., an address that belongs to a > prefix that the receiving router does not configure as on-link. > > RFC2461 clearly (IMO) says that such an address must be regarded as > on-link: > > on-link - an address that is assigned to an interface on a > specified link. A node considers an address to be on- > link if: > (snip) > - any Neighbor Discovery message is received from > the address. > (Section 2.1 of RFC2461) > > Note that in this case a neighbor discovery message (router > solicitation) is received from the address. Indeed. This is quite possibly incorrect behaviour though, since wireless nodes may have mistaken ideas as to where they are connected, and send Router Solicitations (quite unaware) from global addresses which are _not_ on-link. It is very likely in the case that a node has changed its link-layer connection, but it has not received an RA, that it has invalid configuration on the link. In this case, should the router put entries into its ND cache for addresses from global prefixes associated with another subnet? I'm not conviced (yet) that it should (even if it's allowed to by RFC-2461). > >>Does the router reply to a message which has a source >>address not believed to be on this link? > > > So, again, it is not clear what "a source address not believed to be on > this link" means, but if the question is, e.g., > > Does the router reply to a message which has a source > address that belongs to a prefix that the receiving router does not > configure as on-link? > > then the answer is yes. I can understand if the router responds with a multicast (since even :: addresses are capable of receiving a multicast response). I'm more concerned about the creation of incorrect state for the router. For example, invalid NC state could be used to create local routing between addresses on seemingly unconnected subnets, without going through the router controlling the foreign prefix. I've not got any dire predictions as to why this would be a bad thing, but it seems unnecessary (since we have LL) and incorrect (since NC's will have entries which don't reflect the routing architecture). >>Does it only reply with a multicast destination? > > > No, a unicasted response is also valid. Which means that we accept any prefix from any host as part of a valid address, to put in our neighbor caches. So all a node has to do to get bidirectional communication with hosts on a link is to (if it knows their address, as with the router): send them an NS or RS with SLLAO with an arbitrary source address (or even send RS without SLLAO, and respond to the router's NS). This will place an NC on the peer. No routing involved, just neighbor discovery. I'm just wondering if this was the intended functionality? >>What do current implementations do in this case? > > > This doesn't help your question here, but FWIW, the KAME/BSD > implementation only supports for multicast router advertisement. > So, the implementation always replies with a multicast destination, > whether the source of the solicitation is link-local or global. That's helpful to know though. radvd primarily works on multicast advertisement, but I'll have to check the source to see how it works for unicast too. Thanks for your help. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 21:01:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08521 for ; Mon, 3 Nov 2003 21:01:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqVj-0003F5-3K for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 21:01:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA421Zd6012457 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 21:01:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqVi-0003Eq-VJ for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 21:01:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08481 for ; Mon, 3 Nov 2003 21:01:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqVg-0002rT-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:01:32 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGqVg-0002rQ-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:01:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqVC-000381-SF; Mon, 03 Nov 2003 21:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqUP-00037B-1J for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 21:00:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08449 for ; Mon, 3 Nov 2003 21:00:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqUM-0002qb-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:00:10 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak1a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AGqUL-0002qY-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:00:10 -0500 Received: from 132.235.232.96 by pm4 (PureMessage); Mon Nov 3 20:44:20 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak3a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hA41iIYW1792400 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 3 Nov 2003 20:44:19 -0500 (EST) Date: Mon, 03 Nov 2003 20:43:49 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: RE: Thoughts on the draft-hinden last call Message-ID: <1573581890.1067892229@hkruse2003a> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm4) X-PMX-Start: Mon Nov 3 20:44:19 2003 X-PMX-Stop: Mon Nov 3 20:44:20 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Whoa, sorry if this got that far out of context! I very expressly believe that a local scheme in general, and the one in draft-hinden in particular, is needed for a number of scenarios! --On Monday, November 03, 2003 17:12 -0800 Christian Huitema wrote: > Hans, > > You have clearly stated your point. You, and several others, believe > that local addressing is not needed. However, I don't believe that the > working group should heed your opposition. Something is needed if a > significant part of the community believes they need it; unanimity is > definitely not required, and even majority is not required. > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 21:10:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08872 for ; Mon, 3 Nov 2003 21:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqe3-00047N-H9 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 21:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA42ABhY015823 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 21:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqe3-000478-9G for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 21:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08810 for ; Mon, 3 Nov 2003 21:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqe0-0002xF-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:10:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGqe0-0002xC-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:10:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqdv-0003yP-E1; Mon, 03 Nov 2003 21:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqdV-0003xs-Hi for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 21:09:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08793; Mon, 3 Nov 2003 21:09:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqdS-0002wv-00; Mon, 03 Nov 2003 21:09:34 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AGqdS-0002wr-00; Mon, 03 Nov 2003 21:09:34 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A139D15232; Tue, 4 Nov 2003 11:09:33 +0900 (JST) Date: Tue, 04 Nov 2003 11:09:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vijay Devarapalli Cc: ipv6@ietf.org, mip6@ietf.org Subject: Re: A list of issues for RFC2462 update In-Reply-To: <3F987C5B.9070905@iprg.nokia.com> References: <3F987C5B.9070905@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 23 Oct 2003 18:11:55 -0700, >>>>> Vijay Devarapalli said: > here is another issue. it involves both 2461 and 2462. > RFC 2461 says > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. > RFC 2462 says > 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 between 0 and > MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. > lets assume a Mobile Node moves and attaches to a new > link. it does router discovery and configures a Care-of > address. the mobile node cannot send a Binding Update > until it completes DAD for the Care-of address. these > two random delays (before router discovery and before > DAD) contribute a lot to the movement detection delay. > I think this needs to be fixed. > MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst > case scenario, it could be 1 second before a sending > router solicitation, one second before sending neighbor > solicitation for DAD and then 1 second before DAD > completes. the Binding Update cannot be sent until then. Thanks for the pointer. I'll add this to my local issue list. (Note to everyone: this does not mean I'm going to propose a change on RFC2462 to address this.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 21:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09225 for ; Mon, 3 Nov 2003 21:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqkl-0004yp-11 for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 21:17:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA42H6fF019137 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 21:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqkk-0004ya-Qn for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 21:17:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09179 for ; Mon, 3 Nov 2003 21:16:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqki-00036V-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:17:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGqkh-00036S-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqkg-0004uo-77; Mon, 03 Nov 2003 21:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqjh-0004se-E2 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 21:16:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09157 for ; Mon, 3 Nov 2003 21:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqje-00036D-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:15:58 -0500 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1AGqjd-00035m-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:15:58 -0500 Received: from gih505.telstra.net (rsdhcp13.telstra.net [203.50.0.207]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id hA42FLRc046132; Tue, 4 Nov 2003 13:15:23 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031104130536.01ccc8b8@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Nov 2003 13:14:55 +1100 To: Brian E Carpenter , ipv6@ietf.org From: Geoff Huston Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 UnicastAddresses" In-Reply-To: <3FA28CCB.9EE03469@zurich.ibm.com> References: <3F96659F.4040702@innovationslab.net> <5.1.0.14.2.20031030113954.021cbf70@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Brian, >My concern is really to get this in place reasonably quickly, and I think that >means setting relatively clear guidelines for IANA rather than leaving the >field open for endless debate. I believe that you and I are in agreement here Brian in a general sense, but we possibly differ on what "relatively clear guidelines for IANA". I do _not_ think that the current draft has these properties, and I am voicing the view that a further revision of the draft is appropriate as per my comments already on this topic. >It's kind of hard to write down "avoid a gold rush" as an intended >outcome of an RFC, but in fact I agree with the direction of the suggested >text changes in your message cited above, except that I don't see how to >avoid a single authority and therefore a natural monopoly... which >is definitely not an IETF issue. And I'm advocating the view that the document can be further revised such that it can provide reasonable guidelines to IANA without getting into "gold rush" space and without getting into "anti-trust" space, and I would rather that this document were revised a further cycle to correct this before its passed to the IESG as a WG output. regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 21:52:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10218 for ; Mon, 3 Nov 2003 21:52:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrIe-00079Y-PD for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 21:52:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA42q82R027490 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 21:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrIe-00079J-KQ for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 21:52:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10172 for ; Mon, 3 Nov 2003 21:51:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrIb-0003aQ-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:52:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGrIb-0003aN-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrIX-00075g-QT; Mon, 03 Nov 2003 21:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrHy-00075F-7F for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 21:51:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10162 for ; Mon, 3 Nov 2003 21:51:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrHv-0003aD-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:51:23 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AGrHu-0003a0-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:51:22 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Nov 2003 18:50:51 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 3 Nov 2003 18:48:36 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 Nov 2003 18:50:46 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Nov 2003 18:50:51 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Nov 2003 18:49:55 -0800 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.3790.1069); Mon, 3 Nov 2003 18:51:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-ipv6-router-selection-02.txt issues list Date: Mon, 3 Nov 2003 18:50:37 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-router-selection-02.txt issues list thread-index: AcOdjMMocpb9bYRzRsyJ5pog/iDnMgAFFksgATcZ2KA= From: "Dave Thaler" To: X-OriginalArrivalTime: 04 Nov 2003 02:51:06.0262 (UTC) FILETIME=[7E27C360:01C3A27E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I've gone through the threads that Rich Draves sent me to extract=20 the issues raised with draft-ietf-ipv6-router-selection-02.txt. There were a number of relatively minor editorial suggestions to=20 which Rich had responded with an okay. These I am already=20 incorporating into the document. Besides those, there were 10 issues raised which are now at=20 http://www.icir.org/dthaler/RouterSelectionIssues.htm I should have a proposed update available prior to IETF. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 3 21:53:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10335 for ; Mon, 3 Nov 2003 21:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrJb-0007U0-UH for ipv6-archive@odin.ietf.org; Mon, 03 Nov 2003 21:53:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA42r7Gl028761 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 21:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrJb-0007To-NH for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 21:53:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10259 for ; Mon, 3 Nov 2003 21:52:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrJY-0003c7-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:53:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGrJY-0003c4-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrJW-0007LQ-7y; Mon, 03 Nov 2003 21:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrIq-0007En-F8 for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 21:52:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10184 for ; Mon, 3 Nov 2003 21:52:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrIn-0003af-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:52:17 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AGrIm-0003aG-00 for ipv6@ietf.org; Mon, 03 Nov 2003 21:52:17 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Nov 2003 21:56:36 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E6B@ftmail.lab.flarion.com> From: Soliman Hesham To: "'JinHyeock Choi'" , Soliman Hesham , "'Pekka Savola'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list: Prefixes with L=0 Date: Mon, 3 Nov 2003 21:55:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > If the purpose of prefixes with L=0 is to inform hosts to > send traffic > to the default router, why not omit those prefixes altogether from > RAs. Host will send the packets destined to unknown prefixes to a > default router anyway. => Because you want the host receiving the RA to be able to configure an address. If you omit the prefix option that host won't configure an address. > > > => If it is found that in some deployment cases the L=0 > > causes problems, the network admin is free to configure > > the routers accordingly and always use on-link prefixes. > > This is completely under the control of the admin. > > I wonder that there may be some wireless links on which admin can't > assign on-link prefixes. For example, a link with hidden > node problem > like 802.11 b ad-hoc mode or bluetooth. => I'm not sure I follow. > > > I think Fred Templin sent a question some time ago > > on this and Thomas explained how hosts should handle the > > case where the L flag is set to zero. We can add this clarification > > in the new revision if that helps. > > Fred Templin raised the issue whether it's possible to > advertise a prefix > with L=0 and A=1 and Thomas said so. Is this what you have in mind? => I think he raised both (see his last email). > And I think the prefix with L=0 and A=1 may cause unnoticed address > duplication. => If you advertise L =0 and want to assign the same prefix to multiple links, then you must be able to handle DAD, NS ...etc across links. This is what the ND proxy proposal does. In other words, if you have a multi-link subnet, you better know how to relay ND traffic across links otherwise you could end up with the problem you mention above. Hesham > > Best regards > > JinHyeock > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 00:34:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15981 for ; Tue, 4 Nov 2003 00:34:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtp3-0001B1-W1 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 00:33:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA45XjU9004517 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 00:33:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtp3-0001Am-Px for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 00:33:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15938 for ; Tue, 4 Nov 2003 00:33:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGtp1-00063N-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 00:33:43 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGtp0-00063I-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 00:33:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtoM-00014n-W5; Tue, 04 Nov 2003 00:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtoK-000146-Bh for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 00:33:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15923 for ; Tue, 4 Nov 2003 00:32:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGtoH-00062m-00 for ipv6@ietf.org; Tue, 04 Nov 2003 00:32:57 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AGtoH-00062b-00 for ipv6@ietf.org; Tue, 04 Nov 2003 00:32:57 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AF26D6A904; Tue, 4 Nov 2003 07:32:51 +0200 (EET) Message-ID: <3FA73905.60800@kolumbus.fi> Date: Tue, 04 Nov 2003 07:28:37 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: "Bound, Jim" , ipv6@ietf.org Subject: Re: Authors Section on recyle clarifications to 2461and 2462 References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1F3@tayexc13.americas.cpqcorp.net> <021b01c3a23d$0407a320$9f6015ac@dclkempt40> In-Reply-To: <021b01c3a23d$0407a320$9f6015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James Kempf wrote: > Jim, > > Are there any precedents? What has IETF done in other cases where specs have > been rev-ed? > > The only case I personally know of is Mobile IPv4, in which the > author/editor name was not changed when a new revision was put out, but > perhaps there are others where different procedures were followed. I guess all this depends on the amount of modifications. When SIP was revised from RFC 2542 to RFC 3261 or when EAP is being revised from RFC 2284, authors were indeed added. But in both cases the changes were quite significant, approaching a complete rewrite, even if the protocol itself stayed the same and backwards compatibility was retained. My take is that if the changes are small corrections here and there, the new editors (if different) deserve to be mentioned in the contributors or acknowledgements sections. If the changes are significant, including rewrites of complete sections or addition of new functions, then they should be listed at the top, after the original authors. If the case falls somewhere in between... one way could be to list the original authors as they are and after them add the new editor as "Mr. NewEditor (ed)". --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 00:57:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16555 for ; Tue, 4 Nov 2003 00:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuBk-0002f2-9s for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 00:57:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA45vCJ3010222 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 00:57:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuBk-0002en-4k for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 00:57:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16501 for ; Tue, 4 Nov 2003 00:57:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGuBh-0006L6-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 00:57:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGuBg-0006L3-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 00:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuBa-0002aN-UJ; Tue, 04 Nov 2003 00:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuAm-0002V3-4p for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 00:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16468 for ; Tue, 4 Nov 2003 00:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGuAj-0006KK-00 for ipv6@ietf.org; Tue, 04 Nov 2003 00:56:09 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AGuAi-0006K4-00 for ipv6@ietf.org; Tue, 04 Nov 2003 00:56:08 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA45tNls023031; Tue, 4 Nov 2003 14:55:27 +0900 (KST) Message-ID: <01f601c3a299$55999390$ec2f024b@tyre> From: "JinHyeock Choi" To: "Soliman Hesham" , "'Pekka Savola'" Cc: References: <748C6D0A58C0F94CA63C198B6674697A01922E6B@ftmail.lab.flarion.com> Subject: Re: RFC 2461- issue list: Prefixes with L=0 Date: Tue, 4 Nov 2003 15:03:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVzaGFtIA0KDQo+ICA+IEFuZCBJIHRoaW5rIHRoZSBwcmVmaXggd2l0aCBMPTAgYW5kIEE9MSBt YXkgY2F1c2UgdW5ub3RpY2VkIGFkZHJlc3MgDQo+ICA+IGR1cGxpY2F0aW9uLg0KPiANCj4gPT4g SWYgeW91IGFkdmVydGlzZSBMID0wIGFuZCB3YW50IHRvIGFzc2lnbiB0aGUgc2FtZSBwcmVmaXgN Cj4gdG8gbXVsdGlwbGUgbGlua3MsIHRoZW4geW91IG11c3QgYmUgYWJsZSB0byBoYW5kbGUgREFE LCBOUyAuLi5ldGMNCj4gYWNyb3NzIGxpbmtzLiBUaGlzIGlzIHdoYXQgdGhlIE5EIHByb3h5IHBy b3Bvc2FsIGRvZXMuIA0KPiBJbiBvdGhlciB3b3JkcywgaWYgeW91IGhhdmUgYSBtdWx0aS1saW5r IHN1Ym5ldCwgeW91IGJldHRlciBrbm93DQo+IGhvdyB0byByZWxheSBORCB0cmFmZmljIGFjcm9z cyBsaW5rcyBvdGhlcndpc2UgeW91IGNvdWxkIGVuZCANCj4gdXAgd2l0aCB0aGUgcHJvYmxlbSB5 b3UgbWVudGlvbiBhYm92ZS4gDQoNCkxldCBtZSBzdW1tYXJpemUgdGhlIGFib3ZlLg0KDQoxLiBJ biBwcmluY2lwbGUsIGEgcHJlZml4IGlzIGFzc2lnbmVkIHRvIG9ubHkgb25lIGxpbmssIHdoZXRo ZXIgTD0wIG9yIG5vdC4gDQoyLiBGb3IgbXVsdGktbGluayBzdWJuZXQgKHRoZSB1c2Ugb2YgdGhl IHNhbWUgc3VibmV0IHByZWZpeCBvbiBtdWx0aXBsZSBsaW5rKSwgDQogICAgc3BlY2lhbCBjYXJl IGlzIG5lZWRlZCwgZm9yIGV4YW1wbGUgTkQgcHJveHlpbmcuIA0KDQpSaWdodD8gDQoNClRoYW5r cyBmb3IgZW5saWdodGVuaW5nIGNvbW1lbnRzLiA6LSkgSSBoYXZlIGNsZWFyZXIgdmlzaW9uIG5v dy4gICANCg0KQmVzdCByZWdhcmRzDQoNCkppbkh5ZW9jayA= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 01:38:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17704 for ; Tue, 4 Nov 2003 01:38:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGupl-0005nt-QP for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 01:38:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA46cXpl022306 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 01:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGupl-0005ng-Ip for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 01:38:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17657 for ; Tue, 4 Nov 2003 01:38:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGupi-0006x1-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 01:38:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGuph-0006wy-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 01:38:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGupG-0005go-1o; Tue, 04 Nov 2003 01:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuob-0005Wj-5k for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 01:37:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17653 for ; Tue, 4 Nov 2003 01:37:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGuoX-0006wZ-00 for ipv6@ietf.org; Tue, 04 Nov 2003 01:37:17 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AGuoX-0006wW-00 for ipv6@ietf.org; Tue, 04 Nov 2003 01:37:17 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8BF43FCB1; Tue, 4 Nov 2003 01:37:16 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 Nov 2003 01:37:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Authors Section on recyle clarifications to 2461and 2462 Date: Tue, 4 Nov 2003 01:37:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B051224BD@tayexc13.americas.cpqcorp.net> Thread-Topic: Authors Section on recyle clarifications to 2461and 2462 Thread-Index: AcOiPQV/BNIUzNVxQx6FzIi2OiHLLwAYBzSQ From: "Bound, Jim" To: "James Kempf" , X-OriginalArrivalTime: 04 Nov 2003 06:37:16.0323 (UTC) FILETIME=[168ABF30:01C3A29E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We don't have precedence exactly. Usually same author does recycle. As I walk-the-walk and don't just talk-the-talk. For RFC 3493 we had multiple editor for years. But we never changed the original inventor of that API Robert Gilligan. ALso I have seen no significant technical value add except for the fine work from MIPv6. I have told Erik I believe MIPv6 should have its own ND spec if MIPv6 is to put that elsewhere, which I do not support as an engineer or implementor. I like it all in one spec and MIPv6 in current form is exactly correct to me as engineer and implementor. Bottom line I question putting any names on these specs. If we had to recycle 2460 and Steve is still gone and Bob Hinden don't have time (which I guess is the case with Erik and Thomas) would we add another name to the IPv6 specification? I don't believe we would out of respect to Steve. We likewise should not do that to these authors these two specs are as pristine and original as 2460 and as important to IPv6. I think we have an honor issue here. I would recycle and work on these and not even consider my name on the top of the drafts it would not be right. And I was here when both of these were born and most here were not even working on IPv6. We are a community and a community its honor is directly related to its respect for that which was invented by others and giving them that credit within the community. At least require significant "technical contribution" which is not the case here at all. =20 /jim > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Monday, November 03, 2003 2:02 PM > To: Bound, Jim; ipv6@ietf.org > Subject: Re: Authors Section on recyle clarifications to 2461and 2462 >=20 >=20 > Jim, >=20 > Are there any precedents? What has IETF done in other cases=20 > where specs have been rev-ed? >=20 > The only case I personally know of is Mobile IPv4, in which=20 > the author/editor name was not changed when a new revision=20 > was put out, but perhaps there are others where different=20 > procedures were followed. >=20 > jak >=20 >=20 > ----- Original Message -----=20 > From: "Bound, Jim" > To: > Sent: Saturday, November 01, 2003 11:00 PM > Subject: Authors Section on recyle clarifications to 2461and 2462 >=20 >=20 > > As we recycle 2461 and 2462 specifications I suggest that no=20 > > additional names be added to the authors names for two=20 > reasons. First=20 > > its not "honorable" as nothing has been discussed nor I perceive=20 > > currently will be learned that adds any architectural value of=20 > > "significance" to these widely deployed and important IPv6=20 > > specifications. The current authors worked for many years=20 > and earned=20 > > their names on this spec. Second I believe new editors=20 > should be put=20 > > at the bottom of the spec under recycle acknowledgements=20 > per the IETF=20 > > new rule to reduce author names on all specifications. > > > > My .50 cents, > > /jim > > > > --------------------------------------------------------- > > "You want to spread rumors and gossip about me? You want to=20 > question=20 > > my honor and integrity? You want to insult me to my face? Okay...go=20 > > right ahead. But, don't expect me to walk away. Don't expect me to=20 > > take it. Hell, don't expect me to hire a lawyer to do my=20 > fighting for=20 > > me. Some people are inherently peaceful. They're capable of=20 > swallowing=20 > > their anger or letting the legal system take its course. Maybe they=20 > > believe in some sort of Judgement Day, when we all have to=20 > account for=20 > > our transgressions. Me? I am not that patient." Chuck Zito from=20 > > "Street Justice" > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 01:43:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17837 for ; Tue, 4 Nov 2003 01:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuuD-0006Wm-5J for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 01:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA46h9Bp025086 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 01:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuuC-0006WX-Uj for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 01:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17802 for ; Tue, 4 Nov 2003 01:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGuu9-00070i-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 01:43:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGuu9-00070f-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 01:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGuu6-0006Ls-55; Tue, 04 Nov 2003 01:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGutU-0006J4-7F for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 01:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17798 for ; Tue, 4 Nov 2003 01:42:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGutQ-00070W-00 for ipv6@ietf.org; Tue, 04 Nov 2003 01:42:20 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AGutQ-00070T-00 for ipv6@ietf.org; Tue, 04 Nov 2003 01:42:20 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA46gKPh003136 for ; Mon, 3 Nov 2003 23:42:20 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNT00MSDEMJWA@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 03 Nov 2003 23:42:20 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNT002PDEMJ34@mail.sun.net> for ipv6@ietf.org; Mon, 03 Nov 2003 23:42:19 -0700 (MST) Date: Mon, 03 Nov 2003 22:45:07 -0800 From: Alain Durand Subject: Re: Thoughts on the draft-hinden last call In-reply-to: To: Christian Huitema Cc: ipv6@ietf.org, Hans Kruse Message-id: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote: > In the case in point, there is a significant constituency who believes > that they need a replacement for site local addresses, and that > "draft-hinden" is a reasonable way to obtain this replacement. You are > indeed free to not use such addresses and never deploy them within the > networks that you manage, but that does not change the needs of others. In principle, I would almost agree with this statement, with one caveat: "... as long as it does not break anything in the global Internet for people that do not use this proposal" As I explain in a previous message, this last property is not verified by the hinden/haberman draft, as when those addresses leak, they would create untraceable problems, very similar to the one caused by RFC1918 leaks today. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 02:04:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23248 for ; Tue, 4 Nov 2003 02:04:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvEp-0007RT-Sv for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 02:04:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA474RaB028579 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 02:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvEn-0007Qm-AV for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 02:04:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22642 for ; Tue, 4 Nov 2003 02:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvEg-0007GI-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 02:04:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGvEf-0007GE-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 02:04:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvET-0007Hr-0K; Tue, 04 Nov 2003 02:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvEG-0007HT-5a for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 02:03:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22056 for ; Tue, 4 Nov 2003 02:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvEC-0007Ft-00 for ipv6@ietf.org; Tue, 04 Nov 2003 02:03:48 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvEB-0007Ff-00 for ipv6@ietf.org; Tue, 04 Nov 2003 02:03:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA46qPn19249; Tue, 4 Nov 2003 08:52:25 +0200 Date: Tue, 4 Nov 2003 08:52:24 +0200 (EET) From: Pekka Savola To: Colm MacCarthaigh cc: Keith Moore , , , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031103224131.GA26982@castlerea.stdlib.net.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, 3 Nov 2003, Colm MacCarthaigh wrote: > > DNS is a specific lookup service. not a random one that just might happen > > to be around. > > NIS is a specific lookup service, as is WINS, and well I could go on ... > DNS may be more standardised, more widely-deployed and frankly - more > tasteful, but it is no more specific. It's not the only show in town :) > > I don't mean to be facetious here, of course I regard DNS as the "standard" > name to number resolver, but I'm a long long way from thinking it should > be the only means allowed for applications to resolve names. My personal experience is that the lookup mechanisms are rarely fully equivalent/replaceable. They give different kinds of results. /etc/hosts and DNS are (typically) pretty close to each other, but if you pluck in e.g. WINS, the names it'll give you are typically entirely different (starting from the format) from those learned from DNS. I'd expect similar inconsistancies if queries were done using LLMNR or ICMP Node Information Queries. The important point here is who configures the names to be looked up. Looking them up e.g. in LDAP would probably yield similar results than lookup up from the DNS (as they're very probably configured by the same entity) -- but asking from the node itself what it thinks its name is is *very* likely to yield different results than one would get asking his network administrator.. I think typically we have been interested of the latter, that is, what the network administrator of a node thinks a node's name is (and NOT what the node or its user thinks!) -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 02:13:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00803 for ; Tue, 4 Nov 2003 02:13:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvNR-0000rz-7g for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 02:13:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA47DLOr003295 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 02:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvNP-0000nL-14 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 02:13:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00703 for ; Tue, 4 Nov 2003 02:13:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvNL-0007OF-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 02:13:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGvNK-0007OA-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 02:13:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvNA-0000ct-Li; Tue, 04 Nov 2003 02:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGvN0-0000bw-Tc for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 02:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00647 for ; Tue, 4 Nov 2003 02:12:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGvMx-0007Ns-00 for ipv6@ietf.org; Tue, 04 Nov 2003 02:12:51 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AGvMw-0007NI-00 for ipv6@ietf.org; Tue, 04 Nov 2003 02:12:50 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Nov 2003 02:12:17 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E70@ftmail.lab.flarion.com> From: Soliman Hesham To: "'JinHyeock Choi'" , "'Pekka Savola'" Cc: ipv6@ietf.org Subject: RE: RFC 2461- issue list: Prefixes with L=0 Date: Tue, 4 Nov 2003 02:12:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Let me summarize the above. > > 1. In principle, a prefix is assigned to only one link, > whether L=0 or not. => This might be too strong a statement because it might limit other scenarios (apart from multi-link subnets) but I suppose based on current use this is roughly ok. > 2. For multi-link subnet (the use of the same subnet prefix > on multiple link), > special care is needed, for example ND proxying. > > Right? => Yes (with the above comment), that's my understanding. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 03:38:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03813 for ; Tue, 4 Nov 2003 03:38:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwhu-0008ER-9S for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 03:38:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA48cXR3031629 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 03:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwhs-0008Dr-6T for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 03:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03752 for ; Tue, 4 Nov 2003 03:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwhp-0000pK-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 03:38:29 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGwhp-0000pH-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 03:38:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwhQ-0007zR-0F; Tue, 04 Nov 2003 03:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwgu-0007to-HN for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 03:37:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03729 for ; Tue, 4 Nov 2003 03:37:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwgs-0000oX-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:37:30 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwgr-0000oU-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:37:29 -0500 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 IAA03819 for ; Tue, 4 Nov 2003 08:37:30 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA12143 for ; Tue, 4 Nov 2003 08:37:29 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA48bTU30145 for ipv6@ietf.org; Tue, 4 Nov 2003 08:37:29 GMT Date: Tue, 4 Nov 2003 08:37:29 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <20031104083729.GB30061@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, Nov 03, 2003 at 05:12:58PM -0800, Christian Huitema wrote: > > In the case in point, there is a significant constituency who believes > that they need a replacement for site local addresses, and that > "draft-hinden" is a reasonable way to obtain this replacement. You are > indeed free to not use such addresses and never deploy them within the > networks that you manage, but that does not change the needs of others. Agree 100%. IPv6 at least has the advantage that we have address space to offer anyone wanting local addressing a means to gain a unique (or as good as a unique) prefix to use, which is a big advantage on the (dis)ambiguity front. Leakage will still be an issue, but I don't believe that can be fixed by an RFC. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 03:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04131 for ; Tue, 4 Nov 2003 03:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwqK-0000Yh-Fm for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 03:47:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA48lG1G002141 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 03:47:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwqI-0000YS-Qo for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 03:47:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04103 for ; Tue, 4 Nov 2003 03:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwqB-00011F-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 03:47:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGwqB-00011C-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 03:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwq8-0000QU-3j; Tue, 04 Nov 2003 03:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwpx-0000PY-SB for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 03:46:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04072 for ; Tue, 4 Nov 2003 03:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwpv-00010N-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:46:51 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwpu-00010K-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:46:50 -0500 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 IAA04018 for ; Tue, 4 Nov 2003 08:46:51 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA12297 for ; Tue, 4 Nov 2003 08:46:51 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA48kpl30264 for ipv6@ietf.org; Tue, 4 Nov 2003 08:46:51 GMT Date: Tue, 4 Nov 2003 08:46:51 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Authors Section on recyle clarifications to 2461and 2462 Message-ID: <20031104084651.GD30061@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B051224BD@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B051224BD@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Nov 04, 2003 at 01:37:15AM -0500, Bound, Jim wrote: > > If we had to recycle 2460 and Steve is still gone and Bob Hinden don't > have time (which I guess is the case with Erik and Thomas) would we add > another name to the IPv6 specification? I don't believe we would out of > respect to Steve. We likewise should not do that to these authors these > two specs are as pristine and original as 2460 and as important to IPv6. The acknowledgements section seems an appropriate place? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 03:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04235 for ; Tue, 4 Nov 2003 03:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwsC-00019F-4E for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 03:49:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA48nCMp004405 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 03:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwsB-00018y-4K for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 03:49:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04203 for ; Tue, 4 Nov 2003 03:48:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGws8-00013P-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 03:49:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGws8-00013M-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 03:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGws2-00012D-HD; Tue, 04 Nov 2003 03:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwrG-0000w4-N9 for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 03:48:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04175 for ; Tue, 4 Nov 2003 03:48:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwrE-00012J-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:48:12 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwrD-00012F-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:48:11 -0500 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 IAA04033 for ; Tue, 4 Nov 2003 08:48:11 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA12386 for ; Tue, 4 Nov 2003 08:48:11 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA48mAd30283 for ipv6@ietf.org; Tue, 4 Nov 2003 08:48:10 GMT Date: Tue, 4 Nov 2003 08:48:10 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <20031104084810.GE30061@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, Nov 03, 2003 at 10:45:07PM -0800, Alain Durand wrote: > > As I explain in a previous message, this last property is not verified > by the hinden/haberman draft, as when those addresses leak, > they would create untraceable problems, very similar to the one > caused by RFC1918 leaks today. But could we ever stop leakage? And would it not be more dangerous if hijacked or randomly picked prefixes leaked instead of well-known (probabilistically unique) prefixes? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 05:17:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06868 for ; Tue, 4 Nov 2003 05:17:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyFN-0007oL-2D for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 05:17:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4AHDsN029972 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 05:17:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyFL-0007nB-Dh for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 05:17:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06831 for ; Tue, 4 Nov 2003 05:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyFI-0002MJ-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 05:17:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGyFH-0002MG-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 05:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyFA-0007eT-VV; Tue, 04 Nov 2003 05:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyF4-0007e7-7r for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 05:16:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06799 for ; Tue, 4 Nov 2003 05:16:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyF0-0002Le-00 for ipv6@ietf.org; Tue, 04 Nov 2003 05:16:50 -0500 Received: from dhcpw229.nc.u-tokyo.ac.jp ([133.11.123.229] helo=starfruit.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1AGyF0-0002La-00 for ipv6@ietf.org; Tue, 04 Nov 2003 05:16:50 -0500 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 7AF34199D5; Tue, 4 Nov 2003 19:16:34 +0900 (JST) To: Soliman Hesham Cc: ipv6@ietf.org In-reply-to: H.Soliman's message of Tue, 04 Nov 2003 04:34:42 EST. <748C6D0A58C0F94CA63C198B6674697A01922E77@ftmail.lab.flarion.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Issue 13: Omission of prefix options - resolution From: Jun-ichiro itojun Hagino Date: Tue, 04 Nov 2003 19:16:34 +0900 Message-Id: <20031104101634.7AF34199D5@starfruit.itojun.org> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >Suggested resolution: > >- Introduce a new code (1) in the router solicitation >and advertisement. When a host sends an RS with code = 1 >it requests that the RA include all prefixses valid on >that link. Similarly, when a router sends an RA with code=1 >it means that the RA includes all prefixes valid on that >link. This way, a MN can confirm its mobility. we cannot always correlate RS and RA (router can listen to RS, then issue RA on the next periodic advertisement). also RS does not solicit unicast RA. the above solution does not work. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 05:26:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07355 for ; Tue, 4 Nov 2003 05:26:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyOC-0000Pr-HU for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 05:26:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4AQKrq001592 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 05:26:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyOC-0000PW-Av for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 05:26:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07292 for ; Tue, 4 Nov 2003 05:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyO8-0002WD-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 05:26:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGyO6-0002W6-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 05:26:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyNu-00007i-HM; Tue, 04 Nov 2003 05:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyMz-00006z-JB for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 05:25:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07273 for ; Tue, 4 Nov 2003 05:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyMw-0002Vb-00 for ipv6@ietf.org; Tue, 04 Nov 2003 05:25:02 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyMt-0002VA-00 for ipv6@ietf.org; Tue, 04 Nov 2003 05:25:01 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA4AOMo22645; Tue, 4 Nov 2003 12:24:22 +0200 Date: Tue, 4 Nov 2003 12:24:19 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: ipv6@ietf.org Subject: Re: Issue 13: Omission of prefix options - resolution In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E77@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 4 Nov 2003, Soliman Hesham wrote: > - Introduce a new code (1) in the router solicitation > and advertisement. When a host sends an RS with code = 1 > it requests that the RA include all prefixses valid on > that link. Similarly, when a router sends an RA with code=1 > it means that the RA includes all prefixes valid on that > link. This way, a MN can confirm its mobility. I don't think this is necessary. There is plenty of space in RA's to include the prefixes. So, we're basically talking about the case where the network administrator has intentionally not advertised all the prefixes (in which case we need to educate them, but not necessarily in this document). Instead, I'd propose to explain that omitting prefixes could have adverse effects. (And also, without going into it in too much depth, maybe describe *which* adverse effects, but that's a potential can of worms.) -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 05:26:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07376 for ; Tue, 4 Nov 2003 05:26:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyOC-0000Pq-Gb for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 05:26:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4AQKDq001577 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 05:26:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyOC-0000PM-2l for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 05:26:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07289 for ; Tue, 4 Nov 2003 05:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyO8-0002WB-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 05:26:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGyO6-0002W5-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 05:26:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyNx-000091-Jp; Tue, 04 Nov 2003 05:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyNU-00007B-4z for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 05:25:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07279 for ; Tue, 4 Nov 2003 05:25:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyNQ-0002Vj-00 for ipv6@ietf.org; Tue, 04 Nov 2003 05:25:32 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AGyNP-0002Vg-00 for ipv6@ietf.org; Tue, 04 Nov 2003 05:25:32 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA4APIXO030490; Tue, 4 Nov 2003 12:25:18 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) id hA4APIt5030486; Tue, 4 Nov 2003 12:25:18 +0200 Date: Tue, 4 Nov 2003 12:25:18 +0200 Message-Id: <200311041025.hA4APIt5030486@burp.tkv.asdf.org> From: Markku Savela To: H.Soliman@flarion.com CC: ipv6@ietf.org In-reply-to: <748C6D0A58C0F94CA63C198B6674697A01922E77@ftmail.lab.flarion.com> (message from Soliman Hesham on Tue, 4 Nov 2003 04:34:42 -0500) Subject: Re: Issue 13: Omission of prefix options - resolution References: <748C6D0A58C0F94CA63C198B6674697A01922E77@ftmail.lab.flarion.com> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Suggested resolution: > > - Introduce a new code (1) in the router solicitation > and advertisement. When a host sends an RS with code = 1 > it requests that the RA include all prefixses valid on > that link. Similarly, when a router sends an RA with code=1 > it means that the RA includes all prefixes valid on that > link. This way, a MN can confirm its mobility. > > Comments? How does this work with multiple routers on the link in various combinations? Like - Routers may advertise different sets of prefixes, each their own. I don't there is any requirement for routers on link to advertise the same set of prefixes? - I was just experimenting with draft-ietf-ipngwg-router-selection-00.txt and have a "router" that sends RA with lifetime=0 (not a default router), 1 preferred route option, no prefixes. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 06:01:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08807 for ; Tue, 4 Nov 2003 06:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGywA-0003Xu-L9 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 06:01:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4B1QCv013624 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 06:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGywA-0003Xf-FW for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 06:01:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08712 for ; Tue, 4 Nov 2003 06:01:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyw6-0003BP-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:01:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGyw6-0003BM-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:01:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyvo-0003QR-At; Tue, 04 Nov 2003 06:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGyvN-0003L6-4M for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 06:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08621 for ; Tue, 4 Nov 2003 06:00:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyvJ-00039d-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:00:33 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AGyvI-00036I-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:00:32 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Nov 2003 05:59:58 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E79@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Jun-ichiro itojun Hagino'" Cc: ipv6@ietf.org Subject: RE: Issue 13: Omission of prefix options - resolution Date: Tue, 4 Nov 2003 05:59:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > >Suggested resolution: > > > >- Introduce a new code (1) in the router solicitation > >and advertisement. When a host sends an RS with code = 1 > >it requests that the RA include all prefixses valid on > >that link. Similarly, when a router sends an RA with code=1 > >it means that the RA includes all prefixes valid on that > >link. This way, a MN can confirm its mobility. > > we cannot always correlate RS and RA (router can listen > to RS, then > issue RA on the next periodic advertisement). also RS > does not solicit > unicast RA. => Sure, but for code = 1 this behaviour can be modified. Btw, the RA does not need to be unicast, it only needs to indicate that all prefixes are included (i.e. the new code). Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 06:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09423 for ; Tue, 4 Nov 2003 06:23:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzHC-0005Fn-Uc for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 06:23:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4BNAt5020189 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 06:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzHC-0005FY-Q9 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 06:23:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09361 for ; Tue, 4 Nov 2003 06:22:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzH8-0003Vv-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:23:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGzH8-0003Vr-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzH3-00058V-Sv; Tue, 04 Nov 2003 06:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzGX-00056l-EP for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 06:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09355 for ; Tue, 4 Nov 2003 06:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzGT-0003Vd-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:22:25 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AGzGS-0003VQ-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:22:24 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA4BLils018479; Tue, 4 Nov 2003 20:21:45 +0900 (KST) Message-ID: <011d01c3a2c6$ec02d9e0$ec2f024b@tyre> From: "JinHyeock Choi" To: "Pekka Savola" , "Soliman Hesham" Cc: References: Subject: Re: Issue 13: Omission of prefix options - resolution Date: Tue, 4 Nov 2003 20:29:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiAgSSBkb24ndCB0aGluayB0aGlzIGlzIG5lY2Vzc2FyeS4gIFRoZXJlIGlzIHBsZW50eSBvZiBz cGFjZSBpbiBSQSdzIHRvDQo+IGluY2x1ZGUgdGhlIHByZWZpeGVzLiAgU28sIHdlJ3JlIGJhc2lj YWxseSB0YWxraW5nIGFib3V0IHRoZSBjYXNlIHdoZXJlDQo+IHRoZSBuZXR3b3JrIGFkbWluaXN0 cmF0b3IgaGFzIGludGVudGlvbmFsbHkgbm90IGFkdmVydGlzZWQgYWxsIHRoZQ0KPiBwcmVmaXhl cyAoaW4gd2hpY2ggY2FzZSB3ZSBuZWVkIHRvIGVkdWNhdGUgdGhlbSwgYnV0IG5vdCBuZWNlc3Nh cmlseSBpbg0KPiB0aGlzIGRvY3VtZW50KS4NCj4gDQo+IEluc3RlYWQsIEknZCBwcm9wb3NlIHRv IGV4cGxhaW4gdGhhdCBvbWl0dGluZyBwcmVmaXhlcyBjb3VsZCBoYXZlIGFkdmVyc2UNCj4gZWZm ZWN0cy4gKEFuZCBhbHNvLCB3aXRob3V0IGdvaW5nIGludG8gaXQgaW4gdG9vIG11Y2ggZGVwdGgs IG1heWJlDQo+IGRlc2NyaWJlICp3aGljaCogYWR2ZXJzZSBlZmZlY3RzLCBidXQgdGhhdCdzIGEg cG90ZW50aWFsIGNhbiBvZiB3b3Jtcy4pDQoNCkV2ZW4gdGhvdWdoIGFuIFJBIGNvbnRhaW5zIGFs bCB0aGUgcHJlZml4ZXMsIHRoZXJlIGlzIG5vIGluZGljYXRpb24gdGhhdCBpdCBkb2VzLiANCg0K QWZ0ZXIgbGluayBjaGFuZ2UsIGlmIGFuIFJBIHdpdGhvdXQgdGhlIHByZWZpeCBvZiBpdHMgY3Vy cmVudCBDb0EgYXJyaXZlcywgbW9iaWxlIA0Kbm9kZSBjYW4ndCBiZSBzdXJlIHRoYXQgaXRzIENv QSBpcyBubyBsb25nZXIgdmFsaWQuIEhlbmNlIHN0aWxsIHVuY2VydGFpbnR5IHJlbWFpbnMgDQpm b3IgYSBtb2JpbGUgbm9kZS4gIA== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 06:41:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09980 for ; Tue, 4 Nov 2003 06:41:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzYc-0006Hj-NE for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 06:41:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4BfAFG024153 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 06:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzYc-0006HU-He for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 06:41:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09945 for ; Tue, 4 Nov 2003 06:40:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzYY-0003mQ-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:41:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGzYY-0003mN-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:41:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzYU-0006Bs-BW; Tue, 04 Nov 2003 06:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzY5-0006Aq-MK for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 06:40:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09914 for ; Tue, 4 Nov 2003 06:40:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzY1-0003lf-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:40:33 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzY0-0003lS-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:40:32 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA4BduW23935; Tue, 4 Nov 2003 13:39:56 +0200 Date: Tue, 4 Nov 2003 13:39:56 +0200 (EET) From: Pekka Savola To: JinHyeock Choi cc: Soliman Hesham , Subject: Re: Issue 13: Omission of prefix options - resolution In-Reply-To: <011d01c3a2c6$ec02d9e0$ec2f024b@tyre> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 4 Nov 2003, JinHyeock Choi wrote: > Even though an RA contains all the prefixes, there is no indication that > it does. > > After link change, if an RA without the prefix of its current CoA > arrives, mobile node can't be sure that its CoA is no longer valid. > Hence still uncertainty remains for a mobile node. Hence, we need to either make it clearer that the prefixes are not omitted, or make up better movement detection mechanisms. Do you have any specific reasons for this? There is really no reason to omit those prefixes that I could see. Rather than adding new code to verify this, shouldn't we just warn about this situation and be done with it? Or even state that prefixes SHOULD NOT (or MUST NOT) be omitted unless including them would cause a too big packet (over MTU) to be sent? That is, we seem to have different high-level views to this issue. I don't see that we need to fix this theoretical(?) problem, rather try to ensure that it won't happen. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 06:53:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10355 for ; Tue, 4 Nov 2003 06:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzkL-00072o-KQ for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 06:53:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4BrHMe027079 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 06:53:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzkL-00072g-A2 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 06:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10321 for ; Tue, 4 Nov 2003 06:53:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzkH-0003v9-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:53:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGzkG-0003v5-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 06:53:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzk5-0006ta-Sd; Tue, 04 Nov 2003 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGzjE-0006s6-4A for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 06:52:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10307 for ; Tue, 4 Nov 2003 06:51:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzj9-0003uJ-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:52:03 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AGzj8-0003u1-00 for ipv6@ietf.org; Tue, 04 Nov 2003 06:52:03 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA4BpKls020608; Tue, 4 Nov 2003 20:51:20 +0900 (KST) Message-ID: <015901c3a2cb$0dd26960$ec2f024b@tyre> From: "JinHyeock Choi" To: "Pekka Savola" , "Soliman Hesham" Cc: References: Subject: Re: Issue 13: Omission of prefix options - resolution Date: Tue, 4 Nov 2003 20:59:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TWFya2t1IFNhdmVsYSB3cm90ZQ0KPiA+IFN1Z2dlc3RlZCByZXNvbHV0aW9uOg0KPiA+IA0KPiA+ IC0gSW50cm9kdWNlIGEgbmV3IGNvZGUgKDEpIGluIHRoZSByb3V0ZXIgc29saWNpdGF0aW9uDQo+ ID4gYW5kIGFkdmVydGlzZW1lbnQuIFdoZW4gYSBob3N0IHNlbmRzIGFuIFJTIHdpdGggY29kZSA9 IDENCj4gPiBpdCByZXF1ZXN0cyB0aGF0IHRoZSBSQSBpbmNsdWRlIGFsbCBwcmVmaXhzZXMgdmFs aWQgb24NCj4gPiB0aGF0IGxpbmsuIFNpbWlsYXJseSwgd2hlbiBhIHJvdXRlciBzZW5kcyBhbiBS QSB3aXRoIGNvZGU9MQ0KPiA+IGl0IG1lYW5zIHRoYXQgdGhlIFJBIGluY2x1ZGVzIGFsbCBwcmVm aXhlcyB2YWxpZCBvbiB0aGF0DQo+ID4gbGluay4gVGhpcyB3YXksIGEgTU4gY2FuIGNvbmZpcm0g aXRzIG1vYmlsaXR5Lg0KPiA+IA0KPiA+IENvbW1lbnRzPw0KPiANCj4gSG93IGRvZXMgdGhpcyB3 b3JrIHdpdGggbXVsdGlwbGUgcm91dGVycyBvbiB0aGUgbGluayBpbiB2YXJpb3VzDQo+IGNvbWJp bmF0aW9ucz8gTGlrZQ0KPiANCj4gLSBSb3V0ZXJzIG1heSBhZHZlcnRpc2UgZGlmZmVyZW50IHNl dHMgb2YgcHJlZml4ZXMsIGVhY2ggdGhlaXIgb3duLiBJDQo+ICAgZG9uJ3QgdGhlcmUgaXMgYW55 IHJlcXVpcmVtZW50IGZvciByb3V0ZXJzIG9uIGxpbmsgdG8gYWR2ZXJ0aXNlIHRoZQ0KPiAgIHNh bWUgc2V0IG9mIHByZWZpeGVzPw0KDQpUaGlzIGlzIGEgcHJvYmxlbS4gVHdvIHJvdXRlcnMgb24g YSBsaW5rIGFkdmVydGlzaW5nIGRpZmZlcmVudCBzZXQgb2YgDQpwcmVmaXhlcyBtYWtlcyBtb3Zl bWVudCBkZXRlY3Rpb24gY29tcGxpY2F0ZWQuIA0KDQpJbiB0aGlzIGNhc2UsIHdlIG1heSBsZXQg ZWFjaCByb3V0ZXIgYmUgaW1wbGVtZW50ZWQgd2l0aCB0aGUgaG9zdC1zcGVjaWZpYyANCnBhcnQg b2YgUHJlZml4IERpc2NvdmVyeS4gSGVuY2UgaXQga25vd3MgdGhhdCB0aGUgcHJlZml4ZXMgYWR2 ZXJ0aXNlZCBieSANCm90aGVyIHJvdXRlcnMgYW5kIGFkdmVydGlzZXMgdGhlbSBpbiBpdHMgb3du IFJBcy4gVGhpcyBtYXkgYmUgYSBwb3NzaWJsZSANCnNvbHV0aW9uIGJ1dCBuZWVkcyBmdXJ0aGVy IGVsYWJvcmF0aW9uLiAgDQoNCkJ1dCBjdXJyZW50bHkgdGhlIGJlc3Qgc29sdXRpb24gc2VlbXMg dG8gYXZvaWQgc3VjaCBhIHNjZW5hcmlvLiA6LSkNCg0KQnkgdGhlIHdheSwgd2hpbGUgd29ya2lu ZyBvbiBNRCwgd2UgY2FtZSBhY3Jvc3MgYSBzaW1pbGFyIGlzc3VlIG9mIA0KJ29uLWxpbmsgcHJl Zml4IG9uIGEgd2lyZWxlc3MgbGluaycgYXMgYmVsb3dzLiAgDQoNCkFzc3VtZSB0aGVyZSBhcmUg dHdvIFJvdXRlcnMsIFJvdXRlcjEgYW5kIFJvdXRlciAyIG9uIGEgbGluayBsaWtlIA0KYSBmaWd1 cmUuIFRoZXkgc2hhcmUgb25lIEFjY2VzcyBQb2ludCBiZXR3ZWVuIHRoZW0uIA0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgX198X19fXyAgICAgICAgICBfX3xfX19fDQogICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICB8ICAgICAgICB8ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgIHxSb3V0ZXIgfCAg ICAgICAgfFJvdXRlcnwNCiAgICAgICAgICAgICAgICAgICAgICB8X19fMV9fIHwgICAgICAgIHxf X18yX198ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgQTo6IHwgICAgICAgICAgICAgICAg fCAgQjo6ICANCiAgICAgICAgICAgICAgICAgICAgICAgIF9ffF9fX19fX19fX19fX19fX198X19f X18gICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgX198X19fXyAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8QWNjZXNzfCAgICAgICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBQb2ludHwgICAgICAg ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxfX18g X198ICANCiAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUd28gcm91dGVycyBhZHZlcnRpc2Ug dHdvIGRpZmZlcmVudCBwcmVmaXhlcyBvbiB0aGVpciB3aXJlbGVzcyBpbnRlcmZhY2VzLiANClJv dXRlcjEgYWR2ZXJ0aXNlcyB0aGUgcHJlZml4IEE6OiBhbmQgUm91dGVyMiBhZHZlcnRpc2VzIHRo ZSB0aGUgcHJlZml4IEI6Oi4gDQoNCkFuZCB0aGV5IGluamVjdCB0aGUgcmVsYXRlZCByb3V0ZXMg dG8gSW50ZXJuZXQuIFJvdXRlcjEgaW5qZWN0cyByb3V0ZSBmb3IgQTo6IA0KYW5kIFJvdXRlcjIg aW5qZWN0cyByb3V0ZSBmb3IgQjo6LiAgDQoNCkJ1dCBhc3N1bWUgUm91dGVyMSBpcyBpbXBsZW1l bnRlZCB3aXRoIHRoZSBob3N0LXNwZWNpZmljIHBhcnQgb2YgUHJlZml4IA0KRGlzY292ZXJ5LiBI ZW5jZSBpdCBrbm93cyB0aGF0IHRoZSBwcmVmaXggQjo6IGlzIGFzc2lnbmVkIHRvIHRoZSBsaW5r IGJ5IA0KaGVhcmluZyBSQXMgZnJvbSBSb3V0ZXIyLiANCg0KVGhlbiB3aGF0IGlzIHRoZSBSb3V0 ZXIxJ3Mgb24tbGluayBwcmVmaXhlcyBvbiB0aGUgd2lyZWxlc3MgbGluaz8gDQpJcyBpdCB7UHJl Zml4IEE6On0gb3Ige1ByZWZpeCBBOjogLCBQcmVmaXggQjo6fT8gDQoNCldlIGxvb2tlZCB0aHJv dWdoIHRoZSBSRkMgMjQ2MSBidXQgY291bGRuJ3QgZmluZCBtdWNoIGFib3V0IA0Kcm91dGVycyBp bXBsZW1lbnRpbmcgdGhlIFByZWZpeCBEaXNjb3ZlcnkgdG8gZGlzY292ZXIgdGhlIG90aGVyIA0K b24tbGluayBwcmVmaXhlcy4gDQoNCkJlc3QgcmVnYXJkcw0KDQpKaW5IeWVvY2suICANCg0K -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 07:18:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11329 for ; Tue, 4 Nov 2003 07:18:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH08X-0000GX-Us for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 07:18:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4CIHcj001013 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 07:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH08X-0000GG-P2 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 07:18:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11297 for ; Tue, 4 Nov 2003 07:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH08X-0004Kj-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 07:18:17 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH08W-0004Kf-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 07:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH08I-00009e-CZ; Tue, 04 Nov 2003 07:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH089-00009M-Jp for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 07:17:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11277 for ; Tue, 4 Nov 2003 07:17:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH089-0004K3-00 for ipv6@ietf.org; Tue, 04 Nov 2003 07:17:53 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AH088-0004Jc-00 for ipv6@ietf.org; Tue, 04 Nov 2003 07:17:52 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA4CHCls022243; Tue, 4 Nov 2003 21:17:12 +0900 (KST) Message-ID: <017101c3a2ce$aaf0b410$ec2f024b@tyre> From: "JinHyeock Choi" To: "Pekka Savola" Cc: "Soliman Hesham" , References: Subject: Re: Issue 13: Omission of prefix options - resolution Date: Tue, 4 Nov 2003 21:25:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UGVra2EgU2F2b2xhIHdyb3RlDQo+IEhlbmNlLCB3ZSBuZWVkIHRvIGVpdGhlciBtYWtlIGl0IGNs ZWFyZXIgdGhhdCB0aGUgcHJlZml4ZXMgYXJlIG5vdA0KPiBvbWl0dGVkLCBvciBtYWtlIHVwIGJl dHRlciBtb3ZlbWVudCBkZXRlY3Rpb24gbWVjaGFuaXNtcy4NCg0KSSB0aGluayB3ZSBhZ3JlZWQg dGhhdCBpdCdzIG5lY2Vzc2FyeSB0byBtYWtlIGl0IGNsZWFyZXIgdGhhdCB0aGUgDQpwcmVmaXhl cyBhcmUgbm90IG9taXR0ZWQuIA0KDQpCdXQgaXQgc2VlbXMgdGhhdCBJIHByb3Bvc2UgdG8gaW5k aWNhdGUgaXQgZXhwbGljaXRseSBieSB1c2luZyBjb2RlID0xIA0KYW5kIHlvdSBhZHZvY2F0ZSB0 byBkbyBpdCBpbXBsaWNpdGx5IGJ5IG1hbmRhdGluZyAoaXMgaXQgdG9vIHN0cm9uZyB3b3JkPykN CmV2ZXJ5IFJBIGNvbnRhaW5zIGFsbCB0aGUgcHJlZml4ZXMuIA0KDQo+IFRoZXJlIGlzIHJlYWxs eSBubyByZWFzb24gdG8gb21pdCB0aG9zZSBwcmVmaXhlcyB0aGF0IEkgY291bGQgc2VlLiAgDQo+ IFJhdGhlciB0aGFuIGFkZGluZyBuZXcgY29kZSB0byB2ZXJpZnkgdGhpcywgc2hvdWxkbid0IHdl IGp1c3Qgd2FybiBhYm91dA0KPiB0aGlzIHNpdHVhdGlvbiBhbmQgYmUgZG9uZSB3aXRoIGl0PyAg T3IgZXZlbiBzdGF0ZSB0aGF0IHByZWZpeGVzIFNIT1VMRA0KPiBOT1QgKG9yIE1VU1QgTk9UKSBi ZSBvbWl0dGVkIHVubGVzcyBpbmNsdWRpbmcgdGhlbSB3b3VsZCBjYXVzZSBhIHRvbyBiaWcNCj4g cGFja2V0IChvdmVyIE1UVSkgdG8gYmUgc2VudD8NCg0KRm9yIG1lLCBlaXRoZXIgd2F5IGlzIE8u Sywgd2hldGhlciBleHBsaWNpdCBvciBpbXBsaWNpdCwgaWYgb25seSBpdCBtYWtlcyBub24NCi1v bWlzc2lvbiBjbGVhci4gV2UnZCBiZXR0ZXIgY29tcGFyZSB3aGljaCB3YXkgaXMgbW9yZSBlZmZp Y2llbnQsIGJhbm5pbmcgDQpvbWlzc2lvbiBvciBhZG9wdGluZyBhIG5ldyBjb2RlLiANCg0KQnV0 IGhlcmUgaXMgdGhlIGNvbmNlcm4gSSBoYXZlIG9uIGltcGxpY2l0IHdheS4gSW4gd2lyZWxlc3Mg bGluaywgYmFuZHdpZHRoDQppcyBhIHByZWNpb3VzIGNvbW1vZGl0eS4gTW9iaWxlIElQdjYgcmVk dWNlcyB0aGUgbG93ZXIgYm91bmQgb2YgdGhlIFJvdXRlciANCkFkdmVydGlzZW1lbnQgSW50ZXJ2 YWxzLiBHcmVnIERhbGV5IGNhbGN1bGF0ZWQgdGhhdCB0aGUgYmFuZHdpZHRoIGNvbnN1bXB0aW9u IA0KYnkgbXVsdGljYXN0ICBiZWFjb25zIGlzIDE0IGticHMgd2hlbiBSQXMgb25seSBpbmNsdWRl IG9uZSBQcmVmaXggSW5mb3JtYXRpb24gDQpvcHRpb24uIFNvIGluIHdpcmVsZXNzIGVudmlyb25t ZW50LCBpdCBtYXkgdGFrZSB0b28gbXVjaCBiYW5kd2lkdGggdG8gYWR2ZXJ0aXNlIA0KYWxsIHRo ZSBwcmVmaXhlcyBpbiBhbGwgdGhlIFJBcy4gIA0KDQpCZXN0IHJlZ2FyZHMgDQoNCkppbkh5ZW9j aw0KDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 07:22:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11510 for ; Tue, 4 Nov 2003 07:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0CC-0000iK-WB for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 07:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4CM4KD002738 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 07:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0CC-0000i5-QH for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 07:22:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11474 for ; Tue, 4 Nov 2003 07:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0CC-0004P9-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 07:22:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH0CB-0004P6-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 07:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0CA-0000cd-BX; Tue, 04 Nov 2003 07:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0Br-0000bG-KX for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 07:21:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11444 for ; Tue, 4 Nov 2003 07:21:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0Bq-0004OR-00 for ipv6@ietf.org; Tue, 04 Nov 2003 07:21:42 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AH0Bq-0004O3-00 for ipv6@ietf.org; Tue, 04 Nov 2003 07:21:42 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hA4CL6UP018433; Tue, 4 Nov 2003 04:21:07 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA4CL5S05883; Tue, 4 Nov 2003 13:21:05 +0100 (MET) Date: Tue, 4 Nov 2003 13:20:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Issue 13: Omission of prefix options - resolution To: Pekka Savola Cc: JinHyeock Choi , Soliman Hesham , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > There is really no reason to omit those prefixes that I could see. > Rather than adding new code to verify this, shouldn't we just warn about > this situation and be done with it? Or even state that prefixes SHOULD > NOT (or MUST NOT) be omitted unless including them would cause a too big > packet (over MTU) to be sent? Part of the consideration is the folks want to use RAs as frequent beacons for attachment detection. Making such beacons to carry potentially lots of prefixes, especially on bandwidth constrained (wireless) links, might be self-defeating. Thus recommending that all prefixes be sent every 10 milliseconds (or whatever the min number is in the MIPv6 spec) might not be the best approach. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 07:51:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12724 for ; Tue, 4 Nov 2003 07:51:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0eP-00034i-Is for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 07:51:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4CpDGQ011810 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 07:51:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0eP-00034O-7P for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 07:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12675 for ; Tue, 4 Nov 2003 07:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0eO-0004sW-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 07:51:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH0eN-0004sT-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 07:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0eG-0002yj-7o; Tue, 04 Nov 2003 07:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH0e2-0002xk-B7 for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 07:50:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12641 for ; Tue, 4 Nov 2003 07:50:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0e1-0004rC-00 for ipv6@ietf.org; Tue, 04 Nov 2003 07:50:49 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0e0-0004pw-00 for ipv6@ietf.org; Tue, 04 Nov 2003 07:50:48 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA4CoAL25278; Tue, 4 Nov 2003 14:50:10 +0200 Date: Tue, 4 Nov 2003 14:50:09 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: JinHyeock Choi , Soliman Hesham , Subject: Re: Issue 13: Omission of prefix options - resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 4 Nov 2003, Erik Nordmark wrote: > > There is really no reason to omit those prefixes that I could see. > > Rather than adding new code to verify this, shouldn't we just warn about > > this situation and be done with it? Or even state that prefixes SHOULD > > NOT (or MUST NOT) be omitted unless including them would cause a too big > > packet (over MTU) to be sent? > > Part of the consideration is the folks want to use RAs as frequent > beacons for attachment detection. Making such beacons to carry > potentially lots of prefixes, especially on bandwidth constrained > (wireless) links, might be self-defeating. > > Thus recommending that all prefixes be sent every 10 milliseconds (or > whatever the min number is in the MIPv6 spec) might not be the best > approach. Uhh, this seems like a total abuse of the RA mechanism :-). The point of it to be able to carry the prefixes needed for autoconfiguration. If it's supposed to be used for a beacon mechanism, I'd suggest considering whether one could find a method that does not send prefixes at ALL (or, just send the prefix of the router with prefixlen=128 if you really insist). This would enable you to retain the model where RA's would in fact be complete when they included prefix information options that the nodes would use. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 08:41:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14290 for ; Tue, 4 Nov 2003 08:41:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1R0-0006Ia-GK for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 08:41:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4DfQHH024206 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 08:41:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1R0-0006IL-AZ for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 08:41:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14242 for ; Tue, 4 Nov 2003 08:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH1Qz-0005c8-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 08:41:25 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH1Qy-0005c5-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 08:41:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1Qb-00067z-PE; Tue, 04 Nov 2003 08:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1Pt-00067J-7j for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 08:40:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14184 for ; Tue, 4 Nov 2003 08:40:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH1Pr-0005ap-00 for ipv6@ietf.org; Tue, 04 Nov 2003 08:40:16 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AH1Pr-0005ak-00 for ipv6@ietf.org; Tue, 04 Nov 2003 08:40:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 27C8914093; Tue, 4 Nov 2003 08:40:10 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26816-07; Tue, 4 Nov 2003 08:40:09 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id D435A14057; Tue, 4 Nov 2003 08:40:08 -0500 (EST) Date: Tue, 4 Nov 2003 07:35:14 -0500 From: Keith Moore To: Mohacsi Janos Cc: moore@cs.utk.edu, colm@stdlib.net, Stig.Venaas@uninett.no, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031104073514.61046c34.moore@cs.utk.edu> In-Reply-To: <20031104085701.X37922@mignon.ki.iif.hu> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > My argument is not that link-local addresses should be returned by > > getaddrinfo() , it is that getaddrinfo() should be transparent. > > Completely agree. The getaddrinfo() should be completely transparent from > programmers' point of view. The local setup should be system/environment > specific. I think the cleanest solution would be to setup the DNS > resolution order locally by administrator: IPv6 address-resolution enable, > and order of IPv4/IPv6 address-resolution. In my opinion, this should be > included the resolver code and configurable from resolv.conf. what you are describing is not transparent to applications that actually need to know what is in DNS. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 10:46:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19341 for ; Tue, 4 Nov 2003 10:46:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3O1-0004Ou-74 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 10:46:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4FkTUx016910 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 10:46:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3O0-0004Of-P4 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 10:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19273 for ; Tue, 4 Nov 2003 10:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3Ny-0007GG-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 10:46:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH3Ny-0007GD-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 10:46:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3Na-0004Iy-A8; Tue, 04 Nov 2003 10:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3NI-0004IP-TA for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 10:45:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19252 for ; Tue, 4 Nov 2003 10:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3NG-0007Fq-00 for ipv6@ietf.org; Tue, 04 Nov 2003 10:45:42 -0500 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1AH3NF-0007FB-00 for ipv6@ietf.org; Tue, 04 Nov 2003 10:45:42 -0500 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id hA4FjES15813; Tue, 4 Nov 2003 07:45:14 -0800 (PST) Received: (from tim@localhost) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) id hA4FjFZ17964; Tue, 4 Nov 2003 07:45:15 -0800 (PST) Date: Tue, 4 Nov 2003 07:45:15 -0800 (PST) From: Tim Hartrick Message-Id: <200311041545.hA4FjFZ17964@leo.mentat.com> To: ipv6@ietf.org, H.Soliman@flarion.com Subject: Re: Issue 13: Omission of prefix options - resolution X-Sun-Charset: US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hesham, > > Suggested resolution: > > - Introduce a new code (1) in the router solicitation > and advertisement. When a host sends an RS with code = 1 > it requests that the RA include all prefixses valid on > that link. Similarly, when a router sends an RA with code=1 > it means that the RA includes all prefixes valid on that > link. This way, a MN can confirm its mobility. > When this problem was noted in the early days I remember suggesting adding "Solicited" bit to the router advertisement to address this issue. Because of backward compatibility problems that solution will no longer work well. Is there some reason why we wouldn't want to add a new bit, say the "Complete" bit, to the reserved field of the router advertisement? I realize I just finished ranting against adding new bits but using one of the reserved bits for this purpose seems cleaner to me. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 11:56:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22537 for ; Tue, 4 Nov 2003 11:56:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Tg-00012s-9x for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 11:56:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4GuOiV004012 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 11:56:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Tg-00012d-4n for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 11:56:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22513 for ; Tue, 4 Nov 2003 11:56:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4Te-0000eS-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 11:56:23 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH4Te-0000eO-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 11:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4TK-0000tb-KF; Tue, 04 Nov 2003 11:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4QH-0000hf-NB for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 11:52:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22326 for ; Tue, 4 Nov 2003 11:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4QG-0000bK-00 for ipv6@ietf.org; Tue, 04 Nov 2003 11:52:52 -0500 Received: from smtp804.mail.ukl.yahoo.com ([217.12.12.141]) by ietf-mx with smtp (Exim 4.12) id 1AH4QF-0000b1-00 for ipv6@ietf.org; Tue, 04 Nov 2003 11:52:51 -0500 Received: from adsl-64-170-248-130.dsl.lsan03.pacbell.net (HELO eremmell) (elmic@sbcglobal.net@64.170.248.130 with login) by smtp1.bt.mail.vip.ukl.yahoo.com with SMTP; 4 Nov 2003 16:52:11 -0000 From: "Ed Remmell" To: "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" , "'Vijay Devarapalli'" Cc: , Subject: RE: [Mip6] Re: A list of issues for RFC2462 update Date: Tue, 4 Nov 2003 08:52:10 -0800 Message-ID: <001a01c3a2f3$fff16a70$0900a8c0@eremmell> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > RFC 2461 says > > > Before a host sends an initial solicitation, it SHOULD delay the > > transmission for a random amount of time between 0 and > > MAX_RTR_SOLICITATION_DELAY. > > > RFC 2462 says > > > 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 between 0 and > > MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. > > > MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst > > case scenario, it could be 1 second before a sending > > router solicitation, one second before sending neighbor > solicitation > > for DAD and then 1 second before DAD completes. the Binding Update > > cannot be sent until then. Please re-read the above RFC-2462 requirement closely: "If the Neighbor Solicitation is the first message to be sent from an interface after interface (re)initialization..." The DAD NS in this case is *NOT* the first message to be sent, the RS is. Therefore, you do not need the random delay prior to sending the DAD NS in this case. The same random delay before sending the RS can apply to the DAD NS (because it is sent after the RS). That's the way we implement it currently, and it causes us to fail a couple of TAHI tests :-( but we believe we are 100% compliant with the RFCs w/ regards to implementing it this way. Thanks. - Ed Remmell Elmic Systems, USA --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 12:23:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23946 for ; Tue, 4 Nov 2003 12:23:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4tn-0003oL-8N for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 12:23:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4HNNaC014643 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 12:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4tn-0003nw-3V for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 12:23:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23869 for ; Tue, 4 Nov 2003 12:23:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4tl-0001BD-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 12:23:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH4tl-0001BA-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 12:23:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4tR-0003eq-V6; Tue, 04 Nov 2003 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4sm-0003eF-3b for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 12:22:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23837 for ; Tue, 4 Nov 2003 12:22:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4sk-0001AV-00 for ipv6@ietf.org; Tue, 04 Nov 2003 12:22:18 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AH4sk-00019s-00 for ipv6@ietf.org; Tue, 04 Nov 2003 12:22:18 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 Nov 2003 09:21:47 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 Nov 2003 09:21:43 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Nov 2003 09:21:41 -0800 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.6713); Tue, 4 Nov 2003 09:21:38 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 Nov 2003 09:21:43 -0800 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.3790.1069); Tue, 4 Nov 2003 09:21:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Thoughts on the draft-hinden last call Date: Tue, 4 Nov 2003 09:21:43 -0800 Message-ID: Thread-Topic: Thoughts on the draft-hinden last call thread-index: AcOisKFI5BKuhGglRUec6IQX4uT3MQARcXSQ From: "Christian Huitema" To: "Tim Chown" , X-OriginalArrivalTime: 04 Nov 2003 17:21:45.0324 (UTC) FILETIME=[1F100AC0:01C3A2F8] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > On Mon, Nov 03, 2003 at 10:45:07PM -0800, Alain Durand wrote: > > > > As I explain in a previous message, this last property is not verified > > by the hinden/haberman draft, as when those addresses leak, > > they would create untraceable problems, very similar to the one > > caused by RFC1918 leaks today. >=20 > But could we ever stop leakage? >=20 > And would it not be more dangerous if hijacked or randomly picked prefixes > leaked instead of well-known (probabilistically unique) prefixes? Let's assume that the need won't go away. We have de facto three local addressing proposals: use the existing site local prefix, hijack a prefix in the 2000::/3 space, or draft-hinden. Site administrators who perceive this need will pick one of these three proposal. How do they compare from a "leak" point of view? My take is as follow: - using site local is roughly equivalent to using net 10 in IPv4. The address range can be filtered in routers, but it is ambiguous. Ambiguity prevents tracing the source of the leaks. - hijack a prefix is roughly equivalent to the pre-RFC-1958 situation in IPv4, e.g. alumni reusing the MIT address space. The address range can be filtered in some routers, but not in all of them. Leaks are difficult to even notice, and result in misdirection of traffic to an unsuspecting party. Leaks in the routing protocols result in routing disruption. - the addresses proposed in draft-hinden appear to be strictly better than either the existing site-local or hijacked addresses. They can be filtered in routers. Attempts at uniqueness give us a reasonable hope of tracing the source of leaks. They don't conflict with existing addresses, so the leaks don't affect the connectivity or the traffic load of third parties. In short, the proposed addresses cannot eliminate application level leaks, but they can definitely reduce their consequences, and do a much better job at that than the alternatives. -- Christian Huitema =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 12:26:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24236 for ; Tue, 4 Nov 2003 12:26:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4wR-0004FI-KZ for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 12:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4HQ7fG016314 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 12:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4wR-0004F3-6k for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 12:26:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24172 for ; Tue, 4 Nov 2003 12:25:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4wP-0001IQ-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 12:26:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH4wO-0001IN-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 12:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4wN-00046T-Rp; Tue, 04 Nov 2003 12:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4wH-00045h-NG for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 12:25:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24168 for ; Tue, 4 Nov 2003 12:25:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4wG-0001IC-00 for ipv6@ietf.org; Tue, 04 Nov 2003 12:25:56 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4wF-0001I4-00 for ipv6@ietf.org; Tue, 04 Nov 2003 12:25:55 -0500 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 RAA04884 for ; Tue, 4 Nov 2003 17:25:53 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA10054 for ; Tue, 4 Nov 2003 17:25:53 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA4HPrF06743 for ipv6@ietf.org; Tue, 4 Nov 2003 17:25:53 GMT Date: Tue, 4 Nov 2003 17:25:53 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <20031104172553.GE2847@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Nov 04, 2003 at 09:21:43AM -0800, Christian Huitema wrote: > > - the addresses proposed in draft-hinden appear to be strictly better > than either the existing site-local or hijacked addresses. They can be > filtered in routers. Attempts at uniqueness give us a reasonable hope of > tracing the source of leaks. They don't conflict with existing > addresses, so the leaks don't affect the connectivity or the traffic > load of third parties. > > In short, the proposed addresses cannot eliminate application level > leaks, but they can definitely reduce their consequences, and do a much > better job at that than the alternatives. I think this is a good summary and a good reason to move forward with the draft-hinden proposal as a best compromise (since no solution is perfect). Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 12:43:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24867 for ; Tue, 4 Nov 2003 12:43:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5D7-000608-W8 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 12:43:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4HhLTR023062 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 12:43:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5D7-0005zt-QE for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 12:43:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24837 for ; Tue, 4 Nov 2003 12:43:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5D4-0001b9-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 12:43:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH5D4-0001b6-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 12:43:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5Co-0005iU-Jn; Tue, 04 Nov 2003 12:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5CZ-0005cx-CZ for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 12:42:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24816 for ; Tue, 4 Nov 2003 12:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5CX-0001aW-00 for ipv6@ietf.org; Tue, 04 Nov 2003 12:42:45 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AH5CX-0001aT-00 for ipv6@ietf.org; Tue, 04 Nov 2003 12:42:45 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA4HgiPh009808 for ; Tue, 4 Nov 2003 10:42:44 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNU006E79782K@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 04 Nov 2003 10:42:44 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNU00HO1977UN@mail.sun.net> for ipv6@ietf.org; Tue, 04 Nov 2003 10:42:44 -0700 (MST) Date: Tue, 04 Nov 2003 09:45:31 -0800 From: Alain Durand Subject: Re: Thoughts on the draft-hinden last call In-reply-to: <20031104084810.GE30061@login.ecs.soton.ac.uk> To: Tim Chown Cc: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Nov 4, 2003, at 12:48 AM, Tim Chown wrote: > On Mon, Nov 03, 2003 at 10:45:07PM -0800, Alain Durand wrote: >> >> As I explain in a previous message, this last property is not verified >> by the hinden/haberman draft, as when those addresses leak, >> they would create untraceable problems, very similar to the one >> caused by RFC1918 leaks today. > > But could we ever stop leakage? > > And would it not be more dangerous if hijacked or randomly picked > prefixes > leaked instead of well-known (probabilistically unique) prefixes? You're assuming that the alternative to hinden/haberman is hijacking random prefixes. I don't. I see allocation of real PI (by real I mean registered) a more serious alternative. The more I think about it, the more I come to the conclusion that the issue with the hinden/haberman draft is that those prefixes cannot be trace back, making them as good (or as bad) as ambiguous. I just saw a press release from a company building high speed network chips that claim they can process up to a million route at 40 Gb/s... so I'm honestly thinking that handing out PI to people who can justify the need is not as scary as it sounds, at least it would enable us to wait until we get something from Multi6. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 13:01:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25443 for ; Tue, 4 Nov 2003 13:01:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5Ug-0007AG-98 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 13:01:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4I1UEp027539 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 13:01:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5Uf-0007A6-VP for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 13:01:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25420 for ; Tue, 4 Nov 2003 13:01:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5Ue-0001rM-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:01:28 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH5Ud-0001rJ-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:01:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5UE-000753-Kx; Tue, 04 Nov 2003 13:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5U5-000741-3L for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 13:00:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25384 for ; Tue, 4 Nov 2003 13:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5U3-0001qn-00 for ipv6@ietf.org; Tue, 04 Nov 2003 13:00:51 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5U2-0001qk-00 for ipv6@ietf.org; Tue, 04 Nov 2003 13:00:50 -0500 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 SAA05732 for ; Tue, 4 Nov 2003 18:00:49 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA11787 for ; Tue, 4 Nov 2003 18:00:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA4I0nm07380 for ipv6@ietf.org; Tue, 4 Nov 2003 18:00:49 GMT Date: Tue, 4 Nov 2003 18:00:49 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <20031104180049.GK2847@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Nov 04, 2003 at 09:45:31AM -0800, Alain Durand wrote: > > You're assuming that the alternative to hinden/haberman is hijacking > random prefixes. > I don't. I see allocation of real PI (by real I mean registered) a more > serious alternative. > The more I think about it, the more I come to the conclusion that the > issue > with the hinden/haberman draft is that those prefixes cannot be trace > back, > making them as good (or as bad) as ambiguous. > > I just saw a press release from a company building high speed network > chips > that claim they can process up to a million route at 40 Gb/s... > so I'm honestly thinking that handing out PI to people who can justify > the need > is not as scary as it sounds, at least it would enable us to wait until > we get something > from Multi6. Sure if you can provide a solution for PI addressing then you will solve many issues in one... the question for you is then how these people "justify their need" - will anyone who would be able to get a unique hinden/haberman draft prefix be eligible for your PI prefix? How do we control or throttle the allocations and not regret it later? With current IPv6 adoption we don't have a problem though... (!) Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 13:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26359 for ; Tue, 4 Nov 2003 13:26:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5sX-0000d0-Du for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 13:26:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4IQ9U6002408 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 13:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5sX-0000cl-7T for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 13:26:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26329 for ; Tue, 4 Nov 2003 13:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5sV-0002D9-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:26:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH5sU-0002D6-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5sQ-0000UA-Cq; Tue, 04 Nov 2003 13:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5rU-0000TB-Ee for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 13:25:04 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26315 for ; Tue, 4 Nov 2003 13:24:50 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AH5et-0008CF-9U; Tue, 04 Nov 2003 13:12:03 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: ipv6@ietf.org From: The IESG Subject: Last Call: 'IP Forwarding Table MIB' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Tue, 04 Nov 2003 13:12:03 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'IP Forwarding Table MIB ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-05.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 13:53:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27642 for ; Tue, 4 Nov 2003 13:53:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6Il-0002pg-17 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 13:53:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4IrFkx010887 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 13:53:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6Ik-0002pW-RM for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 13:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27609 for ; Tue, 4 Nov 2003 13:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6Ii-0002g3-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:53:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6Ii-0002g0-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:53:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6IY-0002gr-Jy; Tue, 04 Nov 2003 13:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6IA-0002gV-R2 for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 13:52:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27602 for ; Tue, 4 Nov 2003 13:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6I8-0002fh-00 for ipv6@ietf.org; Tue, 04 Nov 2003 13:52:36 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AH6I7-0002fe-00 for ipv6@ietf.org; Tue, 04 Nov 2003 13:52:36 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA4IqZ5u011669 for ; Tue, 4 Nov 2003 11:52:35 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNU00IOPCFNCZ@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 04 Nov 2003 11:52:35 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNU00H3CCFMUN@mail.sun.net> for ipv6@ietf.org; Tue, 04 Nov 2003 11:52:35 -0700 (MST) Date: Tue, 04 Nov 2003 10:55:22 -0800 From: Alain Durand Subject: Re: Thoughts on the draft-hinden last call In-reply-to: <20031104180049.GK2847@login.ecs.soton.ac.uk> To: Tim Chown Cc: ipv6@ietf.org Message-id: <717A967A-0EF8-11D8-AFDA-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> <20031104180049.GK2847@login.ecs.soton.ac.uk> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Nov 4, 2003, at 10:00 AM, Tim Chown wrote: > How do we control or throttle the allocations and not regret it later? > With current IPv6 adoption we don't have a problem though... (!) Exactly the point... The fear of a gold rush has been driving many similar discussions over the last few years. The reality is very different. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 13:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27960 for ; Tue, 4 Nov 2003 13:59:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6OT-0003Rk-Ha for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 13:59:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Ix9l9013248 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 13:59:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6OS-0003Rb-SO for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 13:59:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27889 for ; Tue, 4 Nov 2003 13:58:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6OQ-0002oW-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:59:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6OQ-0002oT-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 13:59:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6OL-0003J7-Rl; Tue, 04 Nov 2003 13:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6NR-0003E0-Tg for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 13:58:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27791 for ; Tue, 4 Nov 2003 13:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6NP-0002lX-00 for ipv6@ietf.org; Tue, 04 Nov 2003 13:58:03 -0500 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1AH6NO-0002kh-00 for ipv6@ietf.org; Tue, 04 Nov 2003 13:58:02 -0500 Received: from nttmcl.com (daal.nttmcl.com [216.69.69.11]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id hA4IvJHB079254; Tue, 4 Nov 2003 10:57:19 -0800 (PST) (envelope-from gene@nttmcl.com) Message-ID: <3FA7F703.3060904@nttmcl.com> Date: Tue, 04 Nov 2003 10:59:15 -0800 From: "Eugene M. Kim" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en, ko-kr, ko MIME-Version: 1.0 To: Keith Moore CC: Mohacsi Janos , colm@stdlib.net, Stig.Venaas@uninett.no, pekkas@netcore.fi, ipv6@ietf.org Subject: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> In-Reply-To: <20031104073514.61046c34.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Trimmed v6ops@ from Cc: as I believe this has less to do with network operation.) Keith Moore wrote: >>>My argument is not that link-local addresses should be returned by >>>getaddrinfo() , it is that getaddrinfo() should be transparent. >>> >>Completely agree. The getaddrinfo() should be completely transparent from >>programmers' point of view. The local setup should be system/environment >>specific. I think the cleanest solution would be to setup the DNS >>resolution order locally by administrator: IPv6 address-resolution enable, >>and order of IPv4/IPv6 address-resolution. In my opinion, this should be >>included the resolver code and configurable from resolv.conf. >> > >what you are describing is not transparent to applications that actually >need to know what is in DNS. > So there seem to be at least two alternatives: * Change/fix the definition of getaddrinfo()/getnameinfo() so they are tied to DNS only but nothing else. * Keep the current semantics of those functions, then update and standarize an API that strictly queries DNS only (res_XXX() and dn_XXX() comes to mind first; if they fall short of what real applications need, we could always define a new superset). Perhaps it'd be desirable to see some actual figures; how much percentage of the applications out there that use gethostbyXXX()/getaddrinfo()/getnameinfo() would assume those functions look up DNS records *only*, and would be severely broken if they were given results not based on DNS. If most of the applications would be broken, it would certainly be worth the trouble to go for the first option (this means going through the lengthy process of updating POSIX as well, because these functions are specified in it too). However, my impression was that a vast majority of applications out there use the functions in their original semantics (i.e. as a shorthand facility for specifying human-readable text form of addresses, not as a frontend interface for DNS only but nothing else), e.g. `ping6 www.kame.net' certainly wouldn't care if the IPv6 address getaddrinfo() returns comes from DNS, NIS, or any other mechanism. I'd gladly stand corrected if there are statistics that say otherwise. My 20 Korean Wons (1 USD ~= 1200 KRW last time I checked :p), Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 14:16:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28922 for ; Tue, 4 Nov 2003 14:16:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6f9-0005EJ-Jf for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 14:16:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JGNl9020097 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 14:16:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6f9-0005E4-E2 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 14:16:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28866 for ; Tue, 4 Nov 2003 14:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6f6-0003Bb-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:16:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6f6-0003BY-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:16:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6eo-00056J-Ua; Tue, 04 Nov 2003 14:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6eC-00054x-7l for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 14:15:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28796 for ; Tue, 4 Nov 2003 14:15:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6e9-0003AW-00 for ipv6@ietf.org; Tue, 04 Nov 2003 14:15:21 -0500 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1AH6e9-00037j-00 for ipv6@ietf.org; Tue, 04 Nov 2003 14:15:21 -0500 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id hA4JEpS19221; Tue, 4 Nov 2003 11:14:53 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id hA4JEpI03785; Tue, 4 Nov 2003 11:14:51 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA23719; Tue, 4 Nov 2003 11:18:52 -0800 (PST) Date: Tue, 4 Nov 2003 11:18:52 -0800 (PST) From: Tim Hartrick Message-Id: <200311041918.LAA23719@feller.mentat.com> To: H.Soliman@flarion.com, itojun@iijlab.net Subject: Re: Issue 13: Omission of prefix options - resolution Cc: ipv6@ietf.org X-Sun-Charset: US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , All, > > >Suggested resolution: > > > >- Introduce a new code (1) in the router solicitation > >and advertisement. When a host sends an RS with code = 1 > >it requests that the RA include all prefixses valid on > >that link. Similarly, when a router sends an RA with code=1 > >it means that the RA includes all prefixes valid on that > >link. This way, a MN can confirm its mobility. > > we cannot always correlate RS and RA (router can listen to RS, then > issue RA on the next periodic advertisement). also RS does not solicit > unicast RA. the above solution does not work. > The code or bit don't work all by themselves. Clearly, new protocol machinery will need to be specified so that hosts which understand the new code or bit can live happily on subnets that don't have routers that speak using the new code or bit. The other combinations of old and new behavior will need to be considered as well. Pekka's suggestion of making router advertisements all or nothing with respect to the inclusion of prefix options would achieve the same ends. We need a way for routers to communicate that there is more information available and we need to work out the backward compatibility details for the cases where either the host or the router don't understand or speak the new dialect. It doesn't sound impossible but it also sounds like more than just a minor bug fix to the specification. It would have been nice to fix this when the problem was first noted several years ago. That would have eliminated the need to worry about backward compatibility. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 14:24:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29474 for ; Tue, 4 Nov 2003 14:24:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6mc-0006az-No for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 14:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JO6pC025347 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 14:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6mc-0006ak-Jv for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 14:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29414 for ; Tue, 4 Nov 2003 14:23:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6mZ-0003Nl-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:24:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6mZ-0003Ni-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6mX-0006Ry-Sm; Tue, 04 Nov 2003 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6mP-0006Re-O8 for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 14:23:53 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29380 for ; Tue, 4 Nov 2003 14:23:41 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AH6fJ-0003MU-Ad; Tue, 04 Nov 2003 14:16:33 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: ipv6@ietf.org From: The IESG Subject: REVISED Last Call: 'Management Information Base for the Internet Protocol (IP)' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Tue, 04 Nov 2003 14:16:33 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The IESG has received a request from the IP Version 6 Working Group to consider the following document: - 'Management Information Base for the Internet Protocol (IP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-26. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-04.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 14:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00657 for ; Tue, 4 Nov 2003 14:46:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH77x-0000Ih-Mx for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 14:46:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Jk9qZ001149 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 14:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH77x-0000IS-EQ for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 14:46:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00610 for ; Tue, 4 Nov 2003 14:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH77u-0003ri-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:46:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH77u-0003rf-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH77q-0000Dq-Lp; Tue, 04 Nov 2003 14:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH770-0000B2-Jq for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 14:45:10 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00559 for ; Tue, 4 Nov 2003 14:44:57 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AH6mm-0003wL-8b; Tue, 04 Nov 2003 14:24:16 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: ipv6@ietf.org From: The IESG Subject: REVISED Last Call: 'Management Information Base for the Transmission Control Protocol (TCP)' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Tue, 04 Nov 2003 14:24:16 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , The IESG has received a request from the IP Version 6 Working Group to consider the following document: - 'Management Information Base for the Transmission Control Protocol (TCP)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-26. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-04.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 17:03:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08079 for ; Tue, 4 Nov 2003 17:03:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9GU-0000QK-Cj for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 17:03:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4M36TM001627 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 17:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9GU-0000QA-7A for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08042 for ; Tue, 4 Nov 2003 17:02:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9GS-0006WZ-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:03:04 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AH9GR-0006WW-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:03:03 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AH9GL-0007da-7T for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:02:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9FR-00009b-Lf; Tue, 04 Nov 2003 17:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Ey-00008p-72 for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 17:01:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07948; Tue, 4 Nov 2003 17:01:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Ev-0006Uw-00; Tue, 04 Nov 2003 17:01:29 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Ev-0006U2-00; Tue, 04 Nov 2003 17:01:29 -0500 Received: from jurassic.eng.sun.com ([129.146.84.45]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA4M0xxA019122; Tue, 4 Nov 2003 14:00:59 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with SMTP id hA4M0wDd410505; Tue, 4 Nov 2003 14:00:58 -0800 (PST) Message-Id: <200311042200.hA4M0wDd410505@jurassic.eng.sun.com> Date: Tue, 4 Nov 2003 14:02:19 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Address Selection API draft To: ipv6@ietf.org Cc: erik.nordmark@sun.com, julien.laganier@sun.com, samita.chakrabarti@sun.com, mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: eHxfkK7voWH0pRCTrZKT3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , A revised version of Address Selection API draft, http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-02.txt has been published recently. At Vienna IETF, the working group was polled to see if this document should become a WG item - I understand that more people wanted to read the draft to make a final decision. The following updates have been made as per working group input since then: * Added comments on JAVA API which might use this draft as a guideline. (section 1) * A section on design alternatives of API (section 2) * The Address selection API draft now addresses specific destination address selection as well as source address selection. socket option is changed from IPV6_SRC_PREFERENCES to IPV6_ADDR_PREFERENCES (section 4) * Introduced new flags for altering rules of default selection of destination address scope (section 4 and 5) * Discusses application requirement to support this API draft and implementation notes (section 6 and 7) * Discusses the choice of address selection rules from RFC3484 in the context of usefulness of this API (section 8) ---------------------------------------------- Please provide comments on this draft to the ipv6@ietf.org list and to the authors (CC'ed). Since it has been identified in the IPv6 group that a API is necessary for application specific control of address selection on a rfc3484 compliant system, the authors like to close any remaining issues on the list and request the working group to take this work as a working group item. Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 17:15:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08489 for ; Tue, 4 Nov 2003 17:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9SK-0001PF-Uz for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 17:15:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MFKVG005399 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 17:15:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9SK-0001P0-Mk for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08457 for ; Tue, 4 Nov 2003 17:15:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9SI-0006ig-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:15:18 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AH9SH-0006id-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:15:17 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AH9SH-0007uu-Av for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:15:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9S2-00018R-Pq; Tue, 04 Nov 2003 17:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9RZ-00017l-6i for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 17:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08434 for ; Tue, 4 Nov 2003 17:14:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9RW-0006fq-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:14:31 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AH9RW-0006fn-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:14:30 -0500 Received: from jurassic.eng.sun.com ([129.146.84.45]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA4MESPh026839 for ; Tue, 4 Nov 2003 15:14:28 -0700 (MST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with SMTP id hA4MESDd421049; Tue, 4 Nov 2003 14:14:28 -0800 (PST) Message-Id: <200311042214.hA4MESDd421049@jurassic.eng.sun.com> Date: Tue, 4 Nov 2003 14:15:48 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Extenstions to IPv6 Socket API for Mobile IP To: ipv6@ietf.org Cc: erik.nordmark@sun.com, samita.chakrabarti@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IUXHTpB+blhJDyFSgj9lUw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Fyi: Extension to Sockets API for Mobile IPv6: http://www.ietf.org/internet-drafts/draft-chakrabarti-mobileip-mipext-advapi-02. txt has been published recently and it will be discussed in the mip6 WG. Please send any comments to mip6@ietf.org alias and to the authors. Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 17:17:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08607 for ; Tue, 4 Nov 2003 17:17:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9U6-0001jm-ES for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 17:17:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MHAuG006672 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 17:17:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9U6-0001jX-5V for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08560 for ; Tue, 4 Nov 2003 17:16:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9U3-0006ks-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:17:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9U3-0006kp-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Ty-0001Wf-97; Tue, 04 Nov 2003 17:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9T4-0001Vo-3a for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 17:16:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08518 for ; Tue, 4 Nov 2003 17:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9T1-0006jl-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:16:03 -0500 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1AH9T0-0006iy-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:16:02 -0500 Received: from nttmcl.com (daal.nttmcl.com [216.69.69.11]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id hA4MFSHB084799; Tue, 4 Nov 2003 14:15:28 -0800 (PST) (envelope-from gene@nttmcl.com) Message-ID: <3FA824FD.2040807@nttmcl.com> Date: Tue, 04 Nov 2003 14:15:25 -0800 From: "Eugene M. Kim" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en, ko-kr, ko MIME-Version: 1.0 To: Keith Moore CC: ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> In-Reply-To: <20031104141639.1c9d1d56.moore@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Trimmed down Cc: list again, assuming we are all reading ipv6@...) Keith Moore wrote: >>So there seem to be at least two alternatives: >> >> * Change/fix the definition of getaddrinfo()/getnameinfo() so they >> are tied to DNS only but nothing else. >> * Keep the current semantics of those functions, then update and >> standarize an API that strictly queries DNS only (res_XXX() and >> dn_XXX() comes to mind first; if they fall short of what real >> applications need, we could always define a new superset). >> > >There's a third option - like I suggested earlier, add a flag to >getaddrinfo that says "only use DNS for this query". The res_XXX >and dn_XXX functions (or improvements to these) are needed anyway >because we use DNS for other things besides address lookup. > That sounds good too, as long as the res_XXX()/dn_XXX() functions are standardized at the same time and the DNS-only getaddrinfo() flag is defined to be equivalent of obtaining address records via res_XXX() calls. The intention here is to define and promote res_XXX()/dn_XXX() as `the' DNS API, and define and promote getaddrinfo() as nothing more than a basic name lookup service. Otherwise people might start thinking that getaddrinfo() would/should be the point of augmentation when they want to implement SRV, MX and other name-to-address lookup API, leading to a whole mess (e.g. they would want to add new members to struct getaddrinfo to return SRV service priority and weight information *shudder*). IMO, people should be first recommended to use res_XXX() in order to implement such a non-A/AAAA lookup scheme, and if they find that too bothersome (which it's likely to be when the scheme is widely deployed), they should define a new API that fully covers the scheme rather than finding a similar API then victimizing it. >>Perhaps it'd be desirable to see some actual figures; how much >>percentage of the applications out there that use >>gethostbyXXX()/getaddrinfo()/getnameinfo() would assume those >>functions look up DNS records *only*, and would be severely broken if >>they were given results not based on DNS. >> > >Well, it has a lot to do with the environment, doesn't it? I mean, if >and when an alternate name-to-address translation service produces >answers identical to DNS, then the app probably doesn't care what >service provided the answers. The problems occur when the translation >service doesn't provide the correct answers, or when the translation >service in use at point A provides different answers than the service in >use at point B. The more different lookup mechanisms in use, the easier >it is for them to get out of sync with one another. > >Similarly, no app will be broken by a decision to use DNS when its host >or network is properly configured. The only time breakage occurs is >when the host or network is improperly configured to use some other >lookup service besides DNS, or when the host is not configured at all. >(yes, we do need to deal with self-configuring or ad hoc networks, >but we need to do so in a way that produces results that don't conflict >with DNS) > > >An increasing number of apps are defined in such a way that DNS is *part >of the protocol specification*; the app will violate the protocol >specification if it uses a service other than DNS. For instance, any >app that uses SRV or MX records falls into this catgory. There's little >justification for an administrator to use an alternate address lookup >service, since they typically have to support at least one app that >requires DNS anyway. > The standard (RFC 3493, or POSIX) as it is defined now is defined to be namespace-neutral (although in a passive manner). A lot of implementations interpret the standard that way too, e.g. nsswitch.conf. If applications abuse it as a DNS interface then break later, it's their problem; they should've taken into account from the first place that getaddrinfo() *may* return non-DNS results. It doesn't seem like a good idea to reduce the functionality of an existing standard just so it meets what applications mistakingly expect it to be. (By the way, I'm talking about the option #1; AI_DNS_ONLY looks good because it does draw a clear line without sacrificing any of the existing capability.) >And there's certainly no reason for IETF to be endorsing the idea that >a site should be able to use any lookup service it likes without >breaking things. > Agreed. The current RFC 3493 seems insufficient in this aspect. An update to RFC 3493 that defines the DNS-only flag could clarify: `If AI_DNS_ONLY is not specified to getaddrinfo() or getnameinfo() calls, the result from such calls MUST NOT be assumed to be obtained solely from DNS. Applications that require the result to be from DNS MUST specify AI_DNS_ONLY when calling getaddrinfo() or getnameinfo().' >>However, my impression was that a vast majority of applications out >>there use the functions in their original semantics (i.e. as a >>shorthand facility for specifying human-readable text form of >>addresses, not as a frontend interface for DNS only but nothing else), >>e.g. `ping6 www.kame.net' certainly wouldn't care if the IPv6 address >>getaddrinfo() returns comes from DNS, NIS, or any other mechanism. >> > >It's been a long time since HOSTS.TXT was sufficient. It's also been >a long time since DNS was only a distributed replacement for HOSTS.TXT. > >The Internet is not defined by the "vast majority of applications". >The Internet is defined by specifications. The problem is that our >specifications are sometimes incomplete. In this case the APIs that >we're recommending be used for implementation of apps aren't specified >with enough precision to allow those apps to interoperate reliably. > (This seems to be getting off-topic; this will be my last on-list response about this particular subject. Sorry ;) I agree with you, except that I think the Internet *is* defined (albeit indirectly) by applications. My take is slightly broader. How the Internet *should be in the future* is defined by specifications. How the Internet *currently is* is defined by various components of the Internet, including the VMoA (:p). The basis upon which people decide how the Internet should be in the future, i.e. specifications, is what they want to accomplish in the current environment, i.e. the current status of the Internet. In that sense, the current Internet and its applications provide some sort of guidance upon creating/amending specifications, usually suggesting a path of less resistance. I'm not saying that what applications do is always right. But the fact that applications are doing a wrong thing means we can just ignore them as if they weren't there. Whatever we do that breaks them will upset some people (especially if they didn't even know those applications had problems, however subtle they may be). So, as long as we can reach our goal of enhancing our specifications to be more clear and precise, why not take a course of action that meets expectation of more applications and/or breaks less applications? This is why I still believe what people expect from (current applications that expect certain behavior from) getaddrinfo() should have a say about how we update RFC 3493. To me it looks like there are going to be more people who are like `What, my changes to /etc/nsswitch.conf has no effect?' or `Why do the entries I added to /etc/hosts seem to be ignored?' (e.g. if system admininstration scripts rely on those files) after we change getaddrinfo() to be DNS-only by default, than people who are like `Geez, this program doesn't work anymore after I change /etc/nsswitch.conf?' (e.g. after raising the priority of NIS database which is out of sync with DNS) under the current behavior. But this is only from my (limited) viewpoint, and I wanted to hear some other inputs as well. Regards, Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 17:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08867 for ; Tue, 4 Nov 2003 17:22:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Yv-0002iM-Cn for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 17:22:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MM91m010418 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 17:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Yu-0002hq-F9 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:22:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08807 for ; Tue, 4 Nov 2003 17:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Yr-0006px-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:22:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9Yr-0006ps-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Yn-0002UP-VR; Tue, 04 Nov 2003 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9YN-0002L5-7V for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 17:21:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08782 for ; Tue, 4 Nov 2003 17:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9YK-0006pR-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:21:32 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AH9YK-0006pO-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:21:32 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 9EB02A0; Wed, 5 Nov 2003 07:21:31 +0900 (JST) To: gene@nttmcl.com Cc: ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) In-Reply-To: Your message of "Tue, 04 Nov 2003 14:15:25 -0800" <3FA824FD.2040807@nttmcl.com> References: <3FA824FD.2040807@nttmcl.com> X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031104222131.9EB02A0@coconut.itojun.org> Date: Wed, 5 Nov 2003 07:21:31 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > That sounds good too, as long as the res_XXX()/dn_XXX() functions are > standardized at the same time and the DNS-only getaddrinfo() flag is > defined to be equivalent of obtaining address records via res_XXX() calls. for dns-only query i recommend getrrsetbyname(), available in BIND9 (if I remember correctly). itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 17:50:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09471 for ; Tue, 4 Nov 2003 17:50:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHA0I-0004te-UX for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 17:50:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MoQED018816 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 17:50:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHA0I-0004tP-Os for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:50:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09448 for ; Tue, 4 Nov 2003 17:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHA0G-000778-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:50:24 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHA0F-000775-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:50:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9zu-0004kH-VN; Tue, 04 Nov 2003 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9yw-0004j0-Sl for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 17:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09432 for ; Tue, 4 Nov 2003 17:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9yu-00076k-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:49:00 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AH9yt-00076e-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:48:59 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E7F3B143C5; Tue, 4 Nov 2003 17:48:59 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31066-06; Tue, 4 Nov 2003 17:48:58 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5DE441430A; Tue, 4 Nov 2003 17:48:58 -0500 (EST) Date: Tue, 4 Nov 2003 16:44:02 -0500 From: Keith Moore To: "Eugene M. Kim" Cc: moore@cs.utk.edu, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) Message-Id: <20031104164402.68a39b3f.moore@cs.utk.edu> In-Reply-To: <3FA824FD.2040807@nttmcl.com> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >> * Change/fix the definition of getaddrinfo()/getnameinfo() so they > >> are tied to DNS only but nothing else. > >> * Keep the current semantics of those functions, then update and > >> standarize an API that strictly queries DNS only (res_XXX() and > >> dn_XXX() comes to mind first; if they fall short of what real > >> applications need, we could always define a new superset). > >> > > > >There's a third option - like I suggested earlier, add a flag to > >getaddrinfo that says "only use DNS for this query". The res_XXX > >and dn_XXX functions (or improvements to these) are needed anyway > >because we use DNS for other things besides address lookup. > > > > That sounds good too, as long as the res_XXX()/dn_XXX() functions are > standardized at the same time and the DNS-only getaddrinfo() flag is > defined to be equivalent of obtaining address records via res_XXX() calls. That makes sense. If you just want A/AAAA records do getservbyname() with the DNS only flag; otherwise use res_XXX/dn_XXX. The only problem is that the res_XXX/dn_XXX functions have really awkward interfaces. But there's something to be said for stability. > Otherwise people might start thinking that > getaddrinfo() would/should be the point of augmentation when they want > to implement SRV, MX and other name-to-address lookup API, leading to a > whole mess People already *are* thinking that, and have been for many years. IMHO one of the biggest botches of getaddrinfo() is the srvname parameter, partially because it tempts people to have getaddrinfo() do SRV lookups (and there's nothing in the specification that says not to do that) and partially because it can cause additional errors. (It is utterly insane to look up a symbolic constant in a file or network-accessible database when that constant is part of the specification for the protocol you're implementing. When I was a sysadmin I lost track of how many times I had to diagnose an application that was failing because getservbyname() for some well-known protocol returned NULL - usually because the YP server wasn't bound or some stupid thing like that.) > IMO, people should be first recommended to use res_XXX() in order to > implement such a non-A/AAAA lookup scheme, and if they find that too > bothersome (which it's likely to be when the scheme is widely deployed), > they should define a new API that fully covers the scheme rather than > finding a similar API then victimizing it. Agree. In particular, lots of problems result from changing existing APIs in ways that introduce new failure modes. > The standard (RFC 3493, or POSIX) as it is defined now is defined to be > namespace-neutral (although in a passive manner). A lot of > implementations interpret the standard that way too, e.g. > nsswitch.conf. If applications abuse it as a DNS interface then break > later, it's their problem; they should've taken into account from the > first place that getaddrinfo() *may* return non-DNS results. It doesn't > seem like a good idea to reduce the functionality of an existing > standard just so it meets what applications mistakingly expect it to > be. I'm sympathetic to that view. I suppose I'm griping that getaddrinfo() was a poor design that we're kind of stuck with now. I certainly agree that a poor design doesn't necessarily justify a retroactive change. At the same time I think it might help to recommend somewhat more uniform behavior for getaddrinfo() - both the code and the way hosts are configured to use it - e.g. - specify more precisely what it means in terms of DNS queries (e.g. no SRV records) - discourage use of proprietary or platform-specific query methods like NIS, NIS+, netinfo, WINS, without forbidding it entirely - specify requirements for consistency between different services that provide lookup for the same names > I'm not saying that what applications do is always right. But the fact > that applications are doing a wrong thing means we can just ignore them > as if they weren't there. I agree with this. We don't want to break existing apps. But the desire to have (more) reliable apps in the future implies a need to define components precisely enough that apps can get repeatable behavior from them - even when those apps run on different platforms, and in different parts of the network. Well, I guess I know what kind of Internet-Draft to write... Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 18:18:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11311 for ; Tue, 4 Nov 2003 18:18:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHARM-0006Jl-4M for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 18:18:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4NIORl024279 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 18:18:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHARM-0006JW-08 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 18:18:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11290 for ; Tue, 4 Nov 2003 18:18:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHARJ-0007SD-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 18:18:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHARI-0007SA-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 18:18:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHAQz-0006F4-Oi; Tue, 04 Nov 2003 18:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHAQH-0006EB-Ep for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 18:17:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11259 for ; Tue, 4 Nov 2003 18:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHAQE-0007Rw-00 for ipv6@ietf.org; Tue, 04 Nov 2003 18:17:14 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak1a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AHAQD-0007Rt-00 for ipv6@ietf.org; Tue, 04 Nov 2003 18:17:14 -0500 Received: from 132.235.232.96 by pm5 (PureMessage); Tue Nov 4 17:43:41 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak3a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hA4MhdYW1747863 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 4 Nov 2003 17:43:40 -0500 (EST) Date: Tue, 04 Nov 2003 17:43:38 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: RE: Thoughts on the draft-hinden last call Message-ID: <1649140875.1067967818@hkruse2003a> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm5) X-PMX-Start: Tue Nov 4 17:43:40 2003 X-PMX-Stop: Tue Nov 4 17:43:41 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thank you! I was trying to get to the same point, but your summary is much better! And no, I absolutely do not think we should try and wait for routable PI space, which seems to be the only other suggestion made on this list. --On Tuesday, November 04, 2003 09:21 -0800 Christian Huitema wrote: > - the addresses proposed in draft-hinden appear to be strictly better > than either the existing site-local or hijacked addresses. They can be > filtered in routers. Attempts at uniqueness give us a reasonable hope of > tracing the source of leaks. They don't conflict with existing > addresses, so the leaks don't affect the connectivity or the traffic > load of third parties. > > In short, the proposed addresses cannot eliminate application level > leaks, but they can definitely reduce their consequences, and do a much > better job at that than the alternatives. > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 18:48:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11940 for ; Tue, 4 Nov 2003 18:48:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHAuB-0007yn-Bz for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 18:48:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4NmBK3030667 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 18:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHAuA-0007xH-R2 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 18:48:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11904 for ; Tue, 4 Nov 2003 18:47:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHAu7-0007iT-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 18:48:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHAu7-0007iQ-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 18:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHAu2-0007pv-99; Tue, 04 Nov 2003 18:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHAtG-0007og-DO for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 18:47:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11896 for ; Tue, 4 Nov 2003 18:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHAtD-0007iA-00 for ipv6@ietf.org; Tue, 04 Nov 2003 18:47:11 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHAtC-0007i7-00 for ipv6@ietf.org; Tue, 04 Nov 2003 18:47:10 -0500 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 053FB16BB0; Wed, 5 Nov 2003 00:47:04 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 2811917148; Wed, 5 Nov 2003 00:47:03 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hA4Nl2Aj027841; Wed, 5 Nov 2003 00:47:02 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hA4Nkvo6027838; Wed, 5 Nov 2003 00:46:57 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Keith Moore Cc: "Eugene M. Kim" , ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 05 Nov 2003 00:46:56 +0100 In-Reply-To: <20031104164402.68a39b3f.moore@cs.utk.edu> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Keith Moore writes: > > Otherwise people might start thinking that > > getaddrinfo() would/should be the point of augmentation when they want > > to implement SRV, MX and other name-to-address lookup API, leading to a > > whole mess > > People already *are* thinking that, and have been for many years. IMHO > one of the biggest botches of getaddrinfo() is the srvname parameter, > partially because it tempts people to have getaddrinfo() do SRV lookups (and > there's nothing in the specification that says not to do that) As far as I can see, the only good reason to have the service argument in getaddrinfo is to make it possible for getaddrinfo to perform SRV lookups. It can ask for SRV-records, and sort the returned addresses according to some combination of SRV priority, weight and other destination address selection rules. If no SRV was found, it can ask for A and/or AAAA records, and use getservbyname to find the port number. Sounds like an easy and reasonable way to deploy SRV. Compare to the non-SRV usage scenario: I use getaddrinfo, to make my code nice and protocol independent, and I want to use some fix port number. Then I'll want getaddrinfo to write the number into the returned sockaddr structures, in the nice protocol neutral way of getaddrinfo. But to do that, I have to convert my fix number into a *string*, and let getaddrinfo convert it back to a number. To me, that mode of operation makes a lot less sense than having getaddrinfo perform SRV lookups... Regards, /Niels -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 18:56:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12094 for ; Tue, 4 Nov 2003 18:56:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHB1x-0000LU-Jg for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 18:56:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4NuDof001322 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 18:56:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHB1x-0000LF-Du for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 18:56:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12066 for ; Tue, 4 Nov 2003 18:55:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHB1u-0007le-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 18:56:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHB1t-0007la-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 18:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHB1n-0000Bt-Ai; Tue, 04 Nov 2003 18:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHB0z-0000BA-90 for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 18:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12043 for ; Tue, 4 Nov 2003 18:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHB0w-0007kw-00 for ipv6@ietf.org; Tue, 04 Nov 2003 18:55:10 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHB0v-0007kt-00 for ipv6@ietf.org; Tue, 04 Nov 2003 18:55:09 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id C2923143FB; Tue, 4 Nov 2003 18:55:05 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12357-02; Tue, 4 Nov 2003 18:55:05 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 9150114353; Tue, 4 Nov 2003 18:55:04 -0500 (EST) Date: Tue, 4 Nov 2003 17:50:08 -0500 From: Keith Moore To: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=) Cc: moore@cs.utk.edu, gene@nttmcl.com, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) Message-Id: <20031104175008.51e17e6a.moore@cs.utk.edu> In-Reply-To: References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > As far as I can see, the only good reason to have the service argument > in getaddrinfo is to make it possible for getaddrinfo to perform SRV > lookups. that's not a good reason, that's a disaster. it would change the behavior of every application on the Internet in an incompatible way, and it would add new failure modes to every application that isn't already specified to use SRV. it would also tempt NATs to tweak DNS in even more preverse ways than they already do. there's a reason that RFC 2782 contains the following text: > Applicability Statement > > In general, it is expected that SRV records will be used by clients > for applications where the relevant protocol specification indicates > that clients should use the SRV record. Such specification MUST > define the symbolic name to be used in the Service field of the SRV > record as described below. It also MUST include security > considerations. Service SRV records SHOULD NOT be used in the absence > ----------------------------------------------------- > of such specification. > --------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 19:27:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12914 for ; Tue, 4 Nov 2003 19:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHBW6-0002Do-TC for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 19:27:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA50RMX1008534 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 19:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHBW6-0002DZ-OP for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 19:27:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12896 for ; Tue, 4 Nov 2003 19:27:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHBW5-0000Gn-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 19:27:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHBW4-0000Gk-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 19:27:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHBVk-00026R-UY; Tue, 04 Nov 2003 19:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHBVS-00025n-BY for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 19:26:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12892 for ; Tue, 4 Nov 2003 19:26:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHBVQ-0000Gc-00 for ipv6@ietf.org; Tue, 04 Nov 2003 19:26:40 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHBVQ-0000GZ-00 for ipv6@ietf.org; Tue, 04 Nov 2003 19:26:40 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 39AF713FEF; Tue, 4 Nov 2003 19:26:09 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16324-09; Tue, 4 Nov 2003 19:26:08 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 09EF213FE6; Tue, 4 Nov 2003 19:26:08 -0500 (EST) Date: Tue, 4 Nov 2003 18:21:12 -0500 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, tjc@ecs.soton.ac.uk, ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-Id: <20031104182112.3ab25d7e.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Excellent analysis. I fully concur. Keith > - using site local is roughly equivalent to using net 10 in IPv4. The > address range can be filtered in routers, but it is ambiguous. Ambiguity > prevents tracing the source of the leaks. > > - hijack a prefix is roughly equivalent to the pre-RFC-1958 situation in > IPv4, e.g. alumni reusing the MIT address space. The address range can > be filtered in some routers, but not in all of them. Leaks are difficult > to even notice, and result in misdirection of traffic to an unsuspecting > party. Leaks in the routing protocols result in routing disruption. > > - the addresses proposed in draft-hinden appear to be strictly better > than either the existing site-local or hijacked addresses. They can be > filtered in routers. Attempts at uniqueness give us a reasonable hope of > tracing the source of leaks. They don't conflict with existing > addresses, so the leaks don't affect the connectivity or the traffic > load of third parties. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 21:00:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16035 for ; Tue, 4 Nov 2003 21:00:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCyD-00084j-OD for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 21:00:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA520TwB031035 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 21:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCyD-00084U-JE for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 21:00:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15995 for ; Tue, 4 Nov 2003 21:00:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCyB-0001dZ-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:00:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHCyA-0001dW-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:00:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCxn-0007xn-TA; Tue, 04 Nov 2003 21:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCxA-0007wO-Gt for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 20:59:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15942 for ; Tue, 4 Nov 2003 20:59:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCx7-0001aH-00 for ipv6@ietf.org; Tue, 04 Nov 2003 20:59:22 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AHCx7-0001Zl-00 for ipv6@ietf.org; Tue, 04 Nov 2003 20:59:21 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA51wIcF472848; Tue, 4 Nov 2003 20:58:18 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-206-166.mts.ibm.com [9.65.206.166]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA51wE9W209012; Tue, 4 Nov 2003 18:58:15 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id hA51tVN05560; Tue, 4 Nov 2003 20:55:36 -0500 Message-Id: <200311050155.hA51tVN05560@cichlid.adsl.duke.edu> To: "Bound, Jim" cc: ipv6@ietf.org Subject: Re: Authors Section on recyle clarifications to 2461and 2462 In-Reply-To: Message from jim.bound@hp.com of "Sun, 02 Nov 2003 02:00:22 EST." <9C422444DE99BC46B3AD3C6EAFC9711B047CA1F3@tayexc13.americas.cpqcorp.net> Date: Tue, 04 Nov 2003 20:55:30 -0500 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > As we recycle 2461 and 2462 specifications I suggest that no additional > names be added to the authors names for two reasons. I don't think such a rigid rule is appropriate. Authors/editors should be properly acknowledged for their work. If a new author/editor takes over an existing RFC, they should be given appropriate credit. As one of the authors on these drafts, I would assume that sharing the credits is a given, since I don't have the cycles to edit the documents myself. I think it's also a bit premature to be definitive about what the final authorship should be. When the revised document is closer to being done, at that point we can assess how much work was involved in the new version, who did that work, and what the best way to acknowledge it should be. > The current authors worked for many years and earned their names on > this spec. That may be true, but it is certainly also true that a lot of what is in the specs is a result of a lot of community input. If anyone looks at (say) ND and thinks I'm an "author" of that spec, I think that would be somewhat misleading. There was a real team effort behind that document. (Excuse me for a moment while I reminisce for a moment...) I also think it is also somewhat destructive to the IETF ideals to somehow assume that I (or any other author on a document) is author for life, no matter what happens. WG documents are supposed to be WG documents - reflecting the will of the WGs. They are not documents owned by authors. And as Jari has pointed out already, it's not uncommon for revisions of documents to end up with 75% new text. The original authors are hardly "authors" anymore in such cases. Folks might also want to have a look at section 2.12 draft-rfc-editor-rfc2223bis-07.txt. It talks specifically about a "contributers" section, which is intended to make it much more clear who the actual contributers are. That would be a fine place to mention the actually history of the document in more detail. I wish more documents took this approach. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 21:09:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16339 for ; Tue, 4 Nov 2003 21:09:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHD6l-0000Qa-1j for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 21:09:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA529J6K001638 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 21:09:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHD6k-0000QL-Sb for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 21:09:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16289 for ; Tue, 4 Nov 2003 21:09:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHD6i-0001k9-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:09:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHD6h-0001k6-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:09:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHD6U-0000Ho-En; Tue, 04 Nov 2003 21:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHD5a-0000H0-OP for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 21:08:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16271 for ; Tue, 4 Nov 2003 21:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHD5Y-0001jR-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:08:04 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1AHD5X-0001in-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:08:03 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA527Pjt348910; Tue, 4 Nov 2003 21:07:25 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-206-166.mts.ibm.com [9.65.206.166]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA527O9W160480; Tue, 4 Nov 2003 19:07:24 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id hA524du05581; Tue, 4 Nov 2003 21:04:46 -0500 Message-Id: <200311050204.hA524du05581@cichlid.adsl.duke.edu> To: "Bound, Jim" cc: "James Kempf" , ipv6@ietf.org Subject: Re: Authors Section on recyle clarifications to 2461and 2462 In-Reply-To: Message from jim.bound@hp.com of "Tue, 04 Nov 2003 01:37:15 EST." <9C422444DE99BC46B3AD3C6EAFC9711B051224BD@tayexc13.americas.cpqcorp.net> Date: Tue, 04 Nov 2003 21:04:39 -0500 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Jim, > If we had to recycle 2460 and Steve is still gone and Bob Hinden don't > have time (which I guess is the case with Erik and Thomas) would we add > another name to the IPv6 specification? I don't believe we would out of > respect to Steve. And who on earth would be willing to author a document if they couldn't even get credit for the work that they put into the revision? While I don't see a need make significant revisions to 2460, I don't think it's healthy to associate individuals with documents to the point where it becomes impossible to conceive of any change in the authorship of a document because of history. Each new version of a document should stand on its own merits, and if a new editor/author has done significant work, they should be acknowledged for it, quite possibly by being listed as a new or additional author. But again, talking hypotheticals is not so productive here. This sort of conversation is best held when it has become clear how much work was put into a document and by who. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 21:34:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17112 for ; Tue, 4 Nov 2003 21:34:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDUv-0002Ew-EE for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 21:34:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA52YHNh008604 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 21:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDUv-0002Eh-8I for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 21:34:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17073 for ; Tue, 4 Nov 2003 21:34:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDUs-00024d-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:34:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHDUs-00024Y-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:34:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDUg-000295-9y; Tue, 04 Nov 2003 21:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDUd-00028d-5K for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 21:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17060 for ; Tue, 4 Nov 2003 21:33:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDUa-00024E-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:33:56 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AHDUZ-000244-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:33:55 -0500 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2O9RGVK3M8ZP48J@vaxh.its.monash.edu.au> for ipv6@ietf.org; Wed, 5 Nov 2003 13:14:04 +1100 Received: from thwack.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 90E20318004; Wed, 05 Nov 2003 13:14:03 +1100 (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 7B5182DC004; Wed, 05 Nov 2003 13:14:03 +1100 (EST) Date: Wed, 05 Nov 2003 13:14:03 +1100 From: Greg Daley Subject: Re: Issue 13: Omission of prefix options - resolution To: Pekka Savola Cc: Erik Nordmark , JinHyeock Choi , Soliman Hesham , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FA85CEB.5070509@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: Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Pekka, Pekka Savola wrote: > On Tue, 4 Nov 2003, Erik Nordmark wrote: > >>>There is really no reason to omit those prefixes that I could see. >>>Rather than adding new code to verify this, shouldn't we just warn about >>>this situation and be done with it? Or even state that prefixes SHOULD >>>NOT (or MUST NOT) be omitted unless including them would cause a too big >>>packet (over MTU) to be sent? >> >>Part of the consideration is the folks want to use RAs as frequent >>beacons for attachment detection. Making such beacons to carry >>potentially lots of prefixes, especially on bandwidth constrained >>(wireless) links, might be self-defeating. >> >>Thus recommending that all prefixes be sent every 10 milliseconds (or >>whatever the min number is in the MIPv6 spec) might not be the best >>approach. > > > Uhh, this seems like a total abuse of the RA mechanism :-). The point of > it to be able to carry the prefixes needed for autoconfiguration. The final paragraph of Section 6.2.3 of rfc-2461 says that a router may want to omit options, but can't do so for a solicited RA. So the abuse isn't against the carrying of all prefixes. The abuse of the RA mechanism is certainly there though (as abuse of wireless bandwidth). Everyone at the mobileIP session at IETF55 knew that it was a limited solution for some environments. > If it's supposed to be used for a beacon mechanism, I'd suggest > considering whether one could find a method that does not send prefixes at > ALL (or, just send the prefix of the router with prefixlen=128 if you > really insist). > > This would enable you to retain the model where RA's would in fact be > complete when they included prefix information options that the nodes > would use. > There is a solution such as this which can omits all options in unsolicited RA, and still allows us to identify that we're on the same link or have moved. This is equivalent to Complete PIO information in RAs, but doesn't necessarily have the prefixes present in unsolicited RAs. It's called Link Identifiers. Instead of (or as well as) sending PIOs, a link identifier option is sent by all routers on the same link. This was described in Erik's MIPv6 hindsight document, but recent work by Monash and Samsung has aimed at making this LinkID Option small, and automatically configured. It's available at: http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.txt This solution works if all routers on the link send LinkIDs, or if not all routers do, but transmit overlapping prefixes. The completeness bit would work even if no other routers on the link support it though. Of course, since section 6.2.3 recommends that routers advertise all options in solicited RAs, maybe the completeness bit could only be set in solicited RAs, if LinkID was present. There are some other things regarding RA contents (there's no solicitation indication) which would be nice, but I guess that's not what we're talking about here. So we have at least two solutions which provide unambiguous prefix indications: LinkID + Solicited RA (lower overhead) Completeness Bit (simpler) Whether these are aimed at RFC-2461bis or receive attention in IPv6 or DNA is another matter. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 21:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17188 for ; Tue, 4 Nov 2003 21:35:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDVi-0002Vo-54 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 21:35:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA52Z5pv009629 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 21:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDVh-0002UF-EC for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 21:35:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17134 for ; Tue, 4 Nov 2003 21:34:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDVe-00025f-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:35:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHDVe-00025c-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDVf-0002Nt-K2; Tue, 04 Nov 2003 21:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDUe-00028n-2w for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 21:34:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17066 for ; Tue, 4 Nov 2003 21:33:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDUb-00024M-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:33:57 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AHDUa-000244-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:33:56 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2O9KG8FIK8ZOMUN@vaxh.its.monash.edu.au> for ipv6@ietf.org; Wed, 5 Nov 2003 13:08:24 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 73D5C39C003; Wed, 05 Nov 2003 13:08:24 +1100 (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 4FF262DC00A; Wed, 05 Nov 2003 13:08:24 +1100 (EST) Date: Wed, 05 Nov 2003 13:08:23 +1100 From: Greg Daley Subject: Re: Issue 13: Omission of prefix options - resolution To: Tim Hartrick Cc: H.Soliman@flarion.com, itojun@iijlab.net, ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FA85B97.7000704@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: <200311041918.LAA23719@feller.mentat.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Tim, Tim Hartrick wrote: > All, > > >>>Suggested resolution: >>> >>>- Introduce a new code (1) in the router solicitation >>>and advertisement. When a host sends an RS with code = 1 >>>it requests that the RA include all prefixses valid on >>>that link. Similarly, when a router sends an RA with code=1 >>>it means that the RA includes all prefixes valid on that >>>link. This way, a MN can confirm its mobility. >> >> we cannot always correlate RS and RA (router can listen to RS, then >> issue RA on the next periodic advertisement). also RS does not solicit >> unicast RA. the above solution does not work. >> > > > The code or bit don't work all by themselves. Clearly, new protocol machinery > will need to be specified so that hosts which understand the new code or bit > can live happily on subnets that don't have routers that speak using > the new code or bit. The other combinations of old and new behavior will need > to be considered as well. Pekka's suggestion of making router advertisements > all or nothing with respect to the inclusion of prefix options would achieve > the same ends. > > We need a way for routers to communicate that there is more information > available and we need to work out the backward compatibility details for the > cases where either the host or the router don't understand or speak the new > dialect. It doesn't sound impossible but it also sounds like more than just > a minor bug fix to the specification. It would have been nice to fix this > when the problem was first noted several years ago. That would have eliminated > the need to worry about backward compatibility. > Backward compatability shouldn't really be a problem. Hosts which are doing RFC2461 Router Discovery will understand RAs with options or bits in them indicating solicitation or completeness, but just not be able to access the improved function. Implementations which support the new function understand what the current problems are (you're right, this may have to be codified somewhere), but may be assisted by the presence of single bit or option, just in the case where RA supports this. I don't think it's that hard, but whether it goes into RFC2461bis is another matter. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 21:53:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18254 for ; Tue, 4 Nov 2003 21:53:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDnG-00048K-FZ for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 21:53:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA52rE3j015882 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 21:53:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDnG-000485-A4 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 21:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18195 for ; Tue, 4 Nov 2003 21:53:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDnD-0002RV-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:53:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHDnC-0002RS-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 21:53:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDn3-0003zU-Ga; Tue, 04 Nov 2003 21:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDmE-0003yw-VY for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 21:52:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17974 for ; Tue, 4 Nov 2003 21:51:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDmB-0002PC-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:52:08 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AHDmB-0002OX-00 for ipv6@ietf.org; Tue, 04 Nov 2003 21:52:07 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 Nov 2003 18:51:35 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Nov 2003 18:51:31 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 Nov 2003 18:51:15 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 Nov 2003 18:51:20 -0800 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.3790.1069); Tue, 4 Nov 2003 18:51:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Authors Section on recyle clarifications to 2461and 2462 Date: Tue, 4 Nov 2003 18:51:33 -0800 Message-ID: Thread-Topic: Authors Section on recyle clarifications to 2461and 2462 thread-index: AcOjQd3shdyvaV0TTJi7ZpuUlR6cSAABTdpQ From: "Christian Huitema" To: "Thomas Narten" , "Bound, Jim" Cc: "James Kempf" , X-OriginalArrivalTime: 05 Nov 2003 02:51:33.0777 (UTC) FILETIME=[B8F7F810:01C3A347] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > If we had to recycle 2460 and Steve is still gone and Bob Hinden don't > > have time (which I guess is the case with Erik and Thomas) would we add > > another name to the IPv6 specification? I don't believe we would out of > > respect to Steve. >=20 > And who on earth would be willing to author a document if they > couldn't even get credit for the work that they put into the revision? In a personal example, I am one of the authors of RFC 2705 (MGCP), but not of its revision, RFC 3435. I actually wrote much of MGCP, but stopped working on it and left others edit the new version. That is in fact very common, and fair if (1) there is a substantial revision, (2) the original author does not participate in the revision, and (3) there are proper acknowledgements. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 4 22:18:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20851 for ; Tue, 4 Nov 2003 22:18:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEBT-0006C0-E1 for ipv6-archive@odin.ietf.org; Tue, 04 Nov 2003 22:18:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA53IFpq023798 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 22:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEBT-0006Bl-87 for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 22:18:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20820 for ; Tue, 4 Nov 2003 22:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHEBQ-00035W-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 22:18:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHEBP-00035T-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 22:18:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEBF-00065p-No; Tue, 04 Nov 2003 22:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEBA-00065Q-6P for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 22:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20803 for ; Tue, 4 Nov 2003 22:17:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHEB6-000356-00 for ipv6@ietf.org; Tue, 04 Nov 2003 22:17:52 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AHEB6-00034n-00 for ipv6@ietf.org; Tue, 04 Nov 2003 22:17:52 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Nov 2003 22:17:23 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E7F@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Tim Hartrick'" , ipv6@ietf.org Subject: RE: Issue 13: Omission of prefix options - resolution Date: Tue, 4 Nov 2003 22:17:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > When this problem was noted in the early days I remember > suggesting adding > "Solicited" bit to the router advertisement to address this > issue. Because > of backward compatibility problems that solution will no > longer work well. > > Is there some reason why we wouldn't want to add a new bit, say the > "Complete" bit, to the reserved field of the router > advertisement? I realize > I just finished ranting against adding new bits but using > one of the reserved > bits for this purpose seems cleaner to me. => Apart from the fact that we have less reserved bits than codes, is there any difference that you see between adding a bit to the RS/RA Vs adding a new code? Hesham > > > > Tim Hartrick > Mentat Inc. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 01:27:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25460 for ; Wed, 5 Nov 2003 01:27:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHH7u-0007EG-Jl for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 01:26:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA56QkoG027782 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 01:26:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHH7u-0007E1-Cu for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 01:26:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25391 for ; Wed, 5 Nov 2003 01:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHH7r-0005CB-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 01:26:43 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHH7q-0005C7-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 01:26:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHH7C-00077x-B7; Wed, 05 Nov 2003 01:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHH6C-00076s-RU for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 01:25:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25323 for ; Wed, 5 Nov 2003 01:24:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHH69-0005A2-00 for ipv6@ietf.org; Wed, 05 Nov 2003 01:24:57 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AHH69-00059q-00 for ipv6@ietf.org; Wed, 05 Nov 2003 01:24:57 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Nov 2003 01:24:22 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E83@ftmail.lab.flarion.com> From: Soliman Hesham To: "'greg.daley@eng.monash.edu.au'" , Pekka Savola Cc: Erik Nordmark , JinHyeock Choi , ipv6@ietf.org Subject: RE: Issue 13: Omission of prefix options - resolution Date: Wed, 5 Nov 2003 01:24:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >So we have at least two solutions which provide >unambiguous prefix indications: > >LinkID + Solicited RA (lower overhead) >Completeness Bit (simpler) => Agreed. Both of those options would solve the problem. The LinkID + Solicited RA would seem to solve the movement detection problem quicker than the "Completeness" bit. If you can see the LinkID you'd only solicit if you see a different one. However, with the completeness bit, you really don't know if you moved whenever you receive an incomplete RA, right? Meaning, a paranoid MN with no other hints, could end up soliciting for a complete RA more often that in the case where it sees the LinkID and know whether it should solicit. It seems like the LinkID is a better approach then? Or am I missing something? Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 01:41:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25967 for ; Wed, 5 Nov 2003 01:41:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHLp-0008B1-2D for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 01:41:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA56f9qe031425 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 01:41:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHLo-0008Am-Sf for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 01:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25927 for ; Wed, 5 Nov 2003 01:40:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHLl-0005Qk-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 01:41:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHHLl-0005Qh-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 01:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHLj-00085E-ES; Wed, 05 Nov 2003 01:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHKw-00083t-6G for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 01:40:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25911 for ; Wed, 5 Nov 2003 01:40:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHKs-0005QS-00 for ipv6@ietf.org; Wed, 05 Nov 2003 01:40:10 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHKs-0005Q6-00 for ipv6@ietf.org; Wed, 05 Nov 2003 01:40:10 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA56dPJ11704; Wed, 5 Nov 2003 08:39:25 +0200 Date: Wed, 5 Nov 2003 08:39:25 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: "'Tim Hartrick'" , Subject: RE: Issue 13: Omission of prefix options - resolution In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E7F@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 4 Nov 2003, Soliman Hesham wrote: > => Apart from the fact that we have less reserved bits > than codes, is there any difference that you see > between adding a bit to the RS/RA Vs adding a new code? Current implementations probably ignore whole messages with codes != 0, while the flag bits are merely ignored? -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 01:44:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26060 for ; Wed, 5 Nov 2003 01:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHOk-0000K3-5K for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 01:44:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA56iA3A001233 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 01:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHOj-0000Jo-Ak for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 01:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26028 for ; Wed, 5 Nov 2003 01:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHOg-0005T1-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 01:44:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHHOf-0005Sy-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 01:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHOc-00007C-Hg; Wed, 05 Nov 2003 01:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHOM-00006w-V2 for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 01:43:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26021 for ; Wed, 5 Nov 2003 01:43:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHOJ-0005Si-00 for ipv6@ietf.org; Wed, 05 Nov 2003 01:43:43 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHOI-0005SW-00 for ipv6@ietf.org; Wed, 05 Nov 2003 01:43:43 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA56gl511781; Wed, 5 Nov 2003 08:42:47 +0200 Date: Wed, 5 Nov 2003 08:42:46 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: "'greg.daley@eng.monash.edu.au'" , Erik Nordmark , JinHyeock Choi , Subject: RE: Issue 13: Omission of prefix options - resolution In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E83@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 5 Nov 2003, Soliman Hesham wrote: > It seems like the LinkID is a better approach then? Or > am I missing something? Maybe, maybe not. Can't say for sure yet. My worry is that we're opening up a problem we don't understand yet, one for which there basically only -00 I-D's of. I can be pretty sure we don't understand the problems and the mechanisms to fix those problems well enough yet. So, the best fix could just be to try to clarify 2461bis, and if modifications are required, let them be done separately.. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 02:32:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24211 for ; Wed, 5 Nov 2003 02:32:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHI9d-0004Zv-RO for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 02:32:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA57WbjG017600 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 02:32:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHI9c-0004Zn-OZ for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 02:32:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24184 for ; Wed, 5 Nov 2003 02:32:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHI9Z-0006Dc-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 02:32:33 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHI9Y-0006DZ-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 02:32:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHI95-0004Nv-V0; Wed, 05 Nov 2003 02:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHI90-0004NF-Ku for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 02:31:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24133 for ; Wed, 5 Nov 2003 02:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHI8w-0006DH-00 for ipv6@ietf.org; Wed, 05 Nov 2003 02:31:54 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1AHI8v-0006DE-00 for ipv6@ietf.org; Wed, 05 Nov 2003 02:31:54 -0500 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2OHH6BIIK8WZ1VX@vaxh.its.monash.edu.au> for ipv6@ietf.org; Wed, 5 Nov 2003 16:54:50 +1100 Received: from thwack.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id A23B8318002; Wed, 05 Nov 2003 16:54:49 +1100 (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 8D86B2DC007; Wed, 05 Nov 2003 16:54:49 +1100 (EST) Date: Wed, 05 Nov 2003 16:54:49 +1100 From: Greg Daley Subject: Re: Issue 13: Omission of prefix options - resolution To: Soliman Hesham Cc: "'Tim Hartrick'" , ipv6@ietf.org, Erik Nordmark , athene@sait.samsung.co.kr Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FA890A9.1080501@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: <748C6D0A58C0F94CA63C198B6674697A01922E7F@ftmail.lab.flarion.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Hesham, Soliman Hesham wrote: > > When this problem was noted in the early days I remember > > suggesting adding > > "Solicited" bit to the router advertisement to address this > > issue. Because > > of backward compatibility problems that solution will no > > longer work well. > > > > Is there some reason why we wouldn't want to add a new bit, say the > > "Complete" bit, to the reserved field of the router > > advertisement? I realize > > I just finished ranting against adding new bits but using > > one of the reserved > > bits for this purpose seems cleaner to me. > > => Apart from the fact that we have less reserved bits > than codes, is there any difference that you see > between adding a bit to the RS/RA Vs adding a new code? A solicited bit doesn't tell you who solicited it in the first place if the RA is multicast (so an S-bit only says we're likely to be sending all PIOs). Since most RA systems multicast responses, this may be a big issue. Erik had some ideas about this off-list though. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 03:55:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26376 for ; Wed, 5 Nov 2003 03:55:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJRq-0001Be-Nl for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 03:55:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA58tUGn004563 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 03:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJRq-0001BW-6m for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 03:55:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26340 for ; Wed, 5 Nov 2003 03:55:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJRn-0007Ey-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 03:55:27 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHJRn-0007Ev-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 03:55:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJRP-00015b-6o; Wed, 05 Nov 2003 03:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJR0-00013s-19 for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 03:54:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26321 for ; Wed, 5 Nov 2003 03:54:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJQx-0007EU-00 for ipv6@ietf.org; Wed, 05 Nov 2003 03:54:35 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AHJQw-0007E6-00 for ipv6@ietf.org; Wed, 05 Nov 2003 03:54:34 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA58rjls025592; Wed, 5 Nov 2003 17:53:51 +0900 (KST) Message-ID: <008501c3a37b$6daaa270$ec2f024b@tyre> From: "JinHyeock Choi" To: "Soliman Hesham" , , "Pekka Savola" Cc: "Erik Nordmark" , References: <748C6D0A58C0F94CA63C198B6674697A01922E83@ftmail.lab.flarion.com> Subject: Re: Issue 13: Omission of prefix options - resolution Date: Wed, 5 Nov 2003 18:01:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVzaGFtIFNvbGlhbSB3cm90ZTogDQo+ID5TbyB3ZSBoYXZlIGF0IGxlYXN0IHR3byBzb2x1dGlv bnMgd2hpY2ggcHJvdmlkZQ0KPiA+dW5hbWJpZ3VvdXMgcHJlZml4IGluZGljYXRpb25zOg0KPiA+ DQo+ID5MaW5rSUQgKyBTb2xpY2l0ZWQgUkEgKGxvd2VyIG92ZXJoZWFkKQ0KPiA+Q29tcGxldGVu ZXNzIEJpdCAgICAgIChzaW1wbGVyKQ0KPiANCj4gPT4gQWdyZWVkLiBCb3RoIG9mIHRob3NlIG9w dGlvbnMgd291bGQgc29sdmUgdGhlIHByb2JsZW0uDQo+IA0KPiBUaGUgTGlua0lEICsgU29saWNp dGVkIFJBIHdvdWxkIHNlZW0gdG8gc29sdmUNCj4gdGhlIG1vdmVtZW50IGRldGVjdGlvbiBwcm9i bGVtIHF1aWNrZXIgdGhhbiB0aGUgDQo+ICJDb21wbGV0ZW5lc3MiIGJpdC4gSWYgeW91IGNhbiBz ZWUgdGhlIExpbmtJRCB5b3UnZA0KPiBvbmx5IHNvbGljaXQgaWYgeW91IHNlZSBhIGRpZmZlcmVu dCBvbmUuIEhvd2V2ZXIsIHdpdGgNCj4gdGhlIGNvbXBsZXRlbmVzcyBiaXQsIHlvdSByZWFsbHkg ZG9uJ3Qga25vdyBpZiB5b3UgbW92ZWQNCj4gd2hlbmV2ZXIgeW91IHJlY2VpdmUgYW4gaW5jb21w bGV0ZSBSQSwgcmlnaHQ/IE1lYW5pbmcsIA0KPiBhIHBhcmFub2lkIE1OIHdpdGggbm8gb3RoZXIg aGludHMsIGNvdWxkIGVuZCB1cCBzb2xpY2l0aW5nDQo+IGZvciBhIGNvbXBsZXRlIFJBIG1vcmUg b2Z0ZW4gdGhhdCBpbiB0aGUgY2FzZSB3aGVyZSBpdCANCj4gc2VlcyB0aGUgTGlua0lEIGFuZCBr bm93IHdoZXRoZXIgaXQgc2hvdWxkIHNvbGljaXQuIA0KPiANCj4gSXQgc2VlbXMgbGlrZSB0aGUg TGlua0lEIGlzIGEgYmV0dGVyIGFwcHJvYWNoIHRoZW4/IE9yIA0KPiBhbSBJIG1pc3Npbmcgc29t ZXRoaW5nPw0KDQpUaGVyZSBhcmUgcHJvIGFuZCBjb24gYmV0d2VlbiB0aGVtLiBGb3IgZXhhbXBs ZSwgaWYgYW4gTU4gcmVjZWl2ZXMgYSBjb21wbGV0ZSANClJBIHdoaWNoIGNvbnRhaW5zIGFsbCB0 aGUgcHJlZml4ZXMsIGl0IGNhbiBmb3JtIG5ldyBDb0EgaW1tZWRpYXRlbHkuIFdoZXJlYXMsIGlm IA0KaXQgcmVjZWl2ZXMgYSBSQSB3aGljaCBjb250YWlucyAgTGlua0lEIGJ1dCBubyBwcmVmaXhl LCBhbiBhZGRpdGlvbmFsIFJTLyBSQSANCmV4Y2hhbmdlIGlzIG5lZWRlZC4gDQoNCkFzIFRpbSBI YXJ0cmljayB3cm90ZSwgdGhlIGNvZGUgb3IgYml0IGRvbid0IHdvcmsgYWxsIGJ5IHRoZW1zZWx2 ZXMuIFRoZXkgYXJlIG5vdA0Kc3VmZmljaWVudCBmb3IgZWZmaWNpZW50IE1ELiBXZSBuZWVkIHRv IHNwZWNpZnkgbmV3IHByb3RvY29sIG1hY2hpbmVyeSwgd2hpY2gsIA0KSSBob3BlLCB3aWxsIGJl IGRvbmUgYXQgRE5BIHF1aWNrbHkuIA0KDQpCZXN0IHJlZ2FyZHMuDQoNCkppbkh5ZW9jayA= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 04:12:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27169 for ; Wed, 5 Nov 2003 04:12:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJi3-0002sU-GL for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 04:12:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA59CFYM011060 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 04:12:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJi2-0002sJ-Qz for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 04:12:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27142 for ; Wed, 5 Nov 2003 04:12:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJi0-0007Zd-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:12:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHJhz-0007Za-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:12:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJhr-0002jf-8u; Wed, 05 Nov 2003 04:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJhm-0002jN-6J for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 04:11:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27130 for ; Wed, 5 Nov 2003 04:11:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJhj-0007ZK-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:11:55 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AHJhi-0007ZH-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:11:54 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA59BoPh004820; Wed, 5 Nov 2003 02:11:51 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA59BnS11386; Wed, 5 Nov 2003 10:11:49 +0100 (MET) Date: Wed, 5 Nov 2003 10:11:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) To: "Eugene M. Kim" Cc: Keith Moore , Mohacsi Janos , colm@stdlib.net, Stig.Venaas@uninett.no, pekkas@netcore.fi, ipv6@ietf.org In-Reply-To: "Your message with ID" <3FA7F703.3060904@nttmcl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > So there seem to be at least two alternatives: > > * Change/fix the definition of getaddrinfo()/getnameinfo() so they > are tied to DNS only but nothing else. > * Keep the current semantics of those functions, then update and > standarize an API that strictly queries DNS only (res_XXX() and > dn_XXX() comes to mind first; if they fall short of what real > applications need, we could always define a new superset). *If* we are going to change something in this area one could also contemplate adding some flags to getaddrinfo/getnameinfo to allow applications to specify "DNS only" or "allow non-DNS resolution". > However, my impression was that a vast majority of applications out > there use the functions in their original semantics (i.e. as a shorthand > facility for specifying human-readable text form of addresses, not as a > frontend interface for DNS only but nothing else), e.g. `ping6 > www.kame.net' certainly wouldn't care if the IPv6 address getaddrinfo() > returns comes from DNS, NIS, or any other mechanism. Over the years I've seen subtle differences even for well-managed installations that use DNS and NIS with the intent that they actually contain the same information; for instance the information might be extracted from the same database and put into DNS and NIS. An example subtlety that leads to surprises for applications is the behavior of reverse lookup. In many cases a reverse lookup using NIS only returns the one-component hostname (e.g. "blixten") and a reverse lookup using DNS returns the FQDN ("blixten.eng.sun.com") Back in the days when folks were using .rhosts for insecure access control this was quite confusing. I don't know if there are applications today that would stumble or fail due to this type of subtle difference. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 04:18:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27456 for ; Wed, 5 Nov 2003 04:18:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJno-0003Uc-Rr for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 04:18:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA59ICIR013427 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 04:18:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJnn-0003US-V5 for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 04:18:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27394 for ; Wed, 5 Nov 2003 04:17:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJnl-0007hm-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:18:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHJnk-0007hj-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:18:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJne-0003Lo-M7; Wed, 05 Nov 2003 04:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJnb-0003LR-7W for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 04:17:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27390 for ; Wed, 5 Nov 2003 04:17:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJnY-0007hf-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:17:56 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AHJnT-0007hM-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:17:55 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA59HAls027375; Wed, 5 Nov 2003 18:17:10 +0900 (KST) Message-ID: <00d201c3a37e$af64c710$ec2f024b@tyre> From: "JinHyeock Choi" To: "Pekka Savola" , "Soliman Hesham" Cc: , "Erik Nordmark" , References: Subject: Re: Issue 13: Omission of prefix options - resolution Date: Wed, 5 Nov 2003 18:24:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UGVra2EgU2F2b2xhIHdyb3RlOiANCj4gTWF5YmUsIG1heWJlIG5vdC4gIENhbid0IHNheSBmb3Ig c3VyZSB5ZXQuICBNeSB3b3JyeSBpcyB0aGF0IHdlJ3JlIG9wZW5pbmcNCj4gdXAgYSBwcm9ibGVt IHdlIGRvbid0IHVuZGVyc3RhbmQgeWV0LCBvbmUgZm9yIHdoaWNoIHRoZXJlIGJhc2ljYWxseSBv bmx5DQo+IC0wMCBJLUQncyBvZi4NCg0KSSBhbSBnbGFkIHRvIHNheSB0aGF0IHRoZXJlIGFjdHVh bGx5IGlzIGF0IGxlYXN0IG9uZSAtMDEgSS1ELiA6LSkuIA0KDQpNb3ZlbWVudCBEZXRlY3Rpb24g T3B0aW1pemF0aW9uIGluIE1vYmlsZSBJUHY2DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1kYWxleS1tb2JpbGVpcC1tb3ZlZGV0ZWN0LTAxLnR4dA0KDQpHcmVnIERh bGV5IGFuZCBJIHdyb3RlIGEgZmV3IElEcyBvbiB0aGlzIHByb2JsZW0uIA0KIA0KPiBJIGNhbiBi ZSBwcmV0dHkgc3VyZSB3ZSBkb24ndCB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtcyBhbmQgdGhlIG1l Y2hhbmlzbXMgDQo+IHRvIGZpeCB0aG9zZSBwcm9ibGVtcyB3ZWxsIGVub3VnaCB5ZXQuDQoNCkkg YWdyZWUuIFdlIHRyeSB0byBoYXZlIGJldHRlciB1bmRlcnN0YW5kaW5nIGF0IEROQSBCb0YuIA0K IA0KPiBTbywgdGhlIGJlc3QgZml4IGNvdWxkIGp1c3QgYmUgdG8gdHJ5IHRvIGNsYXJpZnkgMjQ2 MWJpcywgYW5kIGlmIA0KPiBtb2RpZmljYXRpb25zIGFyZSByZXF1aXJlZCwgbGV0IHRoZW0gYmUg ZG9uZSBzZXBhcmF0ZWx5Li4NCg0KV2UgbmVlZCB0byBzcGVjaWZ5IG5ldyBvcGVyYXRpb25hbCBw cm9jZWR1cmVzIGZvciBlZmZpY2llbnQgTUQvIEROQSwgd2hpY2ggDQptYXkgYmUgZG9uZSBhdCBE TkEgQm9GLiBCdXQgZm9yIHRoZW0sIHdlIG5lZWQgdG8gbW9kaWZ5IFJGQyAyNDYxLCB3aGljaCAN Cm5lZWRzIHRvIGJlIGRvbmUgYXQgSVB2NiBXRywgd2hldGhlciBpdCB0byBkZWZpbmUgYSBuZXcg Yml0IG9yIGFkb3B0IGEgbmV3IA0KT3B0aW9uLiANCg0KQmVzdCByZWdhcmRzDQoNCkppbkh5ZW9j aw== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 04:31:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28155 for ; Wed, 5 Nov 2003 04:31:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHK0T-0004lY-8U for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 04:31:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA59VHJh018320 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 04:31:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHK0S-0004lP-Lh for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 04:31:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28122 for ; Wed, 5 Nov 2003 04:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHK0P-0000Db-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:31:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHK0O-0000DY-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:31:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHK0E-0004cP-S6; Wed, 05 Nov 2003 04:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJzn-0004ba-8v for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 04:30:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28081 for ; Wed, 5 Nov 2003 04:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJzk-0000CY-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:30:32 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AHJzj-0000CU-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:30:31 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA59UJXO008742; Wed, 5 Nov 2003 11:30:19 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) id hA59UGo0008736; Wed, 5 Nov 2003 11:30:16 +0200 Date: Wed, 5 Nov 2003 11:30:16 +0200 Message-Id: <200311050930.hA59UGo0008736@burp.tkv.asdf.org> From: Markku Savela To: athene@sait.samsung.co.kr CC: H.Soliman@flarion.com, greg.daley@eng.monash.edu.au, pekkas@netcore.fi, Erik.Nordmark@sun.com, ipv6@ietf.org In-reply-to: <008501c3a37b$6daaa270$ec2f024b@tyre> (athene@sait.samsung.co.kr) Subject: Re: Issue 13: Omission of prefix options - resolution References: <748C6D0A58C0F94CA63C198B6674697A01922E83@ftmail.lab.flarion.com> <008501c3a37b$6daaa270$ec2f024b@tyre> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > From: "JinHyeock Choi" > There are pro and con between them. For example, if an MN receives a complete > RA which contains all the prefixes, it can form new CoA immediately. Whereas, if > it receives a RA which contains LinkID but no prefixe, an additional RS/ RA > exchange is needed. MIP6 should not configure new COA just because it sees RA. It should always wait until stack has accepted and configured valid address. Mobile IP6 should be considered as two almost independent components: MIP6 and Movement detection (MOVD). Something like follows IP6 Stack ---------- | | MIP6 MOVD MIP6 has really no need for messing with RA's. It should just detect "movement" by the fact that the CoA it has been using has been removed from the stack. Then it can find a new CoA from the stack, when it configures. MOVD may monitore RA's (and use LinkId's or whatever) or use other Layer2 meeans to detect movement. When it notices that the link has changed, it only needs an api to prematurely expire the addressess and prefixes associated with the old link. This way MIP6 works regardless of the reason why link goes down (even if it is done manually). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 08:13:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04297 for ; Wed, 5 Nov 2003 08:13:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNTZ-0008C5-Rf for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 08:13:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5DDXg4031491 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 08:13:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNTZ-0008Bq-NH for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 08:13:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04268 for ; Wed, 5 Nov 2003 08:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNTY-0003hV-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 08:13:32 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHNTY-0003hS-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 08:13:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNT5-00082X-5w; Wed, 05 Nov 2003 08:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNSn-00081l-Mu for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 08:12:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04245 for ; Wed, 5 Nov 2003 08:12:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNSm-0003gw-00 for ipv6@ietf.org; Wed, 05 Nov 2003 08:12:44 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHNSm-0003gt-00 for ipv6@ietf.org; Wed, 05 Nov 2003 08:12:44 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D877CAFB46; Wed, 5 Nov 2003 08:12:43 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15683-04; Wed, 5 Nov 2003 08:12:42 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 2E130AFB41; Wed, 5 Nov 2003 08:12:42 -0500 (EST) Date: Wed, 5 Nov 2003 07:07:44 -0500 From: Keith Moore To: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=) Cc: moore@cs.utk.edu, gene@nttmcl.com, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) Message-Id: <20031105070744.0c7b9f52.moore@cs.utk.edu> In-Reply-To: References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> <20031104175008.51e17e6a.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > As far as I can see, the only good reason to have the service argument > > > in getaddrinfo is to make it possible for getaddrinfo to perform SRV > > > lookups. > > > > that's not a good reason, that's a disaster. > > That's a strong word, given that the only effect on lookups in the > majority of domains that haven't deployed SRV, is one more roundtrip > to the local caching dns-server. Wrong. One problem is that the various apps that don't use SRV now won't all get upgraded at once. So when you turn on a SRV record you will break all of the clients and servers that don't support SRV yet. Either that or you have to configure the server to support both old and new ports. Another part of the problem is that the server has to be explicitly configured to listen on the alternate port - there's no reliable way for the server to automatically determine this. So SRV creates yet another way for DNS to get out of sync with host configuration - another knob that can be set incorrectly. And yes, we went through a similar transition with MX records and email; but the net was much smaller then, and this was a deliberate change to a single app by the people who maintained that app rather than a change to every app made by people who had nothing to do with most of those apps. Even so, my recollection that it wasn't until the mid-1990s that you could count on MTAs recognizing MX records, even though RFC 974 was published in 1986. I'd expect the net to transition even more slowly today. > > it would also tempt NATs to tweak DNS in even more preverse > > ways than they already do. > > I don't understand how this is relevant. It should work fine unless > the NAT operator does anything stupid, and that's the highest level of > NAT-support we can expect for any protocol. NAT vendors do stupid things all the time, like producing NATs that modify the contents of packets where they don't even know what protocol is being used. What makes you think they would stop there? > > there's a reason that RFC 2782 contains the following text: > > > > Service SRV records SHOULD NOT be used in the absence > > of such specification. > > Right, for each particular domain and service, there's a choice that > has to be made before deploying SRV. In order for SRV-records to be > used for a particular service, both ends must have it: There must be > SRV records configured in the DNS-server for the domain, and the > client must ask for and use them. and the server has to listen on that port and honor requests. > The effect of of having getaddrinfo try SRV lookup (or generally, > having a random client application ask for SRV records by default) is > to make it possible for the operator of the domain in question to > easily implement her choice. Funny, you want the admin to have this choice, but you apparently don't want the application specification to have a choice (as RFC 2782 insists must be done) SRV can be useful, but its utility varies widely depending on the application. For some apps it's completely inappropriate. Should ping honor SRV? What about ssh? SNMP? NFS? FTP? Sometimes a domain names a service; sometimes it names a host. and is it really worth it to double the time required to do DNS lookups FOR EVERY APP, when DNS lookups are already abysmally slow and unreliable? > My current interest in SRV is that I'm hacking Ian Jackson's resolver > library "adns" to support IPv6 and SRV. That's fine and useful as long as you make the SRV lookup optional. Apps need to choose whether they want to do SRV or not; not have that choice made for them. > If there's any good reason why I shouldn't > recommend random client applications to use this function, I'd like to > know about it. The reason is: it violates the SRV specification to use SRV with an app that doesn't specify the use of SRV, and it also violates the specifications of those applications that specify a port number to be used. > Ah, and one more question: After a first look around for SRV records > in the current DNS infrastructure, I've found SRV records for the > following services: ftp, http, kerberos, kpasswd, and sip. I imagine > SIP, being a recent protocol, actually specifies the use of SRV (I > haven't read the SIP specs). It does. I believe there's a spec for use of SRV with Kerberos also. I am fairly confident that ftp, http SRV records are bogus and should not be honored by standards-conforming clients. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 08:15:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04462 for ; Wed, 5 Nov 2003 08:15:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNVJ-00006q-Fk for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 08:15:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5DFLrj000414 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 08:15:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNVJ-00006b-Ap for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 08:15:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04401 for ; Wed, 5 Nov 2003 08:15:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNVI-0003mA-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 08:15:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHNVH-0003m7-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 08:15:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNV1-0008Nv-Sp; Wed, 05 Nov 2003 08:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNUg-0008Hp-Eo for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 08:14:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04358 for ; Wed, 5 Nov 2003 08:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNUf-0003ix-00 for ipv6@ietf.org; Wed, 05 Nov 2003 08:14:41 -0500 Received: from web21401.mail.yahoo.com ([216.136.232.71]) by ietf-mx with smtp (Exim 4.12) id 1AHNUe-0003iu-00 for ipv6@ietf.org; Wed, 05 Nov 2003 08:14:40 -0500 Message-ID: <20031105131436.3220.qmail@web21401.mail.yahoo.com> Received: from [221.147.158.213] by web21401.mail.yahoo.com via HTTP; Wed, 05 Nov 2003 05:14:36 PST Date: Wed, 5 Nov 2003 05:14:36 -0800 (PST) From: JinHyeock Choi Subject: Re: Issue 13: Omission of prefix options - resolution To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-350007900-1068038076=:2908" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-350007900-1068038076=:2908 Content-Type: text/plain; charset=us-ascii Markku Savela wrote >> There are pro and con between them. For example, if an MN receives a complete >> RA which contains all the prefixes, it can form new CoA immediately. Whereas, if >> it receives a RA which contains LinkID but no prefixe, an additional RS/ RA >> exchange is needed. > > MIP6 should not configure new COA just because it sees RA. It should > always wait until stack has accepted and configured valid address. I was not clear enough. I tried to mean as belows. "if an MN detects movement (subnet change) by receiving a complete RA ......, if it detects movement (subnet change) by receiving a RA which contains Link ID......" > Mobile IP6 should be considered as two almost independent components: > MIP6 and Movement detection (MOVD). Something like follows > > IP6 Stack > ---------- > | | > MIP6 MOVD > > MIP6 has really no need for messing with RA's. It should just detect > "movement" by the fact that the CoA it has been using has been removed > from the stack. Then it can find a new CoA from the stack, when it > configures. In our case, we implemented movement detection module as a part of our MIPv6 stack. Correct me if wrong, but currently there is no universal way of movement detection. At ETSI event, we found each MIPv6 stack uses different MD modules. Some use NUD like three NS probes, some 1 NS and time out and some ECS (Eager Cell Switching). I restrain myself from delving into detailed movement detection scheme, barely. :-) Best regards JinHyeock --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-350007900-1068038076=:2908 Content-Type: text/html; charset=us-ascii
Markku Savela wrote
>> There are pro and con between them. For example, if an MN receives a complete
>> RA which contains all the prefixes, it can form new CoA immediately. Whereas, if
>> it receives a RA which contains  LinkID but no prefixe, an additional RS/ RA
>> exchange is needed.
>
> MIP6 should not configure new COA just because it sees RA. It should
> always wait until stack has accepted and configured valid address.
 
I was not clear enough. I tried to mean as belows.
 
"if an MN detects movement (subnet change) by receiving a complete RA ......,
if it detects movement (subnet change) by receiving a RA which contains Link ID......"
 
> Mobile IP6 should be considered as two almost independent components:
> MIP6 and Movement detection (MOVD). Something like follows
>
>        IP6 Stack
>      ----------
>      |        |
>    MIP6      MOVD
>
> MIP6 has really no need for messing with RA's. It should just detect
> "movement" by the fact that the CoA it has been using has been removed
> from the stack. Then it can find a new CoA from the stack, when it
> configures.
 
In our case, we implemented movement detection module as a part of our
MIPv6 stack. Correct me if wrong, but currently there is no universal way of
movement detection. At ETSI event, we found each MIPv6
stack uses different MD modules. Some use NUD like three NS probes,
some 1 NS and time out and some ECS (Eager Cell Switching).
 
I restrain myself from delving into detailed movement detection scheme, barely. :-)
 
Best regards
 
JinHyeock

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-350007900-1068038076=:2908-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 08:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05200 for ; Wed, 5 Nov 2003 08:35:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNoX-0001SP-LV for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 08:35:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5DZDl6005595 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 08:35:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNoX-0001SA-Ce for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 08:35:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05171 for ; Wed, 5 Nov 2003 08:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNoW-00044z-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 08:35:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHNoV-00044w-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 08:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNoN-0001Mg-EE; Wed, 05 Nov 2003 08:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNnM-0001Lt-Lz for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 08:34:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05158 for ; Wed, 5 Nov 2003 08:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNnL-00044b-00 for ipv6@ietf.org; Wed, 05 Nov 2003 08:33:59 -0500 Received: from x1-6-00-08-0e-cc-31-33.k129.webspeed.dk ([80.161.142.15] helo=ursa.amorsen.dk) by ietf-mx with esmtp (Exim 4.12) id 1AHNnK-00044Y-00 for ipv6@ietf.org; Wed, 05 Nov 2003 08:33:59 -0500 Received: from [192.168.2.79] (unknown [192.168.2.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id 96EB11C160; Wed, 5 Nov 2003 14:33:48 +0100 (CET) Subject: Re: Issue 13: Omission of prefix options - resolution From: Benny Amorsen To: Markku Savela Cc: athene@sait.samsung.co.kr, H.Soliman@flarion.com, greg.daley@eng.monash.edu.au, pekkas@netcore.fi, Erik.Nordmark@sun.com, ipv6@ietf.org In-Reply-To: <200311050930.hA59UGo0008736@burp.tkv.asdf.org> References: <748C6D0A58C0F94CA63C198B6674697A01922E83@ftmail.lab.flarion.com> <008501c3a37b$6daaa270$ec2f024b@tyre> <200311050930.hA59UGo0008736@burp.tkv.asdf.org> Content-Type: text/plain Message-Id: <1068039224.6812.2.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 05 Nov 2003 14:33:46 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 2003-11-05 at 10:30, Markku Savela wrote: > MIP6 has really no need for messing with RA's. It should just detect > "movement" by the fact that the CoA it has been using has been removed > from the stack. Then it can find a new CoA from the stack, when it > configures. In some cases, imminent death of a CoA is known in advance, and the new address already available. Would it not make sense to initiate switchover before the old address finally goes away? With both addresses working in parallel for a little while, the switchover might not even lead to a single lost packet. /Benny -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 12:10:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13291 for ; Wed, 5 Nov 2003 12:10:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRAz-0006KF-Km for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 12:10:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5HAbZs024311 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 12:10:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRAz-0006K2-0R for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 12:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13253 for ; Wed, 5 Nov 2003 12:10:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRAx-000746-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 12:10:35 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHRAx-000743-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 12:10:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRAR-0006DW-J5; Wed, 05 Nov 2003 12:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHR9p-0006Cv-Du for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 12:09:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13208 for ; Wed, 5 Nov 2003 12:09:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHR9o-00072k-00 for ipv6@ietf.org; Wed, 05 Nov 2003 12:09:24 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHR9n-00072h-00 for ipv6@ietf.org; Wed, 05 Nov 2003 12:09:23 -0500 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id DA1F27EB86; Wed, 5 Nov 2003 18:09:22 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 43AD96A8DB; Wed, 5 Nov 2003 18:09:20 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hA5H9JAj011547; Wed, 5 Nov 2003 18:09:19 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hA5H9E5f011544; Wed, 5 Nov 2003 18:09:14 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Keith Moore Cc: gene@nttmcl.com, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> <20031104175008.51e17e6a.moore@cs.utk.edu> <20031105070744.0c7b9f52.moore@cs.utk.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 05 Nov 2003 18:09:13 +0100 In-Reply-To: <20031105070744.0c7b9f52.moore@cs.utk.edu> Message-ID: Lines: 67 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Keith Moore writes: > NAT vendors do stupid things all the time, like producing NATs that > modify the contents of packets where they don't even know what protocol > is being used. What makes you think they would stop there? *No* protocol can work under the assumption that there's a NAT box on the path that makes arbitrarily stupid changes to packets. Therefore, it's not possible or useful to consider that scenario in protocol or application design. > Funny, you want the admin to have this choice, but you apparently > don't want the application specification to have a choice (as RFC 2782 > insists must be done) The default ssh port is 22. Say that I operate an ssh server, and for some arbitrary reason I want it to listen on a different port, say 80. To make this work, I can send out a mail to all my users telling them to use ssh -p 80, and hope they read and remember that. Or I could install an SRV record in the DNS tree that says that I'm using port 80, and hope the the users' ssh clients will notice. Or both. The ssh spec only says that "the server normally listens for connections on port 22", and that the number is registered with IANA. Just descriptive, no normative language at all. Given that, I can't read the ssh spec as saying which methods, email or SRV or a sign on the wall, I may use to tell my user's and their ssh clients that I use a different port. > SRV can be useful, but its utility varies widely depending on the > application. For some apps it's completely inappropriate. Should > ping honor SRV? To use SRV for ICMP ping seems quite far out. > What about ssh? SNMP? NFS? FTP? Sometimes a > domain names a service; sometimes it names a host. If the server administrater wants it: Sure. Nobody else can really decide whether or not SRV is "useful" or "appropriate" for a particular service instance. > The reason is: it violates the SRV specification to use SRV with an app > that doesn't specify the use of SRV, and it also violates the specifications > of those applications that specify a port number to be used. > I am fairly confident that ftp, http SRV records are bogus and should > not be honored by standards-conforming clients. Thanks for the answers, even if I'm not totally convinced. Let's look at http again, where the spec for http-url:s says clearly that of no port number is given explicitly, port 80 should be used (the text is descriptive here too, "if the port is empty or not given, port 80 is assumed"). Say I have a SRV aware browser that breaks the spec and looks up _http._tcp SRV records, and uses ports given in SRV records instead of the default port 80. Then my SRV aware browser and a traditional browser will get different content for the same URL, which seems like a bad thing. But that's not a new problem. One example is http://www.kame.net (CNAME orange.kame.net), where you, intentionally, get slightly different content for the same URL depending on whether or not your browser and operating system happen to use IPv6. I'm not sure it's a real problem that this kind of "misconfiguration" is possible. Regards, /Niels -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 12:46:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14568 for ; Wed, 5 Nov 2003 12:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRjU-00007l-RA for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 12:46:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5HkG0U000471 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 12:46:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRjU-00007W-LV for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 12:46:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14541 for ; Wed, 5 Nov 2003 12:46:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRjT-0007Z7-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 12:46:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHRjS-0007Z4-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 12:46:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRjG-0008TR-JQ; Wed, 05 Nov 2003 12:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRj5-0008Sq-Gf for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 12:45:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14525 for ; Wed, 5 Nov 2003 12:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRj3-0007Yn-00 for ipv6@ietf.org; Wed, 05 Nov 2003 12:45:49 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHRj3-0007Yk-00 for ipv6@ietf.org; Wed, 05 Nov 2003 12:45:49 -0500 Received: from localhost (unknown [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 74124AFB82; Wed, 5 Nov 2003 12:45:49 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32230-13; Wed, 5 Nov 2003 12:45:41 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 48672AFB4B; Wed, 5 Nov 2003 12:45:41 -0500 (EST) Date: Wed, 5 Nov 2003 12:42:02 -0500 From: Keith Moore To: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=) Cc: moore@cs.utk.edu, gene@nttmcl.com, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) Message-Id: <20031105124202.7f66134c.moore@cs.utk.edu> In-Reply-To: References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> <20031104175008.51e17e6a.moore@cs.utk.edu> <20031105070744.0c7b9f52.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > NAT vendors do stupid things all the time, like producing NATs that > > modify the contents of packets where they don't even know what > > protocol is being used. What makes you think they would stop there? > > *No* protocol can work under the assumption that there's a NAT box on > the path that makes arbitrarily stupid changes to packets. Therefore, > it's not possible or useful to consider that scenario in protocol or > application design. No, but it is entirely reasonable to realize that having applications support SRV is a temptation for NAPT boxes to intercept DNS queries for SRV records, allocate an external port for that service, map it to the internal address and default port for that service, and returning A SRV record that indicates the external port - thus furthering the pollution of the network. > > Funny, you want the admin to have this choice, but you apparently > > don't want the application specification to have a choice (as RFC > > 2782 insists must be done) > > The default ssh port is 22. Say that I operate an ssh server, and for > some arbitrary reason I want it to listen on a different port, say 80. > To make this work, I can send out a mail to all my users telling them > to use ssh -p 80, and hope they read and remember that. Or I could > install an SRV record in the DNS tree that says that I'm using port > 80, and hope the the users' ssh clients will notice. Or both. Or you could redirect attempts to ssh to host X so that they go to host Y instead. This is not an inherently desirable feature. The point is - it's not within either the purview of the DNSext group, or the network administrator, to change how the ssh application operates. Unilaterally imposing SRV records violates the expectations behind the design of the app, and may violate users' expectations also. > > SRV can be useful, but its utility varies widely depending on the > > application. For some apps it's completely inappropriate. Should > > ping honor SRV? > > To use SRV for ICMP ping seems quite far out. To use SRV for lots of protocols seems far out. ICMP is just one end of a broad spectrum. > > What about ssh? SNMP? NFS? FTP? Sometimes a > > domain names a service; sometimes it names a host. > > If the server administrater wants it: Sure. Nobody else can really > decide whether or not SRV is "useful" or "appropriate" for a > particular service instance. Nor, for that matter, can the DNS server administrator. > > The reason is: it violates the SRV specification to use SRV with an > > app that doesn't specify the use of SRV, and it also violates the > > specifications of those applications that specify a port number to > > be used. > > > I am fairly confident that ftp, http SRV records are bogus and > > should not be honored by standards-conforming clients. > > Thanks for the answers, even if I'm not totally convinced. > > Let's look at http again, where the spec for http-url:s says clearly > that of no port number is given explicitly, port 80 should be used > (the text is descriptive here too, "if the port is empty or not given, > port 80 is assumed"). Say I have a SRV aware browser that breaks the > spec and looks up _http._tcp SRV records, and uses ports given in SRV > records instead of the default port 80. There's WAY too much code out there that assumes that the lack of an explicit port number in an HTTP URL means port 80. Imposing SRV on HTTP would break all of that code. For instance, http://example.com:80/foo/bar will be canonicalized to http://example.com/foo/bar - which, if there were a SRV record for _http._tcp.example.com pointing to a different port or host, would change the meaning of the URL. It's incredibly naive to think that you unilaterally can change an interface used by nearly all apps and not break things. To insist on doing it anyway is criminally irresponsible. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 13:30:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16116 for ; Wed, 5 Nov 2003 13:30:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSQG-0002Ll-Fp for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 13:30:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5IUSB2009027 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 13:30:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSQG-0002LW-Bm for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:30:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16086 for ; Wed, 5 Nov 2003 13:30:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSQE-0000Nz-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 13:30:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHSQE-0000Nw-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 13:30:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSPr-0002F0-1H; Wed, 05 Nov 2003 13:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSPD-0002EB-P4 for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 13:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16070 for ; Wed, 5 Nov 2003 13:29:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSPB-0000LP-00 for ipv6@ietf.org; Wed, 05 Nov 2003 13:29:21 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AHSPB-0000LF-00 for ipv6@ietf.org; Wed, 05 Nov 2003 13:29:21 -0500 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 hA5ISoV03365 for ; Wed, 5 Nov 2003 10:28:50 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hA5IWCtX011465 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Nov 2003 10:32:15 -0800 Message-ID: <3FA940FA.2030902@innovationslab.net> Date: Wed, 05 Nov 2003 13:27:06 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" References: <3F9665EC.4010508@innovationslab.net> In-Reply-To: <3F9665EC.4010508@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a reminder that the last call on the deprecation document ends today. In particular, the chairs would like to ensure that the WG agrees on the actual deprecation text in Sections 4 & 6. There has been few comments on this draft and it cannot proceed unless the chairs can be sure that it has been thoroughly reviewed and agreed upon. If you have reviewed the document, have no issues with it, and agree on its content, please let the chairs and/or the working group know. Thanks, Brian & Bob IPv6 WG Chairs Brian Haberman wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : Deprecating Site Local Addresses > Author(s) : C. Huitema, B. Carpenter > Filename : draft-ietf-ipv6-deprecate-site-local-01.txt > Pages : 10 > Date : 2003-10-13 > > Please send substantive comments to the ipv6 mailing list, and minor > editorial comments to the authors. This last call period will end on 5 > November 2003. > > Brian Haberman / Bob Hinden > IPv6 W.G. Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 13:48:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16677 for ; Wed, 5 Nov 2003 13:48:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHShV-0003aF-NP for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 13:48:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5ImHUR013769 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 13:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHShV-0003a0-IP for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:48:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16605 for ; Wed, 5 Nov 2003 13:48:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHShT-0000bX-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 13:48:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHShS-0000bU-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 13:48:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHShH-0003T1-Vg; Wed, 05 Nov 2003 13:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSgr-0003S4-Qq for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 13:47:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16589 for ; Wed, 5 Nov 2003 13:47:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSgp-0000b1-00 for ipv6@ietf.org; Wed, 05 Nov 2003 13:47:35 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AHSgo-0000ay-00 for ipv6@ietf.org; Wed, 05 Nov 2003 13:47:35 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA5IlZPh015819 for ; Wed, 5 Nov 2003 11:47:35 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNW00IOQ6VAGE@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 05 Nov 2003 11:47:35 -0700 (MST) Received: from sun.com ([129.146.11.181]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNW00FLV6V9CB@mail.sun.net> for ipv6@ietf.org; Wed, 05 Nov 2003 11:47:34 -0700 (MST) Date: Wed, 05 Nov 2003 10:47:33 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" To: Brian Haberman Cc: ipv6@ietf.org Message-id: <3FA945C5.6060402@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: <3F9665EC.4010508@innovationslab.net> <3FA940FA.2030902@innovationslab.net> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > 4 Deprecation > > This document formally deprecates the IPv6 site-local unicast prefix > defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The > special behavior of this prefix MUST no longer be supported in new > implementations. I think this section is not ready yet. Couple comments: 1) This is not the IETF job to mandate what an implemention choose to support or not. 2) What constitute a "new implementation"? For example, we shipped IPv6 in Solaris 8. Same bits plus extra features in Solaris 9, more coming in newer relases, but fundamentally the same code fundation. Would Solaris 10, 11, 12, 13, 14.... or what ever new name we come up with be considered as "new implemtations"? This is confusing... 3) What does section 4 exactly means with regard to default address selection RFC3484? Does this obsolete the rules about scope? - Alain. Brian Haberman wrote: > This is a reminder that the last call on the deprecation document > ends today. In particular, the chairs would like to ensure that > the WG agrees on the actual deprecation text in Sections 4 & 6. > There has been few comments on this draft and it cannot proceed > unless the chairs can be sure that it has been thoroughly reviewed > and agreed upon. > > If you have reviewed the document, have no issues with it, and agree > on its content, please let the chairs and/or the working group know. > > Thanks, > Brian & Bob > IPv6 WG Chairs > > Brian Haberman wrote: > >> This is a IPv6 working group last call for comments on advancing the >> following document as an Proposed Standard: >> >> Title : Deprecating Site Local Addresses >> Author(s) : C. Huitema, B. Carpenter >> Filename : draft-ietf-ipv6-deprecate-site-local-01.txt >> Pages : 10 >> Date : 2003-10-13 >> >> Please send substantive comments to the ipv6 mailing list, and minor >> editorial comments to the authors. This last call period will end on 5 >> November 2003. >> >> Brian Haberman / Bob Hinden >> IPv6 W.G. Chairs > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 14:28:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18598 for ; Wed, 5 Nov 2003 14:28:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTKK-0006cx-Em for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 14:28:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JSOHn025461 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 14:28:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTKK-0006cN-8Q for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18502 for ; Wed, 5 Nov 2003 14:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTKH-0001Gd-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:28:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTKH-0001GY-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:28:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTJx-0006SG-Qu; Wed, 05 Nov 2003 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTJE-0006MD-HX for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 14:27:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18359 for ; Wed, 5 Nov 2003 14:27:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTJB-0001E1-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:27:14 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AHTJB-0001DY-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:27:13 -0500 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 hA5JQhV03744 for ; Wed, 5 Nov 2003 11:26:43 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hA5JU5tX011627 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Nov 2003 11:30:08 -0800 Message-ID: <3FA94E8A.1080008@innovationslab.net> Date: Wed, 05 Nov 2003 14:24:58 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Mailing List Subject: Author list for 2461bis and 2462bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The chairs would like to clarify the issue surrounding who gets listed as authors of the updates to 2461 and 2462. Since updating these RFCs is a formal IPv6 WG task, the chairs took the responsibility to procure editors for the updates. We contacted, or attempted to contact, all the authors of these RFCs to gauge their ability to lead the editing of the updates. All the authors who responded indicated that they did not have the time to edit the drafts. We were unable to contact one author of the Neighbor Discovery spec due to e-mail bounces. At that point, the chairs asked Tatuya Jinmei and Hesham Soliman to take on the responsibility of editing 2461bis and 2462bis. For the time being, the chairs expect that the original authors and the new editors will be listed on the front page of these I-Ds. This should give appropriate credit to the original authors and to the new editors as work progresses on the updates. When these documents come closer to completion, we will evaluate who should be listed as authors and who should be listed as contributors. An example of how this has worked in the past, please take a look at the recent MIB updates done in this working group. Regards, Brian & Bob IPv6 WG Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 14:46:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19944 for ; Wed, 5 Nov 2003 14:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTbU-0008Fp-Vj for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 14:46:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Jk8cE031723 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 14:46:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTbU-0008Fa-QJ for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:46:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19904 for ; Wed, 5 Nov 2003 14:45:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTbS-0001of-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:46:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTbR-0001oc-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTbO-00089z-H8; Wed, 05 Nov 2003 14:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTbM-00089W-0r for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 14:46:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19897 for ; Wed, 5 Nov 2003 14:45:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTbJ-0001oS-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:45:57 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTbE-0001oP-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:45:52 -0500 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 TAA10320 for ; Wed, 5 Nov 2003 19:45:51 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA27153 for ; Wed, 5 Nov 2003 19:45:51 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA5JjpH28492 for ipv6@ietf.org; Wed, 5 Nov 2003 19:45:51 GMT Date: Wed, 5 Nov 2003 19:45:51 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Message-ID: <20031105194551.GB28127@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <3F9665EC.4010508@innovationslab.net> <3FA940FA.2030902@innovationslab.net> <3FA945C5.6060402@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA945C5.6060402@sun.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, Nov 05, 2003 at 10:47:33AM -0800, Alain Durand wrote: > > 1) This is not the IETF job to mandate what an implemention choose > to support or not. But, for example, isn't that what the node requirements draft does? Ok it does not "mandate" but it uses wordage like "all IPv6 nodes can be expected to implement the mandatory requirements listed in this document". > 3) What does section 4 exactly means with regard to default address > selection RFC3484? > Does this obsolete the rules about scope? Good point. I assume RFC3484 will need a touch-up or clarification once this deprecation document goes past last call. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 14:47:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20079 for ; Wed, 5 Nov 2003 14:47:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTcR-00009P-83 for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 14:47:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Jl7M1000579 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 14:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTcR-00005n-1Y for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19983 for ; Wed, 5 Nov 2003 14:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTcM-0001qP-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:47:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTcL-0001qM-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTcM-0008PZ-VW; Wed, 05 Nov 2003 14:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTbr-0008My-UW for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 14:46:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19927 for ; Wed, 5 Nov 2003 14:46:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTbp-0001pL-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:46:29 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AHTbo-0001oV-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:46:28 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 5 Nov 2003 11:46:13 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 5 Nov 2003 11:45:56 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Nov 2003 11:45:57 -0800 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.6713); Wed, 5 Nov 2003 11:45:57 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 5 Nov 2003 11:44:54 -0800 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.3790.1069); Wed, 5 Nov 2003 11:46:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Date: Wed, 5 Nov 2003 11:45:56 -0800 Message-ID: Thread-Topic: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" thread-index: AcOjzYKhLb+vyAI6R6eTro2HjQlqawABxdgw From: "Christian Huitema" To: "Alain Durand" , "Brian Haberman" Cc: X-OriginalArrivalTime: 05 Nov 2003 19:46:02.0835 (UTC) FILETIME=[71C12230:01C3A3D5] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 > > 4 Deprecation > > > > This document formally deprecates the IPv6 site-local unicast prefix > > defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The > > special behavior of this prefix MUST no longer be supported in new > > implementations. >=20 > I think this section is not ready yet. Couple comments: >=20 > 1) This is not the IETF job to mandate what an implemention choose > to support or not. Sure. An implementation may choose to give a special meaning to a special prefix, say "DEAD:BEEF::/32", and the IETF cannot do anything about it. However, the whole purpose of the deprecation draft is, well, to deprecate site local addresses. These addresses use to have a special meaning, an expectation that they can only reach "on site" nodes. The special meaning is not supported any more. Applications must not expect it to be supported. Do you have an alternative writing? > 2) What constitute a "new implementation"? > For example, we shipped IPv6 in Solaris 8. Same bits plus extra > features in Solaris 9, more coming in newer relases, but fundamentally > the same code fundation. Would Solaris 10, 11, 12, 13, 14.... > or what ever new name we come up with be considered as "new > implemtations"? > This is confusing... Alternative text for "new implementation" would be welcome. I guess that the intent is clear. > 3) What does section 4 exactly means with regard to default address > selection RFC3484? > Does this obsolete the rules about scope? Well, we still have link local scope, so there is still that. Do you suggest that we write a line for each of the RFC that currently mention site local and explain how to change them? -- Christian Huitema =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 14:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20293 for ; Wed, 5 Nov 2003 14:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTiJ-0000jE-Bf for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 14:53:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JrBoP002794 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 14:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTiJ-0000gP-5q for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:53:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20267 for ; Wed, 5 Nov 2003 14:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTiG-0001yf-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:53:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTiF-0001yc-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:53:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTiA-0000aM-F0; Wed, 05 Nov 2003 14:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHThe-0000Zc-IM for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 14:52:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20249 for ; Wed, 5 Nov 2003 14:52:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHThb-0001y7-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:52:27 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHThb-0001y4-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:52:27 -0500 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 TAA10454 for ; Wed, 5 Nov 2003 19:52:26 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA27810 for ; Wed, 5 Nov 2003 19:52:26 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA5JqQx28572 for ipv6@ietf.org; Wed, 5 Nov 2003 19:52:26 GMT Date: Wed, 5 Nov 2003 19:52:26 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Message-ID: <20031105195226.GD28127@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, Nov 05, 2003 at 11:45:56AM -0800, Christian Huitema wrote: > > Well, we still have link local scope, so there is still that. Do you > suggest that we write a line for each of the RFC that currently mention > site local and explain how to change them? It would be interesting to know how many such references there are. But given the existing site-local usage willcontinue until at least we have a replacement, it seems premature to make any updates until the replacement is hardened? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 14:54:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20371 for ; Wed, 5 Nov 2003 14:54:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTj9-0000yi-JK for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 14:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Js3e1003654 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 14:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTj8-0000tA-JA for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20321 for ; Wed, 5 Nov 2003 14:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTj5-0001zi-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:53:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTj5-0001zf-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTj7-0000oY-HB; Wed, 05 Nov 2003 14:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTiF-0000bX-B8 for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 14:53:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20262 for ; Wed, 5 Nov 2003 14:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTiC-0001yZ-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:53:04 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak3a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AHTiC-0001yW-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:53:04 -0500 Received: from 132.235.232.96 by pm5 (PureMessage); Wed Nov 5 14:15:23 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak3a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hA5JFLYW1645996 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 5 Nov 2003 14:15:22 -0500 (EST) Date: Wed, 05 Nov 2003 14:15:18 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Message-ID: <1723041125.1068041718@hkruse2003a> In-Reply-To: <3FA940FA.2030902@innovationslab.net> References: <3F9665EC.4010508@innovationslab.net> <3FA940FA.2030902@innovationslab.net> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm5) X-PMX-Start: Wed Nov 5 14:15:23 2003 X-PMX-Stop: Wed Nov 5 14:15:23 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have no problems with the document content (and I did NOT try to read it for editorial nits...). --On Wednesday, November 05, 2003 13:27 -0500 Brian Haberman wrote: > If you have reviewed the document, have no issues with it, and agree > on its content, please let the chairs and/or the working group know. 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 15:02:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20728 for ; Wed, 5 Nov 2003 15:02:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTrB-0001ls-So for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 15:02:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5K2Lnn006802 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 15:02:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTrB-0001ld-NF for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 15:02:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20702 for ; Wed, 5 Nov 2003 15:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTr8-0002EJ-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 15:02:18 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTr8-0002EG-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 15:02:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTqs-0001c7-NM; Wed, 05 Nov 2003 15:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTpt-0001YZ-Ou for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 15:01:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20653 for ; Wed, 5 Nov 2003 15:00:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTpq-0002DW-00 for ipv6@ietf.org; Wed, 05 Nov 2003 15:00:58 -0500 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTpq-0002DJ-00 for ipv6@ietf.org; Wed, 05 Nov 2003 15:00:58 -0500 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id hA5K0VS10572; Wed, 5 Nov 2003 12:00:31 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id hA5K0UI12284; Wed, 5 Nov 2003 12:00:30 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA24208; Wed, 5 Nov 2003 12:04:31 -0800 (PST) Date: Wed, 5 Nov 2003 12:04:31 -0800 (PST) From: Tim Hartrick Message-Id: <200311052004.MAA24208@feller.mentat.com> To: greg.daley@eng.monash.edu.au Subject: Re: Issue 13: Omission of prefix options - resolution Cc: H.Soliman@flarion.com, itojun@iijlab.net, ipv6@ietf.org X-Sun-Charset: US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Greg, > Backward compatability shouldn't really be a problem. > Hosts which are doing RFC2461 Router Discovery > will understand RAs with options or bits in them > indicating solicitation or completeness, but just not > be able to access the improved function. > If a host that understands the new "bit" arrives on a network that has routers that don't speak the new "bit" but do send abbreviated router advertisements, then the host will need to take some new unspecified protocol action to force the routers to send unabbreviated router advertisements. Otherwise the host will not detect movement as quickly as it could when arriving on a network with routers that speak the new "bit". I agree that the other combinations of old and new functionality are not likely to have problems. Of course I don't really care for using router advertisements for movement detection, but if we are going to do it, getting in all the corners is important. > > I don't think it's that hard, but whether it goes into > RFC2461bis is another matter. > I know it isn't hard. However, in my opinion, trying to roll it into RFC2461bis is on the edge what should be going in what was advertised as a "bug fix" update. tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 16:24:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24546 for ; Wed, 5 Nov 2003 16:24:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8S-0005Sz-Ga for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 16:24:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LOGBH020999 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 16:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8O-0005R8-B8 for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24291 for ; Wed, 5 Nov 2003 16:23:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHV8M-0003YT-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHV8M-0003YQ-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8F-0005FZ-14; Wed, 05 Nov 2003 16:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHU0Q-0002Zj-Ja for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 15:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21711 for ; Wed, 5 Nov 2003 15:11:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHU0N-0002MG-00 for ipv6@ietf.org; Wed, 05 Nov 2003 15:11:51 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AHU0M-0002MC-00 for ipv6@ietf.org; Wed, 05 Nov 2003 15:11:51 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA5KBo5u028802 for ; Wed, 5 Nov 2003 13:11:50 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNW0005DARPSB@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 05 Nov 2003 13:11:50 -0700 (MST) Received: from sun.com ([129.146.11.181]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNW003GUARO53@mail.sun.net> for ipv6@ietf.org; Wed, 05 Nov 2003 13:11:49 -0700 (MST) Date: Wed, 05 Nov 2003 12:11:48 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" To: Christian Huitema Cc: Brian Haberman , ipv6@ietf.org Message-id: <3FA95984.1010303@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: Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Christian Huitema wrote: > > > >> > 4 Deprecation >> > >> > This document formally deprecates the IPv6 site-local unicast >> >> >prefix > > >> > defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. >> >> >>I think this section is not ready yet. Couple comments: >> >>1) This is not the IETF job to mandate what an implemention choose >> to support or not. >> >> > >Sure. An implementation may choose to give a special meaning to a >special prefix, say "DEAD:BEEF::/32", and the IETF cannot do anything >about it. However, the whole purpose of the deprecation draft is, well, >to deprecate site local addresses. These addresses use to have a special >meaning, an expectation that they can only reach "on site" nodes. The >special meaning is not supported any more. Applications must not expect >it to be supported. Do you have an alternative writing? > > > >>2) What constitute a "new implementation"? >> For example, we shipped IPv6 in Solaris 8. Same bits plus extra >> features in Solaris 9, more coming in newer relases, but >> >> >fundamentally > > >> the same code fundation. Would Solaris 10, 11, 12, 13, 14.... >> or what ever new name we come up with be considered as "new >>implemtations"? >> This is confusing... >> >> > >Alternative text for "new implementation" would be welcome. I guess that >the intent is clear. > > Suggested text to address both comments: replace: "The special behavior of this prefix MUST no longer be supported in new implementations." by "The special behavior of this prefix MUST no longer be supported." >>3) What does section 4 exactly means with regard to default address >>selection RFC3484? >> Does this obsolete the rules about scope? >> >> > >Well, we still have link local scope, so there is still that. Do you >suggest that we write a line for each of the RFC that currently mention >site local and explain how to change them? > Precisely. There are not that many of them. If you go through the archives, you'll find a post where I made the list of places that either mentioned FECO:: or site local. Or a simple grep in the RFC pages will do. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 16:24:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24619 for ; Wed, 5 Nov 2003 16:24:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8l-0005ie-EY for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 16:24:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LOZvj021977 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 16:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8k-0005i6-WC for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:24:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24416 for ; Wed, 5 Nov 2003 16:24:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHV8j-0003bf-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:33 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHV8i-0003YN-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV7p-0005Ao-OV; Wed, 05 Nov 2003 16:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHU0K-0002Ze-KR for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 15:11:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21701 for ; Wed, 5 Nov 2003 15:11:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHU0H-0002Lw-00 for ipv6@ietf.org; Wed, 05 Nov 2003 15:11:45 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AHU0H-0002LP-00 for ipv6@ietf.org; Wed, 05 Nov 2003 15:11:45 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 5 Nov 2003 12:11:31 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Nov 2003 12:11:14 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Nov 2003 12:11:11 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 5 Nov 2003 12:10:10 -0800 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.3790.1069); Wed, 5 Nov 2003 12:11:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Date: Wed, 5 Nov 2003 12:11:16 -0800 Message-ID: Thread-Topic: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" thread-index: AcOY3B6S8GORQ6pbSiC80e3eMAQe/QK+/YwQ From: "Christian Huitema" To: "Erik Nordmark" , "Brian Haberman" Cc: X-OriginalArrivalTime: 05 Nov 2003 20:11:19.0576 (UTC) FILETIME=[F9CD7180:01C3A3D8] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > From: Erik Nordmark, October 22, 2003 1:34 PM > To: Brian Haberman > Cc: ipv6@ietf.org > Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" >=20 >=20 > Overall I support this document, but there are two things that have > me concerned. >=20 > 1. The document talks about a replacement in section 2 and section 5. > While finding replacement for what folks perceived as being benefit > with site local addresses is useful (and perhaps even required), > the text in this draft seems to lock us down into replacement that > consist of defining some new address format. > I find this odd since the the WG has discussed partial replacement > solutions > (for instance, draft-zill-ipv6wg-zone-prefixlen-00.txt) which do not > involve > defining a new address format. >=20 > Does this document indeed intend to prevent the WG from working > on replacement solutions which do not define a new addressing format? > That would seem silly thus I suggest the text be reworked a bit to > make this more clear. The 'prefix length' draft is indeed independent of address formats, and provides an alternative to the use of site local addresses for security. I would agree to add a short paragraph describing how a prefix length option can be a helpful part of the solution. However, this option alone does not solve the other requirements, e.g. stable addresses that don't depend on out-of-site events.=20 > 2. Section 2 talks of only two categories of issues but I > think there is a 3rd one: "moving the problem to the application space". >=20 > The text in section 2.1 talks of only one aspect of this (having to deal > with scope ids in the application). > draft-wasserman-ipv6-sl-impact-02.txt in section 3.7 has additional > issues relating to: > - Two-party client/server applications that exchange IP > addresses at the application layer. > - Multi-party applications that exchange IP addresses at the > application layer. > Thus in particular the last two paragraphs in section 3.7 in > draft-wasserman-ipv6-sl-impact-02.txt seems to be missing from this draft > and I think they need to be included to make sure important aspects of > the issues are not forgotten as we move forward. OK. I think we can easily add a section with these two paragraphs and capture the idea. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 16:45:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25681 for ; Wed, 5 Nov 2003 16:45:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVT3-0000Oj-BE for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 16:45:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LjXMU001519 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 16:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVT2-0000OP-QZ for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:45:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25501 for ; Wed, 5 Nov 2003 16:45:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVT0-000423-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHVSk-0003yU-02 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVLn-0007je-QP; Wed, 05 Nov 2003 16:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVLc-0007hq-Rk for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 16:37:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25239 for ; Wed, 5 Nov 2003 16:37:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVLa-0003sX-00 for ipv6@ietf.org; Wed, 05 Nov 2003 16:37:50 -0500 Received: from lacnic.net.uy ([200.40.228.66] helo=omega.lacnic.net.uy) by ietf-mx with esmtp (Exim 4.12) id 1AHVLZ-0003sO-00 for ipv6@ietf.org; Wed, 05 Nov 2003 16:37:49 -0500 Received: from IBM-X31.lacnic.net ([192.168.1.71]) by omega.lacnic.net.uy (8.12.5/8.12.5) with ESMTP id hA5IawlL012985 for ; Wed, 5 Nov 2003 18:36:59 GMT Message-Id: <6.0.0.22.0.20031105182741.029f12a8@200.40.228.66> X-Sender: raul@200.40.228.66 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 05 Nov 2003 18:37:15 -0300 To: ipv6@ietf.org From: Raul Echeberria Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" In-Reply-To: <3F96659F.4040702@innovationslab.net> References: <3F96659F.4040702@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 08:10 22/10/2003, Brian Haberman wrote: >This is a IPv6 working group last call for comments on advancing the >following document as an Proposed Standard: > > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-unique-local-01.txt > Pages : 15 > Date : 2003-9-24 > >Please send substantive comments to the ipv6 mailing list, and minor >editorial comments to the authors. This last call period will end on 5 >November 2003. Comments: - section 3.2 of the document includes recommendations on fees that are not appropriated to be included in a Proposed Standard. The document should limit to recommend the establishment of a central registry and suggesting a fee in a recovery basis fashion. - section 13.0 is not clear in the requirements under which the IANA should design the central authority. - While my first thought is that unique local IPv6 Unicast Addresses would be useful, I have realized that there are still serious doubts on this point and the impact of the introduction of them. Based on these considerations, I think that more discussion on this document is necessary. Regards, Raul Echeberria LACNIC -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 17:48:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28166 for ; Wed, 5 Nov 2003 17:48:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWS1-0004H6-5z for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 17:48:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5MmXOn016426 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 17:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWS0-0004Gr-UK for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 17:48:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28133 for ; Wed, 5 Nov 2003 17:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWRy-00055f-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 17:48:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHWRx-00055c-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 17:48:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWRV-00042x-Rq; Wed, 05 Nov 2003 17:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWQz-00041N-2v for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 17:47:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28042 for ; Wed, 5 Nov 2003 17:47:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWQw-00054l-00 for ipv6@ietf.org; Wed, 05 Nov 2003 17:47:26 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AHWQv-00054h-00 for ipv6@ietf.org; Wed, 05 Nov 2003 17:47:26 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D197C15210; Thu, 6 Nov 2003 07:47:22 +0900 (JST) Date: Thu, 06 Nov 2003 07:47:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: ipv6@ietf.org Subject: Re: WGLC comments about scoping-arch In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 3 Nov 2003 11:26:55 +0200 (EET), >>>>> Pekka Savola said: > Below are my LC comments on the scoping-arch document. Thanks for the careful reading and detailed comments. From a quick glance, it seems to me most (or probably all) of your points are reasonable. I'll try to make a detailed response point by point later. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 18:09:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29474 for ; Wed, 5 Nov 2003 18:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWm1-0006IJ-LK for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 18:09:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5N9Dia024189 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 18:09:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWm1-0006I4-Db for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:09:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29408 for ; Wed, 5 Nov 2003 18:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWly-0005Mt-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:09:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHWlx-0005Mq-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWlq-00069S-1Q; Wed, 05 Nov 2003 18:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWl8-00063S-C0 for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 18:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29301 for ; Wed, 5 Nov 2003 18:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWl5-0005Mg-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:08:15 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AHWl5-0005M0-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:08:15 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Nov 2003 15:07:48 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Nov 2003 15:07:44 -0800 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); Wed, 5 Nov 2003 15:07:47 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Nov 2003 15:07:45 -0800 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.3790.1069); Wed, 5 Nov 2003 15:07:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Date: Wed, 5 Nov 2003 15:07:47 -0800 Message-ID: Thread-Topic: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" thread-index: AcOj2RHWn3uZmVyNRqK/DW9XfHySoQAF7SFg From: "Christian Huitema" To: "Alain Durand" Cc: "Brian Haberman" , X-OriginalArrivalTime: 05 Nov 2003 23:07:53.0512 (UTC) FILETIME=[A447CA80:01C3A3F1] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Suggested text to address both comments: >=20 > replace: > "The special behavior of this prefix MUST no longer be supported in new > implementations." >=20 > by >=20 > "The special behavior of this prefix MUST no longer be supported." Well, we did not intend to force every implementation developer to go fix the problem immediately, recall the products that have already shipped, etc. The "new implementation" piece is meant to convey that meaning. Just dropping it does not really solve the issue. > >Well, we still have link local scope, so there is still that. Do you > >suggest that we write a line for each of the RFC that currently mention > >site local and explain how to change them? > > > Precisely. There are not that many of them. If you go through the > archives, > you'll find a post where I made the list of places that either mentioned > FECO:: or site local. Or a simple grep in the RFC pages will do. I would rather use a catch-up phrase than an exhaustive list. Something like:=20 "The special behavior of this prefix MUST no longer be supported in new implementations or in new protocol definitions. References to this prefix should be removed from IETF documents when these documents are revised." -- Christian Huitema =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 18:30:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00965 for ; Wed, 5 Nov 2003 18:30:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX6b-0005GC-W7 for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 18:30:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NUTpr020216 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 18:30:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX6b-0005Fv-NZ for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:30:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00894 for ; Wed, 5 Nov 2003 18:30:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHX6Y-0005gp-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:30:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHX6Y-0005gm-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:30:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX6A-0004zF-6p; Wed, 05 Nov 2003 18:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX5p-0004yJ-Rv for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 18:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00866 for ; Wed, 5 Nov 2003 18:29:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHX5m-0005dq-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:29:38 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHX5m-0005dn-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:29:38 -0500 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 3A7CD9F55A; Thu, 6 Nov 2003 00:29:36 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 9D8DC9F532; Wed, 5 Nov 2003 22:56:43 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hA5LuhAj014935; Wed, 5 Nov 2003 22:56:43 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hA5Luca1014932; Wed, 5 Nov 2003 22:56:38 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Keith Moore Cc: gene@nttmcl.com, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> <20031104175008.51e17e6a.moore@cs.utk.edu> <20031105070744.0c7b9f52.moore@cs.utk.edu> <20031105124202.7f66134c.moore@cs.utk.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 05 Nov 2003 22:56:38 +0100 In-Reply-To: <20031105124202.7f66134c.moore@cs.utk.edu> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Keith Moore writes: > Or you could redirect attempts to ssh to host X so that they go to host > Y instead. This is not an inherently desirable feature. Sure, but if I have write access to the DNS configuration (so that I can add the SRV record), then I don't need any SRV records to do that redirection, plain A or CNAME works fine. SRV just let's me do it on a more fine grained scale. > > If the server administrater wants it: Sure. Nobody else can really > > decide whether or not SRV is "useful" or "appropriate" for a > > particular service instance. > > Nor, for that matter, can the DNS server administrator. The server and administrator and DNS server administrator have to cooperate. If they for some reason refuse to do that, they simply can't deploy SRV in any useful way. > For instance, http://example.com:80/foo/bar will be canonicalized to > http://example.com/foo/bar - which, if there were a SRV record for > _http._tcp.example.com pointing to a different port or host, would > change the meaning of the URL. Thanks, that's a good point. It's got more to do with URL syntax than with the http protocol per se, but it still seems like it could be a real problem with using SRV records for http. Regards, /Niels -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 18:36:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01225 for ; Wed, 5 Nov 2003 18:36:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXC5-0000xy-2n for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 18:36:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Na94P003712 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 18:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXC4-0000xE-Pd for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01183 for ; Wed, 5 Nov 2003 18:35:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXC1-0005nF-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:36:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHXC1-0005nC-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXBy-0000cb-AX; Wed, 05 Nov 2003 18:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXB5-0005kC-WF for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 18:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01152 for ; Wed, 5 Nov 2003 18:34:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXB2-0005mO-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:35:04 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AHXB2-0005mL-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:35:04 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA5NZ4Ph025217 for ; Wed, 5 Nov 2003 16:35:04 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNW000KNK6FSB@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 05 Nov 2003 16:35:04 -0700 (MST) Received: from sun.com ([129.146.11.181]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNW00384K6F59@mail.sun.net> for ipv6@ietf.org; Wed, 05 Nov 2003 16:35:03 -0700 (MST) Date: Wed, 05 Nov 2003 15:35:03 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" To: Christian Huitema Cc: Brian Haberman , ipv6@ietf.org Message-id: <3FA98927.1040704@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: Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Christian Huitema wrote: >>Suggested text to address both comments: >> >> >> >>"The special behavior of this prefix MUST no longer be supported." >> >> > >Well, we did not intend to force every implementation developer to go >fix the problem immediately, recall the products that have already >shipped, etc. The "new implementation" piece is meant to convey that >meaning. Just dropping it does not really solve the issue. > What you are describing here will be accomplished by using a SHOULD statement instead of a MUST. "The special behavior of this prefix SHOULD no longer be supported" >>>Well, we still have link local scope, so there is still that. Do you >>>suggest that we write a line for each of the RFC that currently >>> >>> >mention > > >>>site local and explain how to change them? >>> >>> >>> >>Precisely. There are not that many of them. If you go through the >>archives, >>you'll find a post where I made the list of places that either >> >> >mentioned > > >>FECO:: or site local. Or a simple grep in the RFC pages will do. >> >> > >I would rather use a catch-up phrase than an exhaustive list. Something >like: >"The special behavior of this prefix MUST no longer be supported in new >implementations or in new protocol definitions. References to this >prefix should be removed from IETF documents when these documents are >revised." > Well, the list of specs that are using SL is really not that long... and if you do not say how "new" implementation should handle those "old" specs now that SL are gone, you only do half of the deprecating job. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 18:51:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01786 for ; Wed, 5 Nov 2003 18:51:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXQu-00088j-6o for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 18:51:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NpSHD031288 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 18:51:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXQu-00088Z-19 for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:51:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01753 for ; Wed, 5 Nov 2003 18:51:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXQq-00061u-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:51:24 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHXQq-00061r-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:51:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXQU-00082Z-Hp; Wed, 05 Nov 2003 18:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXPh-0007zx-Ut for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 18:50:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01736 for ; Wed, 5 Nov 2003 18:49:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXPe-00061M-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:50:10 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AHXPe-00061J-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:50:10 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A3B7C15210; Thu, 6 Nov 2003 08:50:07 +0900 (JST) Date: Thu, 06 Nov 2003 08:50:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Zefram Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-main-ipaddr-text-rep-01.txt In-Reply-To: <20031024163339.GC26187@fysh.org> References: <200310241444.KAA04152@ietf.org> <20031024163339.GC26187@fysh.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 24 Oct 2003 17:33:40 +0100, >>>>> Zefram said: >> Title : Textual Representation of IPv4 and IPv6 Addresses >> Author(s) : A. Main >> Filename : draft-main-ipaddr-text-rep-01.txt >> Pages : 12 >> Date : 2003-10-23 > ... >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-main-ipaddr-text-rep-01.txt > I've not been able to work on this for most of the last six months due > to personal problems, but I've finally got round to handling the comments > from the first draft and I'm in full working order again. > It was pointed out that this ought to be standards-track, and I've > labelled this draft accordingly. Does this need to be adopted as a WG > draft in order to be published on the standards track? I'm not clear > on the procedure here. If there's any non-trivial decision to be made > about the relation between the WG and this draft then it could probably > be decided quickly in Minneapolis. (I won't be in Minneapolis, btw -- > I'm not going to the US under the present regime.) I support this draft, and I personally think it should be published as a standard truck document. A couple of points that are related to this draft: 1. I'm particularly interested in if this document updates Section 2.2 of draft-ietf-ipv6-addr-arch-v4-00.txt. As discussed in this list before (see the thread found at http://www.atm.tut.fi/list-archive/ipng/msg09279.html), we cannot really be sure from the addr-arch document if the following representation is a valid IPv6 address: 1234:1234:1234:1234:01234:: (Note that it contains 5 digits as a 16-bit value) The ambiguity of the interpretation actually introduces ambiguity of an inet_pton() implementation. On the other hand, draft-main-ipaddr-text-rep makes it clear that such a notation is invalid. I agree on this interpretation, though this may be controversial as you can see in the thread above. 2. draft-ietf-ipv6-scoping-arch-00.txt defines an extension of the textual representation for IPv6 scoped addresses in order to disambiguate the scope zone. I'm not sure if draft-main-ipaddr-text-rep should be modified to support the extension (my current impression is that it's too much), but we probably need to clarify relationship between these two documents. (As a co-editor of scoping-arch, I'll do this for the scoping-arch document if necessary) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 20:06:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04020 for ; Wed, 5 Nov 2003 20:06:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYbS-0004My-P3 for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 20:06:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA616QCQ016796 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 20:06:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYbS-0004Mp-KH for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 20:06:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03982 for ; Wed, 5 Nov 2003 20:06:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHYbQ-000720-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 20:06:24 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHYbQ-00071x-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 20:06:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYb5-0004Gv-KU; Wed, 05 Nov 2003 20:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYaJ-0004Fz-W9 for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 20:05:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03942 for ; Wed, 5 Nov 2003 20:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHYaH-00070L-00 for ipv6@ietf.org; Wed, 05 Nov 2003 20:05:13 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AHYaH-000708-00 for ipv6@ietf.org; Wed, 05 Nov 2003 20:05:13 -0500 Received: from cisco.com (sjc-vpn3-604.cisco.com [10.21.66.92]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA614ciN024059; Wed, 5 Nov 2003 17:04:40 -0800 (PST) Message-ID: <3FA99E23.7000308@cisco.com> Date: Wed, 05 Nov 2003 17:04:35 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman CC: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" References: <3F9665EC.4010508@innovationslab.net> <3FA940FA.2030902@innovationslab.net> In-Reply-To: <3FA940FA.2030902@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, In response to your last call, I'd like to comment on the following sections of the document: Section 2.4 "Site is a Vague Concept" This section does overstate the case. The last paragraph itself is sufficient cause for concern, regarding the concept as it was envisioned. There is nothing wrong with an administratively scoped boundary, and I would make that more clear. What must be clear is what happens when you have more than one such beastie. Section 4 I agree with Alain. Any text that reads "MUST no longer be supported" is itself not supportable ;-) The IETF cannot dictate this sort of behavior, and making claims that we can is not helpful. I would simply state that the behavior is deprecated, and that new implementations needn't implement it. Whether they choose to do so is a matter for them. Realistically speaking I would be concerned if my routing vendor released a new piece of software that caused my existing network to stop routing. Thus, the text, "However, router implementations SHOULD be configured to prevent routing of this prefix by default", is not quite right. I understand this was not the intent, given what is said about existing deployments, but a router doesn't know from existing versus new deployments. Rather, something like the following: "New routing implementations should not support the functionality necessary to implement site-local scoping, and existing implementations should anticipate removing existing support at some point in the future." Eliot ps: you may use any of my words without listing me as an author ;-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 21:14:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05965 for ; Wed, 5 Nov 2003 21:14:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHZfH-0000R4-E5 for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 21:14:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA62EREl001673 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 21:14:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHZfH-0000Qt-6I for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 21:14:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05939 for ; Wed, 5 Nov 2003 21:14:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHZfE-000004-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 21:14:24 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHZfE-0007np-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 21:14:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHZer-0000LB-BO; Wed, 05 Nov 2003 21:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHZeI-0000KX-P8 for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 21:13:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05929 for ; Wed, 5 Nov 2003 21:13:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHZeG-0007nQ-00 for ipv6@ietf.org; Wed, 05 Nov 2003 21:13:24 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1AHZeF-0007nM-00 for ipv6@ietf.org; Wed, 05 Nov 2003 21:13:23 -0500 Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2PMFZRY868WZ373@vaxh.its.monash.edu.au> for ipv6@ietf.org; Thu, 6 Nov 2003 12:27:26 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 7ECA2158002; Thu, 06 Nov 2003 12:27:26 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id 502F2120005; Thu, 06 Nov 2003 12:27:26 +1100 (EST) Date: Thu, 06 Nov 2003 12:27:26 +1100 From: Greg Daley Subject: Re: Issue 13: Omission of prefix options - resolution To: Tim Hartrick Cc: H.Soliman@flarion.com, itojun@iijlab.net, ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FA9A37E.4050109@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: <200311052004.MAA24208@feller.mentat.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Tim, Tim Hartrick wrote: > Greg, > > >>Backward compatability shouldn't really be a problem. >>Hosts which are doing RFC2461 Router Discovery >>will understand RAs with options or bits in them >>indicating solicitation or completeness, but just not >>be able to access the improved function. >> > > > If a host that understands the new "bit" arrives on a network that has > routers that don't speak the new "bit" but do send abbreviated router > advertisements, then the host will need to take some new unspecified > protocol action to force the routers to send unabbreviated router > advertisements. Otherwise the host will not detect movement as quickly > as it could when arriving on a network with routers that speak the new > "bit". I agree that the other combinations of old and new functionality > are not likely to have problems. This is not a new function. Hosts already have to deal with abbreviated router advertisements if they comply with RFC-2461. Section 6.2.3, Page 45: "A router MAY choose not to include some or all options when sending unsolicited Router Advertisements..." The defined mechanism for discovering all options is to send an RS. The Router should (not must...?) send all options in that case. You're right that the behaviour for movement detection is sub optimal though, in that a message has to be sent. > Of course I don't really care for using router advertisements for movement > detection, but if we are going to do it, getting in all the corners is > important. > > >>I don't think it's that hard, but whether it goes into >>RFC2461bis is another matter. >> > > > I know it isn't hard. However, in my opinion, trying to roll it into > RFC2461bis is on the edge what should be going in what was advertised as > a "bug fix" update. I think that the solution may not actually be a "complete" bit, if we can achieve what we want to do with another mechanism. The fact that there are multiple possible solutions and no clear winner is an indication that it shouldn't go directly into RFC-2461bis. That said, I don't think it unimportant to consider. Greg. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 5 22:22:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07982 for ; Wed, 5 Nov 2003 22:22:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHaj2-0004W8-SG for ipv6-archive@odin.ietf.org; Wed, 05 Nov 2003 22:22:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA63MOWJ017358 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 22:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHaj2-0004Vt-M9 for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 22:22:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07951 for ; Wed, 5 Nov 2003 22:22:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHaix-0000w2-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 22:22:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHaix-0000vz-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 22:22:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHaig-0004Kc-60; Wed, 05 Nov 2003 22:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHahu-0004Ix-PA for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 22:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07880 for ; Wed, 5 Nov 2003 22:21:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHahr-0000uQ-00 for ipv6@ietf.org; Wed, 05 Nov 2003 22:21:11 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AHahr-0000uD-00 for ipv6@ietf.org; Wed, 05 Nov 2003 22:21:11 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Nov 2003 22:20:31 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E89@ftmail.lab.flarion.com> From: Soliman Hesham To: ipv6@ietf.org Subject: Issue 13: Omission of prefix options - summary Date: Wed, 5 Nov 2003 22:20:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Folks, Just a quick summary on this issue. It seems that there is an agreement that there is a problem. However, it is not clear what the solution should be. It seems like we agree that a "Complete" bit is better than a new code. There is also conflicting opinions on whether the new LinkID would be better than both (Complete bit or new code). In any case, since several people (including those who brought up the issue) seem to agree that the issue is best addressed in DNA. And since there is no compelling reason for adding this into 2461 Vs introducing a solution in a new spec, I'd like to suggest that we close this issue and let DNA (or IPv6) handle this issue separately. So, in the current document, nothing needs to be done about this issue (unless there are strong objections). Hesham PS: To save emails, I'll assume silence means there is no objections. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 02:11:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25089 for ; Thu, 6 Nov 2003 02:11:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHeIH-0007s8-UJ for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 02:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA67B1qK030261 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 02:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHeIG-0007ri-K1 for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 02:11:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24535 for ; Thu, 6 Nov 2003 02:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHeIC-0003fO-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 02:10:57 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHeIC-0003fK-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 02:10:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHeHL-0007fG-Eb; Thu, 06 Nov 2003 02:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHeGp-0007Vk-VW for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 02:09:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23023 for ; Thu, 6 Nov 2003 02:09:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHeGm-0003eR-00 for ipv6@ietf.org; Thu, 06 Nov 2003 02:09:28 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AHeGl-0003eO-00 for ipv6@ietf.org; Thu, 06 Nov 2003 02:09:27 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:13ff::10]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F031315214 for ; Thu, 6 Nov 2003 16:09:24 +0900 (JST) Date: Thu, 06 Nov 2003 16:09:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Subject: Re: Authors Section on recyle clarifications to 2461and 2462 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1F3@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1F3@tayexc13.americas.cpqcorp.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Sun, 2 Nov 2003 02:00:22 -0500, >>>>> "Bound, Jim" said: > As we recycle 2461 and 2462 specifications I suggest that no additional > names be added to the authors names for two reasons. First its not > "honorable" as nothing has been discussed nor I perceive currently will > be learned that adds any architectural value of "significance" to these > widely deployed and important IPv6 specifications. The current authors > worked for many years and earned their names on this spec. Second I > believe new editors should be put at the bottom of the spec under > recycle acknowledgements per the IETF new rule to reduce author names on > all specifications. I believe Thomas and Brian perfectly clarified the "process" issues including this (thanks!), and I have basically nothing to add the clarifications. But as a person listed as a co-editor in the rfc246[12]bis drafts, I think I'm responsible for making a response. I didn't intend to claim I would get a credit as an inventor of the specifications by listing myself in the top page. I fully respect the work by the RFC authors. I think all the credits about the essential techncical part of the specification should go to the orignal authors, and to the original authors only. If I gave anyone of you the impression that I'm making a false claim by the organization of the author (or editor) list, I'm sad and apologize for the careless edit. For further revisions (if any), I'll follow the latest suggestion by Brian, and, as a result, the author list will not change. I'm perfectly fine with the policy that we'll decide how the final list should be organized when the document comes close to publication. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 04:46:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01638 for ; Thu, 6 Nov 2003 04:46:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHghy-00023N-9e for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 04:45:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69jfC7007867 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 04:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHghx-00022d-6i for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 04:45:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01487 for ; Thu, 6 Nov 2003 04:45:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHght-0005wr-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 04:45:37 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgcq-0005gP-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 04:40:25 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgY1-0001WG-Ma for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 04:35:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgNu-000856-8z; Thu, 06 Nov 2003 04:24:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHg3h-0006eD-BT for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 04:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29613 for ; Thu, 6 Nov 2003 04:03:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHg3e-0005D0-00 for ipv6@ietf.org; Thu, 06 Nov 2003 04:04:02 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AHg3d-0005CJ-00 for ipv6@ietf.org; Thu, 06 Nov 2003 04:04:02 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA692Nls010634; Thu, 6 Nov 2003 18:02:24 +0900 (KST) Message-ID: <00dd01c3a445$caa33c60$e329024b@tyre> From: "JinHyeock Choi" To: "Soliman Hesham" , Cc: "Tim Hartrick" References: <748C6D0A58C0F94CA63C198B6674697A01922E89@ftmail.lab.flarion.com> Subject: Re: Issue 13: Omission of prefix options - summary Date: Thu, 6 Nov 2003 18:10:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBIZXNoYW0NCg0KSSBkaXNhZ3JlZS4gDQoNCklNTywgQ29tcGxldGUgYml0IChvciBjb2Rl KSBpcyBhbiBlc3NlbnRpYWwgYnVpbGRpbmcgYmxvY2sgZm9yIGFuIA0KZWZmaWNpZW50IE1EIHNj aGVtZSBhbmQgd2UnZCBiZXR0ZXIgcmVzb2x2ZSB0aGlzIGlzc3VlIHRoaXMgdGltZS4gDQoNCkl0 IGlzIElQdjYgV0cgd2hlcmUgd2UgY2FuIGRlZmluZSBhIGNvbXBsdGUgYml0LCBpLmUuIGFsdGVy IGEgUkENCm1lc3NhZ2UgZm9ybWF0LCB0aG91Z2ggaXQgbWF5IGJlIGRvbmUgaW4gRE5BIHRvIHNw ZWNpZnkgZGV0YWlsZWQgDQpNRCBwcm9jZWR1cmUgYmFzZWQgb24gY29tcGxldGUgYml0LiAuDQoN CkkgdGhpbmsgd2UgYWdyZWVkIHRoYXQgaXQncyBuZWNlc3NhcnkgdG8gbWFrZSBpdCBjbGVhcmVy IHRoYXQgdGhlIHByZWZpeGVzIA0KYXJlIG5vdCBvbWl0dGVkIGFuZCBMaW5rSUQgc2NoZW1lIGNh bid0IGRvIHRoaXMgam9iLiBMaW5rSUQgYW5kIA0KQ29tcGxldGUgYml0IGlzIHNpbWlsYXIgYnV0 IG5vdCBleGFjdGx5IHRoZSBzYW1lLiBJJ2xsIGVsYWJvcmF0ZSB0aGlzIGluIA0KZGV0YWlsIGJl bG93LiAgIA0KDQpJIHRoaW5rLCB3aGVuIHdlIHVwZGF0ZSBORCwgd2UnZCBiZXR0ZXIgYWRkIHRo aXMgZmVhdHVyZSB0byBSRkMgMjQ2MSwNCmxlc3QgdGhlcmUgc2hvdWxkIGJlIG9uZSBtb3JlIHVw ZGF0ZSBsYXRlci4gICANCiAgDQpLaW5kbHkgZmluZCBteSBpbiBsaW5lIGNvbW1lbnRzDQoNCkhl c2hhbSBTb2xpbWFuIHdyb3RlOiANCj4gSnVzdCBhIHF1aWNrIHN1bW1hcnkgb24gdGhpcyBpc3N1 ZS4gSXQgc2VlbXMgdGhhdCB0aGVyZSBpcw0KPiBhbiBhZ3JlZW1lbnQgdGhhdCB0aGVyZSBpcyBh IHByb2JsZW0uIEhvd2V2ZXIsIGl0IGlzIG5vdA0KPiBjbGVhciB3aGF0IHRoZSBzb2x1dGlvbiBz aG91bGQgYmUuIEl0IHNlZW1zIGxpa2Ugd2UgYWdyZWUNCj4gdGhhdCBhICJDb21wbGV0ZSIgYml0 IGlzIGJldHRlciB0aGFuIGEgbmV3IGNvZGUuIA0KPiBUaGVyZSBpcyBhbHNvIGNvbmZsaWN0aW5n IG9waW5pb25zIG9uIHdoZXRoZXIgdGhlIG5ldyBMaW5rSUQNCj4gd291bGQgYmUgYmV0dGVyIHRo YW4gYm90aCAoQ29tcGxldGUgYml0IG9yIG5ldyBjb2RlKS4gDQoNClRoZSBwcm9ibGVtIGlzOiBU aGUgb21pc3Npb24gb2YgdGhlIHByZWZpeGVzIG1ha2VzIGl0IGRpZmZpY3VsdCBmb3IgYSBtb2Jp bGUgDQpub2RlIHRvIGNoZWNrIHdoZXRoZXIgdGhlIHByZWZpeCBvZiB0aGUgY3VycmVudCBJUCBh ZGRyZXNzIGlzIHN1cHBvcnRlZCBpbiANCnRoZSBjdXJyZW50IGxpbmsuIA0KDQpBbGxvdyBtZSBk ZWx2ZSBpbnRvIGRldGFpbCBhIGxpdHRsZS4NCg0KSW4gc29tZSBjYXNlcywgd2l0aCBMaW5rSUQs IGFuIE1OIGNhbiBkZXRlY3QgbGluayBjaGFuZ2UgYnV0IGNhbid0IA0KY2hlY2sgdGhlIHZhbGlk aXR5IG9mIGN1cnJlbnQgQ29BIGNvcnJlY3RseS4gSGVyZSBpcyBhbiBleGFtcGxlLiANCg0KQXNz dW1lIGEgcm91dGVyIGhhcyB0d28gaW50ZXJmYWNlcyBhbmQgdHdvIGFjY2VzcyBwb2ludHMgYXJl IGF0dGFjaGVkIA0KdG8gdGhlIGVhY2ggaW50ZXJmYWNlcyBhcyBiZWxvdy4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0rICBSb3V0ZXIgICstLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgIEE6OiwgDQogICAgICAgICAgICAg IEE6OiAgICAgfCAgICAgICAgKy0tLS0tLS0tLS0rICAgICAgICB8ICBCOjoNCiAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICArLS0tKy0tLSsgICAgICAgICAgICAgICAgICAgICstLS0rLS0tKw0KICAgICAg ICAgICAgICAgIHwgICBBUDEgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICBBUDIgIHwNCiAg ICAgICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsNCg0K ICAgICAgICAgICAgICAgICAgICAgQTo6MQ0KICAgICAgICAgICAgICAgICstLS0rLS0tKyAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgfCAgTU4gICAgfCAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgbGVmdCBpbnRlcmZhY2UgYWR2ZXJ0aXNlIHRoZSBwcmVmaXggQTo6IGFuZCB0aGUg cmlnaHQgaW50ZXJmYWNlIGFkdmVydGlzZXMgDQp0aGUgcHJlZml4IEE6OiBhbmQgcHJlZml4IEE6 OiBhbmQgQjo6LiBUaGVuIHR3byBpbnRlcmZhY2Ugc2hvdWxkIGFkdmVydGlzZSANCnRoZSBkaWZm ZXJlbnQgTGlua0lEcy4gDQoNCkFzc3VtZSB0aGVyZSBpcyBhbiBNTiBpbiB0aGUgbGVmdCBsaW5r IHdpdGggQ29BLCBBOjoxLiBXaGVuIGl0IG1vdmVzIA0KdG8gdGhlIHJpZ2h0IGxpbmsgYW5kIHJl Y2VpdmVzIGFuIFJBIHdpdGggTGlua0lEIChhbmQgd2l0aG91dCBwcmVmaXggQTo6KSwgDQppdCB3 aWxsICBtaXN0YWtlIHRoYXQgaXQgY2FuJ3QgdXNlIGl0J3MgY3VycmVudCBDb0EgYW55IGxvbmdl ciBhbmQgcGVyZm9ybSANCnVubmVjZXNzYXJ5IGhhbmRvZmYuIA0KDQpNdWx0aS1saW5rIHN1Ym5l dCBtYWtlcyBtYXR0ZXJzIGNvbXBsZXggYW5kIEkgd29uZGVyIHdlIGNhbiBzYWZlbHkgDQppZ25v cmUgdGhlIGFib3ZlIGFzIHRoZSBwYXRob2xvZ2ljYWwgZXhjZXB0aW9uLiBPdGhlcndpc2UsIHdl IHNob3VsZCANCnRpZ2h0ZW4gdGhlIG11bHRpLWxpbmsgc3VibmV0IHByb3RvY29sIHRvIGF2b2lk IHN1Y2ggYW4gYWNjaWRlbnQuIA0KDQo+IEluIGFueSBjYXNlLCBzaW5jZSBzZXZlcmFsIHBlb3Bs ZSAoaW5jbHVkaW5nIHRob3NlIHdobyANCj4gYnJvdWdodCB1cCB0aGUgaXNzdWUpIHNlZW0gdG8g YWdyZWUgdGhhdCB0aGUgaXNzdWUgaXMgDQo+IGJlc3QgYWRkcmVzc2VkIGluIEROQS4gQW5kIHNp bmNlIHRoZXJlIGlzIG5vIGNvbXBlbGxpbmcNCj4gcmVhc29uIGZvciBhZGRpbmcgdGhpcyBpbnRv IDI0NjEgVnMgaW50cm9kdWNpbmcgYSBzb2x1dGlvbg0KPiBpbiBhIG5ldyBzcGVjLCBJJ2QgbGlr ZSB0byBzdWdnZXN0IHRoYXQgd2UgY2xvc2UgdGhpcyANCj4gaXNzdWUgYW5kIGxldCBETkEgKG9y IElQdjYpIGhhbmRsZSB0aGlzIGlzc3VlIHNlcGFyYXRlbHkuIA0KDQpJIGFtIGFmcmFpZCBJIGdh dmUgYSB3cm9uZyBpbXByZXNzaW9uLiANCg0KSSBtZWFudCB0aGF0LCB3ZSB3aWxsIGRlaW5mZSBN RCBzb2x1dGlvbiB3aXRoIGRldGFpbGVkIG9wZXJhdGlvbmFsIA0KcHJvY2VkdXJlIGluIEROQSBX Ry4gIEJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIElQdjYgV0cgd2hlcmUgDQp3ZSBhZGVmaW5lIGEg bmV3IGJpdCBpbiBSQSBtZXNzYWdlLiANCg0KQ29tcGxldGUgYml0IGJ5IGl0c2VsZiBpcyBub3Qg c3VmZmljaWVudCBmb3IgZWZmaWNpZW50IE1ELiBXZSBhbHNvIG5lZWRzIHRvIA0Kc3BlY2lmeSB0 aGUgb3BlcmF0aW9uYWwgcHJvY2VkdXJlIGZvciBjb21wbGV0ZSBiaXQgKGNvbXBsZXRlIFJBKS4g Rm9yIA0KZXhhbXBsZSwgb3BlcmF0aW9uIGRlc2NyaXB0aW9uIGxpa2UNCg0KJ0FuIE1OIFNIT1VM RCBpbnRlcnByZXQgYSBkaWZmZXJlbnQgY29tcGxldGUgUkEgYXMgYSBtb3ZlbWVudCANCmluZGlj YXRpb24gYnV0IFNIT1VMRCBOT1QgaW50ZXJwcmV0IGEgbGFjayBvZiBjb21wbGV0ZSBSQSBhcyBv bmUuIA0KDQpJIG1lYW50IHRoYXQsIHdlIHdpbGwgc3BlY2lmeSBzdWNoIGFuIG9wZXJhdGlvbmFs IHByb2NlZHVyZXMgaW4gRE5BIFdHLg0KDQpJTU8sIHRob3VnaCBjb21wbGV0ZSBiaXQgaXMgbm90 IHN1ZmZpY2llbnQgZm9yIGVmZmljaWVudCBNRCwgaXQncyBuZWNlc3NhcnkgDQpmb3IgZWZmaWNp ZW50IE1ELiBJdCB3aWxsIGJlIGRpZmZpY3VsdCBmb3IgdXMgdG8gZGVzaWduIGEgZWZmaWNpZW50 IE1EIHByb2NlZHVyZSANCndpdGhvdXQgY29tcGxldGVuZXNzIGluZGljYXRpb24sIGNvbXBsZXRl IGJpdC4gDQoNCj4gU28sIGluIHRoZSBjdXJyZW50IGRvY3VtZW50LCBub3RoaW5nIG5lZWRzIHRv IGJlIGRvbmUgYWJvdXQgDQo+IHRoaXMgaXNzdWUgKHVubGVzcyB0aGVyZSBhcmUgc3Ryb25nIG9i amVjdGlvbnMpLg0KDQpJIHdpc2gsIHdoZW4gd2UgdXBkYXRlIFJGQyAyNDYxLCB3ZSBhbHNvIGFk ZCB0aGlzIGZlYXR1cmUsIGNvbXBsZXRlIGJpdCwgDQppbnRvIE5laWdoYm9yIERpc2NvdmVyeS4g T3RoZXJ3aXNlIEkgYW0gYWZyYWlkIHdlIG1heSBoYXZlIHRvIHVwZGF0ZSBORCANCm9uY2UgbW9y ZSBsYXRlci4gIA0KIA0KPiBIZXNoYW0NCj4gDQo+IFBTOiBUbyBzYXZlIGVtYWlscywgSSdsbCBh c3N1bWUgc2lsZW5jZSBtZWFucyB0aGVyZSBpcyANCj4gbm8gb2JqZWN0aW9ucy4NCg0KSSBob3Bl IG15IHJlcGx5IGlzIGZhc3QgZW5vdWdoIHNvIHRoYXQgSSB3aWxsIG5vdCBiZSBjb3VudGVkIGFz IG9uZSBvZiBzaWxlbnQNCnRob3NlIGluIGZhdm9yLiA6LSkgDQoNClRoYW5rcyBmb3IgeW91ciBr aW5kIGNvbnNpZGVyYXRpb24NCg0KQmVzdCByZWdhcmRzDQoNCkppbkh5ZW9jayA= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 05:08:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02498 for ; Thu, 6 Nov 2003 05:08:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh45-0004Mb-LO for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 05:08:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6A8XSV016767 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 05:08:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh44-0004ML-Rf for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 05:08:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02449 for ; Thu, 6 Nov 2003 05:08:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh41-0006KX-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 05:08:29 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHh40-0006KU-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 05:08:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh3b-00047R-Ov; Thu, 06 Nov 2003 05:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh3E-00042u-NH for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 05:07:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02434 for ; Thu, 6 Nov 2003 05:07:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh3B-0006K1-00 for ipv6@ietf.org; Thu, 06 Nov 2003 05:07:37 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AHh3A-0006Jh-00 for ipv6@ietf.org; Thu, 06 Nov 2003 05:07:36 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AHh2t-0003AM-00 for ; Thu, 06 Nov 2003 10:07:19 +0000 Date: Thu, 6 Nov 2003 10:07:19 +0000 To: ipv6@ietf.org Subject: Re: I-D ACTION:draft-main-ipaddr-text-rep-01.txt Message-ID: <20031106100719.GA6173@fysh.org> References: <200310241444.KAA04152@ietf.org> <20031024163339.GC26187@fysh.org> 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , JINMEI Tatuya / ?$B?@L@C#:H wrote: >1. I'm particularly interested in if this document updates Section 2.2 > of draft-ietf-ipv6-addr-arch-v4-00.txt. It's meant to supersede what's currently there, one way or another. Ultimately, ipv6-addr-arch really ought to have a normative reference to ipaddr-text-rep, but is there an issue with them being at different stages of the standards track? Perhaps we can't do that on this iteration. In which order are ipv6-addr-arch-v4 and ipaddr-text-rep likely to be published as RFCs? If ipv6-addr-arch-v4 comes first, then ipaddr-text-rep should be noted as updating it. If the other way round, ipv6-addr-arch should either explicitly reference ipaddr-text-rep or copy the new, precise, text from ipaddr-text-rep section 3.2. (The ABNF could also be copied across, but it's not essential, and I'd like to avoid a proliferation of duplicates. The URI syntax document already has a duplicate of an earlier version of the ABNF, in order to avoid a publication dependency.) [more than four digits in a hex piece] > On the other hand, draft-main-ipaddr-text-rep makes it clear that > such a notation is invalid. I agree on this interpretation, though > this may be controversial as you can see in the thread above. I don't think it's at all controversial. Every source that has explicitly addressed this issue specifies a maximum of four digits (see ipaddr-text-rep section 2.2). This issue was raised on this mailing list last time ipaddr-text-rep was discussed, and there was an overwhelming consensus for a maximum of four digits. >2. draft-ietf-ipv6-scoping-arch-00.txt defines an extension of the > textual representation for IPv6 scoped addresses in order to > disambiguate the scope zone. I'm not sure if > draft-main-ipaddr-text-rep should be modified to support the > extension (my current impression is that it's too much), but we > probably need to clarify relationship between these two documents. The presentation format for unscoped addresses, specified in ipaddr-text-rep, forms part of the scoped address syntax. It's not necessary to put the scoped address syntax in the same document. There's a similar issue with the address prefix syntax; I considered including that in ipaddr-text-rep, but I think it's already adequately specified by section 2.3 of draft-ietf-ipv6-addr-arch-v4-00. Section 10 of draft-ietf-ipv6-scoping-arch-00 incorporates the IPv6 unscoped address syntax by reference, without specifying which document is to provide that syntax. It should probably have an explicit normative reference to ipaddr-text-rep. -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 05:58:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03936 for ; Thu, 6 Nov 2003 05:58:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhqU-0007IG-4w for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 05:58:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6AwYu1028030 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 05:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhqT-0007I1-Tf for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 05:58:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03901 for ; Thu, 6 Nov 2003 05:58:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHhqQ-0006zn-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 05:58:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHhqP-0006zk-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 05:58:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhpy-0007C3-Az; Thu, 06 Nov 2003 05:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhpa-0007BY-4W for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 05:57:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03848 for ; Thu, 6 Nov 2003 05:57:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHhpW-0006yr-00 for ipv6@ietf.org; Thu, 06 Nov 2003 05:57:34 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHhpR-0006yN-00 for ipv6@ietf.org; Thu, 06 Nov 2003 05:57:29 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA6Aut604791; Thu, 6 Nov 2003 12:56:56 +0200 Date: Thu, 6 Nov 2003 12:56:55 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" In-Reply-To: <3FA940FA.2030902@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 5 Nov 2003, Brian Haberman wrote: > This is a reminder that the last call on the deprecation document > ends today. In particular, the chairs would like to ensure that > the WG agrees on the actual deprecation text in Sections 4 & 6. > There has been few comments on this draft and it cannot proceed > unless the chairs can be sure that it has been thoroughly reviewed > and agreed upon. I do not believe the -01 version addresses the comments I made to the -00 version. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 07:37:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06205 for ; Thu, 6 Nov 2003 07:37:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHjOJ-0003d0-Ob for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 07:37:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6CbZW3013940 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 07:37:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHjOJ-0003cd-08 for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 07:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06177 for ; Thu, 6 Nov 2003 07:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHjOI-0000HS-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 07:37:34 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHjOH-0000HP-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 07:37:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHjNl-0003Kd-JW; Thu, 06 Nov 2003 07:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHjN4-0003JS-AC for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 07:36:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06156 for ; Thu, 6 Nov 2003 07:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHjN3-0000Gk-00 for ipv6@ietf.org; Thu, 06 Nov 2003 07:36:17 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHjN2-0000GZ-00 for ipv6@ietf.org; Thu, 06 Nov 2003 07:36:17 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA6CZfJ06110; Thu, 6 Nov 2003 14:35:41 +0200 Date: Thu, 6 Nov 2003 14:35:41 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" In-Reply-To: <3F96659F.4040702@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 22 Oct 2003, Brian Haberman wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-unique-local-01.txt > Pages : 15 > Date : 2003-9-24 FWIW, I have not reviewed the document in detail at this point, but I must echo the concerns raised by others (Erik, Alain in particular). Btw. one particular place where the document probably needs a lot of improvement is the specification or description on _how_ exactly these packets should be discarded at site borders. Blackholing ("silent discard") the packets would be HIGHLY disadvantageous, because an address leak or similar leads to falling back to something like TCP timeout, and the apps/stack cannot fail back to use the next address. Btw.2, the document requires a Table of Contents, it's 15 pages. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 11:00:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14868 for ; Thu, 6 Nov 2003 11:00:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmYj-00072D-Jx for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 11:00:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6G0Xdr027035 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 11:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmYi-00071y-Ns for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 11:00:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14793 for ; Thu, 6 Nov 2003 11:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmYg-0002yG-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 11:00:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHmYf-0002yC-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 11:00:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmXG-0006pf-FJ; Thu, 06 Nov 2003 10:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmWu-0006p2-9p for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 10:58:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14559 for ; Thu, 6 Nov 2003 10:58:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmWr-0002tA-00 for ipv6@ietf.org; Thu, 06 Nov 2003 10:58:37 -0500 Received: from [194.196.100.238] (helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AHmWq-0002rr-00 for ipv6@ietf.org; Thu, 06 Nov 2003 10:58:36 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id hA6FvqNb062442; Thu, 6 Nov 2003 16:57:52 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA6FvqqI277216; Thu, 6 Nov 2003 16:57:52 +0100 Received: from zurich.ibm.com ([9.145.246.63]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA39450; Thu, 6 Nov 2003 16:57:50 +0100 Message-ID: <3FAA6F5A.565FF8EE@zurich.ibm.com> Date: Thu, 06 Nov 2003 16:57:14 +0100 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: Christian Huitema , Brian Haberman , ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" References: <3FA98927.1040704@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, I agree with Christian's responses. We need to prevent panic (people rushing to switch off FEC0 immediately) and we need to prevent people continuing to write code to support it. I find it hard to see any wording that is better than the current draft. The IETF often specifies what must or must not be implemented. I also don't think we should rewrite all the RFCs that refer to SL. I have no problem with listing them, as in Note that the following documents refer to link local addresses and will require appropriate updates: [RFC xxx], [RFC yyy],... Brian Alain Durand wrote: > > Christian Huitema wrote: > > >>Suggested text to address both comments: > >> > >> > >> > >>"The special behavior of this prefix MUST no longer be supported." > >> > >> > > > >Well, we did not intend to force every implementation developer to go > >fix the problem immediately, recall the products that have already > >shipped, etc. The "new implementation" piece is meant to convey that > >meaning. Just dropping it does not really solve the issue. > > > What you are describing here will be accomplished by using a SHOULD > statement > instead of a MUST. > "The special behavior of this prefix SHOULD no longer be supported" > > >>>Well, we still have link local scope, so there is still that. Do you > >>>suggest that we write a line for each of the RFC that currently > >>> > >>> > >mention > > > > > >>>site local and explain how to change them? > >>> > >>> > >>> > >>Precisely. There are not that many of them. If you go through the > >>archives, > >>you'll find a post where I made the list of places that either > >> > >> > >mentioned > > > > > >>FECO:: or site local. Or a simple grep in the RFC pages will do. > >> > >> > > > >I would rather use a catch-up phrase than an exhaustive list. Something > >like: > >"The special behavior of this prefix MUST no longer be supported in new > >implementations or in new protocol definitions. References to this > >prefix should be removed from IETF documents when these documents are > >revised." > > > Well, the list of specs that are using SL is really not that long... > and if you do not say how "new" implementation should handle those > "old" specs now that SL are gone, you only do half of the deprecating job. > > - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 11:01:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14979 for ; Thu, 6 Nov 2003 11:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmZM-0007AA-89 for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 11:01:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6G1Cb5027528 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 11:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmZM-00079v-1i for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 11:01:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14891 for ; Thu, 6 Nov 2003 11:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmZJ-0002zN-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 11:01:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHmZJ-0002zK-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 11:01:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmZE-00073j-A2; Thu, 06 Nov 2003 11:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmYM-0006yO-7C for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 11:00:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14691 for ; Thu, 6 Nov 2003 10:59:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmYJ-0002vi-00 for ipv6@ietf.org; Thu, 06 Nov 2003 11:00:07 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1AHmYH-0002uT-00 for ipv6@ietf.org; Thu, 06 Nov 2003 11:00:06 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA6Fx7D8069848; Thu, 6 Nov 2003 15:59:07 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA6Fx7qI246068; Thu, 6 Nov 2003 16:59:07 +0100 Received: from zurich.ibm.com ([9.145.246.63]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA51312; Thu, 6 Nov 2003 16:59:06 +0100 Message-ID: <3FAA6FA6.5590F7BC@zurich.ibm.com> Date: Thu, 06 Nov 2003 16:58:30 +0100 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: Pekka Savola CC: Brian Haberman , ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, it's been a while, but my recollection is that we (the authors) didn't agree and didn't see any support for your comments on the list. I could be wrong. Brian Pekka Savola wrote: > > On Wed, 5 Nov 2003, Brian Haberman wrote: > > This is a reminder that the last call on the deprecation document > > ends today. In particular, the chairs would like to ensure that > > the WG agrees on the actual deprecation text in Sections 4 & 6. > > There has been few comments on this draft and it cannot proceed > > unless the chairs can be sure that it has been thoroughly reviewed > > and agreed upon. > > I do not believe the -01 version addresses the comments I made to the -00 > version. > > -- > 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 IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 11:18:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16232 for ; Thu, 6 Nov 2003 11:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmpb-0000gO-8V for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 11:18:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6GHxqa002624 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 11:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmpa-0000g9-SC for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 11:17:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16134 for ; Thu, 6 Nov 2003 11:17:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmpZ-0003S8-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 11:17:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHmpY-0003Qs-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 11:17:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmof-0000Jb-UD; Thu, 06 Nov 2003 11:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmo7-0000IB-0C for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 11:16:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16024 for ; Thu, 6 Nov 2003 11:16:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmo6-0003Ph-00 for ipv6@ietf.org; Thu, 06 Nov 2003 11:16:26 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AHmo0-0003PD-00 for ipv6@ietf.org; Thu, 06 Nov 2003 11:16:20 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CB20BB938; Thu, 6 Nov 2003 11:16:14 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 11:16:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Thu, 6 Nov 2003 11:16:14 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122559@tayexc13.americas.cpqcorp.net> Thread-Topic: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Thread-Index: AcOiHdjBSqgK0WcKS2q96wR3xJq+mACY1r1A From: "Bound, Jim" To: "Stig Venaas" , "Keith Moore" Cc: "Pekka Savola" , , X-OriginalArrivalTime: 06 Nov 2003 16:16:14.0918 (UTC) FILETIME=[4D2F2E60:01C3A481] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable There is nothing in getaddrinfo that precludes its use with any name service. If customized extesions are needed for that then extended specs can be suggested. /jim > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Stig Venaas > Sent: Monday, November 03, 2003 10:16 AM > To: Keith Moore > Cc: Pekka Savola; v6ops@ops.ietf.org; ipv6@ietf.org > Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG >=20 >=20 > [...] > > - IMHO, getaddrinfo()'s job should be to report what is in=20 > DNS, not to try to > > coerce apps into behaving well. So even though apps=20 > shouldn't be using > > link-local addresses, and even though people shouldn't=20 > list link-local > > addresses in DNS, getaddrinfo() should not try to hide=20 > such addresses from > > apps if they happen to appear in DNS. >=20 > I can sympathize with your opinions. I think two things are needed: >=20 > o A standard call that most applications can use in a simple=20 > way. IMHO it > should query DNS, other name services, /etc/hosts etc. >=20 > o A standard call that applications can use to check what is in DNS >=20 > The first should IMHO be something like getaddrinfo() where=20 > applications simply try the addresses in the order they are=20 > returned. I also think it should be possible for an=20 > administrator to define which name services should be used,=20 > which type of addresses should be returned, and the order. >=20 > Another matter is what the API should be. Most IPv6 enabled=20 > applications today use getaddrinfo(), while specialized DNS=20 > applications like "host" use their own resolver routines. So=20 > I would say that getaddrinfo() without special arguments=20 > would be good for the general applications. For the DNS=20 > applications one could use getaddrinfo() with a new option,=20 > or a completely new call. It's easier to change the few DNS=20 > applications that are out there. >=20 > Stig >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 12:23:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19217 for ; Thu, 6 Nov 2003 12:23:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHnr3-0004oM-9W for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 12:23:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6HNX6W018488 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 12:23:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHnr3-0004o7-1y for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 12:23:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19168 for ; Thu, 6 Nov 2003 12:23:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHnr1-0004TR-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:23:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHnr1-0004TN-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:23:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHnpa-0004e3-6Z; Thu, 06 Nov 2003 12:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHnod-0004c8-OM for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 12:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19082 for ; Thu, 6 Nov 2003 12:20:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHnoc-0004RD-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:21:02 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AHnob-0004Qy-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:21:01 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 09:20:45 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 Nov 2003 09:20:18 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Nov 2003 09:20:30 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 Nov 2003 09:20:22 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 09:19:13 -0800 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.3790.1069); Thu, 6 Nov 2003 09:19:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Date: Thu, 6 Nov 2003 09:20:32 -0800 Message-ID: Thread-Topic: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Thread-Index: AcOkf0KcD9dkTwtpQy6yZneE6OvYzwACqPWA From: "Christian Huitema" To: "Brian E Carpenter" , "Pekka Savola" Cc: "Brian Haberman" , X-OriginalArrivalTime: 06 Nov 2003 17:19:15.0209 (UTC) FILETIME=[1A69CF90:01C3A48A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Actually, the 01 draft includes two changes to address Pekka's feedback: add some explanatory text in section 2.2, address leak, and section 2.3, routing pain; and in section 5, qualify that the replacement of site local is only as secure if blocking rules are actually implemented at site boundaries. But it is clear that we want to keep the document short and concise, and thus chose to not widely expand the text in section 2 and 5. > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Brian > E Carpenter > Sent: Thursday, November 06, 2003 7:59 AM > To: Pekka Savola > Cc: Brian Haberman; ipv6@ietf.org > Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" >=20 > Pekka, it's been a while, but my recollection is that we (the authors) > didn't agree and didn't see any support for your comments on the list. >=20 > I could be wrong. >=20 > Brian >=20 > Pekka Savola wrote: > > > > On Wed, 5 Nov 2003, Brian Haberman wrote: > > > This is a reminder that the last call on the deprecation document > > > ends today. In particular, the chairs would like to ensure that > > > the WG agrees on the actual deprecation text in Sections 4 & 6. > > > There has been few comments on this draft and it cannot proceed > > > unless the chairs can be sure that it has been thoroughly reviewed > > > and agreed upon. > > > > I do not believe the -01 version addresses the comments I made to the - > 00 > > version. > > > > -- > > 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 IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM >=20 > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 12:44:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19927 for ; Thu, 6 Nov 2003 12:44:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoAh-0005rh-93 for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 12:43:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Hhpri022546 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 12:43:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoAh-0005rZ-32 for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 12:43:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19902 for ; Thu, 6 Nov 2003 12:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoAf-0004jx-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:43:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHoAf-0004ju-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:43:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHo9s-0005jE-S1; Thu, 06 Nov 2003 12:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHo93-0005ih-JL for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 12:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19864 for ; Thu, 6 Nov 2003 12:41:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHo91-0004jU-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:42:07 -0500 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AHo91-0004jR-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:42:07 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3DCAE112E1; Thu, 6 Nov 2003 12:42:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 12:42:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 13: Omission of prefix options - resolution Date: Thu, 6 Nov 2003 12:42:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122562@tayexc13.americas.cpqcorp.net> Thread-Topic: Issue 13: Omission of prefix options - resolution Thread-Index: AcOit2lGpmFNrb4kQVWrHWv9es219QB1V2sA From: "Bound, Jim" To: "Soliman Hesham" , X-OriginalArrivalTime: 06 Nov 2003 17:42:07.0053 (UTC) FILETIME=[4C1897D0:01C3A48D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hesham, Host nodes should not be doing this? We did not put this in ND for very good reason. We want to reduce what Hosts no about prefixes and leave to the stateless and stateful. Why do we want to put this into HOsts. What is the reason. That is not below. What problem is this addition trying to fix or solve? =20 I have read the draft below and believe the core issue is resolved. What prefixes are supplied is in the system not the host or why not just use DHCPv6? I think we cannot and must not overrule the essential meaning of the A and M bits. In fact I suggest in additon to each member of this list a problem statement be stated for each change to 2461. thanks /jim > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Soliman Hesham > Sent: Tuesday, November 04, 2003 4:35 AM > To: ipv6@ietf.org > Subject: Issue 13: Omission of prefix options - resolution >=20 >=20 > Hi,=20 >=20 > This is an attempt to resolve this issue: >=20 > Issue 13: Impacts of the omission of a prefix option.=20 > section 2.2 in : > =20 > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.t xt describes the impacts of omitting a prefix option from an RA on movement detection for mobile nodes. RFC 2461=20 does not require options to be present in every RA. In case you haven't had time to look through the draft=20 here is the background info: This issue raises the problem with omitting some prefixes from an RA. The problem here is that 2461 says that a router may choose to omit some prefixes from the RA to save BW (i.e. while the lifetime of that prefix has not expired).=20 A mobile node might take this as an indication of movement (i.e. it is no longer reachable on the CoA that was derived from the omitted prefix). This may unnecessarily cause the=20 mobile node to send a binding update to the HA/CNs to indicate that its CoA has changed.=20 The other problem is that a host has no idea whether an RA contains all the prefix options that are valid on a link. Therefore, even if it sends an RS it might still get an RA with an incomplete list of prefixes. Suggested resolution: - Introduce a new code (1) in the router solicitation and advertisement. When a host sends an RS with code =3D 1 it requests that the RA include all prefixses valid on that link. Similarly, when a router sends an RA with code=3D1 it means that the RA includes all prefixes valid on that link. This way, a MN can confirm its mobility. Comments? Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 12:49:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20085 for ; Thu, 6 Nov 2003 12:49:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoFQ-0006Gm-Ha for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 12:48:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Hmigo024094 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 12:48:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoFQ-0006GX-CG for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 12:48:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20051 for ; Thu, 6 Nov 2003 12:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoFO-0004oM-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:48:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHoFO-0004oJ-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:48:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoEj-00066K-TF; Thu, 06 Nov 2003 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoEC-00065o-Ff for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 12:47:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20024 for ; Thu, 6 Nov 2003 12:47:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoEA-0004ni-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:47:26 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AHoE9-0004nf-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:47:26 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E5497FE6B; Thu, 6 Nov 2003 12:47:25 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 12:47:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Authors Section on recyle clarifications to 2461and 2462 Date: Thu, 6 Nov 2003 12:47:25 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122563@tayexc13.americas.cpqcorp.net> Thread-Topic: Authors Section on recyle clarifications to 2461and 2462 Thread-Index: AcOjQcZmxQ+o7nQVRzSlKf2ey/agPQBTDD0g From: "Bound, Jim" To: "Thomas Narten" Cc: "James Kempf" , X-OriginalArrivalTime: 06 Nov 2003 17:47:25.0745 (UTC) FILETIME=[0A0D2210:01C3A48E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thomas, I philosophically agree with you. Then lets be consistent and document this possibly with rfc-editor document. /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com]=20 > Sent: Tuesday, November 04, 2003 9:05 PM > To: Bound, Jim > Cc: James Kempf; ipv6@ietf.org > Subject: Re: Authors Section on recyle clarifications to 2461and 2462=20 >=20 >=20 > Jim, >=20 > > If we had to recycle 2460 and Steve is still gone and Bob=20 > Hinden don't=20 > > have time (which I guess is the case with Erik and Thomas) would we=20 > > add another name to the IPv6 specification? I don't=20 > believe we would=20 > > out of respect to Steve. >=20 > And who on earth would be willing to author a document if=20 > they couldn't even get credit for the work that they put into=20 > the revision? >=20 > While I don't see a need make significant revisions to 2460,=20 > I don't think it's healthy to associate individuals with=20 > documents to the point where it becomes impossible to=20 > conceive of any change in the authorship of a document=20 > because of history. Each new version of a document should=20 > stand on its own merits, and if a new editor/author has done=20 > significant work, they should be acknowledged for it, quite=20 > possibly by being listed as a new or additional author. But=20 > again, talking hypotheticals is not so productive here. This=20 > sort of conversation is best held when it has become clear=20 > how much work was put into a document and by who. >=20 > Thomas >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 12:53:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20280 for ; Thu, 6 Nov 2003 12:53:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoJM-0006e7-Ek for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 12:52:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6HqmVg025541 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 12:52:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoJL-0006dr-Gu for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 12:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20221 for ; Thu, 6 Nov 2003 12:52:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoJJ-0004rX-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:52:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHoJJ-0004rU-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 12:52:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoIb-0006Tp-NR; Thu, 06 Nov 2003 12:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoHr-0006T5-6Y for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 12:51:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20185 for ; Thu, 6 Nov 2003 12:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoHp-0004qZ-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:51:13 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AHoHo-0004qW-00 for ipv6@ietf.org; Thu, 06 Nov 2003 12:51:12 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 02745FEEB; Thu, 6 Nov 2003 12:51:13 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Nov 2003 12:51:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: Issue 13: Omission of prefix options - summary Date: Thu, 6 Nov 2003 12:51:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122564@tayexc13.americas.cpqcorp.net> Thread-Topic: Issue 13: Omission of prefix options - summary Thread-Index: AcOkTRyuaY3LmuJ5QkCvNYufjw789gAQULxw From: "Bound, Jim" To: "JinHyeock Choi" , "Soliman Hesham" , Cc: "Tim Hartrick" X-OriginalArrivalTime: 06 Nov 2003 17:51:12.0783 (UTC) FILETIME=[916061F0:01C3A48E] Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGJpcyBkaXNjdXNzaW9uIHNob3VsZCBnbyB0byBtaXBzaG9wIElNTy4NCg0KT2YgY291cnNlIEkg ZG8gbm90IGhhdmUgYW4gaXNzdWUgd2l0aCBvdGhlciBkb2NzIGV4dGVuZGluZyBORCBvcHRpb25z LiAgDQoNCkJ1dCBJIGRvbid0IGJlbGlldmUgdGhpcyBpcyBuZWVkZWQgYW5kIHdvdWxkIGxpa2Ug dG8gc2VlIGNsZWFyIHdoYXQgcHJvYmxlbSBpcyB0aGlzIHNvbHZpbmcuICBJdCBkb2VzIG5vdCBo ZWxwIHdpdGggTUQgYnV0IEkgZG8gbm90IHRoaW5rIHRoaXMgV0cgaXMgdGhlIHBsYWNlIHRvIGRp c3VzcyBNRCBpc3N1ZXMgYnV0IG1pcHNob3AuDQoNCi9qaW0NCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2LWFkbWluQGlldGYub3JnIFttYWlsdG86aXB2Ni1hZG1p bkBpZXRmLm9yZ10gT24gDQo+IEJlaGFsZiBPZiBKaW5IeWVvY2sgQ2hvaQ0KPiBTZW50OiBUaHVy c2RheSwgTm92ZW1iZXIgMDYsIDIwMDMgNDoxMCBBTQ0KPiBUbzogU29saW1hbiBIZXNoYW07IGlw djZAaWV0Zi5vcmcNCj4gQ2M6IFRpbSBIYXJ0cmljaw0KPiBTdWJqZWN0OiBSZTogSXNzdWUgMTM6 IE9taXNzaW9uIG9mIHByZWZpeCBvcHRpb25zIC0gc3VtbWFyeQ0KPiANCj4gDQo+IERlYXIgSGVz aGFtDQo+IA0KPiBJIGRpc2FncmVlLiANCj4gDQo+IElNTywgQ29tcGxldGUgYml0IChvciBjb2Rl KSBpcyBhbiBlc3NlbnRpYWwgYnVpbGRpbmcgYmxvY2sgZm9yIGFuIA0KPiBlZmZpY2llbnQgTUQg c2NoZW1lIGFuZCB3ZSdkIGJldHRlciByZXNvbHZlIHRoaXMgaXNzdWUgdGhpcyB0aW1lLiANCj4g DQo+IEl0IGlzIElQdjYgV0cgd2hlcmUgd2UgY2FuIGRlZmluZSBhIGNvbXBsdGUgYml0LCBpLmUu IGFsdGVyIGEgDQo+IFJBIG1lc3NhZ2UgZm9ybWF0LCB0aG91Z2ggaXQgbWF5IGJlIGRvbmUgaW4g RE5BIHRvIHNwZWNpZnkgZGV0YWlsZWQgDQo+IE1EIHByb2NlZHVyZSBiYXNlZCBvbiBjb21wbGV0 ZSBiaXQuIC4NCj4gDQo+IEkgdGhpbmsgd2UgYWdyZWVkIHRoYXQgaXQncyBuZWNlc3NhcnkgdG8g bWFrZSBpdCBjbGVhcmVyIHRoYXQgDQo+IHRoZSBwcmVmaXhlcyANCj4gYXJlIG5vdCBvbWl0dGVk IGFuZCBMaW5rSUQgc2NoZW1lIGNhbid0IGRvIHRoaXMgam9iLiBMaW5rSUQgYW5kIA0KPiBDb21w bGV0ZSBiaXQgaXMgc2ltaWxhciBidXQgbm90IGV4YWN0bHkgdGhlIHNhbWUuIEknbGwgDQo+IGVs YWJvcmF0ZSB0aGlzIGluIA0KPiBkZXRhaWwgYmVsb3cuICAgDQo+IA0KPiBJIHRoaW5rLCB3aGVu IHdlIHVwZGF0ZSBORCwgd2UnZCBiZXR0ZXIgYWRkIHRoaXMgZmVhdHVyZSB0byBSRkMgMjQ2MSwN Cj4gbGVzdCB0aGVyZSBzaG91bGQgYmUgb25lIG1vcmUgdXBkYXRlIGxhdGVyLiAgIA0KPiAgIA0K PiBLaW5kbHkgZmluZCBteSBpbiBsaW5lIGNvbW1lbnRzDQo+IA0KPiBIZXNoYW0gU29saW1hbiB3 cm90ZTogDQo+ID4gSnVzdCBhIHF1aWNrIHN1bW1hcnkgb24gdGhpcyBpc3N1ZS4gSXQgc2VlbXMg dGhhdCB0aGVyZSBpcw0KPiA+IGFuIGFncmVlbWVudCB0aGF0IHRoZXJlIGlzIGEgcHJvYmxlbS4g SG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHdoYXQgDQo+ID4gdGhlIHNvbHV0aW9uIHNob3VsZCBi ZS4gSXQgc2VlbXMgbGlrZSB3ZSBhZ3JlZSB0aGF0IGEgDQo+ICJDb21wbGV0ZSIgYml0IA0KPiA+ IGlzIGJldHRlciB0aGFuIGEgbmV3IGNvZGUuIFRoZXJlIGlzIGFsc28gY29uZmxpY3Rpbmcgb3Bp bmlvbnMgb24gDQo+ID4gd2hldGhlciB0aGUgbmV3IExpbmtJRCB3b3VsZCBiZSBiZXR0ZXIgdGhh biBib3RoIChDb21wbGV0ZSANCj4gYml0IG9yIG5ldyANCj4gPiBjb2RlKS4NCj4gDQo+IFRoZSBw cm9ibGVtIGlzOiBUaGUgb21pc3Npb24gb2YgdGhlIHByZWZpeGVzIG1ha2VzIGl0IA0KPiBkaWZm aWN1bHQgZm9yIGEgbW9iaWxlIA0KPiBub2RlIHRvIGNoZWNrIHdoZXRoZXIgdGhlIHByZWZpeCBv ZiB0aGUgY3VycmVudCBJUCBhZGRyZXNzIGlzIA0KPiBzdXBwb3J0ZWQgaW4gDQo+IHRoZSBjdXJy ZW50IGxpbmsuIA0KPiANCj4gQWxsb3cgbWUgZGVsdmUgaW50byBkZXRhaWwgYSBsaXR0bGUuDQo+ IA0KPiBJbiBzb21lIGNhc2VzLCB3aXRoIExpbmtJRCwgYW4gTU4gY2FuIGRldGVjdCBsaW5rIGNo YW5nZSBidXQgY2FuJ3QgDQo+IGNoZWNrIHRoZSB2YWxpZGl0eSBvZiBjdXJyZW50IENvQSBjb3Jy ZWN0bHkuIEhlcmUgaXMgYW4gZXhhbXBsZS4gDQo+IA0KPiBBc3N1bWUgYSByb3V0ZXIgaGFzIHR3 byBpbnRlcmZhY2VzIGFuZCB0d28gYWNjZXNzIHBvaW50cyBhcmUgYXR0YWNoZWQgDQo+IHRvIHRo ZSBlYWNoIGludGVyZmFjZXMgYXMgYmVsb3cuDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0rDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICB8ICAgICAgICAgDQo+ICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0rICBSb3V0ZXIgICstLS0tLSsNCj4gICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg fCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgQTo6LCANCj4gICAgICAgICAgICAgICBBOjog ICAgIHwgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgfCAgQjo6DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAg ICAgICAgICAgICstLS0rLS0tKyAgICAgICAgICAgICAgICAgICAgKy0tLSstLS0rDQo+ICAgICAg ICAgICAgICAgICB8ICAgQVAxICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgQVAyICB8DQo+ ICAgICAgICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsN Cj4gDQo+ICAgICAgICAgICAgICAgICAgICAgIEE6OjENCj4gICAgICAgICAgICAgICAgICstLS0r LS0tKyAgICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICAgICAgICAgICB8ICBNTiAgICB8ICAg ICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgDQo+IA0KPiANCj4gVGhlIGxlZnQgaW50ZXJmYWNlIGFkdmVydGlzZSB0aGUg cHJlZml4IEE6OiBhbmQgdGhlIHJpZ2h0IA0KPiBpbnRlcmZhY2UgYWR2ZXJ0aXNlcyANCj4gdGhl IHByZWZpeCBBOjogYW5kIHByZWZpeCBBOjogYW5kIEI6Oi4gVGhlbiB0d28gaW50ZXJmYWNlIA0K PiBzaG91bGQgYWR2ZXJ0aXNlIA0KPiB0aGUgZGlmZmVyZW50IExpbmtJRHMuIA0KPiANCj4gQXNz dW1lIHRoZXJlIGlzIGFuIE1OIGluIHRoZSBsZWZ0IGxpbmsgd2l0aCBDb0EsIEE6OjEuIFdoZW4g aXQgbW92ZXMgDQo+IHRvIHRoZSByaWdodCBsaW5rIGFuZCByZWNlaXZlcyBhbiBSQSB3aXRoIExp bmtJRCAoYW5kIHdpdGhvdXQgDQo+IHByZWZpeCBBOjopLCANCj4gaXQgd2lsbCAgbWlzdGFrZSB0 aGF0IGl0IGNhbid0IHVzZSBpdCdzIGN1cnJlbnQgQ29BIGFueSANCj4gbG9uZ2VyIGFuZCBwZXJm b3JtIA0KPiB1bm5lY2Vzc2FyeSBoYW5kb2ZmLiANCj4gDQo+IE11bHRpLWxpbmsgc3VibmV0IG1h a2VzIG1hdHRlcnMgY29tcGxleCBhbmQgSSB3b25kZXIgd2UgY2FuIHNhZmVseSANCj4gaWdub3Jl IHRoZSBhYm92ZSBhcyB0aGUgcGF0aG9sb2dpY2FsIGV4Y2VwdGlvbi4gT3RoZXJ3aXNlLCB3ZSBz aG91bGQgDQo+IHRpZ2h0ZW4gdGhlIG11bHRpLWxpbmsgc3VibmV0IHByb3RvY29sIHRvIGF2b2lk IHN1Y2ggYW4gYWNjaWRlbnQuIA0KPiANCj4gPiBJbiBhbnkgY2FzZSwgc2luY2Ugc2V2ZXJhbCBw ZW9wbGUgKGluY2x1ZGluZyB0aG9zZSB3aG8NCj4gPiBicm91Z2h0IHVwIHRoZSBpc3N1ZSkgc2Vl bSB0byBhZ3JlZSB0aGF0IHRoZSBpc3N1ZSBpcyANCj4gPiBiZXN0IGFkZHJlc3NlZCBpbiBETkEu IEFuZCBzaW5jZSB0aGVyZSBpcyBubyBjb21wZWxsaW5nDQo+ID4gcmVhc29uIGZvciBhZGRpbmcg dGhpcyBpbnRvIDI0NjEgVnMgaW50cm9kdWNpbmcgYSBzb2x1dGlvbg0KPiA+IGluIGEgbmV3IHNw ZWMsIEknZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB3ZSBjbG9zZSB0aGlzIA0KPiA+IGlzc3VlIGFu ZCBsZXQgRE5BIChvciBJUHY2KSBoYW5kbGUgdGhpcyBpc3N1ZSBzZXBhcmF0ZWx5LiANCj4gDQo+ IEkgYW0gYWZyYWlkIEkgZ2F2ZSBhIHdyb25nIGltcHJlc3Npb24uIA0KPiANCj4gSSBtZWFudCB0 aGF0LCB3ZSB3aWxsIGRlaW5mZSBNRCBzb2x1dGlvbiB3aXRoIGRldGFpbGVkIG9wZXJhdGlvbmFs IA0KPiBwcm9jZWR1cmUgaW4gRE5BIFdHLiAgQnV0IEkgdGhpbmsgaXQgd291bGQgYmUgSVB2NiBX RyB3aGVyZSANCj4gd2UgYWRlZmluZSBhIG5ldyBiaXQgaW4gUkEgbWVzc2FnZS4gDQo+IA0KPiBD b21wbGV0ZSBiaXQgYnkgaXRzZWxmIGlzIG5vdCBzdWZmaWNpZW50IGZvciBlZmZpY2llbnQgTUQu IFdlIA0KPiBhbHNvIG5lZWRzIHRvIA0KPiBzcGVjaWZ5IHRoZSBvcGVyYXRpb25hbCBwcm9jZWR1 cmUgZm9yIGNvbXBsZXRlIGJpdCAoY29tcGxldGUgUkEpLiBGb3IgDQo+IGV4YW1wbGUsIG9wZXJh dGlvbiBkZXNjcmlwdGlvbiBsaWtlDQo+IA0KPiAnQW4gTU4gU0hPVUxEIGludGVycHJldCBhIGRp ZmZlcmVudCBjb21wbGV0ZSBSQSBhcyBhIG1vdmVtZW50IA0KPiBpbmRpY2F0aW9uIGJ1dCBTSE9V TEQgTk9UIGludGVycHJldCBhIGxhY2sgb2YgY29tcGxldGUgUkEgYXMgb25lLiANCj4gDQo+IEkg bWVhbnQgdGhhdCwgd2Ugd2lsbCBzcGVjaWZ5IHN1Y2ggYW4gb3BlcmF0aW9uYWwgcHJvY2VkdXJl cyANCj4gaW4gRE5BIFdHLg0KPiANCj4gSU1PLCB0aG91Z2ggY29tcGxldGUgYml0IGlzIG5vdCBz dWZmaWNpZW50IGZvciBlZmZpY2llbnQgTUQsIA0KPiBpdCdzIG5lY2Vzc2FyeSANCj4gZm9yIGVm ZmljaWVudCBNRC4gSXQgd2lsbCBiZSBkaWZmaWN1bHQgZm9yIHVzIHRvIGRlc2lnbiBhIA0KPiBl ZmZpY2llbnQgTUQgcHJvY2VkdXJlIA0KPiB3aXRob3V0IGNvbXBsZXRlbmVzcyBpbmRpY2F0aW9u LCBjb21wbGV0ZSBiaXQuIA0KPiANCj4gPiBTbywgaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQsIG5v dGhpbmcgbmVlZHMgdG8gYmUgZG9uZSBhYm91dA0KPiA+IHRoaXMgaXNzdWUgKHVubGVzcyB0aGVy ZSBhcmUgc3Ryb25nIG9iamVjdGlvbnMpLg0KPiANCj4gSSB3aXNoLCB3aGVuIHdlIHVwZGF0ZSBS RkMgMjQ2MSwgd2UgYWxzbyBhZGQgdGhpcyBmZWF0dXJlLCANCj4gY29tcGxldGUgYml0LCANCj4g aW50byBOZWlnaGJvciBEaXNjb3ZlcnkuIE90aGVyd2lzZSBJIGFtIGFmcmFpZCB3ZSBtYXkgaGF2 ZSB0byANCj4gdXBkYXRlIE5EIA0KPiBvbmNlIG1vcmUgbGF0ZXIuICANCj4gIA0KPiA+IEhlc2hh bQ0KPiA+IA0KPiA+IFBTOiBUbyBzYXZlIGVtYWlscywgSSdsbCBhc3N1bWUgc2lsZW5jZSBtZWFu cyB0aGVyZSBpcw0KPiA+IG5vIG9iamVjdGlvbnMuDQo+IA0KPiBJIGhvcGUgbXkgcmVwbHkgaXMg ZmFzdCBlbm91Z2ggc28gdGhhdCBJIHdpbGwgbm90IGJlIGNvdW50ZWQgDQo+IGFzIG9uZSBvZiBz aWxlbnQgdGhvc2UgaW4gZmF2b3IuIDotKSANCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBraW5kIGNv bnNpZGVyYXRpb24NCj4gDQo+IEJlc3QgcmVnYXJkcw0KPiANCj4gSmluSHllb2NrICBEIMO7w4LF oMWgeMKu4oC54oSiwqjFoHjFoMOLwqbDvnrDl8KuxaEpwrLDmsK2K0XDqnrDi+KAoMObwrPDv8OD DQo+IHrDl8KuD2opan/FoMOLwp3DusWg4oC6DQo+IA0K -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 14:25:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24231 for ; Thu, 6 Nov 2003 14:25:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpkm-0003pe-Fy for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 14:25:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6JPC1l014729 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 14:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpkm-0003pU-Ay for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 14:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24182 for ; Thu, 6 Nov 2003 14:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpkj-0006HE-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 14:25:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHpkj-0006H9-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 14:25:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpkb-0003iP-UT; Thu, 06 Nov 2003 14:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpkB-0003hG-BP for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 14:24:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24162; Thu, 6 Nov 2003 14:24:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpk8-0006Gt-00; Thu, 06 Nov 2003 14:24:32 -0500 Received: from dhcp4.se.kurtis.pp.se ([195.43.225.73]) by ietf-mx with esmtp (Exim 4.12) id 1AHpk7-0006Gp-00; Thu, 06 Nov 2003 14:24:31 -0500 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hA6JO55h001805; Thu, 6 Nov 2003 20:24:05 +0100 (CET) Date: Thu, 6 Nov 2003 20:24:01 +0100 Subject: Re: Clash of IPv6 and Multi6 WG meetings Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: agenda@ietf.org, multi6@ops.ietf.org, ipv6@ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20031106190241.GF20850@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From what I hear this is still being worked on. - - kurtis - On torsdag, nov 6, 2003, at 20:02 Europe/Stockholm, Tim Chown wrote: > On Thu, Nov 06, 2003 at 07:14:40AM +0100, Kurt Erik Lindqvist wrote: >> >> To reply in public as well. This is being looked at - but I would not >> hold my breath. Scheduling seems to have been really hard this time. I >> will let you all know. > > It seems the "final agenda" has ipv6 and multi6 clashing at 5pm > Tuesday. > > However, we have three multi6 WG slots: > > 15:45- 16:45 Tuesday > 17:00- 18:00 Tuesday (clashing with multi6) > 09:00- 11:30 Wednesday > > If this stays as is, I would hope the multi6 WG chairs will fund some > way > to make the key discussions happen in slots 1 and 3 :) But let's > hope > there's still scope for a fix, or compression of essential multi6 into > the > two slots. > > Tim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6qf1KarNKXTPFCVEQL87gCdFHVKrRzK24RxP2hg7/ky0C4QysQAnj9V e14IOt3GOLev5YA52LBmoAtz =fkwW -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 14:30:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24674 for ; Thu, 6 Nov 2003 14:30:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHppm-0004Yp-79 for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 14:30:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6JUM15017525 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 14:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHppm-0004YZ-0Z for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 14:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24567 for ; Thu, 6 Nov 2003 14:30:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHppj-0006P4-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 14:30:19 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHpex-0006BO-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 14:19:11 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHpRv-0008OV-Ed for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 14:05:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpRI-0001nU-7G; Thu, 06 Nov 2003 14:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpQW-0001lf-VG for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 14:04:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23209; Thu, 6 Nov 2003 14:04:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpQT-0005yx-00; Thu, 06 Nov 2003 14:04:13 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpQT-0005yQ-00; Thu, 06 Nov 2003 14:04:13 -0500 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 TAA15310; Thu, 6 Nov 2003 19:02:41 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA04152; Thu, 6 Nov 2003 19:02:41 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA6J2fC21271; Thu, 6 Nov 2003 19:02:41 GMT Date: Thu, 6 Nov 2003 19:02:41 +0000 From: Tim Chown To: agenda@ietf.org, multi6@ops.ietf.org, ipv6@ietf.org Subject: Re: Clash of IPv6 and Multi6 WG meetings Message-ID: <20031106190241.GF20850@login.ecs.soton.ac.uk> Mail-Followup-To: agenda@ietf.org, multi6@ops.ietf.org, ipv6@ietf.org References: <20BEB9BA-0D2D-11D8-BC3D-00039388672E@muada.com> <814BA15B-1020-11D8-8572-000A9598A184@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814BA15B-1020-11D8-8572-000A9598A184@kurtis.pp.se> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, Nov 06, 2003 at 07:14:40AM +0100, Kurt Erik Lindqvist wrote: > > To reply in public as well. This is being looked at - but I would not > hold my breath. Scheduling seems to have been really hard this time. I > will let you all know. It seems the "final agenda" has ipv6 and multi6 clashing at 5pm Tuesday. However, we have three multi6 WG slots: 15:45- 16:45 Tuesday 17:00- 18:00 Tuesday (clashing with multi6) 09:00- 11:30 Wednesday If this stays as is, I would hope the multi6 WG chairs will fund some way to make the key discussions happen in slots 1 and 3 :) But let's hope there's still scope for a fix, or compression of essential multi6 into the two slots. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 17:14:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04280 for ; Thu, 6 Nov 2003 17:14:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsOP-0000Bv-EW for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 17:14:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MEHmE000729 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 17:14:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsOP-0000Ba-1n for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04233 for ; Thu, 6 Nov 2003 17:14:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsOM-0001fl-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 17:14:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsOM-0001ff-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 17:14:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsND-0008JR-BC; Thu, 06 Nov 2003 17:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsMr-0008IV-2P for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 17:12:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04178 for ; Thu, 6 Nov 2003 17:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsMo-0001eb-00 for ipv6@ietf.org; Thu, 06 Nov 2003 17:12:38 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AHsMn-0001eY-00 for ipv6@ietf.org; Thu, 06 Nov 2003 17:12:38 -0500 Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2QTJWBU0U8ZQ8GQ@vaxh.its.monash.edu.au> for ipv6@ietf.org; Fri, 7 Nov 2003 09:02:12 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 3F853158002; Fri, 07 Nov 2003 09:02:12 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id 2828A120005; Fri, 07 Nov 2003 09:02:12 +1100 (EST) Date: Fri, 07 Nov 2003 09:02:12 +1100 From: Greg Daley Subject: Re: Issue 13: Omission of prefix options - summary To: "Bound, Jim" Cc: JinHyeock Choi , Soliman Hesham , ipv6@ietf.org, Tim Hartrick Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FAAC4E4.2050404@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 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: <9C422444DE99BC46B3AD3C6EAFC9711B05122564@tayexc13.americas.cpqcorp.net> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Jim, Bound, Jim wrote: >Tbis discussion should go to mipshop IMO. > >Of course I do not have an issue with other docs extending ND options. > >But I don't believe this is needed and would like to see clear what >problem is this solving. It does not help with MD but I do not think >this WG is the place to disuss MD issues but mipshop. > >/jim Mipshop has a very restricted charter which doesn't cover these issues. The DNA BoF is currently looking at these issues, as a generic attempt to tighten up the Network Attachment strategies for wireless hosts. This is similar to what Mobile IP requires, but has broader applicability. For example, with some systems MobileIP signalling may be unnecessary, but detection of network change is. The issues are: does it need to be done? If so, where and when? where is the venue (IPv6, DNA, Mipshop....) The when is whether it is applicable to 2461bis. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 6 17:44:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05928 for ; Thu, 6 Nov 2003 17:44:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrk-0002uR-NB for ipv6-archive@odin.ietf.org; Thu, 06 Nov 2003 17:44:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MiaSp011177 for ipv6-archive@odin.ietf.org; Thu, 6 Nov 2003 17:44:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrk-0002uC-Hy for ipv6-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:44:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05833 for ; Thu, 6 Nov 2003 17:44:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsrh-0002Gq-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 17:44:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsrh-0002Gn-00 for ipv6-web-archive@ietf.org; Thu, 06 Nov 2003 17:44:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrB-0002aj-Hw; Thu, 06 Nov 2003 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsqi-0002a8-E3 for ipv6@optimus.ietf.org; Thu, 06 Nov 2003 17:43:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05760 for ; Thu, 6 Nov 2003 17:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqf-0002Fq-00 for ipv6@ietf.org; Thu, 06 Nov 2003 17:43:29 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqf-0002Fh-00 for ipv6@ietf.org; Thu, 06 Nov 2003 17:43:29 -0500 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 hA6MgwV13033 for ; Thu, 6 Nov 2003 14:42:59 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hA6MkQtX016642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 6 Nov 2003 14:46:29 -0800 Message-ID: <3FAACE2F.20807@innovationslab.net> Date: Thu, 06 Nov 2003 17:41:51 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Scribes Needed References: <3FA0F6DF.60806@innovationslab.net> In-Reply-To: <3FA0F6DF.60806@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We still need note-takers for the work-group sessions. If you are able, please volunteer. The more, the merrier. Thanks, Brian & Bob IPv6 WG Chairs Brian Haberman wrote: > All, > This is a call for volunteer scribes. The chairs would like to > have at least two independent minute takers for each of the IPv6 WG > sessions in Minneapolis. If you are willing, please indicate to the > chairs your willingness to help and which sessions you can help. > > Thanks, > Brian & Bob > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 01:01:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18338 for ; Fri, 7 Nov 2003 01:01:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzgc-0006DA-Gy for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 01:01:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA761YAj023875 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 01:01:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzgc-0006D0-BE for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 01:01:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18315 for ; Fri, 7 Nov 2003 01:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzgZ-00079p-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 01:01:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHzgY-00079l-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 01:01:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzg6-00067W-V6; Fri, 07 Nov 2003 01:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzfl-00066n-7l for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 01:00:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18275 for ; Fri, 7 Nov 2003 01:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzfi-00079H-00 for ipv6@ietf.org; Fri, 07 Nov 2003 01:00:38 -0500 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AHzfh-00079D-00 for ipv6@ietf.org; Fri, 07 Nov 2003 01:00:37 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6EE954EA0; Fri, 7 Nov 2003 01:00:34 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 01:00:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 13: Omission of prefix options - summary Date: Fri, 7 Nov 2003 01:00:33 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA229@tayexc13.americas.cpqcorp.net> Thread-Topic: Issue 13: Omission of prefix options - summary Thread-Index: AcOks3bO5ubQ12B1RCWgexWiDGYzjQAP1ZoA From: "Bound, Jim" To: Cc: "JinHyeock Choi" , "Soliman Hesham" , , "Tim Hartrick" X-OriginalArrivalTime: 07 Nov 2003 06:00:34.0180 (UTC) FILETIME=[7533A440:01C3A4F4] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Greg, That is good and clear mail. Thanks then lets see what happens at DNA BOF. I am on mipshop and quite nervous about the extreme conservative charter for time-to-market of those technologies as a note. I missed that charter discussion and I plan on being at DNA BOF if for no other reasons self defense. So DNA BOF Look at what is needed not done in mipshop then look at 2461. Here is my reasoning why its ok to do ND extensions out of IPv6 WG I will share with you and why more importantly it is good for the IETF processes to keep evolving specs in a reasonable manner. As implementor as you, I have no issue of having ND integrated into a spec for a specific purpose. Even if one whacks reserved fields in 2461 because if implementor just supports 2461 but not MIPv6 it will just work just like any good engineering mod overlay. Now if the 2461 overlay needs an update that is different I agree. And that does not mean it changes standards track status because of adding an overlay. Anyway here is my logic using a systems view: ------------------------------- Whenever one can multitask or multithread and solve problems simultaneously with discrete vectors the system is more efficient. The key is to manage all vectors so they do not break the overall system. I believe an IETF spec can extend a core spec and it just needs to be reviewed by that core spec center of expertise without adding to the core spec. This permits work to flow around the core spec as an extension and not all vectors bottleneck at the one core spec. This is also a theory I have how to live with chaos within systems and extension to how nature operates on our planet. But that gets into all systems not just IETF. =20 ----------------------------- /jim "The drinkin' bone's connected to the party bone. The party bone's connected to the stayin' out all night long. An' she won't think it's funny and I'll wind up all alone. And the lonely bone's connected to the drinkin' bone." - Tracy Byrd > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au]=20 > Sent: Thursday, November 06, 2003 5:02 PM > To: Bound, Jim > Cc: JinHyeock Choi; Soliman Hesham; ipv6@ietf.org; Tim Hartrick > Subject: Re: Issue 13: Omission of prefix options - summary >=20 >=20 > Hi Jim, >=20 > Bound, Jim wrote: > >Tbis discussion should go to mipshop IMO. > > > >Of course I do not have an issue with other docs extending=20 > ND options. > >But I don't believe this is needed and would=20 > like to see clear what=20 > >problem is this solving. It does not help with MD but I do=20 > not think=20 > >this WG is the place to disuss MD issues but mipshop. > > > >/jim >=20 > Mipshop has a very restricted charter which doesn't > cover these issues. >=20 > The DNA BoF is currently looking at these issues, > as a generic attempt to tighten up the Network Attachment=20 > strategies for wireless hosts. >=20 > This is similar to what Mobile IP requires, but has > broader applicability. For example, with some systems > MobileIP signalling may be unnecessary, but > detection of network change is. >=20 > The issues are: does it need to be done? > If so, where and when? >=20 > where is the venue (IPv6, DNA, Mipshop....) >=20 > The when is whether it is applicable to 2461bis. >=20 > Greg >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 03:52:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05850 for ; Fri, 7 Nov 2003 03:52:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2Lq-0008QQ-Ad for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 03:52:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA78qIu9032380 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 03:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2Lq-0008QB-2C for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 03:52:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05817 for ; Fri, 7 Nov 2003 03:52:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2Ln-0001KW-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 03:52:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI2Ln-0001KS-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 03:52:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2Kc-0008DQ-5h; Fri, 07 Nov 2003 03:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2KJ-0008C2-1Z for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 03:50:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05722 for ; Fri, 7 Nov 2003 03:50:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2KG-0001JE-00 for ipv6@ietf.org; Fri, 07 Nov 2003 03:50:40 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AI2KF-0001Iq-00 for ipv6@ietf.org; Fri, 07 Nov 2003 03:50:40 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Nov 2003 03:50:09 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E9A@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Bound, Jim'" , ipv6@ietf.org Subject: RE: Issue 13: Omission of prefix options - resolution Date: Fri, 7 Nov 2003 03:50:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Host nodes should not be doing this? We did not put this in > ND for very > good reason. We want to reduce what Hosts no about prefixes > and leave to > the stateless and stateful. Why do we want to put this into > HOsts. What > is the reason. That is not below. => I should have described the scenario a bit better. This is a case where hosts need to know whether they have changed links or not. The only way we know that today is through the contents of the RA. Hosts today use the prefixes advertised (or not) as an input to the movement detection algorithm amongst other things. There are different flavours of movement detection depending on how conservative an implementor wants to be. But in all those flavours, the prefix option (or absence of) may well trigger the algorithm. I don't have a strong opinion on whether this should go into 2461bis or not. But I do think that there is a problem. Another consideration is how _real_ this problem is. Does anyone know of a router implementation that sometimes does not advertise all options to save BW ? > What problem is this addition trying to fix or solve? > > I have read the draft below and believe the core issue is resolved. > What prefixes are supplied is in the system not the host or > why not just > use DHCPv6? => DHCPv6 can be used, but in order to trigger DHCPv6 a host needs to know that it has changed links. Otherwise it will be triggered unnecessarily. I think we cannot and must not overrule the essential > meaning of the A and M bits. => Agreed. We won't do that. > > In fact I suggest in additon to each member of this list a problem > statement be stated for each change to 2461. => I'll try to cover that briefly in a "background" section when I send a suggestion to resolve an issue. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 04:30:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07108 for ; Fri, 7 Nov 2003 04:30:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2wc-0002Qq-Sg for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 04:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79UILd009348 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 04:30:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2wa-0002Qh-LT for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 04:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07077 for ; Fri, 7 Nov 2003 04:30:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2wX-0001ne-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 04:30:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI2wX-0001nb-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 04:30:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2wP-0002Mh-08; Fri, 07 Nov 2003 04:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2vu-0002M7-Ap for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 04:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07046 for ; Fri, 7 Nov 2003 04:29:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2vr-0001nQ-00 for ipv6@ietf.org; Fri, 07 Nov 2003 04:29:31 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AI2vq-0001nN-00 for ipv6@ietf.org; Fri, 07 Nov 2003 04:29:30 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA79TQXO032462; Fri, 7 Nov 2003 11:29:26 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.6) id hA79TQ6X032458; Fri, 7 Nov 2003 11:29:26 +0200 Date: Fri, 7 Nov 2003 11:29:26 +0200 Message-Id: <200311070929.hA79TQ6X032458@burp.tkv.asdf.org> From: Markku Savela To: H.Soliman@flarion.com CC: ipv6@ietf.org In-reply-to: <748C6D0A58C0F94CA63C198B6674697A01922E9A@ftmail.lab.flarion.com> (message from Soliman Hesham on Fri, 7 Nov 2003 03:50:05 -0500) Subject: Re: Issue 13: Omission of prefix options - resolution References: <748C6D0A58C0F94CA63C198B6674697A01922E9A@ftmail.lab.flarion.com> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > From: Soliman Hesham > Does anyone know of a router implementation that sometimes does not > advertise all options to save BW ? The problem is not with single router. It's with multiple routers and this change requiring them to be in synch and advertising complete set of each others prefixes. And as I mentioned earlier, if I attach some dead end lan segment to an existing link using the preferred route option, I don't want this router to be inconvenienced by forcing it also to advertise all prefixes. It would just send this preferred route option without any prefixes. As compromise, I could accept that a router, which knows it is advertising all valid prefixes on the link, could set some "complete bit" in RA. However, it must always be legal send incomplete RA's, too. In my view: MIP6 detecting a movement by sniffing RA, and not finding the current CoA among the prefixes, is wrong approach. If layer2 singals are not available, I would think some type of link-id option is better approach. You could have totally independent MIP6 beacon sender, that would only send RA's without prefixes, containing only the Link-ID (to make this beacon very short). Or, preferrably, the beacon should be sending some totally new MIP6 specific ICMP6 message type. Those links that wish to support movement, would install the beacon sender, independently on any routers on the link. Of course, the Home Agent would be obvious beacon sender. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 05:02:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08449 for ; Fri, 7 Nov 2003 05:02:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3R8-00050g-G0 for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 05:01:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7A1ouS019259 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 05:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3R7-00050Y-18 for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05:01:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08413 for ; Fri, 7 Nov 2003 05:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3R3-0002Lv-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 05:01:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3R3-0002Ls-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 05:01:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3QM-0004na-12; Fri, 07 Nov 2003 05:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Q2-0004mj-V0 for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 05:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08388 for ; Fri, 7 Nov 2003 05:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Pz-0002LR-00 for ipv6@ietf.org; Fri, 07 Nov 2003 05:00:39 -0500 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Pz-0002LO-00 for ipv6@ietf.org; Fri, 07 Nov 2003 05:00:39 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CF8CFAAC1; Fri, 7 Nov 2003 05:00:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 05:00:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 13: Omission of prefix options - resolution Date: Fri, 7 Nov 2003 05:00:39 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA22D@tayexc13.americas.cpqcorp.net> Thread-Topic: Issue 13: Omission of prefix options - resolution Thread-Index: AcOlDDINhYeS8vXUQz+zAoesf3dcRgACHKaA From: "Bound, Jim" To: "Soliman Hesham" , X-OriginalArrivalTime: 07 Nov 2003 10:00:39.0652 (UTC) FILETIME=[FF883A40:01C3A515] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hesham, I realize hosts today "could" use prefixes from L bit being set to know its on a new link. But that is not why the L bit is there. The L bit is there as an optimization to avoid an NS or direct send knowing it is onlink and a fast path could be written to just move the packet to the link-layer address. =20 The reason it is good to not use it is when one does not want to make an annoucement of all prefixes on a Link and force NS's. Let me give you example. 911 Attack, Squad in Military Engaged Operation, or EMS helping a victim with Wearable Medical Devices. In each case the entity does not want to advertise those prefixes over a wireless, Satcom, or cellular link. Same for a shopper in a mall with GPS device locating ones favorite perfume or firearm shop in the mall. =20 Regardless this L bit has a use and dependency and was not created for mobility but for stationary nodes. The R bit defined in MIPv6 solves the problem below. When the node reaches the link it will hear the new RA with R bit set and new router prefix. So what has to happen is MIPv6 routers have to be turned on to deploy. But that is ok because without MIPv6 routers MIPv6 won't work :--) But if one insists inform links that are supporting MIPv6 to just set the L bit with policy admin and that fixes it too. Help me here I think this is pretty basic stuff :--) This is not a flaw in 2461 but a good feature and I like it and want to use it as is and don't want L bit as default. /jim ------------------------------------ He said my name is Private Andrew Malone if you're reading this then I didn't make it home but for every dream that's shattered another one=20 comes true this car was once a dream of mine now it belongs to you=20 and though you may take her and make her your own you'll always be riding with Private Malone - David Ball www.minibite.com/america/malone.htm > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com]=20 > Sent: Friday, November 07, 2003 3:50 AM > To: Bound, Jim; ipv6@ietf.org > Subject: RE: Issue 13: Omission of prefix options - resolution >=20 >=20 >=20 > > Host nodes should not be doing this? We did not put this in=20 > > ND for very > > good reason. We want to reduce what Hosts no about prefixes=20 > > and leave to > > the stateless and stateful. Why do we want to put this into=20 > > HOsts. What > > is the reason. That is not below. >=20 > =3D> I should have described the scenario a bit better.=20 > This is a case where hosts need to know whether they have=20 > changed links or not. The only way we know that today is=20 > through the contents of the RA. Hosts today use the prefixes=20 > advertised (or not) as an input to the movement detection=20 > algorithm amongst other things. There are different flavours=20 > of movement detection depending on how conservative an=20 > implementor wants=20 > to be. But in all those flavours, the prefix option (or absence > of) may well trigger the algorithm.=20 >=20 > I don't have a strong opinion on whether this should go into=20 > 2461bis or not. But I do think that there is a problem.=20 > Another consideration is how _real_ this problem is. Does=20 > anyone know of=20 > a router implementation that sometimes does not advertise=20 > all options to save BW ?=20 >=20 > > What problem is this addition trying to fix or solve? =20 > >=20 > > I have read the draft below and believe the core issue is=20 > resolved. > What prefixes are supplied is in the system not=20 > the host or=20 > > why not just > > use DHCPv6? =20 >=20 > =3D> DHCPv6 can be used, but in order to trigger DHCPv6 a host=20 > needs to know that it has changed links. Otherwise it will be=20 > triggered unnecessarily.=20 >=20 > I think we cannot and must not overrule the essential > > meaning of the A and M bits. >=20 > =3D> Agreed. We won't do that. >=20 > >=20 > > In fact I suggest in additon to each member of this list a=20 > problem > statement be stated for each change to 2461. >=20 > =3D> I'll try to cover that briefly in a "background" section=20 > when I send a suggestion to resolve an issue. >=20 > Hesham=20 >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 05:18:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08882 for ; Fri, 7 Nov 2003 05:18:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3gy-0006CX-Jf for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 05:18:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7AICjA023831 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 05:18:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3gy-0006CI-Ey for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05:18:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08852 for ; Fri, 7 Nov 2003 05:18:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3gv-0002XC-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 05:18:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3gu-0002X8-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 05:18:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3gn-00065P-KE; Fri, 07 Nov 2003 05:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3gH-00064o-8Y for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 05:17:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08825 for ; Fri, 7 Nov 2003 05:17:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3gD-0002WX-00 for ipv6@ietf.org; Fri, 07 Nov 2003 05:17:25 -0500 Received: from smtp5.clb.oleane.net ([213.56.31.25]) by ietf-mx with esmtp (Exim 4.12) id 1AI3gC-0002WH-00 for ipv6@ietf.org; Fri, 07 Nov 2003 05:17:25 -0500 Received: from oleane ([194.250.212.114]) by smtp5.clb.oleane.net with SMTP id hA7AGspR006796 for ; Fri, 7 Nov 2003 11:16:55 +0100 Message-ID: <04b001c3a518$caa4c520$0601a8c0@www.oleane.com> From: "M Winkhler" To: Subject: WiMAX Summit Date: Fri, 7 Nov 2003 11:20:38 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04AD_01C3A521.2C2609A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_04AD_01C3A521.2C2609A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are WiMAX and WiFi complementary (local vs. metropolitan area = networking)?=20 When and how will WiMAX evolve towards mobility?=20 Can WiMAX be considered as a migration path to 4G?=20 How is addressed the interoperability challenge?=20 These questions, among others, will be addressed during the WiMAX = Summit, to be held in Paris on May 25 to 28, 2004.=20 A call for papers has been launched on-line at: http://www.upperside.fr/wimax04/wimax04intro.htm =20 ------=_NextPart_000_04AD_01C3A521.2C2609A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are WiMAX and WiFi complementary (local vs. = metropolitan=20 area networking)?
When and how will WiMAX evolve towards = mobility?=20
Can WiMAX be considered as a migration path to 4G?
How is = addressed the=20 interoperability challenge?

These questions, among others, will = be=20 addressed during the WiMAX = Summit, to=20 be held in Paris on May 25 to 28, 2004. =

A=20 call for papers has been launched on-line at:
http://www.uppe= rside.fr/wimax04/wimax04intro.htm
 
 
 
------=_NextPart_000_04AD_01C3A521.2C2609A0-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 05:36:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09359 for ; Fri, 7 Nov 2003 05:36:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3yW-0006xb-GB for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 05:36:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7AaKlt026749 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 05:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3yW-0006xK-AX for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05:36:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09332 for ; Fri, 7 Nov 2003 05:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3yS-0002jp-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 05:36:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3yS-0002jm-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 05:36:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3yF-0006ok-0B; Fri, 07 Nov 2003 05:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3xv-0006o1-MZ for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 05:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09320 for ; Fri, 7 Nov 2003 05:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3xs-0002jH-00 for ipv6@ietf.org; Fri, 07 Nov 2003 05:35:40 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AI3xr-0002j2-00 for ipv6@ietf.org; Fri, 07 Nov 2003 05:35:39 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Nov 2003 05:35:10 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EA0@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Bound, Jim'" , ipv6@ietf.org Subject: RE: Issue 13: Omission of prefix options - resolution Date: Fri, 7 Nov 2003 05:35:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Jim, > I realize hosts today "could" use prefixes from L bit being > set to know > its on a new link. But that is not why the L bit is there. > The L bit is > there as an optimization to avoid an NS or direct send knowing it is > onlink and a fast path could be written to just move the > packet to the > link-layer address. > > The reason it is good to not use it is when one does not > want to make an > annoucement of all prefixes on a Link and force NS's. => Completely understand, but I was not referring to the L bit in my email, I was referring to the disappearance of the _entire_ prefix option. I happen to agree with a few people that the best solution to this problem is to introduce the LinkID which makes it much simpler to detect movement. The R bit defined in MIPv6 solves > the problem below. When the node reaches the link it will > hear the new > RA with R bit set and new router prefix. So what has to > happen is MIPv6 > routers have to be turned on to deploy. But that is ok > because without > MIPv6 routers MIPv6 won't work :--) => Sure. But in the scenario discussed in this issue, the whole prefix option disappears. Therefore, there is no R bit either. The question is if some router designer decided to save BW and not advertise all options all the time. The MN first hears Prefix1 and Prefix2 (from one or two routers doesn't matter). It derives a CoA based on Prefix1. The next adv contains Prefix2 only (because its timer was about to expire and therefore had to be advertised again, while prefix1 didn't need to. Or because there were two routers and one of them decided that it doesn't need to advertise its prefix this time). Now, this might force a movement detection implementation to think that it _might_ have moved. Depending on how "conservative" that implemenation is, the reaction will vary from: "form a new CoA based on prefix2" (not conservative) to "check that prefix1 and default router are still alive" (conservative). If the MN hadn't moved at all (as is the case in this example), neither action is desirable. Having a new option (not suggesting to add that to 2461) called a LinkID (could be a globally unique address) and included in every RA sent from all routers on the same link, would allow the router to save other options, while eliminating movement detection problems. But since there is no concensus on the solution (some prefer the "complete bit"), or its inclusion in 2461 (Vs DNA or another IPv6 draft), it seems like we should either reject this issue or delay the discussion until we resolve all the other issues and hope that opinions have converged by that time. > Help me here I think this is pretty basic stuff :--) => Hope this helps :) Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 07:13:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12007 for ; Fri, 7 Nov 2003 07:13:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5Tq-0002wu-LI for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 07:12:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7CCk9H011138 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 07:12:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5Tq-0002tZ-3S for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 07:12:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11967 for ; Fri, 7 Nov 2003 07:12:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI5Tp-0003z9-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 07:12:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI5Tp-0003z6-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 07:12:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5T6-0002jO-8w; Fri, 07 Nov 2003 07:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI5SR-0002i4-Aa for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 07:11:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11919 for ; Fri, 7 Nov 2003 07:11:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI5SM-0003xZ-00 for ipv6@ietf.org; Fri, 07 Nov 2003 07:11:14 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AI5SM-0003x0-00 for ipv6@ietf.org; Fri, 07 Nov 2003 07:11:14 -0500 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 hA7CAjV17637 for ; Fri, 7 Nov 2003 04:10:45 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hA7CEFtX018598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Nov 2003 04:14:18 -0800 Message-ID: <3FAB8B76.2050804@innovationslab.net> Date: Fri, 07 Nov 2003 07:09:26 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Mailing List Subject: Latest Agenda Content-Type: multipart/mixed; boundary="------------020001080304000006050605" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------020001080304000006050605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, This is the latest (final?) agenda for the IPv6 WG meetings in Minneapolis. Regards, Brian & Bob IPv6 WG Chairs --------------020001080304000006050605 Content-Type: text/plain; name="Agenda.txt" Content-Disposition: inline; filename="Agenda.txt" Content-Transfer-Encoding: 7bit Tuesday (11/11/03) 1700-1800 ------------------------------ 1. Intro & Agenda Bashing chairs 5 minutes 2. Milestone Review and Document Status chairs 10 minutes 3. Tunnel MIB Thaler 10 minutes - draft-thaler-inet-tunnel-mib-00.txt - Goal: overview of proposal, adopt as WG item? 4. Proxy RA Thaler 10 minutes - draft-thaler-ipv6-ndproxy-01.txt - Goal: status update, adopt as WG item? 5. ICMP Updates Hinden 10 minutes - draft-ietf-ipngwg-icmp-v3-02.txt - Goal: status update 6. Local Communications Goals Hain/Templin 15 minutes - draft-hain-templin-ipv6-localcomm-03.txt - Goal: discussion of open issues Wednesday (11/12/03) 1300-1500 ------------------------------ 1. Intro & Agenda Bashing chairs 5 minutes 2. Router Selection Thaler 10 minutes - draft-ietf-ipv6-router-selection-02.txt - Goal: issue discussion, next steps 3. Neighbor Discovery Updates Tatuya 15 minutes - draft-soliman-ipv6-2461-bis-00.txt - Goal: issue discussion 4. Stateless Autoconfiguration Updates Tatuya 15 minutes - draft-jinmei-ipv6-rfc2462bis-00.txt - Goal: issue discussion 5. Scoped Address Arch Document Tatuya 10 minutes - draft-ietf-ipv6-scoping-arch-00.txt - Goal: discussion of last call comments 6. SL Deprecation Document Carpenter 20 minutes - draft-ietf-ipv6-deprecate-site-local-01.txt - Goal: discussion of last call comments 7. ULA Document Hinden 15 minutes - draft-ietf-ipv6-unique-local-addr-01.txt - Goal: discussion of last call comments 8. Address Architecture Update Hinden 15 minutes - draft-ietf-ipv6-addr-arch-v4-00.txt - Goal: review changes and plan for moving forward 9. Identifier/Locator Separation Lindqvist 10 minutes --------------020001080304000006050605-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 11:10:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20436 for ; Fri, 7 Nov 2003 11:10:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9BF-0005zI-5E for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 11:09:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7G9nOg023017 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 11:09:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9BE-0005zA-PV for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 11:09:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20406 for ; Fri, 7 Nov 2003 11:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9BB-0006vO-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 11:09:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI9BB-0006vL-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 11:09:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9AT-0005s2-VL; Fri, 07 Nov 2003 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9A3-0005ri-GM for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 11:08:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20369 for ; Fri, 7 Nov 2003 11:08:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9A0-0006uY-00 for ipv6@ietf.org; Fri, 07 Nov 2003 11:08:32 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AI99z-0006u9-00 for ipv6@ietf.org; Fri, 07 Nov 2003 11:08:32 -0500 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id hA7G7dls029502; Sat, 8 Nov 2003 01:07:41 +0900 (KST) Message-ID: <008101c3a54a$5fc6e8a0$ec2f024b@tyre> From: "JinHyeock Choi" To: "Soliman Hesham" , "'Bound, Jim'" , References: <748C6D0A58C0F94CA63C198B6674697A01922EA0@ftmail.lab.flarion.com> Subject: Re: Issue 13: Omission of prefix options - resolution Date: Sat, 8 Nov 2003 01:15:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVzaGFtIFNvbGltYW4gd3JvdGU6IA0KDQpbT21pdHRlZF0gDQo+IEhhdmluZyBhIG5ldyBvcHRp b24gKG5vdCBzdWdnZXN0aW5nIHRvIGFkZCB0aGF0IHRvIDI0NjEpDQo+IGNhbGxlZCBhIExpbmtJ RCAoY291bGQgYmUgYSBnbG9iYWxseSB1bmlxdWUgYWRkcmVzcykgYW5kDQo+IGluY2x1ZGVkIGlu IGV2ZXJ5IFJBIHNlbnQgZnJvbSBhbGwgcm91dGVycyBvbiB0aGUgc2FtZSBsaW5rLCANCj4gd291 bGQgYWxsb3cgdGhlIHJvdXRlciB0byBzYXZlIG90aGVyIG9wdGlvbnMsIHdoaWxlIA0KPiBlbGlt aW5hdGluZyBtb3ZlbWVudCBkZXRlY3Rpb24gcHJvYmxlbXMuDQoNCkxpbmtJRCBzb2x1dGlvbiBj YW4gcHJldmVudCBNTiBmcm9tIGFzc3VtaW5nIG1vdmVtZW50IA0Kd2hpbGUgaXQgaGFzIG5vdC4g QnV0IEkgYW0gYWZyYWlkLCB3aGVuIGFuIE1OIGFjdHVhbGx5IG1vdmVzLCANCkxpbmtJRCBieSBp dHNlbGYgaXMgb2YgbGltaXRlZCB1c2UuICANCg0KQXNzdW1lIGFuIE1OIGFjdHVhbGx5IG1vdmVz IGludG8gYW5vdGhlciBsaW5rIGFuZCByZWNlaXZlcyANCmFuIHVuc29saWNpdGVkIFJBIHdpdGgg b25seSBMaW5rSUQuIFRvIGdldCBuZWNlc3NhcnkgcHJlZml4IA0KaW5mb3JtYXRpb24sIGFuIE1O IHNob3VsZCBwZXJmb3JtIGFkZGl0aW9uYWwgUlMvIFJBIGV4Y2hhbmdlLiANClRoaXMgd2lsbCB0 YWtlIHRpbWUgYmVjYXVzZSBhIHJvdXRlciBpcyBzdXBwb3NlZCB0byBleGVjdXRlIHJhbmRvbSAN CmRlbGF5IGJlZm9yZSBzZW5kaW5nIFJBLiANCg0KT3RoZXJ3aXNlLCBhZnRlciBtb3ZlbWVudCwg YW4gTU4gbWF5IHJlY2VpdmUgYSBsaW5rLWxheWVyIGhpbnQgDQpub3RpZnlpbmcgbGluay1sYXll ciBjaGFuZ2UuIFRoZW4gYW4gTU4gY2FuIHNlbnQgdHJpZ2dlcmVkIFJTIG1lc3NhZ2UgDQphbmQg d2lsbCByZWNlaXZlIGEgc29saWNpdGVkIFJBIHdpdGggYWxsIHRoZSBvcHRpb25zLiBJbiB0aGlz IGNhc2UsIExpbmtJRCANCnBsYXlzIGxpdHRsZSByb2xlLiAgDQoNCj4gQnV0IHNpbmNlIHRoZXJl IGlzIG5vIGNvbmNlbnN1cyBvbiB0aGUgc29sdXRpb24gKHNvbWUgcHJlZmVyDQo+IHRoZSAiY29t cGxldGUgYml0IiksIG9yIGl0cyBpbmNsdXNpb24gaW4gMjQ2MSAoVnMgRE5BIG9yIA0KPiBhbm90 aGVyIElQdjYgZHJhZnQpLCANCg0KSSBhZ3JlZSB3aXRoIHNpZ2guIA0KDQo+IGl0IHNlZW1zIGxp a2Ugd2Ugc2hvdWxkIGVpdGhlciByZWplY3QNCj4gdGhpcyBpc3N1ZSBvciBkZWxheSB0aGUgZGlz Y3Vzc2lvbiB1bnRpbCB3ZSByZXNvbHZlDQo+IGFsbCB0aGUgb3RoZXIgaXNzdWVzIGFuZCBob3Bl IHRoYXQgb3BpbmlvbnMgaGF2ZSBjb252ZXJnZWQNCj4gYnkgdGhhdCB0aW1lLg0KDQpJIGFncmVl LiBXZSBuZWVkIG1vcmUgZWxhYm9yYXRpb24gYW5kIElQdjYgV0cgbWF5IG5vdCBiZSB0aGUgYmVz dCANCnBsYWNlIGZvciB0aGlzLiANCg0KSSBoYXZlIG9uZSBxdWVzdGlvbi4gSXMgaXQgcG9zc2li bGUgZm9yIHVzIHRvIGRlZmluZSBjb21wbGV0ZSBiaXQgaW4gRE5BPyANCg0KPj4gSSBiZWxpZXZl IGFuIElFVEYgc3BlYyBjYW4gZXh0ZW5kIGEgY29yZSBzcGVjIGFuZCBpdCBqdXN0IG5lZWRzIHRv IGJlDQo+PiByZXZpZXdlZCBieSB0aGF0IGNvcmUgc3BlYyBjZW50ZXIgb2YgZXhwZXJ0aXNlIHdp dGhvdXQgYWRkaW5nIHRvIHRoZQ0KPj4gY29yZSBzcGVjLiAgDQoNCkFzIEppbSB3cm90ZSBhYm92 ZSwgaWYgRE5BIHNwZWMgY2FuIGV4dGVuZCBhIGNvcmUgc3BlYywgUkZDIDI0NjEsIA0KaXQncyBP LksuIGZvciBtZSB0byBjbG9zZSB0aGlzIGlzc3VlLiANCg0KSWYgbm90LCBJIGFtIGZvciB0aGUg ZGVsYXkuIA0KDQpCZXN0IHJlZ2FyZHMNCg0KSmluSHllb2NrIA== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 14:29:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03037 for ; Fri, 7 Nov 2003 14:29:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICIb-0001aW-2F for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 14:29:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7JTbq6006100 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 14:29:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICIa-0001aI-Qg for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:29:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02993 for ; Fri, 7 Nov 2003 14:29:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICIY-0001kc-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 14:29:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICIX-0001kZ-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 14:29:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICI1-0001TU-IS; Fri, 07 Nov 2003 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICHu-0001TD-2P for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 14:28:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02973 for ; Fri, 7 Nov 2003 14:28:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICHq-0001k7-00 for ipv6@ietf.org; Fri, 07 Nov 2003 14:28:50 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AICHq-0001k4-00 for ipv6@ietf.org; Fri, 07 Nov 2003 14:28:50 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7AAE4FD1B; Fri, 7 Nov 2003 14:28:50 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 14:28:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 13: Omission of prefix options - resolution Date: Fri, 7 Nov 2003 14:28:49 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B051225E4@tayexc13.americas.cpqcorp.net> Thread-Topic: Issue 13: Omission of prefix options - resolution Thread-Index: AcOlDDINhYeS8vXUQz+zAoesf3dcRgAV0NCw From: "Bound, Jim" To: "Soliman Hesham" , X-OriginalArrivalTime: 07 Nov 2003 19:28:50.0298 (UTC) FILETIME=[5F23FDA0:01C3A565] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > =3D> I should have described the scenario a bit better.=20 > This is a case where hosts need to know whether they have=20 > changed links or not. The only way we know that today is=20 > through the contents of the RA.=20 Thats a pretty good indication and definite detection at layer 3.=20 Just for clarification that is the MIPv6 R bit set so we are on same page. > Hosts today use the prefixes=20 > advertised (or not) as an input to the movement detection=20 > algorithm amongst other things. The prefixes advertized should not be used that way. The MN must use the R bit. I do not support making MNs work by changing this in 2461. MNs will not work at layer 3 until either ND with R bit, FMIP, or HMIP is deployed. =20 That is life all have to deal with it. Thats my position. Or I do believe layer 2 notification works. > There are different flavours=20 > of movement detection depending on how conservative an=20 > implementor wants=20 > to be. But in all those flavours, the prefix option (or absence > of) may well trigger the algorithm. That is a bogus assumption and inaccurate reading of the spec. That is what we call in an implmeentation ill-behaved code. The L bit was never mean't to do this and an implementor should not assume such things in a spec to use or accept the penalty later. =20 =20 >=20 > I don't have a strong opinion on whether this should go into=20 > 2461bis or not. But I do think that there is a problem.=20 What problem. You don't like the ND R bit? > Another consideration is how _real_ this problem is. Does=20 > anyone know of=20 > a router implementation that sometimes does not advertise=20 > all options to save BW ?=20 This is totally irrelevant. The L bit is very clear and if offers one or infinity prefixes is not the point of the technical interpetation issue. The L bit was not mean't as a feature for movement detection ever. Assuming that is a mistake. >=20 > > What problem is this addition trying to fix or solve? =20 > >=20 > > I have read the draft below and believe the core issue is=20 > resolved. > What prefixes are supplied is in the system not=20 > the host or=20 > > why not just > > use DHCPv6? =20 >=20 > =3D> DHCPv6 can be used, but in order to trigger DHCPv6 a host=20 > needs to know that it has changed links. Otherwise it will be=20 > triggered unnecessarily.=20 You misread my comment. I am not advocating DHCPv6 but was using juxtaposition to point out that the L bit is key for what it does on the link and that is not to support any form of movement detection but for optimization of the link. That is all. >=20 > I think we cannot and must not overrule the essential > > meaning of the A and M bits. >=20 > =3D> Agreed. We won't do that. Good. >=20 > >=20 > > In fact I suggest in additon to each member of this list a=20 > problem > statement be stated for each change to 2461. >=20 > =3D> I'll try to cover that briefly in a "background" section=20 > when I send a suggestion to resolve an issue. We went on this thread first thinking prefixes could be duplicated on two links, now to reinventing what the L bit is and does. But you did not respond to a very important issue in this mail thread. The mechanism defined as standard (waiting for RFC) in MIPv6 ND extension to address movement detection at layer 3 is the R bit for the RA. What I am hearing is some don't want to wait for that to be deployed. And we can use the end result of the L bit to do end run around needing the R bit and I disagree. This WG supported MIPv6 to use the R bit and it will work. Until that is deployed then MNs won't be deployed.=20 Another issue is with L bit set and just one prefix is provided and MN sees it then it knows it is hearing the RA thus a new link. 1+N prefixes is irrelevant for movement detection. =20 Good discussion. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 14:49:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03776 for ; Fri, 7 Nov 2003 14:49:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICbc-0003XO-Cw for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 14:49:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7JnGtD013592 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 14:49:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICbc-0003X9-8k for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:49:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03741 for ; Fri, 7 Nov 2003 14:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICbZ-00022M-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 14:49:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICbZ-00022J-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 14:49:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICbO-0003RL-Gj; Fri, 07 Nov 2003 14:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICaz-0003Qx-5c for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 14:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03721 for ; Fri, 7 Nov 2003 14:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICav-00021k-00 for ipv6@ietf.org; Fri, 07 Nov 2003 14:48:33 -0500 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1AICav-00021h-00 for ipv6@ietf.org; Fri, 07 Nov 2003 14:48:33 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3FD72139DB; Fri, 7 Nov 2003 14:48:33 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 14:48:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 13: Omission of prefix options - resolution Date: Fri, 7 Nov 2003 14:48:32 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA237@tayexc13.americas.cpqcorp.net> Thread-Topic: Issue 13: Omission of prefix options - resolution Thread-Index: AcOlGt8ecp74qwpoRgizIuFgerWuhgASqqCw From: "Bound, Jim" To: "Soliman Hesham" , X-OriginalArrivalTime: 07 Nov 2003 19:48:33.0018 (UTC) FILETIME=[2018BDA0:01C3A568] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hesham, =20 > > The reason it is good to not use it is when one does not=20 > > want to make an > > annoucement of all prefixes on a Link and force NS's. =20 >=20 > =3D> Completely understand, but I was not referring to the L > bit in my email, I was referring to the disappearance > of the _entire_ prefix option.=20 Who said the prefix option is disappearing? Its part of the standard. The L bit can be NOT SET too. >=20 > I happen to agree with a few people that the best solution > to this problem is to introduce the LinkID which makes > it much simpler to detect movement.=20 Thats fine but do it in DNA or some other focus group on movement detection is my point and it should not be listed as issue for 2461bis here at this point is my view. >=20 > The R bit defined in MIPv6 solves > > the problem below. When the node reaches the link it will=20 > > hear the new > > RA with R bit set and new router prefix. So what has to=20 > > happen is MIPv6 > > routers have to be turned on to deploy. But that is ok=20 > > because without > > MIPv6 routers MIPv6 won't work :--) >=20 > =3D> Sure. But in the scenario discussed in this issue,=20 > the whole prefix option disappears. Therefore, there is > no R bit either. Why and how. Then one is saying drop the ND msg to support the R bit? Thats absurd. It is part of MIPv6 and going to PS. Un-confuse me? > The question is if some router designer=20 > decided to save BW and not advertise all options all the=20 > time. The MN first hears Prefix1 and Prefix2 (from one or two=20 > routers doesn't matter). It derives a CoA based on Prefix1.=20 Ok here we go again. That is is a bogus router and not participative of MIPv6.=20 I could come up with scenarios like this for TCP, Telenet, NFS, etc etc. We have to assume products that support MIPv6 will do what they are suppose to do. > The next adv contains Prefix2 only (because its timer was=20 > about to expire and therefore had to be advertised again,=20 > while prefix1 didn't need to. But either prefix will provide movment detection it is the absence of the prefix that is the problem and that is the absence of a valid participating router. Ergo broken network configuration for MIPv6 deployment. Simple replace the router with one that knows how to operate to support MNs via MIPv6. We don't add yet more options to specs in the IETF to do end run around bogus products. >Or because there were two=20 > routers and one of them decided=20 > that it doesn't need to advertise its prefix this time).=20 This is called routers being in synch again a deployment issue, not anything broken in ND and MIPv6. We decided I guess long ago to not put the same config controls on routers we do hosts for whatever reason and this is the end result.=20 > Now, this might force a movement detection implementation > to think that it _might_ have moved. Depending on how=20 > "conservative" that implemenation is, the reaction will vary > from: "form a new CoA based on prefix2" (not conservative) to=20 > "check that prefix1 and default router are still alive"=20 > (conservative).=20 > If the MN hadn't moved at all (as is the case in this=20 > example), neither action is desirable.=20 This is why we cannot ignore detection without layer 2 and I stated that on the first thread. It is quicker than getting new options like a link-id it is a very fast lookup to see if I had a link state change at layer 2. But this should not happen if the routers are in synch. And only one router should be sending prefixes with the R bit make that policy. >=20 > Having a new option (not suggesting to add that to 2461) > called a LinkID (could be a globally unique address) and=20 > included in every RA sent from all routers on the same link,=20 > would allow the router to save other options, while=20 > eliminating movement detection problems. That is to much overhead for all routers add it just to when the R bit is used and put it in MD or DNA spec. But having only one router permitted to send RA with R bit solves it too. >=20 > But since there is no concensus on the solution (some prefer=20 > the "complete bit"), or its inclusion in 2461 (Vs DNA or=20 > another IPv6 draft), it seems like we should either reject > this issue or delay the discussion until we resolve > all the other issues and hope that opinions have converged > by that time. We have to wait then. But I will add the other one and that is make a policy. >=20 > > Help me here I think this is pretty basic stuff :--) =20 >=20 > =3D> Hope this helps :) =20 Yes but it still comes down to where the most efficient scalable fix is and that requires more discussion this is not ready for 2461biz. thanks /jim >=20 > Hesham >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 15:22:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05847 for ; Fri, 7 Nov 2003 15:22:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID7Z-0005Of-3k for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 15:22:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7KMHKd020739 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 15:22:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID7Y-0005OQ-Tu for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:22:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05779 for ; Fri, 7 Nov 2003 15:22:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AID7X-0002PK-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 15:22:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AID7X-0002PH-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 15:22:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID7J-0005IK-1i; Fri, 07 Nov 2003 15:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID6d-0005HS-G9 for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 15:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05688 for ; Fri, 7 Nov 2003 15:21:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AID6c-0002Ot-00 for ipv6@ietf.org; Fri, 07 Nov 2003 15:21:18 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AID6a-0002OY-00 for ipv6@ietf.org; Fri, 07 Nov 2003 15:21:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA7KKIw13200; Fri, 7 Nov 2003 12:20:18 -0800 X-mProtect: <200311072020> Nokia Silicon Valley Messaging Protection Received: from danira-pool051144.americas.nokia.com (10.241.51.144, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIvIM2g; Fri, 07 Nov 2003 12:20:16 PST Message-ID: <3FABFE75.5000206@iprg.nokia.com> Date: Fri, 07 Nov 2003 12:20:05 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: Soliman Hesham , ipv6@ietf.org Subject: the real issue (was Re: Issue 13: Omission of prefix options - resolution) References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA237@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA237@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am not sure what is being discussed here. I am confused... Neighbor Discovery as it is today is kind of very very unfriendly for movement detection (and therefore mobile nodes). just to make it clear, Mobile IPv6 spec currently is quite conservative when it comes to movement detection. there were a bunch of mechanisms in the earlier Mobile IPv6 drafts which would have made faster movement detection possibly. these mechanism included a lot of changes to the ND specs. they were all removed from the spec (I wont go into why they were removed). a new WG called "Detecting Network Attachment" (DNA) is being chartered to work on faster movement detection. absence of prefix information (that the mobile node saw earlier) is not used for movement detection currently. but it is considered as one of the hints that the mobile node may have moved. there are weak hints and strong hits. this for example is a weak hint. an L2 trigger for example is a strong hint. weak hints are always ambiguous. the mobile node has to do additional steps to confirm if it has moved. if the routers always include all prefix information in the router advertisement, it makes it *easier* for movement detection by eliminating a weak hint. the complete bit is one solution for this. if the bit is set, it means all the prefixes for that particular link are included in the router advertisement. but this has some backward compatibility issues. the linkid, where each router includes a linkid in the router advertisement the linkid being unique for each link), is another solution. I guess this issue can be handled in the DNA WG, when it is formed. but if DNA WG modifies/extends Neigbor Discovery specs, I hope the IPv6 WG would be receptive to these changes. my previous experience shows this is not the case, unfortunately. :( Vijay Bound, Jim wrote: > Hesham, > > > >> > The reason it is good to not use it is when one does not >> > want to make an >> > annoucement of all prefixes on a Link and force NS's. >> >>=> Completely understand, but I was not referring to the L >>bit in my email, I was referring to the disappearance >>of the _entire_ prefix option. > > > Who said the prefix option is disappearing? Its part of the standard. > > The L bit can be NOT SET too. > > >>I happen to agree with a few people that the best solution >>to this problem is to introduce the LinkID which makes >>it much simpler to detect movement. > > > Thats fine but do it in DNA or some other focus group on movement > detection is my point and it should not be listed as issue for 2461bis > here at this point is my view. > > > >> The R bit defined in MIPv6 solves >> > the problem below. When the node reaches the link it will >> > hear the new >> > RA with R bit set and new router prefix. So what has to >> > happen is MIPv6 >> > routers have to be turned on to deploy. But that is ok >> > because without >> > MIPv6 routers MIPv6 won't work :--) >> >>=> Sure. But in the scenario discussed in this issue, >>the whole prefix option disappears. Therefore, there is >>no R bit either. > > > Why and how. Then one is saying drop the ND msg to support the R bit? > Thats absurd. It is part of MIPv6 and going to PS. Un-confuse me? > > >>The question is if some router designer >>decided to save BW and not advertise all options all the >>time. The MN first hears Prefix1 and Prefix2 (from one or two >>routers doesn't matter). It derives a CoA based on Prefix1. > > > Ok here we go again. That is is a bogus router and not participative of > MIPv6. > I could come up with scenarios like this for TCP, Telenet, NFS, etc etc. > We have to assume products that support MIPv6 will do what they are > suppose to do. > > > >>The next adv contains Prefix2 only (because its timer was >>about to expire and therefore had to be advertised again, >>while prefix1 didn't need to. > > > But either prefix will provide movment detection it is the absence of > the prefix that is the problem and that is the absence of a valid > participating router. Ergo broken network configuration for MIPv6 > deployment. Simple replace the router with one that knows how to > operate to support MNs via MIPv6. We don't add yet more options to > specs in the IETF to do end run around bogus products. > > >>Or because there were two >>routers and one of them decided >>that it doesn't need to advertise its prefix this time). > > > This is called routers being in synch again a deployment issue, not > anything broken in ND and MIPv6. We decided I guess long ago to not put > the same config controls on routers we do hosts for whatever reason and > this is the end result. > > >>Now, this might force a movement detection implementation >>to think that it _might_ have moved. Depending on how >>"conservative" that implemenation is, the reaction will vary >>from: "form a new CoA based on prefix2" (not conservative) to >>"check that prefix1 and default router are still alive" >>(conservative). >>If the MN hadn't moved at all (as is the case in this >>example), neither action is desirable. > > > This is why we cannot ignore detection without layer 2 and I stated that > on the first thread. It is quicker than getting new options like a > link-id it is a very fast lookup to see if I had a link state change at > layer 2. > > But this should not happen if the routers are in synch. > > And only one router should be sending prefixes with the R bit make that > policy. > > >>Having a new option (not suggesting to add that to 2461) >>called a LinkID (could be a globally unique address) and >>included in every RA sent from all routers on the same link, >>would allow the router to save other options, while >>eliminating movement detection problems. > > > That is to much overhead for all routers add it just to when the R bit > is used and put it in MD or DNA spec. But having only one router > permitted to send RA with R bit solves it too. > > >>But since there is no concensus on the solution (some prefer >>the "complete bit"), or its inclusion in 2461 (Vs DNA or >>another IPv6 draft), it seems like we should either reject >>this issue or delay the discussion until we resolve >>all the other issues and hope that opinions have converged >>by that time. > > > We have to wait then. But I will add the other one and that is make a > policy. > > >> > Help me here I think this is pretty basic stuff :--) >> >>=> Hope this helps :) > > > Yes but it still comes down to where the most efficient scalable fix is > and that requires more discussion this is not ready for 2461biz. > > thanks > /jim > > >>Hesham >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 7 15:33:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06553 for ; Fri, 7 Nov 2003 15:33:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDIX-00068P-2Z for ipv6-archive@odin.ietf.org; Fri, 07 Nov 2003 15:33:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7KXbw9023580 for ipv6-archive@odin.ietf.org; Fri, 7 Nov 2003 15:33:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDIW-00068F-IO for ipv6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:33:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06524 for ; Fri, 7 Nov 2003 15:33:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDIV-0002Yr-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 15:33:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDIU-0002Yo-00 for ipv6-web-archive@ietf.org; Fri, 07 Nov 2003 15:33:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDHy-00062R-3y; Fri, 07 Nov 2003 15:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDHm-00062B-6X for ipv6@optimus.ietf.org; Fri, 07 Nov 2003 15:32:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06511 for ; Fri, 7 Nov 2003 15:32:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDHk-0002YZ-00 for ipv6@ietf.org; Fri, 07 Nov 2003 15:32:48 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDHj-0002YW-00 for ipv6@ietf.org; Fri, 07 Nov 2003 15:32:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA7KWE304433; Fri, 7 Nov 2003 22:32:14 +0200 Date: Fri, 7 Nov 2003 22:32:13 +0200 (EET) From: Pekka Savola Reply-To: v6ops@ops.ietf.org To: v6ops@ops.ietf.org cc: ipv6@ietf.org Subject: SUMMARY: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, I'll try to summarize this thread, or at least try to find the most important points from it, because it went on for long and I doubt many had energy enough to keep up with it. (more accurately, I'll just summarize the first part of the thread that was integral to the original topic, see the last point) I believe we should try to avoid crossposting about this subject to both v6ops and ipv6 WG in the future :-). - this seems like a problem that would merit from further investigation - it was not sufficiently clear that this mechanism is about optimizing away unnecessary DNS lookups and making them more robust (e.g. in the face of DNS/load-balancer misbehaviour); default address selection does not help in this case (however, if destination address selection is not implemented, this method would give an additional benefit as well) - currently defined AI_ADDRCONFIG is rather vague, and it should be clarified in any case (e.g., "is address without route OK?") if it's intended to be usable ("too ambiguous to implement") - the problem description (by yours truly) was not sufficiently clear, so it wasn't clear what problems the proposed modifications were trying to address - some application writers are moving away / staying away from getaddrinfo because of the side-effects of e.g. DNS resolvers/load-balancers, also for the majority installed base of IPv4-only and dual-stack (but without v6 connectivity) systems; this option would help a bit there. - a system-level global knob, in addition to an application getaddrinfo hint, could be useful, but this should probably default to off at least (the point below) - the default application behaviour should not be changed, that is, AI_ADDRCONFIG should remain optional; the getaddrinfo/system should not try to second-guess what an application wants, nor hide information that exists in the DNS unless the application indicates it wants the information filtered - if sufficiently many people think link-locals w/ getaddrinfo would be a useful feature, a tradeoffs document instead of a purely recommendations document would be in order - this does not change the situation in the case where a route exists, but an ICMP DU is received (v6onbydefault-00 section 3.2 discusses this), or the case when the packets are silently dropped (e.g. by a discarding firewall) - the latter parts of the thread went into an area ("getaddrinfo should use DNS-only vs not") beyond the main scope of the original topic, and are not included in this thread summary; suffice to say that opinions differ on whether getaddrinfo should be agnostic of the lookup mechanism or not. However, this does have a connection to the original debate: the addition of the link-locals to AI_ADDRCONFIG would cause problems if getaddrinfo was used with local lookup services (or similar) other than the DNS. So, for the purposes of AI_ADDRCONFIG and link-locals, the link local exclusion should probably be limited to DNS or other similar naming services, if done. ---------- Forwarded message ---------- Date: Tue, 28 Oct 2003 14:30:05 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Cc: ipv6@ietf.org Subject: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Hi, (Cc:'ed to ipv6@ietf.org as well, because this seems to have significant impact with the IPv6 APIs as well..) When revising my "transarch" document, I noticed another issue v6 on-by-default might cause. If v6 is enabled by default, all the implementations I know generate the link-local addresses for all the interfaces automatically, unless explicitly configured otherwise (some don't have this knob). This seems to cause an unintended consequence with getaddrinfo and its AI_ADDRCONFIG hint (as specified in the basic socket API RFC). That is, AI_ADDRCONFIG hint causes AAAA DNS queries to be made only if an IPv6 address is configured on the node (similar with v4). Loopback addresses are excluded from this. However, these typically autoconfigured link-local addresses are *not* excluded. In consequence, AI_ADDRCONFIG seems to be of less utility than at least I had hoped. The only reason I could think of for AI_ADDRCONFIG *not* excluding the link-locals as well could be that if a node is expected to be able to communicate using regular, getaddrinfo() -using apps, using the link-local addresses (this would eliminate this possibility). IMHO, using link-local addresses for anything except well-specified purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really counter-productive -- as you'll have to make those apps be able to distinguish the zone identifiers as well, and that's probably something we DON'T want to do. But your mileage may vary. So, I'll conclude by a few questions to give food for thought: - does this seem like a problem, that is, should getaddrinfo() + AI_ADDRCONFIG perform AAAA DNS queries etc. if the node only has v6 link-local/loopback addresses? - is getaddrinfo() + link-local addresses something we should support? - should this be fixed by e.g.: a) recommending that the implementations filter out link-locals as well when doing AI_ADDRCONFIG (a BCP/Info document) b) specifying additional semantics for AI_ADDRCONFIG c) specifying a new hint which would perform this Note: if we go select any of these (especially the latter two), it might make sense to bring this discussion up in the relevant API forums like POSIX as well, because the IETF API documents are just Informational RFCs. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 8 01:03:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24191 for ; Sat, 8 Nov 2003 01:03:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMBT-0001hI-68 for ipv6-archive@odin.ietf.org; Sat, 08 Nov 2003 01:02:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA862t3C006520 for ipv6-archive@odin.ietf.org; Sat, 8 Nov 2003 01:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMBT-0001h5-18 for ipv6-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 01:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24165 for ; Sat, 8 Nov 2003 01:02:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMBP-0001fl-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 01:02:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIMBP-0001fi-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 01:02:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMAd-0001b4-Aw; Sat, 08 Nov 2003 01:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIM9j-0001Y4-FY for ipv6@optimus.ietf.org; Sat, 08 Nov 2003 01:01:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24120 for ; Sat, 8 Nov 2003 01:00:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIM9f-0001ee-00 for ipv6@ietf.org; Sat, 08 Nov 2003 01:01:03 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AIM9f-0001dq-00 for ipv6@ietf.org; Sat, 08 Nov 2003 01:01:03 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sat, 8 Nov 2003 01:00:31 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EA5@ftmail.lab.flarion.com> From: Soliman Hesham To: "'JinHyeock Choi'" , "'Bound, Jim'" , ipv6@ietf.org Subject: RE: Issue 13: Omission of prefix options - resolution Date: Sat, 8 Nov 2003 01:00:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > LinkID solution can prevent MN from assuming movement > while it has not. But I am afraid, when an MN actually moves, > LinkID by itself is of limited use. > > Assume an MN actually moves into another link and receives > an unsolicited RA with only LinkID. To get necessary prefix > information, an MN should perform additional RS/ RA exchange. > This will take time because a router is supposed to execute random > delay before sending RA. > > Otherwise, after movement, an MN may receive a link-layer hint > notifying link-layer change. Then an MN can sent triggered > RS message > and will receive a solicited RA with all the options. In > this case, LinkID > plays little role. => So does the complete bit if you assume that routers follow the recommendation of 2461 of sending a complete RA when solicited. But in any case, the LinkID does not play a limited role in the above scenario, it plays the role of confirming that a MN has moved. It doesn't solve all problems, but it is certainly a strong indication of movement. You substituted it with the L2 trigger in naothe scenario but it's worth noting that the L2 trigger is not as strong an indication as the LinkID because it does not necessarily indicate IP mobility. > > it seems like we should either reject > > this issue or delay the discussion until we resolve > > all the other issues and hope that opinions have converged > > by that time. > > I agree. We need more elaboration and IPv6 WG may not be the best > place for this. > > I have one question. Is it possible for us to define > complete bit in DNA? => Of course. MIPv6 extended ND in the MIPv6 specification. There is no reason why any WG in IETF can do the same. > As Jim wrote above, if DNA spec can extend a core spec, RFC 2461, > it's O.K. for me to close this issue. => New options/extensions can be defined in a separate spec for sure. Thanks! Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 8 01:49:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25502 for ; Sat, 8 Nov 2003 01:49:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMuI-0004UI-2q for ipv6-archive@odin.ietf.org; Sat, 08 Nov 2003 01:49:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA86nEH1017244 for ipv6-archive@odin.ietf.org; Sat, 8 Nov 2003 01:49:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMuH-0004U3-T1 for ipv6-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 01:49:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25473 for ; Sat, 8 Nov 2003 01:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMuE-0002No-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 01:49:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIMuE-0002Nl-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 01:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMu7-0004OA-Ot; Sat, 08 Nov 2003 01:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMtr-0004Ns-T3 for ipv6@optimus.ietf.org; Sat, 08 Nov 2003 01:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25464 for ; Sat, 8 Nov 2003 01:48:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMto-0002Nb-00 for ipv6@ietf.org; Sat, 08 Nov 2003 01:48:44 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMtn-0002ND-00 for ipv6@ietf.org; Sat, 08 Nov 2003 01:48:43 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA86m0D13510; Sat, 8 Nov 2003 08:48:00 +0200 Date: Sat, 8 Nov 2003 08:48:00 +0200 (EET) From: Pekka Savola To: Vijay Devarapalli cc: "Bound, Jim" , Soliman Hesham , Subject: Re: the real issue (was Re: Issue 13: Omission of prefix options - resolution) In-Reply-To: <3FABFE75.5000206@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, 7 Nov 2003, Vijay Devarapalli wrote: > the complete bit is one solution for this. if the bit is set, it > means all the prefixes for that particular link are included in the > router advertisement. but this has some backward compatibility > issues. Was this really what we talked about?? I think we were discussing a Complete bit which would say "I didn't omit any prefixes". Whether a router on a link can administratively assure that all the prefixes ever to be seen on a physical link are included is IMO a completely separate topic. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 8 07:24:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14731 for ; Sat, 8 Nov 2003 07:24:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIS80-0003Yg-8G for ipv6-archive@odin.ietf.org; Sat, 08 Nov 2003 07:23:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8CNiYf013675 for ipv6-archive@odin.ietf.org; Sat, 8 Nov 2003 07:23:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIS80-0003YU-1I for ipv6-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 07:23:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14697 for ; Sat, 8 Nov 2003 07:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIS7z-0006Jg-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 07:23:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIS7z-0006Jc-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 07:23:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIS7J-0003TD-NB; Sat, 08 Nov 2003 07:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIS7E-0003Su-MH for ipv6@optimus.ietf.org; Sat, 08 Nov 2003 07:22:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14663 for ; Sat, 8 Nov 2003 07:22:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIS7E-0006J5-00 for ipv6@ietf.org; Sat, 08 Nov 2003 07:22:56 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AIS7D-0006Is-00 for ipv6@ietf.org; Sat, 08 Nov 2003 07:22:55 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sat, 8 Nov 2003 07:22:22 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EA9@ftmail.lab.flarion.com> From: Soliman Hesham To: "'JinHyeock Choi'" , "'Bound, Jim'" , ipv6@ietf.org Subject: RE: Issue 13: Omission of prefix options - resolution Date: Sat, 8 Nov 2003 07:22:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Fatal typo below ;) > > I have one question. Is it possible for us to define > > complete bit in DNA? > > => Of course. MIPv6 extended ND in the MIPv6 specification. > There is no reason why any WG in IETF can do the same. => ^^ should be: cannot do the same Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 8 22:33:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05528 for ; Sat, 8 Nov 2003 22:33:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIgKA-00040I-LE for ipv6-archive@odin.ietf.org; Sat, 08 Nov 2003 22:33:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA93XElK015384 for ipv6-archive@odin.ietf.org; Sat, 8 Nov 2003 22:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIgKA-000403-8W for ipv6-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 22:33:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05493 for ; Sat, 8 Nov 2003 22:33:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIgK6-0001hG-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 22:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIgK6-0001h7-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 22:33:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIgJ0-0003sh-NZ; Sat, 08 Nov 2003 22:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIgId-0003sD-Lq for ipv6@optimus.ietf.org; Sat, 08 Nov 2003 22:31:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05483 for ; Sat, 8 Nov 2003 22:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIgIa-0001go-00 for ipv6@ietf.org; Sat, 08 Nov 2003 22:31:36 -0500 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1AIgIZ-0001gl-00 for ipv6@ietf.org; Sat, 08 Nov 2003 22:31:35 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9FF70A161; Sat, 8 Nov 2003 22:31:34 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 8 Nov 2003 22:31:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: the real issue (was Re: Issue 13: Omission of prefix options - resolution) Date: Sat, 8 Nov 2003 22:31:33 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122616@tayexc13.americas.cpqcorp.net> Thread-Topic: the real issue (was Re: Issue 13: Omission of prefix options - resolution) Thread-Index: AcOlbJ2i/80IJ69hQjmWyPqSxTLfJwBBTsQw From: "Bound, Jim" To: "Vijay Devarapalli" Cc: "Soliman Hesham" , X-OriginalArrivalTime: 09 Nov 2003 03:31:34.0435 (UTC) FILETIME=[F9864F30:01C3A671] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable IPv6 has been receptive to all changes. How fast they accept them is directly proportional to the way it is presented to them. /jim > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 > Sent: Friday, November 07, 2003 3:20 PM > To: Bound, Jim > Cc: Soliman Hesham; ipv6@ietf.org > Subject: the real issue (was Re: Issue 13: Omission of prefix=20 > options - resolution) >=20 >=20 > I am not sure what is being discussed here. I am confused... >=20 > Neighbor Discovery as it is today is kind of very very=20 > unfriendly for movement detection (and therefore mobile nodes). >=20 > just to make it clear, Mobile IPv6 spec currently is quite=20 > conservative when it comes to movement detection. there were=20 > a bunch of mechanisms in the earlier Mobile IPv6 drafts which=20 > would have made faster movement detection possibly. these=20 > mechanism included a lot of changes to the ND specs. they=20 > were all removed from the spec (I wont go into why they were=20 > removed). a new WG called "Detecting Network Attachment"=20 > (DNA) is being chartered to work on faster movement detection. >=20 > absence of prefix information (that the mobile node saw=20 > earlier) is not used for movement detection currently. but it=20 > is considered as one of the hints that the mobile node may=20 > have moved. there are weak hints and strong hits. this for=20 > example is a weak hint. an L2 trigger for example is a strong=20 > hint. weak hints are always ambiguous. the mobile node has to=20 > do additional steps to confirm if it has moved. >=20 > if the routers always include all prefix information in the=20 > router advertisement, it makes it *easier* for movement=20 > detection by eliminating a weak hint. >=20 > the complete bit is one solution for this. if the bit is set,=20 > it means all the prefixes for that particular link are=20 > included in the router advertisement. but this has some=20 > backward compatibility issues. >=20 > the linkid, where each router includes a linkid in the router=20 > advertisement the linkid being unique for each link), is=20 > another solution. >=20 > I guess this issue can be handled in the DNA WG, when it is=20 > formed. but if DNA WG modifies/extends Neigbor Discovery=20 > specs, I hope the IPv6 WG would be receptive to these=20 > changes. my previous experience shows this is not the case,=20 > unfortunately. :( >=20 > Vijay >=20 > Bound, Jim wrote: > > Hesham, > >=20 > > =20 > >=20 > >> > The reason it is good to not use it is when one does not > >> > want to make an > >> > annoucement of all prefixes on a Link and force NS's. =20 > >> > >>=3D> Completely understand, but I was not referring to the L=20 > bit in my=20 > >>email, I was referring to the disappearance of the _entire_ prefix=20 > >>option. > >=20 > >=20 > > Who said the prefix option is disappearing? Its part of=20 > the standard. > >=20 > > The L bit can be NOT SET too. > >=20 > >=20 > >>I happen to agree with a few people that the best solution > >>to this problem is to introduce the LinkID which makes > >>it much simpler to detect movement. > >=20 > >=20 > > Thats fine but do it in DNA or some other focus group on movement=20 > > detection is my point and it should not be listed as issue=20 > for 2461bis=20 > > here at this point is my view. > >=20 > >=20 > >=20 > >> The R bit defined in MIPv6 solves > >> > the problem below. When the node reaches the link it will > >> > hear the new > >> > RA with R bit set and new router prefix. So what has to=20 > >> > happen is MIPv6 > >> > routers have to be turned on to deploy. But that is ok=20 > >> > because without > >> > MIPv6 routers MIPv6 won't work :--) > >> > >>=3D> Sure. But in the scenario discussed in this issue, > >>the whole prefix option disappears. Therefore, there is > >>no R bit either. > >=20 > >=20 > > Why and how. Then one is saying drop the ND msg to support=20 > the R bit?=20 > > Thats absurd. It is part of MIPv6 and going to PS. Un-confuse me? > >=20 > >=20 > >>The question is if some router designer > >>decided to save BW and not advertise all options all the=20 > >>time. The MN first hears Prefix1 and Prefix2 (from one or two=20 > >>routers doesn't matter). It derives a CoA based on Prefix1.=20 > >=20 > >=20 > > Ok here we go again. That is is a bogus router and not=20 > participative=20 > > of MIPv6. I could come up with scenarios like this for TCP,=20 > Telenet,=20 > > NFS, etc etc. We have to assume products that support MIPv6 will do=20 > > what they are suppose to do. > >=20 > >=20 > >=20 > >>The next adv contains Prefix2 only (because its timer was > >>about to expire and therefore had to be advertised again,=20 > >>while prefix1 didn't need to. > >=20 > >=20 > > But either prefix will provide movment detection it is the=20 > absence of=20 > > the prefix that is the problem and that is the absence of a valid=20 > > participating router. Ergo broken network configuration for MIPv6=20 > > deployment. Simple replace the router with one that knows how to > > operate to support MNs via MIPv6. We don't add yet more options to > > specs in the IETF to do end run around bogus products. > >=20 > >=20 > >>Or because there were two > >>routers and one of them decided=20 > >>that it doesn't need to advertise its prefix this time).=20 > >=20 > >=20 > > This is called routers being in synch again a deployment issue, not=20 > > anything broken in ND and MIPv6. We decided I guess long=20 > ago to not=20 > > put the same config controls on routers we do hosts for whatever=20 > > reason and this is the end result. > >=20 > >=20 > >>Now, this might force a movement detection implementation > >>to think that it _might_ have moved. Depending on how > >>"conservative" that implemenation is, the reaction will vary > >>from: "form a new CoA based on prefix2" (not conservative) to=20 > >>"check that prefix1 and default router are still alive"=20 > >>(conservative).=20 > >>If the MN hadn't moved at all (as is the case in this=20 > >>example), neither action is desirable.=20 > >=20 > >=20 > > This is why we cannot ignore detection without layer 2 and I stated=20 > > that on the first thread. It is quicker than getting new=20 > options like=20 > > a link-id it is a very fast lookup to see if I had a link=20 > state change=20 > > at layer 2. > >=20 > > But this should not happen if the routers are in synch. > >=20 > > And only one router should be sending prefixes with the R bit make=20 > > that policy. > >=20 > >=20 > >>Having a new option (not suggesting to add that to 2461) called a=20 > >>LinkID (could be a globally unique address) and included in=20 > every RA=20 > >>sent from all routers on the same link, would allow the=20 > router to save=20 > >>other options, while eliminating movement detection problems. > >=20 > >=20 > > That is to much overhead for all routers add it just to=20 > when the R bit=20 > > is used and put it in MD or DNA spec. But having only one router=20 > > permitted to send RA with R bit solves it too. > >=20 > >=20 > >>But since there is no concensus on the solution (some prefer > >>the "complete bit"), or its inclusion in 2461 (Vs DNA or=20 > >>another IPv6 draft), it seems like we should either reject > >>this issue or delay the discussion until we resolve > >>all the other issues and hope that opinions have converged > >>by that time. > >=20 > >=20 > > We have to wait then. But I will add the other one and=20 > that is make a=20 > > policy. > >=20 > >=20 > >> > Help me here I think this is pretty basic stuff :--) > >> > >>=3D> Hope this helps :) > >=20 > >=20 > > Yes but it still comes down to where the most efficient=20 > scalable fix=20 > > is and that requires more discussion this is not ready for 2461biz. > >=20 > > thanks > > /jim > >=20 > >=20 > >>Hesham > >> > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 8 23:39:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06945 for ; Sat, 8 Nov 2003 23:39:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhLn-0006qF-Lx for ipv6-archive@odin.ietf.org; Sat, 08 Nov 2003 23:39:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA94cx3V026293 for ipv6-archive@odin.ietf.org; Sat, 8 Nov 2003 23:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhLn-0006q0-Dk for ipv6-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 23:38:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06909 for ; Sat, 8 Nov 2003 23:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhLl-0002Xh-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 23:38:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIhLk-0002Xb-00 for ipv6-web-archive@ietf.org; Sat, 08 Nov 2003 23:38:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhKr-0006lo-6Q; Sat, 08 Nov 2003 23:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhKW-0006hS-9L for ipv6@optimus.ietf.org; Sat, 08 Nov 2003 23:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06877 for ; Sat, 8 Nov 2003 23:37:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhKT-0002Ww-00 for ipv6@ietf.org; Sat, 08 Nov 2003 23:37:37 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AIhKS-0002WP-00 for ipv6@ietf.org; Sat, 08 Nov 2003 23:37:37 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA94awC26352; Sat, 8 Nov 2003 20:36:58 -0800 X-mProtect: <200311090436> Nokia Silicon Valley Messaging Protection Received: from danira-pool051115.americas.nokia.com (10.241.51.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVs2oBL; Sat, 08 Nov 2003 20:36:56 PST Message-ID: <3FADC45D.80200@iprg.nokia.com> Date: Sat, 08 Nov 2003 20:36:45 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: the real issue (was Re: Issue 13: Omission of prefix options - resolution) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit you are right. not all prefixes for the particular link. all prefixes advertised by the router. Vijay Pekka Savola wrote: > On Fri, 7 Nov 2003, Vijay Devarapalli wrote: > >>the complete bit is one solution for this. if the bit is set, it >>means all the prefixes for that particular link are included in the >>router advertisement. but this has some backward compatibility >>issues. > > > Was this really what we talked about?? > > I think we were discussing a Complete bit which would say "I didn't omit > any prefixes". -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 00:02:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07459 for ; Sun, 9 Nov 2003 00:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhiJ-0007jK-0e for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 00:02:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA952EuE029708 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 00:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhiI-0007j5-Qi for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 00:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07429 for ; Sun, 9 Nov 2003 00:02:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhiG-0002ud-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 00:02:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIhiG-0002ua-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 00:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhi6-0007bt-9L; Sun, 09 Nov 2003 00:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhh8-0007ZB-VR for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 00:01:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07412 for ; Sun, 9 Nov 2003 00:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhh5-0002rc-00 for ipv6@ietf.org; Sun, 09 Nov 2003 00:00:59 -0500 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1AIhh4-0002rY-00 for ipv6@ietf.org; Sun, 09 Nov 2003 00:00:59 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 66D9126C for ; Sun, 9 Nov 2003 00:00:28 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 09 Nov 2003 00:00:28 -0500 Message-Id: <20031109050028.66D9126C@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.86% | 14 | 9.20% | 73940 | pekkas@netcore.fi 6.96% | 11 | 9.81% | 78844 | jim.bound@hp.com 6.96% | 11 | 8.94% | 71821 | moore@cs.utk.edu 7.59% | 12 | 5.94% | 47714 | h.soliman@flarion.com 6.33% | 10 | 6.51% | 52334 | athene@sait.samsung.co.kr 5.70% | 9 | 4.95% | 39777 | jinmei@isl.rdc.toshiba.co.jp 5.70% | 9 | 4.59% | 36861 | tjc@ecs.soton.ac.uk 4.43% | 7 | 4.79% | 38482 | huitema@windows.microsoft.com 3.80% | 6 | 4.23% | 33999 | greg.daley@eng.monash.edu.au 3.80% | 6 | 3.68% | 29537 | alain.durand@sun.com 3.80% | 6 | 3.57% | 28659 | kruse@ohio.edu 3.16% | 5 | 2.83% | 22761 | brian@innovationslab.net 2.53% | 4 | 3.29% | 26403 | nisse@lysator.liu.se 2.53% | 4 | 2.12% | 17041 | msa@burp.tkv.asdf.org 1.90% | 3 | 2.58% | 20700 | gene@nttmcl.com 1.90% | 3 | 1.54% | 12389 | tim@mentat.com 1.90% | 3 | 1.50% | 12042 | erik.nordmark@sun.com 1.90% | 3 | 1.44% | 11586 | ftemplin@iprg.nokia.com 1.27% | 2 | 1.74% | 13995 | vijayd@iprg.nokia.com 1.90% | 3 | 1.07% | 8563 | iesg-secretary@ietf.org 1.27% | 2 | 1.30% | 10409 | brc@zurich.ibm.com 1.27% | 2 | 1.18% | 9489 | narten@us.ibm.com 1.27% | 2 | 0.97% | 7819 | samita.chakrabarti@eng.sun.com 0.63% | 1 | 1.22% | 9784 | colm@stdlib.net 0.63% | 1 | 0.84% | 6778 | adelaide_00@yahoo.com 0.63% | 1 | 0.70% | 5628 | sra+ipng@hactrn.net 0.63% | 1 | 0.69% | 5517 | zefram@fysh.org 0.63% | 1 | 0.60% | 4807 | stig.venaas@uninett.no 0.63% | 1 | 0.58% | 4665 | kempf@docomolabs-usa.com 0.63% | 1 | 0.58% | 4622 | eremmell@elmic.com 0.63% | 1 | 0.56% | 4512 | lear@cisco.com 0.63% | 1 | 0.56% | 4484 | j.schoenwaelder@iu-bremen.de 0.63% | 1 | 0.56% | 4465 | m.winkhler@fr.oleane.com 0.63% | 1 | 0.53% | 4288 | dthaler@windows.microsoft.com 0.63% | 1 | 0.53% | 4265 | suresh.krishnan@ericsson.ca 0.63% | 1 | 0.53% | 4259 | raul@lacnic.net 0.63% | 1 | 0.53% | 4223 | jari.arkko@kolumbus.fi 0.63% | 1 | 0.52% | 4182 | gih@telstra.net 0.63% | 1 | 0.52% | 4171 | kurtis@kurtis.pp.se 0.63% | 1 | 0.51% | 4122 | elizabeth.rodriguez@dothill.com 0.63% | 1 | 0.48% | 3825 | benny+nospam@amorsen.dk 0.63% | 1 | 0.43% | 3489 | itojun@iijlab.net 0.63% | 1 | 0.40% | 3215 | mario.goebbels@skynet.be 0.63% | 1 | 0.39% | 3138 | itojun@itojun.org --------+------+--------+----------+------------------------ 100.00% | 158 |100.00% | 803604 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 01:19:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08678 for ; Sun, 9 Nov 2003 01:19:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIiug-0001re-8x for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 01:19:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA96J6Rp007160 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 01:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIiug-0001rP-2z for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 01:19:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08652 for ; Sun, 9 Nov 2003 01:18:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIiud-0003kv-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 01:19:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIiuc-0003ks-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 01:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIite-0001ma-5o; Sun, 09 Nov 2003 01:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIitB-0001lx-U0 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 01:17:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08634 for ; Sun, 9 Nov 2003 01:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIit8-0003k8-00 for ipv6@ietf.org; Sun, 09 Nov 2003 01:17:30 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AIit8-0003k4-00 for ipv6@ietf.org; Sun, 09 Nov 2003 01:17:30 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:13ff::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0950115210; Sun, 9 Nov 2003 15:17:27 +0900 (JST) Date: Sun, 09 Nov 2003 15:17:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian E Carpenter Cc: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" In-Reply-To: <3FAA6F5A.565FF8EE@zurich.ibm.com> References: <3FA98927.1040704@sun.com> <3FAA6F5A.565FF8EE@zurich.ibm.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 06 Nov 2003 16:57:14 +0100, >>>>> Brian E Carpenter said: > I also don't think we should rewrite all the RFCs that refer to SL. > I have no problem with listing them, as in > Note that the following documents refer to link local addresses > and will require appropriate updates: [RFC xxx], [RFC yyy],... Although this is quite obvious, but just to be sure, did you actually mean "... refer to site local addresses" instead of "... link local addresses"? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 06:51:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26688 for ; Sun, 9 Nov 2003 06:51:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIo6F-0007qu-AZ for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 06:51:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9BpNtM030180 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 06:51:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIo6F-0007qh-6R for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 06:51:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26667 for ; Sun, 9 Nov 2003 06:51:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIo6A-0007lB-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 06:51:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIo6A-0007l8-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 06:51:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIo4x-0007lV-KX; Sun, 09 Nov 2003 06:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIo4i-0007l1-9O for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 06:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26644 for ; Sun, 9 Nov 2003 06:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIo4d-0007kS-00 for ipv6@ietf.org; Sun, 09 Nov 2003 06:49:43 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AIo4c-0007kP-00 for ipv6@ietf.org; Sun, 09 Nov 2003 06:49:42 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id A301193; Sun, 9 Nov 2003 20:49:40 +0900 (JST) To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" In-Reply-To: Your message of "Thu, 6 Nov 2003 14:35:41 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031109114940.A301193@coconut.itojun.org> Date: Sun, 9 Nov 2003 20:49:40 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > This is a IPv6 working group last call for comments on advancing the > > following document as an Proposed Standard: > > > > Title : Unique Local IPv6 Unicast Addresses > > Author(s) : R. Hinden, B. Haberman > > Filename : draft-ietf-ipv6-unique-local-01.txt > > Pages : 15 > > Date : 2003-9-24 i object to publish this document as a standard track document. experimental would be more preferable. unique local IPv6 unicast address avoids some problems of site-local, but not all; there are major problem still remains. - it is not expected to be routable, however, it will be treated as if it is a global address. therefore it is likely to be leak out. 1.0 asserts that "even if it leaks out there's no conflict", but "no conflict" is not enough - we do need to be 100% sure there's no leak out, otherwise it is unacceptable. - operationally, there's a much easier way to get a block of address which has the features unique local IPv6 unicast address has; it is to use 6to4 address prefix (2002:v4v4:v4v4::/48). as long as you do not renumber IPv4 address and IPv6 address at the same time, 6to4 address will give you enough address for the suggested use of unique local IPv6 unicast address. moreover, 6to4 address are routable (though there's tunnelling overhead if outsiders are to contact 6to4 address accidentally). there is no need to define unique local IPv6 unicast address. some may object on the 2nd point, like "when I don't have IPv4 address what should I do?". well, IPv6/v4 dual stack operation will continue for ages so i do not consider it a problem. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 07:53:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27612 for ; Sun, 9 Nov 2003 07:53:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIp3v-0001Ej-Ev for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 07:53:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Cr3cO004754 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 07:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIp3v-0001Eb-9A for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 07:53:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27588 for ; Sun, 9 Nov 2003 07:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIp3u-0000fy-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 07:53:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIp3u-0000fu-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 07:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIp2w-00019S-0k; Sun, 09 Nov 2003 07:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIp2c-00018z-Dk for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 07:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27580 for ; Sun, 9 Nov 2003 07:51:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIp2b-0000fm-00 for ipv6@ietf.org; Sun, 09 Nov 2003 07:51:41 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIp2a-0000fj-00 for ipv6@ietf.org; Sun, 09 Nov 2003 07:51:40 -0500 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 MAA04086 for ; Sun, 9 Nov 2003 12:51:38 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA05462 for ; Sun, 9 Nov 2003 12:51:37 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA9Cpbf05901 for ipv6@ietf.org; Sun, 9 Nov 2003 12:51:37 GMT Date: Sun, 9 Nov 2003 12:51:37 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <20031109125137.GC5596@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20031109114940.A301193@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031109114940.A301193@coconut.itojun.org> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sun, Nov 09, 2003 at 08:49:40PM +0900, Jun-ichiro itojun Hagino wrote: > > - it is not expected to be routable, however, it will be treated > as if it is a global address. therefore it is likely to be leak out. > 1.0 asserts that "even if it leaks out there's no conflict", but > "no conflict" is not enough - we do need to be 100% sure there's no > leak out, otherwise it is unacceptable. I don't think we'd ever get 100% confidence of zero leakage, but that shouldn't deter us from having a site-local addressing scheme that at least cures the other major problem of ambiguity in the addresses. I think the Hinden draft can only fix the ambiguity problem. But if people use Hinden-draft the leakage is more readily traced. > some may object on the 2nd point, like "when I don't have IPv4 address > what should I do?". well, IPv6/v4 dual stack operation will continue > for ages so i do not consider it a problem. What about the ambiguity where the network is disconnected or intermittently connected and the site only has Net10 IPv4 addresses? The Hinden draft at least allows such networks to merge or temporarily interconnect for IPv6 with a good assurance of there being no address clash. Or are you suggesting you would always have to reconfigure for the Net10 clash anyway? It is also the case that many networks with an IPv4 address have a dynamic address, so your local IPv6 addresses would not have the desirable property of being stable (they are not "provider independent" unless the IPv4 address is also a PI one). I think any scheme defined now should be designed with IPv6-only operation also in mind. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 09:05:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28671 for ; Sun, 9 Nov 2003 09:05:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqBN-0003NV-0P for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 09:04:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9E4mL2012979 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 09:04:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqBM-0003NG-SU for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 09:04:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28631 for ; Sun, 9 Nov 2003 09:04:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqBL-0001Sk-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:04:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIqBL-0001Sh-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:04:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqAc-0003H8-0o; Sun, 09 Nov 2003 09:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqA1-0003GR-Pc for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 09:03:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28593 for ; Sun, 9 Nov 2003 09:03:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqA0-0001S6-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:03:24 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIq9y-0001Rg-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:03:23 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA9E2pE10845 for ; Sun, 9 Nov 2003 16:02:51 +0200 Date: Sun, 9 Nov 2003 16:02:50 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: comments on thaler-ndproxy-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, The doc is pretty good but needs more work The most important thing appears to be identifying the which features we need (considering the tradeoffs) substantial ----------- 1) The impression of the document is that it's underspecified but workable. If the goal is to make it more fun to implement this (instead of more boring :-), by omitting the details of the specification, this document succeeds. If not, the details need to be added.. Well, the details probably need to be added anyway, because some of these apparently obvious methods could vary a lot from person to person (a couple of examples in the semi-editorial section) 2) I'm not sure whether they should be included in the scenarios, but I think they're very relevant. That is, deploying the ND proxy to perform bridging firewall functions on a subnet for multiple reasons.. remember, that's one of the *major* reasons why NATs are also deployed in more or less transparent/zero-conf manner. Of course, in most cases, this can be solved with a regular bridging firewall as well, no need to use an ND proxy. For example as in scenario 1: | +-------+ +--------+ local |Ethernet | | Wireless | Access | +---------+ A +-))) (((-+ +--> rest of network hosts | | | link | Point | | +-------+ +--------+ .. assume that local hosts could also, theoretically, have wireless interfaces themselves, and communicate directly over the wireless link without the presence of A. Now, a major reason to deploy something like A would be the ability to add firewall rules in A, to protect all the local hosts in one go. To sum it up, I'm not 100% sure how much of this needs to be spelled out or not. Maybe one could include a few words on what other functions the ND proxies (firewalling etc.) could be used to provide between the segments, with some caveats. What would probably also be very useful is to spell out some of the scenarios where ND proxy is NOT needed, but regular bridging would be OK as well -- to give a view that bridging and ND-proxying really do provide a complete set of solutions. (Just to make it easier to show folks that NATs are really not needed -- this is a bit out of scope of the original document, but could be really useful if not done somewhere else (e.g., v6ops solutions documents..)). 3) I'm not sure whether specifying the mechanism for IPv4 is within the mandate of this WG. But it seems to come in free, so, no huge resistance here. The worry is just that there may be some v4 features we're not really aware of and making ND proxying work on v4 might actually take a lot more effort than we realize at first (difficult to say at this phase). 4) I want the loop-prevention features to be to non-requirements. If loop prevention is required, the ND-proxy is deployed improperly. The only thing from loop prevention I'd appreciate is that the failure mode would be obvious when/if ND proxying was deployed in such a manner that a loop would occur. (This would result to moving the loop prevention stuff to an appendix or removing it..) 5) Non-goals has: o Support Neighbor Discovery, Router Discovery, or DHCPv4 packets using encryption with an ESP header. We also note that the current methods for securing these protocols do not use an ESP header. Where encryption is required, link-layer encryption can be used on each segment. ==> Uhh, isn't the current approach hostile to IPsec AH as well, as the payload of the packets (e.g. SLLA, TLLA) are modified, unless the ND proxy acts as some form of authorized intermediary? ==> I'm not sure whether link-layer encryption sentence is accurate. Let's consider two cases: the L2 encryption uses a shared secret (known by the proxy) -- OK; the L2 encryption uses stronger methods (usually the more useful deployment of L2 encryption) -- the ND proxy needs act as MITM here, but then L2 encryption will fail, right? So, it would seem that in the presence of IPsec AH, IPsec ESP, or link-layer non-shared key encryption the deployment of ND-proxies may be problematic, but with some restrictions, possible. These will need to be considered explicitly somewhere, e.g. a deployment or security considerations section. 6) I'm not sure if the spec as written supports the seamless movement between bridged segments, which was a requirement, for example: If the received packet is an ICMPv6 Redirect message, then the proxied packet should be modified as follows. If the proxy has a valid (i.e., not INCOMPLETE) neighbor entry for the target address on the same interface as the redirected host, then the TLLA option in the proxied Redirect simply contains the link-layer address of the target as found in the proxy's neighbor entry, since the redirected host may reach the target address directly. ==> now, consider the same if the node moved to a different segment since the neighbor entry was created? Or in: The NA is received by P, which then processes it as it would any unicast packet; i.e., it forwards this out interface 1, based on the neighbor cache. However, before actually sending the packet out, it inspects it to determine if the packet being sent is one which requires proxying. Since it is an NA, it updates its neighbor entry for B to be REACHABLE and records the link-layer address b. P then replaces the link-layer address in the TLLA option with its own link-layer address on the outgoing interface, p1. The packet is then sent out interface 1. ==> this doesn't seem to work when moving between segments without a: 1) a cache timeout, or 2) the host, immediately after moving, sending a packet, updating the proxy's cache. If the host is silent before moving and afterwards, there will be no indication where it has gone. Right? 7) doesn't the following break the requirements of transparent introduction -- for both hosts (need to consider the bridge as a router), and for the router (it needs to be aware of the ND proxy, right?)v From=20an IPv6 perspective, RFC 2461 [ND] already defines the ability to proxy Neighbor Advertisements. The requirements for securing proxied messages are similar to those for securing Router Advertisements, since the receiver must verify that the advertisement came from a valid router/proxy, rather than from the owner of a specific address. 8) An IPR section is required. Is there known IPR on this? 9) The link layer address changes could affect the packet size. Note that as the length is given in the units of 64 bits, for most (all?) the applicable link types that indicates that the packet size won't be changed. Could be worth pointing out. However, adding MTU option in sect 4.1.3.3 is a different issue altogether. Actually, it would also be possible to overflow the RA size by adding the MTU, if the RA is really loaded witrh prefixes. This is of course very theoretical, but probably needs to be mentioned explicitly! semi-editorial -------------- ==> needs a ToC, as it's over 15 pages Expires December 2003 [Page 1] =0C ==> something is wrong with the page breaks When a proxy interface comes up, the node puts it in "all- multicast" mode so that it will receive all multicast packets. It is common for interfaces to not support full promiscuous mode (e.g., on a wireless client), but all-multicast mode is generally still supported. ==> s/all multicast/all multicast and broadcast/, right? (not sure whether the definition of multicast explicitly includes broadcast...) When any IP or ARP packet is received on a proxy interface, it must be parsed to see whether it is known to be of a type that negotiates link-layer addresses. This document covers the following types: ARP, IPv6 Neighbor Discovery, IPv6 Router Discovery, IPv6 Redirects, and DHCPv4. ==> Could you spell out, for clarity, some protocols: a) which are not supported by this spec, or b) which do not need to be supported by this spec (but one could think whether they need be), e.g. DHCPv6? The link layer header, and the link-layer address within the payload for each forwarded packet will be modified as follows: [...] ==> as noted above, these are a bit underspecified.. ("where in the packets"?) As with all forwarded packets, the link-layer header is also new. Any Authentication Header would also be removed, and a new one may be added as discussed below under Security Considerations. ==> note that Security Consideration doesn't currently discuss this :-) When any IPv4 or ARP packet is received on a proxy interface, it must be parsed to see whether it is known to be one of the following types: ARP, or DHCPv4. ==> again, not specified how ARP or DHCPv4 packets are recognized; this should be pretty obvious, but is a bit under-specified.. ==> I note that IPv4 Redirects are not supported, but this hasn't been spelled out anywhere. Omission or intentional ? To support scenario 2, if the MTU of the upstream segment is smaller than the MTU of the downstream segment then IPv6 Router Advertisements (RAs) must also be proxied as follows. If the RA contains an MTU Option, the RA is forwarded unmodified. Otherwise, the proxy adds an MTU Option with a value of minimum of the link MTUs of the proxy interfaces, and then proxies it as described above. ==> it should probably be spelled out here, due to the non-requirement, ND-proxying doesn't work at all if the routers are connected to a link with higher MTU. It also creates a neighbor entry for B (on an arbitrary proxy interface) in the INCOMPLETE state. Since the packet is multicast, P then needs to proxy the NS out all other proxy interfaces on the subnet. Before sending the packet out interface 2, it replaces the link-layer address in the SLLA option with its own link-layer address, p2. ==> the use of terms "all other proxy interfaces", etc. are a bit misnomers in this particular example of just two interfaces. I'd suggest expanding the example so that P has three interfaces, but only with two nodes A and B (one interface is empty) Loop prevention can be done done by having the proxy implement the Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all proxy interfaces. ==> is this really enough of a specification?? :-)) Operation of the Spanning Tree Protocol (STP) over other types of link layers is done by encapsulating the STP frame in an IPv6 header as follows. The Next Header field is set to [TBA by IANA], indicating that an STP header follows. The Destination Address field is set to the Link-scoped STP Multicast Group [TBA by IANA]. All proxies operating on non-IEEE 802 media join this group so they will receive STP packets. STP packets are never forwarded or proxied. ==> which format is used for encapsulation of STP? Directly afterwards? It is a "terminal header", correct, so no TLV encoding or similar need be done? ==> Are ND proxies acting as decapsulators/encapsulators for these STP packets between the links? If nothing is done based on these, how do they help in the first place? 10. Appendix A: Comparison with other approaches ==> this section should be reworded to be refer to RA-proxy only, or add some other approaches (probably preferable!) such as IPv4 Proxy ARP (the differences are probably rather interesting..) editorial --------- o Support Neighbor Discovery, Router Discovery, or DHCPv4 packets using encryption with an ESP header. We also note that the current methods for securing these protocols do not use an ESP header. Where encryption is required, link-layer encryption can be used on each segment. ==> s/ESP/IPsec Encapsulation Security Payload (ESP)/ ==> s/Where encryption/Where the encryption of these, typically on-link, neighbor discovery communications/ interface on which it arrived; such a packet is instead silently dropped. ==> s/dropped/discarded/ ocally but no ARP REPLY is generated immediately. Instead, the ARP REQUEST is proxied (as described above) and the ARP REPLY will ==> use a proper pointer to sect 4.1 instead of "above". (similar elsewhere..) B receives this NS, processing it as usual. Hence it creates a neighbor entry for A mapping it to the link-layer address p2. It responds with a Neighbor Advertisement (NA) sent to A containing B's link-layer address b. The NA is sent using A's neighbor entry, i.e. to the link-layer address p2. ==> s/with a/with a unicast/ example, propritery protocols). This section prescribes guidelines ==> s/propritery/proprietary/ From=20an IPv6 perspective, RFC 2461 [ND] already defines the ==> some scrap here, "=20". -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 09:21:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28988 for ; Sun, 9 Nov 2003 09:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqRG-0004Gf-MI for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 09:21:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9ELEIk016399 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 09:21:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqRG-0004GQ-GW for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 09:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28934 for ; Sun, 9 Nov 2003 09:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqRE-0001ey-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:21:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIqRE-0001ev-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:21:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqR4-0004Cb-Tq; Sun, 09 Nov 2003 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqQd-0004Bz-6u for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 09:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28915 for ; Sun, 9 Nov 2003 09:20:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqQb-0001eJ-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:20:33 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqQa-0001e9-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:20:32 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA9EJqv11074; Sun, 9 Nov 2003 16:19:53 +0200 Date: Sun, 9 Nov 2003 16:19:51 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Brian Haberman , Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" In-Reply-To: <3FAA6FA6.5590F7BC@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 6 Nov 2003, Brian E Carpenter wrote: > Pekka, it's been a while, but my recollection is that we (the authors) > didn't agree and didn't see any support for your comments on the list. > > I could be wrong. There was no opposition, and there was support for at least referencing the SL-IMPACT work (or something else, giving a fuller description of SL problems). On Thu, 6 Nov 2003, Christian Huitema wrote: > Actually, the 01 draft includes two changes to address Pekka's feedback: > add some explanatory text in section 2.2, address leak, and section 2.3, > routing pain; and in section 5, qualify that the replacement of site > local is only as secure if blocking rules are actually implemented at > site boundaries. But it is clear that we want to keep the document short > and concise, and thus chose to not widely expand the text in section 2 > and 5. Yes, I noticed that some (most?) changes were incorporated, but at least the above (which I believe was important, and had some support) wasn't. Of course the question then would be would the doc be normative or informative. The former could block the document unless SL-IMPACT is published soon. As there is already enough description of the issues, informational would probably be close to the mark.. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 09:37:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29391 for ; Sun, 9 Nov 2003 09:37:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqgk-0004vt-Ek for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 09:37:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9EbDQT018945 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 09:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqgj-0004vU-O0 for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 09:37:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29341 for ; Sun, 9 Nov 2003 09:37:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqgi-0001tA-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:37:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIqgh-0001t7-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:37:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqgX-0004nT-Rv; Sun, 09 Nov 2003 09:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqfv-0004mA-RP for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 09:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29319 for ; Sun, 9 Nov 2003 09:36:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqfu-0001sd-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:36:22 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AIqft-0001sa-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:36:21 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 91D4393; Sun, 9 Nov 2003 23:36:17 +0900 (JST) To: ipv6@ietf.org Subject: anycast-analysis draft References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031109143617.91D4393@coconut.itojun.org> Date: Sun, 9 Nov 2003 23:36:17 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , what have happened to anycast-analysis draft? i believed that it is in IESG queue or RFC-editor queue, but it's not in http://www.rfc-editor.org/queue.html. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 09:40:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29522 for ; Sun, 9 Nov 2003 09:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqjc-0005au-Aj for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 09:40:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9EeBdF021394 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 09:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqja-0005XP-S8 for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 09:40:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29494 for ; Sun, 9 Nov 2003 09:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqjY-0001wk-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:40:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIqjY-0001wh-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 09:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqjW-0005V2-Pg; Sun, 09 Nov 2003 09:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIqjN-0005Ts-3A for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 09:39:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29487 for ; Sun, 9 Nov 2003 09:39:43 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIqjL-0001wZ-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:39:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIqjK-0001wW-00 for ipv6@ietf.org; Sun, 09 Nov 2003 09:39:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9Edre27228 for ; Sun, 9 Nov 2003 16:39:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 16:39:53 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 16:39:52 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 16:39:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: anycast-analysis draft Date: Sun, 9 Nov 2003 16:39:51 +0200 Message-ID: Thread-Topic: anycast-analysis draft Thread-Index: AcOmzwTOJX8GYYj7RdiPwoQFTu58pgAADs0g To: , X-OriginalArrivalTime: 09 Nov 2003 14:39:51.0826 (UTC) FILETIME=[556E9F20:01C3A6CF] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Itojun, > what have happened to anycast-analysis draft? i believed that it is > in IESG queue or RFC-editor queue, but it's not in > http://www.rfc-editor.org/queue.html. From the draft tracker: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= search_job_owner=3D0&search_group_acronym=3Dipv6&search_status_id=3D&sear= ch_cur_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D&s= earch_area_acronym=3D&search_button=3DSEARCH It appears that it is still stuck in IESG Evalutation. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 10:28:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01624 for ; Sun, 9 Nov 2003 10:28:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrUV-00078z-IA for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 10:28:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9FSdkh027455 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 10:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrUV-00078k-B0 for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 10:28:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01592 for ; Sun, 9 Nov 2003 10:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrUT-0002XV-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 10:28:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIrUS-0002XS-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 10:28:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrTt-000744-KP; Sun, 09 Nov 2003 10:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrSu-00073T-JN for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 10:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01559 for ; Sun, 9 Nov 2003 10:26:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrSs-0002Wg-00 for ipv6@ietf.org; Sun, 09 Nov 2003 10:26:58 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AIrSr-0002Wd-00 for ipv6@ietf.org; Sun, 09 Nov 2003 10:26:57 -0500 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 26A5596; Mon, 10 Nov 2003 00:26:55 +0900 (JST) To: john.loughney@nokia.com Cc: ipv6@ietf.org In-reply-to: john.loughney's message of Sun, 09 Nov 2003 16:39:51 +0200. 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: anycast-analysis draft From: itojun@iijlab.net Date: Mon, 10 Nov 2003 00:26:55 +0900 Message-Id: <20031109152655.26A5596@coconut.itojun.org> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>From the draft tracker: > >https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= >search_job_owner=3D0&search_group_acronym=3Dipv6&search_status_id=3D&sear= >ch_cur_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D&s= >earch_area_acronym=3D&search_button=3DSEARCH > >It appears that it is still stuck in IESG Evalutation. oh thanks. datatracker is not linked from ietf.org webpage (or my clicking ability is not enough). itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 13:40:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06010 for ; Sun, 9 Nov 2003 13:40:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuTV-0006Pp-Di for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 13:39:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Idnvr024655 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 13:39:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuTV-0006Pa-6i for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:39:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05967 for ; Sun, 9 Nov 2003 13:39:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuTT-0005DN-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 13:39:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIuTS-0005DK-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 13:39:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuSj-0006Iv-RO; Sun, 09 Nov 2003 13:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuSS-0006H2-Mi for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 13:38:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05911 for ; Sun, 9 Nov 2003 13:38:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuSQ-0005C4-00 for ipv6@ietf.org; Sun, 09 Nov 2003 13:38:42 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AIuSP-0005BB-00 for ipv6@ietf.org; Sun, 09 Nov 2003 13:38:41 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9IcAlC010428; Sun, 9 Nov 2003 18:38:10 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9Ic4lF248988; Sun, 9 Nov 2003 19:38:04 +0100 Received: from zurich.ibm.com (sig-9-145-147-176.de.ibm.com [9.145.147.176]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA43680; Sun, 9 Nov 2003 19:38:02 +0100 Message-ID: <3FAE8966.EA36E58E@zurich.ibm.com> Date: Sun, 09 Nov 2003 19:37:26 +0100 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: Pekka Savola CC: Brian Haberman , ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, correct, and SL-IMPACT must not become a blocking reference. Brian Pekka Savola wrote: > > On Thu, 6 Nov 2003, Brian E Carpenter wrote: > > Pekka, it's been a while, but my recollection is that we (the authors) > > didn't agree and didn't see any support for your comments on the list. > > > > I could be wrong. > > There was no opposition, and there was support for at least referencing > the SL-IMPACT work (or something else, giving a fuller description of SL > problems). > > On Thu, 6 Nov 2003, Christian Huitema wrote: > > Actually, the 01 draft includes two changes to address Pekka's feedback: > > add some explanatory text in section 2.2, address leak, and section 2.3, > > routing pain; and in section 5, qualify that the replacement of site > > local is only as secure if blocking rules are actually implemented at > > site boundaries. But it is clear that we want to keep the document short > > and concise, and thus chose to not widely expand the text in section 2 > > and 5. > > Yes, I noticed that some (most?) changes were incorporated, but at least > the above (which I believe was important, and had some support) wasn't. > > Of course the question then would be would the doc be normative or > informative. The former could block the document unless SL-IMPACT is > published soon. As there is already enough description of the issues, > informational would probably be close to the mark.. > > -- > 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 IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 13:41:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06068 for ; Sun, 9 Nov 2003 13:41:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuUl-0006db-KM for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 13:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9If7CG025509 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 13:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuUl-0006dM-Ex for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:41:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06040 for ; Sun, 9 Nov 2003 13:40:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuUj-0005Eb-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 13:41:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIuUi-0005EY-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 13:41:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuUg-0006Zg-Va; Sun, 09 Nov 2003 13:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuTg-0006S6-26 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 13:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05982 for ; Sun, 9 Nov 2003 13:39:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuTd-0005Dj-00 for ipv6@ietf.org; Sun, 09 Nov 2003 13:39:57 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1AIuTc-0005D4-00 for ipv6@ietf.org; Sun, 09 Nov 2003 13:39:56 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9Id5xm062864 for ; Sun, 9 Nov 2003 18:39:06 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9IctlF082394 for ; Sun, 9 Nov 2003 19:38:55 +0100 Received: from zurich.ibm.com (sig-9-145-147-176.de.ibm.com [9.145.147.176]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA43116 for ; Sun, 9 Nov 2003 19:38:54 +0100 Message-ID: <3FAE8999.7A5BE780@zurich.ibm.com> Date: Sun, 09 Nov 2003 19:38:17 +0100 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@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" References: <3FA98927.1040704@sun.com> <3FAA6F5A.565FF8EE@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Silly me! Brian JINMEI Tatuya / 神明達哉 wrote: > > >>>>> On Thu, 06 Nov 2003 16:57:14 +0100, > >>>>> Brian E Carpenter said: > > > I also don't think we should rewrite all the RFCs that refer to SL. > > I have no problem with listing them, as in > > > Note that the following documents refer to link local addresses > > and will require appropriate updates: [RFC xxx], [RFC yyy],... > > Although this is quite obvious, but just to be sure, did you actually > mean "... refer to site local addresses" instead of "... link local > addresses"? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 13:55:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06497 for ; Sun, 9 Nov 2003 13:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuiR-0007gm-IV for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 13:55:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9ItFcK029550 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 13:55:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuiR-0007gX-BS for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06473 for ; Sun, 9 Nov 2003 13:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuiP-0005S1-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 13:55:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIuiO-0005Ry-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 13:55:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuiF-0007cs-HR; Sun, 09 Nov 2003 13:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuhc-0007c8-43 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 13:54:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06463 for ; Sun, 9 Nov 2003 13:54:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuhZ-0005Rk-00 for ipv6@ietf.org; Sun, 09 Nov 2003 13:54:21 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1AIuhY-0005RG-00 for ipv6@ietf.org; Sun, 09 Nov 2003 13:54:20 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9Ir8D8050270; Sun, 9 Nov 2003 18:53:08 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9IqvlF155222; Sun, 9 Nov 2003 19:52:57 +0100 Received: from zurich.ibm.com (sig-9-145-147-176.de.ibm.com [9.145.147.176]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA45436; Sun, 9 Nov 2003 19:52:45 +0100 Message-ID: <3FAE8CD8.FB187DE4@zurich.ibm.com> Date: Sun, 09 Nov 2003 19:52:08 +0100 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: Jun-ichiro itojun Hagino CC: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <20031109114940.A301193@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit itojun, Tim has replied technically. I would object to this being published as Experimental. That would be the worst solution, since nobody would have any idea whether it was safe to use it. I'd rather we simply started misusing PA or, indeed, 6to4 space to solve the operational problem. In fact, that is simply bound to happen unless the IETF resolves this quickly. Brian Jun-ichiro itojun Hagino wrote: > > > > This is a IPv6 working group last call for comments on advancing the > > > following document as an Proposed Standard: > > > > > > Title : Unique Local IPv6 Unicast Addresses > > > Author(s) : R. Hinden, B. Haberman > > > Filename : draft-ietf-ipv6-unique-local-01.txt > > > Pages : 15 > > > Date : 2003-9-24 > > i object to publish this document as a standard track document. > experimental would be more preferable. > > unique local IPv6 unicast address avoids some problems of site-local, > but not all; there are major problem still remains. > - it is not expected to be routable, however, it will be treated > as if it is a global address. therefore it is likely to be leak out. > 1.0 asserts that "even if it leaks out there's no conflict", but > "no conflict" is not enough - we do need to be 100% sure there's no > leak out, otherwise it is unacceptable. > - operationally, there's a much easier way to get a block of address > which has the features unique local IPv6 unicast address has; > it is to use 6to4 address prefix (2002:v4v4:v4v4::/48). as long as > you do not renumber IPv4 address and IPv6 address at the same time, > 6to4 address will give you enough address for the suggested use of > unique local IPv6 unicast address. moreover, 6to4 address are > routable (though there's tunnelling overhead if outsiders are to > contact 6to4 address accidentally). there is no need to define > unique local IPv6 unicast address. > > some may object on the 2nd point, like "when I don't have IPv4 address > what should I do?". well, IPv6/v4 dual stack operation will continue > for ages so i do not consider it a problem. > > itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 15:36:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09759 for ; Sun, 9 Nov 2003 15:36:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwHe-0003MY-E4 for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 15:35:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9KZg76012922 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 15:35:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwHe-0003ML-9m for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 15:35:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09730 for ; Sun, 9 Nov 2003 15:35:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwHd-0006i9-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 15:35:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIwHc-0006i6-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 15:35:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwH1-0003IU-M8; Sun, 09 Nov 2003 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwGI-0003HU-5e for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 15:34:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09697 for ; Sun, 9 Nov 2003 15:34:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwGG-0006ht-00 for ipv6@ietf.org; Sun, 09 Nov 2003 15:34:16 -0500 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1AIwGF-0006hq-00 for ipv6@ietf.org; Sun, 09 Nov 2003 15:34:15 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id ABA9AADD1; Sun, 9 Nov 2003 15:34:14 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 9 Nov 2003 15:34:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Sun, 9 Nov 2003 15:34:14 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122629@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Thread-Index: AcOmt/F/N9Tc7g30Q6amwJG3K5k8bwASKI6Q From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 09 Nov 2003 20:34:14.0513 (UTC) FILETIME=[D6FB2E10:01C3A700] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Itojun, I see your point. But, we need to give the market away to do this or they will invent addreses. This is better than SL. Unless we believe it is ok for users to use Experimental RFC and are renumbering is strong enough that we can support a change later with implementations. So for now I have to support this for standards track but I am listening to you seriously. thanks /jim > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On=20 > Behalf Of Jun-ichiro itojun Hagino > Sent: Sunday, November 09, 2003 6:50 AM > To: ipv6@ietf.org > Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6=20 > Unicast Addresses" >=20 >=20 > > > This is a IPv6 working group last call for comments on=20 > advancing the=20 > > > following document as an Proposed Standard: > > >=20 > > > Title : Unique Local IPv6 Unicast Addresses > > > Author(s) : R. Hinden, B. Haberman > > > Filename : draft-ietf-ipv6-unique-local-01.txt > > > Pages : 15 > > > Date : 2003-9-24 >=20 > i object to publish this document as a standard track document. > experimental would be more preferable. >=20 > unique local IPv6 unicast address avoids some problems=20 > of site-local, > but not all; there are major problem still remains. > - it is not expected to be routable, however, it will be treated > as if it is a global address. therefore it is likely=20 > to be leak out. > 1.0 asserts that "even if it leaks out there's no=20 > conflict", but > "no conflict" is not enough - we do need to be 100%=20 > sure there's no > leak out, otherwise it is unacceptable. > - operationally, there's a much easier way to get a=20 > block of address > which has the features unique local IPv6 unicast address has; > it is to use 6to4 address prefix=20 > (2002:v4v4:v4v4::/48). as long as > you do not renumber IPv4 address and IPv6 address at=20 > the same time, > 6to4 address will give you enough address for the=20 > suggested use of > unique local IPv6 unicast address. moreover, 6to4 address are > routable (though there's tunnelling overhead if=20 > outsiders are to > contact 6to4 address accidentally). there is no need=20 > to define > unique local IPv6 unicast address. >=20 > some may object on the 2nd point, like "when I don't=20 > have IPv4 address > what should I do?". well, IPv6/v4 dual stack operation=20 > will continue > for ages so i do not consider it a problem. >=20 > itojun >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 16:22:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10804 for ; Sun, 9 Nov 2003 16:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIx0f-0005mN-4E for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 16:22:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9LMDOT022209 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 16:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIx0e-0005m8-Up for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 16:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10774 for ; Sun, 9 Nov 2003 16:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIx0d-0007HN-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 16:22:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIx0c-0007HK-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 16:22:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIx0S-0005iS-Tk; Sun, 09 Nov 2003 16:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwzY-0005cc-Iv for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 16:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10695 for ; Sun, 9 Nov 2003 16:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwzW-0007Gc-00 for ipv6@ietf.org; Sun, 09 Nov 2003 16:21:02 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AIwzV-0007GN-00 for ipv6@ietf.org; Sun, 09 Nov 2003 16:21:01 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9LKOCU049352; Sun, 9 Nov 2003 21:20:24 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9LKOb9227914; Sun, 9 Nov 2003 22:20:24 +0100 Received: from zurich.ibm.com ([9.145.246.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA60764; Sun, 9 Nov 2003 22:20:22 +0100 Message-ID: <3FAEAF70.7702DB1F@zurich.ibm.com> Date: Sun, 09 Nov 2003 22:19:44 +0100 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: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain Durand wrote: > > On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote: > > In the case in point, there is a significant constituency who believes > > that they need a replacement for site local addresses, and that > > "draft-hinden" is a reasonable way to obtain this replacement. You are > > indeed free to not use such addresses and never deploy them within the > > networks that you manage, but that does not change the needs of others. > > In principle, I would almost agree with this statement, with one caveat: > "... as long as it does not break anything in the global Internet for > people that do not use this proposal" > > As I explain in a previous message, this last property is not verified > by the hinden/haberman draft, as when those addresses leak, > they would create untraceable problems, very similar to the one > caused by RFC1918 leaks today. Q: Who is to blame and likely to be a victim? A: any ISP without ingress filtering. To misquote Pekka, why exactly should we care if ISP X's operations break because it fails to implement ingress filtering? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 16:26:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10902 for ; Sun, 9 Nov 2003 16:26:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIx4S-00067W-9L for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 16:26:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9LQ8Dx023516 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 16:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIx4R-00067B-U7 for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 16:26:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10864 for ; Sun, 9 Nov 2003 16:25:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIx4Q-0007JX-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 16:26:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIx4P-0007JU-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 16:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIx4N-00063P-1M; Sun, 09 Nov 2003 16:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIx3r-00062c-H9 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 16:25:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10842 for ; Sun, 9 Nov 2003 16:25:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIx3p-0007In-00 for ipv6@ietf.org; Sun, 09 Nov 2003 16:25:29 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1AIx3o-0007IO-00 for ipv6@ietf.org; Sun, 09 Nov 2003 16:25:28 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9LOpgZ040718; Sun, 9 Nov 2003 21:24:51 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9LOpb9265016; Sun, 9 Nov 2003 22:24:51 +0100 Received: from zurich.ibm.com ([9.145.246.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA43688; Sun, 9 Nov 2003 22:24:49 +0100 Message-ID: <3FAEB07B.58C50161@zurich.ibm.com> Date: Sun, 09 Nov 2003 22:24:11 +0100 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: Tim Chown , ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain, Please define "real PI (by real I mean registered)". Not having seen the draft that defines it, I can't evaluate your argument. Brian Alain Durand wrote: > > On Nov 4, 2003, at 12:48 AM, Tim Chown wrote: > > > On Mon, Nov 03, 2003 at 10:45:07PM -0800, Alain Durand wrote: > >> > >> As I explain in a previous message, this last property is not verified > >> by the hinden/haberman draft, as when those addresses leak, > >> they would create untraceable problems, very similar to the one > >> caused by RFC1918 leaks today. > > > > But could we ever stop leakage? > > > > And would it not be more dangerous if hijacked or randomly picked > > prefixes > > leaked instead of well-known (probabilistically unique) prefixes? > > You're assuming that the alternative to hinden/haberman is hijacking > random prefixes. > I don't. I see allocation of real PI (by real I mean registered) a more > serious alternative. > The more I think about it, the more I come to the conclusion that the > issue > with the hinden/haberman draft is that those prefixes cannot be trace > back, > making them as good (or as bad) as ambiguous. > > I just saw a press release from a company building high speed network > chips > that claim they can process up to a million route at 40 Gb/s... > so I'm honestly thinking that handing out PI to people who can justify > the need > is not as scary as it sounds, at least it would enable us to wait until > we get something > from Multi6. > > - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:01:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12090 for ; Sun, 9 Nov 2003 17:01:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxbv-0008C1-Mf for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:00:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9M0h1V031487 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:00:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxbv-0008Bm-Em for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:00:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12003 for ; Sun, 9 Nov 2003 17:00:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxbt-00008M-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:00:41 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AIxbs-00008I-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:00:40 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AIxbq-0007WO-Ru for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:00:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxbJ-0007zV-Jr; Sun, 09 Nov 2003 17:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxb0-0007yA-Ks for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 16:59:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11785 for ; Sun, 9 Nov 2003 16:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxay-0007l4-00 for ipv6@ietf.org; Sun, 09 Nov 2003 16:59:44 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1AIxax-0007l1-00 for ipv6@ietf.org; Sun, 09 Nov 2003 16:59:43 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id hA9Lxdcm013821 for ; Sun, 9 Nov 2003 14:59:39 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HO300DNAUFF66@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Sun, 09 Nov 2003 14:59:39 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HO3009IAUFEM9@mail.sun.net> for ipv6@ietf.org; Sun, 09 Nov 2003 14:59:39 -0700 (MST) Date: Sun, 09 Nov 2003 14:02:29 -0800 From: Alain Durand Subject: Re: Thoughts on the draft-hinden last call In-reply-to: <3FAEAF70.7702DB1F@zurich.ibm.com> To: Brian E Carpenter Cc: ipv6@ietf.org Message-id: <695B33A7-1300-11D8-916A-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <3FAEAF70.7702DB1F@zurich.ibm.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Nov 9, 2003, at 1:19 PM, Brian E Carpenter wrote: > Alain Durand wrote: >> >> On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote: >>> In the case in point, there is a significant constituency who >>> believes >>> that they need a replacement for site local addresses, and that >>> "draft-hinden" is a reasonable way to obtain this replacement. You >>> are >>> indeed free to not use such addresses and never deploy them within >>> the >>> networks that you manage, but that does not change the needs of >>> others. >> >> In principle, I would almost agree with this statement, with one >> caveat: >> "... as long as it does not break anything in the global Internet for >> people that do not use this proposal" >> >> As I explain in a previous message, this last property is not verified >> by the hinden/haberman draft, as when those addresses leak, >> they would create untraceable problems, very similar to the one >> caused by RFC1918 leaks today. > > Q: Who is to blame and likely to be a victim? > > A: any ISP without ingress filtering. Did you never heard about the AS112 project as an example of how much trouble RFC1918 can cause? http://www.as112.net/ With that regard, as hinden/haberman addresses are not resolvable in the reverse tree DNS, they will cause exactly the same issue as RF1918. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:05:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12291 for ; Sun, 9 Nov 2003 17:05:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxgQ-0000Jp-NM for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:05:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9M5MlN001226 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxgQ-0000Jh-HX for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:05:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12268 for ; Sun, 9 Nov 2003 17:05:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxgO-0000Eq-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:05:20 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AIxgN-0000Ei-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:05:20 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AIxgM-0007dU-V8 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:05:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxg7-0000Bi-S0; Sun, 09 Nov 2003 17:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxfT-00008Z-93 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:04:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12204 for ; Sun, 9 Nov 2003 17:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxfQ-0000D0-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:04:21 -0500 Received: from dyn138-234.ietf58.ietf.org ([130.129.138.234] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1AIxfQ-0000Cd-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:04:20 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hA9M3xS02045; Sun, 9 Nov 2003 23:03:59 +0100 Message-ID: <3FAEB9CE.9040003@it.su.se> Date: Sun, 09 Nov 2003 23:03:58 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Brian E Carpenter CC: Alain Durand , Tim Chown , ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> <3FAEB07B.58C50161@zurich.ibm.com> In-Reply-To: <3FAEB07B.58C50161@zurich.ibm.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian E Carpenter wrote: | Alain, | | Please define "real PI (by real I mean registered)". Not having seen the | draft that defines it, I can't evaluate your argument. | I seem to remember Kurtis making a proposal but I'm not sure if it was written up anywhere (or were you making a point :-) ) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/rrnO8Jx8FtbMZncRAgeBAJ9bg961vnYKz9o7onTYEFgdf5mKLwCeI2Nc nUj98jZl4vNo9RDz8VhvDmA= =vg+D -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:14:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12664 for ; Sun, 9 Nov 2003 17:14:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxow-0001Bk-AP for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:14:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9MEACx004568 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxow-0001Bb-1H for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:14:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12641 for ; Sun, 9 Nov 2003 17:13:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxot-0000Lp-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:14:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIxot-0000Lm-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:14:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxon-00017w-Qt; Sun, 09 Nov 2003 17:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxoB-00017F-J3 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:13:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12604 for ; Sun, 9 Nov 2003 17:13:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxo9-0000LF-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:13:21 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AIxo8-0000LC-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:13:20 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hA9MDJ5u016518 for ; Sun, 9 Nov 2003 15:13:19 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HO3003X1V26M8@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Sun, 09 Nov 2003 15:13:19 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HO300AV8V25GA@mail.sun.net> for ipv6@ietf.org; Sun, 09 Nov 2003 15:13:18 -0700 (MST) Date: Sun, 09 Nov 2003 14:16:10 -0800 From: Alain Durand Subject: Re: Thoughts on the draft-hinden last call In-reply-to: <3FAEB07B.58C50161@zurich.ibm.com> To: Brian E Carpenter Cc: ipv6@ietf.org, Tim Chown Message-id: <528FFE50-1302-11D8-916A-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> <3FAEB07B.58C50161@zurich.ibm.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Nov 9, 2003, at 1:24 PM, Brian E Carpenter wrote: > Alain, > > Please define "real PI (by real I mean registered)". Not having seen > the > draft that defines it, I can't evaluate your argument. The problem with the Hinden/harbeman draft is that it allocates a part of the public IPv6 address space for private, unregistered usage. The consequence is that when (and not if) those addresses will leak in the public Internet, they will be untraceable and won't resolve at all in the reverse tree DNS. My suggestion is to let the authority in charge of administering the public IP address space to allocate directly address space from a specific bloc to whoever wants it, with no expectation that it will be routable and leave it up to the customers and their ISP to see if this gets routed or not (with a recommendation that by default it is not). That way, those addresses would be traceable the day they will leak. Of course, this requires a little extra management, and perhaps a (small) recurring fee to maintain the database instead of a one time 10 euro, but this should not stop anybody serious. If you, or the wg, thinks this avenue is worth exploring, I can write a 2 page draft. I honestly believe that this entire issue can be solved outside of the IETF by the RIRs without introducing anything new/damaging in the IPv6 architecture. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:32:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13112 for ; Sun, 9 Nov 2003 17:32:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy6V-00020r-AD for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:32:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9MWJ5Z007731 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy6V-00020c-3k for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:32:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13058 for ; Sun, 9 Nov 2003 17:32:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIy6S-0000e8-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:32:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIy6S-0000e5-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy6D-0001wC-Qj; Sun, 09 Nov 2003 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy5P-0001v0-DL for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:31:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13040 for ; Sun, 9 Nov 2003 17:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIy5M-0000di-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:31:08 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIy5L-0000dB-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:31:08 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA9MUXV18366; Mon, 10 Nov 2003 00:30:33 +0200 Date: Mon, 10 Nov 2003 00:30:32 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Alain Durand , Subject: Re: Thoughts on the draft-hinden last call In-Reply-To: <3FAEAF70.7702DB1F@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sun, 9 Nov 2003, Brian E Carpenter wrote: [...] > > As I explain in a previous message, this last property is not verified > > by the hinden/haberman draft, as when those addresses leak, > > they would create untraceable problems, very similar to the one > > caused by RFC1918 leaks today. > > Q: Who is to blame and likely to be a victim? > > A: any ISP without ingress filtering. > > To misquote Pekka, why exactly should we care if ISP X's operations > break because it fails to implement ingress filtering? Uhh, but isn't the pain felt by everyone, especially if the leakage is more subtle than source/destination address? E.g., leakage in the payload... -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:35:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13251 for ; Sun, 9 Nov 2003 17:35:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy9D-0002Ph-86 for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9MZ7hp009271 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy9D-0002PS-2p for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13227 for ; Sun, 9 Nov 2003 17:34:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIy9A-0000gY-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:35:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIy9A-0000gV-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy99-0002Ln-HN; Sun, 09 Nov 2003 17:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIy93-0002LA-VR for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:34:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13213 for ; Sun, 9 Nov 2003 17:34:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIy91-0000gE-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:34:55 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AIy90-0000g4-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:34:54 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9MYNlC054166; Sun, 9 Nov 2003 22:34:23 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9MYMlF168396; Sun, 9 Nov 2003 23:34:22 +0100 Received: from zurich.ibm.com ([9.145.246.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA60724; Sun, 9 Nov 2003 23:34:21 +0100 Message-ID: <3FAEC0C6.19A192ED@zurich.ibm.com> Date: Sun, 09 Nov 2003 23:33:42 +0100 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: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> <3FAEB07B.58C50161@zurich.ibm.com> <528FFE50-1302-11D8-916A-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain, I think it is well worth writing such a draft. It might move this debate forward. However, I'll point out one advantage of Hinden/Haberman that it cannot match - the locally-assigned version of Hinden/Haberman is instantly available when IANA assigns a prefix, without a one to two year delay to put registry policy and mechanisms in place. Brian Alain Durand wrote: > > On Nov 9, 2003, at 1:24 PM, Brian E Carpenter wrote: > > > Alain, > > > > Please define "real PI (by real I mean registered)". Not having seen > > the > > draft that defines it, I can't evaluate your argument. > > The problem with the Hinden/harbeman draft is that it allocates a part > of > the public IPv6 address space for private, unregistered usage. > The consequence is that when (and not if) those addresses > will leak in the public Internet, they will be untraceable and won't > resolve at all > in the reverse tree DNS. > > My suggestion is to let the authority in charge of administering > the public IP address space to allocate directly address space > from a specific bloc to whoever wants it, with no expectation that > it will be routable and leave it up to the customers and their ISP > to see if this gets routed or not (with a recommendation that by > default it is not). > > That way, those addresses would be traceable the day they will leak. > Of course, this requires a little extra management, > and perhaps a (small) recurring fee to maintain the database > instead of a one time 10 euro, but this should not stop anybody serious. > > If you, or the wg, thinks this avenue is worth exploring, I can write > a 2 page draft. I honestly believe that this entire issue can be > solved outside of the IETF by the RIRs without introducing anything > new/damaging in the IPv6 architecture. > > - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:43:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14718 for ; Sun, 9 Nov 2003 17:43:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyH8-0003K3-Fo for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:43:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9MhIYG012765 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:43:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyH8-0003Jo-Bl for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14564 for ; Sun, 9 Nov 2003 17:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyH5-0000x1-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:43:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIyH5-0000wy-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:43:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyGs-0003Fs-1C; Sun, 09 Nov 2003 17:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyG8-0003FO-FY for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:42:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14276 for ; Sun, 9 Nov 2003 17:42:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyG5-0000u5-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:42:13 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AIyG5-0000sf-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:42:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA9Mfda18758; Sun, 9 Nov 2003 14:41:39 -0800 X-mProtect: <200311092241> Nokia Silicon Valley Messaging Protection Received: from dyn142-204.ietf58.ietf.org (130.129.142.204, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdAQlICb; Sun, 09 Nov 2003 14:41:37 PST Message-Id: <4.3.2.7.2.20031109141830.02fc4928@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 09 Nov 2003 14:40:39 -0800 To: "Jun-ichiro itojun Hagino" From: Bob Hinden Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Cc: ipv6@ietf.org In-Reply-To: <20031109114940.A301193@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Itojun, > i object to publish this document as a standard track document. > experimental would be more preferable. I don't agree. I think this is appropriate for standards track. > unique local IPv6 unicast address avoids some problems of site-local, > but not all; there are major problem still remains. > - it is not expected to be routable, however, it will be treated > as if it is a global address. therefore it is likely to be > leak out. > 1.0 asserts that "even if it leaks out there's no conflict", but > "no conflict" is not enough - we do need to be 100% sure there's no > leak out, otherwise it is unacceptable. I don't think we have to be 100% sure. Overall I think it is much better to have a well known non-ambiguous prefix that we can have a reasonable likely hood that it is filtered. > - operationally, there's a much easier way to get a block of address > which has the features unique local IPv6 unicast address has; > it is to use 6to4 address prefix (2002:v4v4:v4v4::/48). as long as > you do not renumber IPv4 address and IPv6 address at the same time, > 6to4 address will give you enough address for the suggested use of > unique local IPv6 unicast address. moreover, 6to4 address are > routable (though there's tunnelling overhead if outsiders are to > contact 6to4 address accidentally). there is no need to define > unique local IPv6 unicast address. This approach doesn't work well for disconnected sites who may not have a global IPv4 address. I suspect they would use Net 10 IPv4 addresses. This would, of course, result in ambiguous prefixes like site-local. Something we are trying to move away from. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:44:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14912 for ; Sun, 9 Nov 2003 17:44:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyHs-0003UD-0f for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Mi35g013395 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyHr-0003Ty-Rt for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14793 for ; Sun, 9 Nov 2003 17:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyHp-0000zA-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:44:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIyHo-0000z5-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyHq-0003QB-F9; Sun, 09 Nov 2003 17:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyH9-0003K6-Q4 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:43:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14572 for ; Sun, 9 Nov 2003 17:43:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyH7-0000x9-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:43:17 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AIyH5-0000vW-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:43:15 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9MgjCU047198; Sun, 9 Nov 2003 22:42:45 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9MgilF210508; Sun, 9 Nov 2003 23:42:45 +0100 Received: from zurich.ibm.com ([9.145.246.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA47984; Sun, 9 Nov 2003 23:42:43 +0100 Message-ID: <3FAEC2BD.D62DB9BF@zurich.ibm.com> Date: Sun, 09 Nov 2003 23:42:05 +0100 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: Pekka Savola CC: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, Leakage in the payload (i.e. a referral) is problem we will have anyway, e.g. if the referred address is inside a firewall. I think that problem is unavoidable. It's true that with a fully registered PI, diagnosis is easier. Brian Pekka Savola wrote: > > On Sun, 9 Nov 2003, Brian E Carpenter wrote: > [...] > > > As I explain in a previous message, this last property is not verified > > > by the hinden/haberman draft, as when those addresses leak, > > > they would create untraceable problems, very similar to the one > > > caused by RFC1918 leaks today. > > > > Q: Who is to blame and likely to be a victim? > > > > A: any ISP without ingress filtering. > > > > To misquote Pekka, why exactly should we care if ISP X's operations > > break because it fails to implement ingress filtering? > > Uhh, but isn't the pain felt by everyone, especially if the leakage is > more subtle than source/destination address? E.g., leakage in the > payload... > > -- > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:47:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15359 for ; Sun, 9 Nov 2003 17:47:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKo-00042S-CL for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:47:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Ml6IC015518 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKo-00040s-2L for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15274 for ; Sun, 9 Nov 2003 17:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyKl-0001A8-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:47:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIyKl-0001A5-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKk-0003ua-AS; Sun, 09 Nov 2003 17:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKD-0003tU-7q for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:46:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15223 for ; Sun, 9 Nov 2003 17:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyKA-00019E-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:46:26 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1AIyK9-000189-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:46:26 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9MjtgZ021044; Sun, 9 Nov 2003 22:45:55 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9MjnlF250680; Sun, 9 Nov 2003 23:45:50 +0100 Received: from zurich.ibm.com ([9.145.246.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA43136; Sun, 9 Nov 2003 23:45:48 +0100 Message-ID: <3FAEC376.67684BED@zurich.ibm.com> Date: Sun, 09 Nov 2003 23:45:10 +0100 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: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <3FAEAF70.7702DB1F@zurich.ibm.com> <695B33A7-1300-11D8-916A-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain Durand wrote: > > On Nov 9, 2003, at 1:19 PM, Brian E Carpenter wrote: > > > Alain Durand wrote: > >> > >> On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote: > >>> In the case in point, there is a significant constituency who > >>> believes > >>> that they need a replacement for site local addresses, and that > >>> "draft-hinden" is a reasonable way to obtain this replacement. You > >>> are > >>> indeed free to not use such addresses and never deploy them within > >>> the > >>> networks that you manage, but that does not change the needs of > >>> others. > >> > >> In principle, I would almost agree with this statement, with one > >> caveat: > >> "... as long as it does not break anything in the global Internet for > >> people that do not use this proposal" > >> > >> As I explain in a previous message, this last property is not verified > >> by the hinden/haberman draft, as when those addresses leak, > >> they would create untraceable problems, very similar to the one > >> caused by RFC1918 leaks today. > > > > Q: Who is to blame and likely to be a victim? > > > > A: any ISP without ingress filtering. > > Did you never heard about the AS112 project as an example of how much > trouble RFC1918 can cause? > http://www.as112.net/ > With that regard, as hinden/haberman addresses are not resolvable in > the reverse tree DNS, > they will cause exactly the same issue as RF1918. If they are referred outside their context, sure. But that problem can arise for any form of privately used addresses, however they are assigned - if nobody puts them in the public reverse tree, they will cause problems. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 17:47:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15394 for ; Sun, 9 Nov 2003 17:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKt-00042k-KS for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 17:47:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9MlB80015536 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 17:47:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKt-00042V-F9 for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:47:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15278 for ; Sun, 9 Nov 2003 17:46:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyKm-0001AF-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:47:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIyKl-0001AC-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 17:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKm-0003w0-Dm; Sun, 09 Nov 2003 17:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyKR-0003u0-7X for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 17:46:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15248 for ; Sun, 9 Nov 2003 17:46:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyKO-00019f-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:46:40 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyKN-00019U-00 for ipv6@ietf.org; Sun, 09 Nov 2003 17:46:40 -0500 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 WAA12380 for ; Sun, 9 Nov 2003 22:46:38 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA11121 for ; Sun, 9 Nov 2003 22:46:38 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA9Mkcp13251 for ipv6@ietf.org; Sun, 9 Nov 2003 22:46:38 GMT Date: Sun, 9 Nov 2003 22:46:38 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call Message-ID: <20031109224638.GL12270@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> <3FAEB07B.58C50161@zurich.ibm.com> <528FFE50-1302-11D8-916A-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528FFE50-1302-11D8-916A-00039376A6AA@sun.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sun, Nov 09, 2003 at 02:16:10PM -0800, Alain Durand wrote: > > My suggestion is to let the authority in charge of administering > the public IP address space to allocate directly address space > from a specific bloc to whoever wants it, with no expectation that > it will be routable and leave it up to the customers and their ISP > to see if this gets routed or not (with a recommendation that by > default it is not). OK, let's compare that against the aims stated in Hinden-Haberman in section 1.0: - Globally unique prefix. - Well known prefix to allow for easy filtering at site boundaries. - Allows sites to be combined or privately interconnected without creating any address conflicts or require renumbering of interfaces using these prefixes. - Internet Service Provider independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity. - If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses. - In practice, applications may treat these address like global scoped addresses. Although I'm a little lagged :) I don't see that your proposal has different properties, "only" that you allocate from some specific block. If that block is fc00::/8 as per Hinden-Haberman, aren't we in the same position? So the real issue is the locally-assigned addresses (given that leakage is inevitable)? I think the "probably unique locally assigned" prefix crept in maybe after the above goals were written, given that the locally assigned prefixes may not be unique, and would not be registered/traceable? The one addition you have to the above goals seems to be traceability. [You also suggest a recurring fee, which this draft does not. I would prefer the draft to just say words to the effect to deter land rush on the address space, and not specifics of how.] Would it help or hurt to split this into two drafts, one proposal that is unique by registration/escrow (and that thus has traceability) and one that is probabilistically unique? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 18:02:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16726 for ; Sun, 9 Nov 2003 18:02:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyZu-0005Vf-BX for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 18:02:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9N2gCa021173 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 18:02:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyZu-0005VQ-3R for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 18:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16694 for ; Sun, 9 Nov 2003 18:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyZq-0001aR-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 18:02:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIyZo-0001aO-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 18:02:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyZF-0005Ny-7i; Sun, 09 Nov 2003 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyYd-0005La-BB for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 18:01:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16656 for ; Sun, 9 Nov 2003 18:01:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyYa-0001a3-00 for ipv6@ietf.org; Sun, 09 Nov 2003 18:01:20 -0500 Received: from dyn138-234.ietf58.ietf.org ([130.129.138.234] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1AIyYZ-0001a0-00 for ipv6@ietf.org; Sun, 09 Nov 2003 18:01:20 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hA9N1DS02179; Mon, 10 Nov 2003 00:01:13 +0100 Message-ID: <3FAEC738.8080201@it.su.se> Date: Mon, 10 Nov 2003 00:01:12 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Brian E Carpenter CC: Pekka Savola , ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call References: <3FAEC2BD.D62DB9BF@zurich.ibm.com> In-Reply-To: <3FAEC2BD.D62DB9BF@zurich.ibm.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian E Carpenter wrote: | Pekka, | | Leakage in the payload (i.e. a referral) is problem we will have anyway, | e.g. if the referred address is inside a firewall. I think that problem There are important differences between the two types of leakage though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/rsc48Jx8FtbMZncRAm/MAJ97TXjCZYI44ToNSsPpjAMtkXOsrwCeM1YO KIFeOIsC5L7vfOlnL+AWmto= =hc4+ -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 18:15:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18185 for ; Sun, 9 Nov 2003 18:15:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIym0-0006Fs-PM for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 18:15:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9NFCx7024038 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 18:15:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIym0-0006Fd-Hx for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 18:15:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18106 for ; Sun, 9 Nov 2003 18:14:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIylx-0001k2-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 18:15:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIylx-0001jz-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 18:15:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyls-0006Bn-0L; Sun, 09 Nov 2003 18:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIylj-0006BI-E8 for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 18:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18070 for ; Sun, 9 Nov 2003 18:14:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIylg-0001jl-00 for ipv6@ietf.org; Sun, 09 Nov 2003 18:14:52 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AIylf-0001jb-00 for ipv6@ietf.org; Sun, 09 Nov 2003 18:14:52 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA9NE7x04774; Sun, 9 Nov 2003 15:14:07 -0800 X-mProtect: <200311092314> Nokia Silicon Valley Messaging Protection Received: from dyn142-204.ietf58.ietf.org (130.129.142.204, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd6ishaD; Sun, 09 Nov 2003 15:14:04 PST Message-Id: <4.3.2.7.2.20031109144725.02edb578@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 09 Nov 2003 15:13:10 -0800 To: Alain Durand From: Bob Hinden Subject: Re: Thoughts on the draft-hinden last call Cc: Brian E Carpenter , ipv6@ietf.org, Tim Chown In-Reply-To: <528FFE50-1302-11D8-916A-00039376A6AA@sun.com> References: <3FAEB07B.58C50161@zurich.ibm.com> <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> <3FAEB07B.58C50161@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Alain, >If you, or the wg, thinks this avenue is worth exploring, I can write >a 2 page draft. I honestly believe that this entire issue can be >solved outside of the IETF by the RIRs without introducing anything >new/damaging in the IPv6 architecture. ULA do not introduce a change to the IPv6 architecture. They are only another way of allocating global unicast addresses. Implementations will treat them like other types of global unicast addresses. Like other types of IPv6 global unicast addresses they may be routable or not. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 9 18:24:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18715 for ; Sun, 9 Nov 2003 18:24:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyug-0007BT-UQ for ipv6-archive@odin.ietf.org; Sun, 09 Nov 2003 18:24:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9NOAQH027615 for ipv6-archive@odin.ietf.org; Sun, 9 Nov 2003 18:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyug-0007BK-Fm for ipv6-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 18:24:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18669 for ; Sun, 9 Nov 2003 18:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyud-0001wF-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 18:24:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIyuc-0001wC-00 for ipv6-web-archive@ietf.org; Sun, 09 Nov 2003 18:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyuY-00077X-DO; Sun, 09 Nov 2003 18:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyuB-00076Y-Kp for ipv6@optimus.ietf.org; Sun, 09 Nov 2003 18:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18653 for ; Sun, 9 Nov 2003 18:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyu8-0001vl-00 for ipv6@ietf.org; Sun, 09 Nov 2003 18:23:36 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AIyu8-0001vf-00 for ipv6@ietf.org; Sun, 09 Nov 2003 18:23:36 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA9NNaPh023614 for ; Sun, 9 Nov 2003 16:23:36 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HO300DNHYBB66@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Sun, 09 Nov 2003 16:23:36 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HO3009N2YB7M9@mail.sun.net> for ipv6@ietf.org; Sun, 09 Nov 2003 16:23:35 -0700 (MST) Date: Sun, 09 Nov 2003 15:26:22 -0800 From: Alain Durand Subject: Re: Thoughts on the draft-hinden last call In-reply-to: <4.3.2.7.2.20031109144725.02edb578@mailhost.iprg.nokia.com> To: Bob Hinden Cc: ipv6@ietf.org, Brian E Carpenter , Tim Chown Message-id: <21396E4C-130C-11D8-916A-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3FAEB07B.58C50161@zurich.ibm.com> <6DA388EC-0E92-11D8-821A-00039376A6AA@sun.com> <20031104084810.GE30061@login.ecs.soton.ac.uk> <3FAEB07B.58C50161@zurich.ibm.com> <4.3.2.7.2.20031109144725.02edb578@mailhost.iprg.nokia.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Nov 9, 2003, at 3:13 PM, Bob Hinden wrote: > Alain, > >> If you, or the wg, thinks this avenue is worth exploring, I can write >> a 2 page draft. I honestly believe that this entire issue can be >> solved outside of the IETF by the RIRs without introducing anything >> new/damaging in the IPv6 architecture. > > ULA do not introduce a change to the IPv6 architecture. They are only > another way of allocating global unicast addresses. Implementations > will treat them like other types of global unicast addresses. Like > other types of IPv6 global unicast addresses they may be routable or > not. I disagree. They are different because they have different properties by design. So if an application is returned both type, it will have to make a choice... This, for me, is a change in the architecture. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 00:15:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25829 for ; Mon, 10 Nov 2003 00:15:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4Op-0005oA-Sv for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 00:15:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAA5FdVa022322 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 00:15:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4Op-0005nx-Mj for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 00:15:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25801 for ; Mon, 10 Nov 2003 00:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4On-0006eV-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 00:15:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ4Om-0006eS-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 00:15:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4OG-0005iG-ED; Mon, 10 Nov 2003 00:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4O3-0005hc-JM for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 00:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25781 for ; Mon, 10 Nov 2003 00:14:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4O1-0006ZA-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:14:49 -0500 Received: from web80504.mail.yahoo.com ([66.218.79.74]) by ietf-mx with smtp (Exim 4.12) id 1AJ4O0-0006Yb-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:14:48 -0500 Message-ID: <20031110051419.98144.qmail@web80504.mail.yahoo.com> Received: from [130.129.72.244] by web80504.mail.yahoo.com via HTTP; Sun, 09 Nov 2003 21:14:19 PST Date: Sun, 9 Nov 2003 21:14:19 -0800 (PST) From: Fred Templin Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1817518015-1068441259=:94772" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1817518015-1068441259=:94772 Content-Type: text/plain; charset=us-ascii As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-1817518015-1068441259=:94772 Content-Type: text/html; charset=us-ascii
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-1817518015-1068441259=:94772-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 00:32:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26235 for ; Mon, 10 Nov 2003 00:32:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4eq-0006gS-LI for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 00:32:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAA5WCQj025686 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 00:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4eq-0006gD-HQ for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 00:32:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26210 for ; Mon, 10 Nov 2003 00:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4en-0006tL-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 00:32:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ4en-0006tI-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 00:32:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4eh-0006cZ-1z; Mon, 10 Nov 2003 00:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4e3-0006c3-5l for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 00:31:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26182 for ; Mon, 10 Nov 2003 00:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4e0-0006se-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:31:20 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4dz-0006sb-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:31:19 -0500 Received: from ocean.jinmei.org (unknown [2001:468:19ff:80:fd61:7fa4:3e42:5f4b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 80E841521A for ; Mon, 10 Nov 2003 14:31:18 +0900 (JST) Date: Mon, 10 Nov 2003 14:31:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: A list of issues for RFC2462 update In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 17 Oct 2003 17:40:52 +0900, >>>>> JINMEI Tatuya said: > The attached below is a issue list to make necessary updates on > RFC2462 (Stateless Address Autoconfiguration). I've slightly revised the list mainly based on comments received so far. (Some URLs do not seem to be available...sorry about that) I'm going to propose how to address (or not address) the issues in separate threads. A general rule (as I understood it) is: - changes should basically be clarifications or obvious bug fixes - do not break compatibility with existing implementations - do not introduce new features Of course, some issues may still be controversial in terms of the basic rule. We'll discuss such issues later to get a consensus. Thanks, p.s. if I clearly missed something that was commented on the list or privately, please let me know. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Easy ones (which will only need some editorial works): 1. A minor typo by Ignatios Souvatzis, Dec. 1998 http://www.wcug.wwu.edu/lists/ipng/199812/msg00043.html (already fixed in rfc2462bis-00) 2. Dead Code in Addrconf DOS Algortim Prevention by Jim Bound, Nov 1998 http://www.wcug.wwu.edu/lists/ipng/199811/msg00024.html 3. A corner case about inbound NA processing by Richard Draves (via TAHI test), Jun 2000 There was a consensus on the behavior, but the text is not clear. Need to update. 4. Unclear text about StoredLifetime by jinmei, Aug 2001 http://www.wcug.wwu.edu/lists/ipng/200108/msg00541.html need to clarify the text. 5. Remove references to site-local addresses === Issues that may require some discussion, but will not be very hard to get consensus: 6. Source address selection issues wrt deprecated addresses mainly by Richard Draves, several times. e.g. which should be preferred between a deprecated address and smaller-scope address? 7. Deprecated address handling (the semantics of "new communication" is not very clear) by itojun, Nov 2000 and Aug 2002 There seemed to be a consensus on a text proposed by Thomas Narten: http://www.atm.tut.fi/list-archive/ipng/msg05182.html Erik Nordmark made a related point (what if an application specifies a deprecated address as a source address): http://www.atm.tut.fi/list-archive/ipng/msg05311.html 8. Semantics about the L=0 and A=1 case by Fred Templin, Feb 2003 Thomas Narten said he did not see the need for further clarification (which I agree on): http://www.atm.tut.fi/list-archive/ipng/msg07820.html 9. Using stable storage for autoconfigured addresses by Erik Nordmark, Jun 2002 http://www.atm.tut.fi/list-archive/ipng/msg04383.html There seemed to be no discussion on this. Erik thought "it is quite reasoanble that implementations that have stable storage retain their addresses and expiry times (preferred and valid) whether the addresses were acquired using RFC 2462 or DHCP." 11. IEEE 802.11 devices do not meet a requirement described in RFC2462 As pointed out in draft-park-ipv6-dad-problem-wlan-00.txt === Issues that may be controversial: 12. Conflict with the MLD spec about random delay for the first packet by Greg Daley, May 2005 http://www.atm.tut.fi/list-archive/ipng/msg09614.html The first NS for a DAD is usually not the first packet from the sending node, since an MLD report should usually sent before the NS. 13. DAD related issues inconsistency in the text (mixture of SHOULD and MAY) by itojun, Jun 2001 What about the link partitioning case by Pekka Savola, Jun 2001(?) omitting DAD, DAD vs DIID, various delays in DAD, etc. many people, many times 14. Possible Denial of Service Attack by Ken Powell, Feb 2000 What if a malicious node intentionally sends prefixes for other LANs? It kills communication from the attacked link to the other LAN. There seemed to be no clear consensus. (The SEND req draft does not seem to talk about this issue.) 15. The semantics of the M/O flags by several people, several times. Points from Ralph Droms in Mar 2003 seems to be a good starting point: http://www.atm.tut.fi/list-archive/ipng/msg03047.html a. the text needs to be updated to use RFC 2119 keywords b. which keywords? c. what is "the stateful configuration protocol"? d. if the answer to "c" is DHCPv6, should RFC 2462 more explicitly reference the configuration-only version of DHCPv6 in the description of the 'O'flag? Adam Machalek also pointed out some inconsistency about mandatory level of the stateful configuration protocol: http://www.atm.tut.fi/list-archive/ipng/msg04363.html We have three occurrences in RFC2462 related to this issue. The first two do not have RFC2119 keywords: - Section 4 (PROTOCOL OVERVIEW) a managed address configuration flag indicates whether hosts should use stateful autoconfiguration - Section 5.2 (Autoconfiguration-Related Variables) (M flag) The flag indicates whether or not addresses are to be configured using the stateful autoconfiguration mechanism. (O flag) The flag indicates whether or not information other than addresses is to be obtained using the stateful autoconfiguration mechanism. - Section 5.5.2 (Absence of Router Advertisements) If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. 16. Whether a (not a host) router can autoconfigure itself using RFC2462 (or bis) including if a router can configure a global address by stateless autoconf if a router can configure a link-local address in a way described in RFC 2462 if a router can configure itself about "other" configuration information by several people, several times 17. If we need a 'not-yet-ready' status of an autoconfigured address to help renumbering operation by Fred Baker, Apr 2003 http://www.atm.tut.fi/list-archive/ipng/msg09394.html 18. Avoiding interface failure upon DAD failure (mainly) by Jari Arkko, May 2003 RFC2462 says in Section 5.4.5 (When Duplicate Address Detection Fails) that: A tentative address that is determined to be a duplicate as described above, MUST NOT be assigned to an interface and the node SHOULD log a system management error. If the address is a link-local address formed from an interface identifier, the interface SHOULD be disabled. Jari pointed out the latter requirement may be too strong. However, the latest mip6 draft leaves this as "ND extensions". draft-ietf-mobileip-ipv6-24.txt says in B.6 (Neighbor Discovery Extensions) that: For instance, mechanisms that would allow recovery from a Duplicate Address Detection collision would be useful for link-local, care-of, and home addresses. 19. If RFC2462 requires 64bit IFID by several people, several times. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 00:42:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26507 for ; Mon, 10 Nov 2003 00:42:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4oh-0007Z0-0P for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 00:42:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAA5gMOQ029074 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 00:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4og-0007Yr-O9 for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 00:42:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26473 for ; Mon, 10 Nov 2003 00:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4oe-0006z5-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 00:42:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ4od-0006z2-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 00:42:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4oM-0007Q6-5n; Mon, 10 Nov 2003 00:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ4nP-0007PN-19 for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 00:41:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26447 for ; Mon, 10 Nov 2003 00:40:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ4nM-0006yg-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:41:00 -0500 Received: from [47.166.48.91] (helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AJ4nL-0006yP-00 for ipv6@ietf.org; Mon, 10 Nov 2003 00:40:59 -0500 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAA5eQj14198; Mon, 10 Nov 2003 05:40:27 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 05:40:28 -0000 Message-ID: <4103264BC8D3D51180B7002048400C45043ABBBC@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: ipv6@ietf.org Cc: Christian Huitema , Brian E Carpenter Subject: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Date: Mon, 10 Nov 2003 05:40:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A74D.1F0F9582" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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_01C3A74D.1F0F9582 Content-Type: text/plain I am generally happy with the document after reviewing it. I found a number of fairly trivial nits, plus one wording query: Section 2.3, first para - also an editorial nit in same para: In the first para the draft says: The ambiguity of site local addresses also creates problems for the routers. In theory, site local addresses are only used within a contiguous site, and all routers in that site can treat them as if they were not ambiguous. In practice, problem occurs when sites are ------- the problem disjoint, or when routers have to handle several sites I am not sure that the word 'disjoint' is right here. When I read it I wasn't sure whether the intention was to callout situations where 'sites' overlapped and the word 'not' was missing. The next sentence clarifies that we a dealing with sites which are partitioned but the components are not directly connected. I think partitioned might be a better description. Editorial nits: Section 1: It might be desirable to add 'unicast' to site local on the first occurrence (as this what the discussion has been about) and would be desirable for the second occurrence. Section 2.2, para 3: The experience with RFC1918 addresses also shows some non trivial leaks, besides pacing these addresses in IP headers. Private ------ s/b placing Section 2.2, last para: The second sentence may be a little too colloquial. Section 2.3, 4th para: In multi-homed routers, such as for example site border routers, the routing process should be complemented by a filtering process, to guarantee that packets sourced with a site local address never leave the site. This filtering process will in turn interact with the routing of packets, as it may cause the drop of packets sent to a ---- dropping Section 2.5: Spurious blank line in 1st para. Section3: Non-ambiguous should be hypenated throughout - currently there is a mixture of hyphenated and non hyphenated(sic). Section3, last para: One question remains, anycast addressing. Anycast addresses are ambiguous by construction, since they refer by definition to any host that has been assigned a given anycast address. Link-local or global anycast addresses can be"baked in the code". ---- missing space Regards, Elwyn Davies > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: 05 November 2003 18:27 > To: ipv6@ietf.org > Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" > > > This is a reminder that the last call on the deprecation document > ends today. In particular, the chairs would like to ensure that > the WG agrees on the actual deprecation text in Sections 4 & 6. > There has been few comments on this draft and it cannot proceed > unless the chairs can be sure that it has been thoroughly reviewed > and agreed upon. > > If you have reviewed the document, have no issues with it, and agree > on its content, please let the chairs and/or the working group know. > > Thanks, > Brian & Bob > IPv6 WG Chairs > > Brian Haberman wrote: > > > This is a IPv6 working group last call for comments on advancing the > > following document as an Proposed Standard: > > > > Title : Deprecating Site Local Addresses > > Author(s) : C. Huitema, B. Carpenter > > Filename : draft-ietf-ipv6-deprecate-site-local-01.txt > > Pages : 10 > > Date : 2003-10-13 > > > > Please send substantive comments to the ipv6 mailing list, and minor > > editorial comments to the authors. This last call period > will end on 5 > > November 2003. > > > > Brian Haberman / Bob Hinden > > IPv6 W.G. Chairs > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ------_=_NextPart_001_01C3A74D.1F0F9582 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IPv6 w.g. Last Call on "Deprecating Site Local = Addresses"

I am generally happy with the document after = reviewing it.  I found a number of fairly trivial nits, plus one = wording query:

Section  2.3, first para - also an editorial nit = in same para:
In the first para the draft says:
   The ambiguity of site local addresses = also creates problems for the
   routers. In theory, site local = addresses are only used within a
   contiguous site, and all routers in = that site can treat them as if
   they were not ambiguous. In practice, = problem occurs when sites are
          &nb= sp;           &nb= sp;           &nb= sp;      -------
          &nb= sp;           &nb= sp;           &nb= sp;      the problem  
   disjoint, or when routers have to = handle several sites

I am not sure that the word 'disjoint' is right = here.  When I read it I wasn't sure whether the intention was to = callout situations where 'sites' overlapped and the word 'not' was = missing.  The next sentence clarifies that we a dealing with sites = which are partitioned but the components are not directly = connected.   I think partitioned might be a better = description.

Editorial nits:

Section 1: It might be desirable to add 'unicast' to = site local on the first occurrence (as this what the discussion has = been about) and would be desirable for the second = occurrence.

Section 2.2, para 3:
   The experience with RFC1918 addresses = also shows some non trivial
   leaks, besides pacing these addresses = in IP headers. Private
          &nb= sp;       ------ s/b
          &nb= sp;       placing

Section 2.2, last para:
The second sentence may be a little too = colloquial.

Section 2.3, 4th para:
 In multi-homed routers, such as for example = site border routers, the
   routing process should be complemented = by a filtering process, to
   guarantee that packets sourced with a = site local address never leave
   the site. This filtering process will = in turn interact with the
   routing of packets, as it may cause the = drop of packets sent to a
          &nb= sp;           &nb= sp;           &nb= sp;        ----
          &nb= sp;           &nb= sp;           &nb= sp;        dropping

Section 2.5: Spurious blank line in 1st para.

Section3:
Non-ambiguous should be hypenated throughout - = currently there is a mixture of hyphenated and non = hyphenated(sic).

Section3, last para:
   One question remains, anycast = addressing. Anycast addresses are
   ambiguous by construction, since they = refer by definition to any
   host that has been assigned a given = anycast address. Link-local or
   global anycast addresses can = be"baked in the code".
          &nb= sp;           &nb= sp;          ---- missing = space

Regards,
Elwyn Davies
> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net= ]
> Sent: 05 November 2003 18:27
> To: ipv6@ietf.org
> Subject: Re: IPv6 w.g. Last Call on = "Deprecating Site Local Addresses"
>
>
> This is a reminder that the last call on the = deprecation document
> ends today.  In particular, the chairs = would like to ensure that
> the WG agrees on the actual deprecation text in = Sections 4 & 6.
> There has been few comments on this draft and = it cannot proceed
> unless the chairs can be sure that it has been = thoroughly reviewed
> and agreed upon.
>
> If you have reviewed the document, have no = issues with it, and agree
> on its content, please let the chairs and/or = the working group know.
>
> Thanks,
> Brian & Bob
> IPv6 WG Chairs
>
> Brian Haberman wrote:
>
> > This is a IPv6 working group last call for = comments on advancing the
> > following document as an Proposed = Standard:
> >
> >     = Title        : Deprecating Site = Local Addresses
> >     = Author(s)    : C. Huitema, B. Carpenter
> >     = Filename    : = draft-ietf-ipv6-deprecate-site-local-01.txt
> >     = Pages        : 10
> >     = Date        : 2003-10-13
> >
> > Please send substantive comments to the = ipv6 mailing list, and minor
> > editorial comments to the authors.  = This last call period
> will end on 5
> > November 2003.
> >
> > Brian Haberman / Bob Hinden
> > IPv6 W.G. Chairs
>
>
> = --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6=
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C3A74D.1F0F9582-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 06:06:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15624 for ; Mon, 10 Nov 2003 06:06:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ9sY-0006Zu-0z for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 06:06:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAB6fO9025283 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 06:06:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ9sX-0006Zg-PC for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 06:06:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15587 for ; Mon, 10 Nov 2003 06:06:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ9sQ-0002qN-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 06:06:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ9sQ-0002qK-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 06:06:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ9ru-0006PM-KS; Mon, 10 Nov 2003 06:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ9rr-0006Ov-Re for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 06:05:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15576 for ; Mon, 10 Nov 2003 06:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ9rn-0002q6-00 for ipv6@ietf.org; Mon, 10 Nov 2003 06:05:55 -0500 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1AJ9rm-0002q2-00 for ipv6@ietf.org; Mon, 10 Nov 2003 06:05:55 -0500 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 hAAB44Rc051377 for ; Mon, 10 Nov 2003 22:04:49 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Nov 2003 21:36:29 +1100 To: ipv6@ietf.org From: Geoff Huston Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 12:51 PM 9/11/2003 +0000, Tim Chown wrote: >On Sun, Nov 09, 2003 at 08:49:40PM +0900, Jun-ichiro itojun Hagino wrote: > > > > - it is not expected to be routable, however, it will be treated > > as if it is a global address. therefore it is likely to be > leak out. > > 1.0 asserts that "even if it leaks out there's no conflict", but > > "no conflict" is not enough - we do need to be 100% sure there's no > > leak out, otherwise it is unacceptable. > >I don't think we'd ever get 100% confidence of zero leakage, but that >shouldn't >deter us from having a site-local addressing scheme that at least cures the >other major problem of ambiguity in the addresses. I think the Hinden draft >can only fix the ambiguity problem. But if people use Hinden-draft the >leakage is more readily traced. As I've pointed out a number of times the Hinden draft does not remove ambiguity completely, given its specification of a local use algorithm. It is not completely clear to me that the algorithm presented in the draft is a robust way to assess the probability of collision - the analysis I undertook and documented indicated that any 'perfectly' random selection algorithm, where one global id was as likely as any other to be generated each time the algorithm was run, would have a probability greater than 0.5 that at least 2 outcomes were identical once 1.24 million selection outcomes were drawn from such a 'perfectly' random algorithm. 'no conflict' as an absolute assertion, as distinct form a prediction based on probabilities and the degree of randomness of a random draw algorithm that may or may not be used by end sites for global id selection ("after all its local use - so maybe I'll just save a bit of time and use an id of '1' in my local config" :-( ) is not what the local use part of this draft is actually providing here. If you wanted to have an absolute assurance that no collisions occur in this space then it is necessary to drop the local draw section of the proposal and manage the entire space using the central registry draw mechanism. So I think the "cures the other major problem of ambiguity" is not an entirely technically accurate statement - "mitigates" or even "provides some increased level of assurance" is a more precise phrase here. And maybe that's adequate, or maybe not. After thinking about this and looking at the evident need to make some progress here I'd like to believe that this level of resolution of potential ambiguity is adequate, given that there is always the option to use a central registry draw to obtain a global id that is assuredly unique. My other issues with the current rev of the draft are still on the table, and of course I'd be happy to work with the authors to come up with some revised words that may find some reasonable (rough) wg consensus, and still remain within the overall spirit and intent of this proposal. Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 10:41:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25290 for ; Mon, 10 Nov 2003 10:41:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEAK-0003NQ-Pp for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 10:41:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFfKcB012974 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 10:41:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEAK-0003NB-JU for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 10:41:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25213 for ; Mon, 10 Nov 2003 10:41:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEAI-0006Fo-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 10:41:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEAH-0006Fk-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 10:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE85-00033o-V8; Mon, 10 Nov 2003 10:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJE7S-0002zd-Ak for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 10:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25099 for ; Mon, 10 Nov 2003 10:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJE7P-0006D7-00 for ipv6@ietf.org; Mon, 10 Nov 2003 10:38:19 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AJE7O-0006D4-00 for ipv6@ietf.org; Mon, 10 Nov 2003 10:38:19 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L2W1AW4RGQ8WZ7R6@vaxh.its.monash.edu.au> for ipv6@ietf.org; Tue, 11 Nov 2003 02:37:58 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 8CDCD39C003; Tue, 11 Nov 2003 02:37:58 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 7C9B32DC005; Tue, 11 Nov 2003 02:37:58 +1100 (EST) Date: Tue, 11 Nov 2003 02:37:58 +1100 From: Gregory Daley Subject: Re: RE: Issue 13: Omission of prefix options - summary To: "Bound, Jim" Cc: greg.daley@eng.monash.edu.au, JinHyeock Choi , Soliman Hesham , ipv6@ietf.org, Tim Hartrick Message-id: <161c2915dd41.15dd41161c29@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Jim, ----- Original Message ----- From: "Bound, Jim" Date: Friday, November 7, 2003 5:00 pm Subject: RE: Issue 13: Omission of prefix options - summary > Greg, > > That is good and clear mail. Thanks then lets see what happens > at DNA BOF. I am on mipshop and quite nervous about the > extreme conservative charter for time-to-market of those > technologies as a note. I missed that charter discussion > and I plan on being at DNA BOF if for no other reasons self > defense. I hope there are even better reasons than that to visit the BoF :) The close nature of the MIPSHOP group has been a concern which initially drove the DNA BoF. At this stage, (as you can see) there is some early work to get this worked out for DNA (or some other modification to ND). I'd have to say that a comprehensive solution for DNA still needs work. We're starting to get a good idea of what's useful to DNA though (the problem and goals). Hopefully we can develop this into a coherent draft solution before the next IETF. > So DNA BOF > Look at what is needed not done in mipshop > then look at 2461. > > Here is my reasoning why its ok to do ND extensions out of IPv6 WG I > will share with you and why more importantly it is good for the IETF > processes to keep evolving specs in a reasonable manner. As > implementoras you, I have no issue of having ND integrated into a > spec for a > specific purpose. Even if one whacks reserved fields in 2461 > because if > implementor just supports 2461 but not MIPv6 it will just work > just like > any good engineering mod overlay. Now if the 2461 overlay needs an > update that is different I agree. And that does not mean it changes > standards track status because of adding an overlay. Indeed. rfc2461bis is for clarification, not new function. > Anyway here is my logic using a systems view: > > ------------------------------- > Whenever one can multitask or multithread and solve problems > simultaneously with discrete vectors the system is more efficient. > The > key is to manage all vectors so they do not break the overall > system. I > believe an IETF spec can extend a core spec and it just needs to be > reviewed by that core spec center of expertise without adding to the > core spec. This permits work to flow around the core spec as an > extension and not all vectors bottleneck at the one core spec. > This is > also a theory I have how to live with chaos within systems and > extensionto how nature operates on our planet. But that gets into > all systems > not just IETF. > ----------------------------- I think this is a good way to look at things (and accords with how I see things). Please tell me if I don't seem to be following this maxim. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 12:35:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02455 for ; Mon, 10 Nov 2003 12:35:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFwZ-0004Je-FP for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 12:35:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAHZFTT016589 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 12:35:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFwZ-0004JU-8I for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 12:35:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02378 for ; Mon, 10 Nov 2003 12:35:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFwX-00010u-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 12:35:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFwW-00010r-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 12:35:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFvO-00042a-92; Mon, 10 Nov 2003 12:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFv9-0003xf-Tv for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 12:33:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02265 for ; Mon, 10 Nov 2003 12:33:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFv8-0000yZ-00 for ipv6@ietf.org; Mon, 10 Nov 2003 12:33:46 -0500 Received: from web80510.mail.yahoo.com ([66.218.79.80]) by ietf-mx with smtp (Exim 4.12) id 1AJFv7-0000xn-00 for ipv6@ietf.org; Mon, 10 Nov 2003 12:33:45 -0500 Message-ID: <20031110173314.23014.qmail@web80510.mail.yahoo.com> Received: from [130.129.65.242] by web80510.mail.yahoo.com via HTTP; Mon, 10 Nov 2003 09:33:14 PST Date: Mon, 10 Nov 2003 09:33:14 -0800 (PST) From: Fred Templin Subject: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031110051419.98144.qmail@web80504.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-865920420-1068485594=:22385" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-865920420-1068485594=:22385 Content-Type: text/plain; charset=us-ascii I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-865920420-1068485594=:22385 Content-Type: text/html; charset=us-ascii
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-865920420-1068485594=:22385-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 13:46:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05024 for ; Mon, 10 Nov 2003 13:46:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH3O-0008Tm-Md for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 13:46:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAIkMH4032590 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 13:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH3O-0008TK-3r for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 13:46:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04979 for ; Mon, 10 Nov 2003 13:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJH3L-000254-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 13:46:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJH3L-000251-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 13:46:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH29-0008Cs-RZ; Mon, 10 Nov 2003 13:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH1g-0008CH-8s for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 13:44:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04934 for ; Mon, 10 Nov 2003 13:44:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJH1d-00020r-00 for ipv6@ietf.org; Mon, 10 Nov 2003 13:44:34 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AJH1d-00020S-00 for ipv6@ietf.org; Mon, 10 Nov 2003 13:44:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAAIhxB04383; Mon, 10 Nov 2003 10:43:59 -0800 X-mProtect: <200311101843> Nokia Silicon Valley Messaging Protection Received: from dyn142-204.ietf58.ietf.org (130.129.142.204, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdZtPkec; Mon, 10 Nov 2003 10:43:57 PST Message-Id: <4.3.2.7.2.20031110104020.03642440@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 10:43:02 -0800 To: Geoff Huston From: Bob Hinden Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Cc: ipv6@ietf.org In-Reply-To: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Geoff, >After thinking about this and looking at the evident need to make some >progress >here I'd like to believe that this level of resolution of potential ambiguity >is adequate, given that there is always the option to use a central >registry draw to >obtain a global id that is assuredly unique. > >My other issues with the current rev of the draft are still on the table, >and of course >I'd be happy to work with the authors to come up with some revised words >that may find >some reasonable (rough) wg consensus, and still remain within the overall >spirit >and intent of this proposal. Thanks. That would be very helpful. I will contact you off list and see if we can get together to come with some wording that could be presented to the w.g. during the Thursday session. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 14:54:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08979 for ; Mon, 10 Nov 2003 14:54:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI77-0005LP-NC for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 14:54:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJsHdh020535 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 14:54:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI77-0005L8-9x for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14:54:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08894 for ; Mon, 10 Nov 2003 14:54:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI74-0003Le-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 14:54:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJI74-0003La-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 14:54:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI5u-00050A-Ef; Mon, 10 Nov 2003 14:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI5Y-0004zb-Nk for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 14:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08795 for ; Mon, 10 Nov 2003 14:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI5V-0003JO-00 for ipv6@ietf.org; Mon, 10 Nov 2003 14:52:37 -0500 Received: from web80504.mail.yahoo.com ([66.218.79.74]) by ietf-mx with smtp (Exim 4.12) id 1AJI5U-0003J2-00 for ipv6@ietf.org; Mon, 10 Nov 2003 14:52:37 -0500 Message-ID: <20031110195204.74981.qmail@web80504.mail.yahoo.com> Received: from [130.129.140.51] by web80504.mail.yahoo.com via HTTP; Mon, 10 Nov 2003 11:52:04 PST Date: Mon, 10 Nov 2003 11:52:04 -0800 (PST) From: Fred Templin Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" To: Alain Durand , Bob Hinden Cc: Geoff Huston , ipv6@ietf.org In-Reply-To: <3FAFE8AA.6010009@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-858178631-1068493924=:74314" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-858178631-1068493924=:74314 Content-Type: text/plain; charset=us-ascii How about this - what if we let individual users randomly self generate an address which they then take to the registration authority. If no one else has previously registered the address, the registration authority grants the assignment and records it in the registration database. If the address was already taken, the user repeats the random self generation process and asks again to have the registration recorded. The process should converge after relatively few iterations given a reasonable random self-generation scheme - especially if the pool of addresses is large. Any thoughts on this idea? Fred osprey67@yahoo.com Alain Durand wrote: I think that if you were to drop entirely the randomly self generated addresses and do not say anything about the fee scruture except it has to be low cost, it would be a much more swallable pill. - Alain. Bob Hinden wrote: > Geoff, > >> After thinking about this and looking at the evident need to make >> some progress >> here I'd like to believe that this level of resolution of potential >> ambiguity >> is adequate, given that there is always the option to use a central >> registry draw to >> obtain a global id that is assuredly unique. >> >> My other issues with the current rev of the draft are still on the >> table, and of course >> I'd be happy to work with the authors to come up with some revised >> words that may find >> some reasonable (rough) wg consensus, and still remain within the >> overall spirit >> and intent of this proposal. > > > Thanks. That would be very helpful. I will contact you off list and > see if we can get together to come with some wording that could be > presented to the w.g. during the Thursday session. > > Bob > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-858178631-1068493924=:74314 Content-Type: text/html; charset=us-ascii
How about this - what if we let individual users randomly self
generate an address which they then take to the registration
authority. If no one else has previously registered the address,
the registration authority grants the assignment and records
it in the registration database. If the address was already taken,
the user repeats the random self generation process and asks
again to have the registration recorded. The process should
converge after relatively few iterations given a reasonable
random self-generation scheme - especially if the pool of
addresses is large.

Any thoughts on this idea?
 
Fred
osprey67@yahoo.com

Alain Durand <Alain.Durand@Sun.COM> wrote:
I think that if you were to drop entirely the randomly self generated
addresses
and do not say anything about the fee scruture except it has to
be low cost, it would be a much more swallable pill.

- Alain.


Bob Hinden wrote:

> Geoff,
>
>> After thinking about this and looking at the evident need to make
>> some progress
>> here I'd like to believe that this level of resolution of potential
>> ambiguity
>> is adequate, given that there is always the option to use a central
>> registry draw to
>> obtain a global id that is assuredly unique.
>>
>> My other issues with the current rev of the draft are still on the
>> table, and of course
>> I'd be happy to work with the authors to come up with some revised
>> words that may find
>> some reasonable (rough) wg consensus, and still remain within the
>> overall spirit
>> and intent of this proposal.
>
>
> Thanks. That would be very helpful. I will contact you off list and
> see if we can get together to come with some wording that could be
> presented to the w.g. during the Thursday session.
>
> Bob
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-858178631-1068493924=:74314-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 15:17:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10998 for ; Mon, 10 Nov 2003 15:17:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJISz-0007Ji-2p for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:16:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKGre8028122 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJISy-0007JQ-RN for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:16:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10850 for ; Mon, 10 Nov 2003 15:16:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJISx-0003os-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:16:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJISx-0003op-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:16:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJISA-0006vI-1L; Mon, 10 Nov 2003 15:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIRQ-0006sQ-DV for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 15:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10661 for ; Mon, 10 Nov 2003 15:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIRO-0003kX-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:15:15 -0500 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AJIRO-0003kU-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:15:14 -0500 Received: from ssprunk (ip154.post-vineyard.dfw.interquest.net [66.135.181.154]) by ns2.sea (8.12.10/8.12.5) with SMTP id hAAKFCJR007082; Mon, 10 Nov 2003 12:15:13 -0800 Message-ID: <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Iljitsch van Beijnum" , "Hans Kruse" Cc: References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Mon, 10 Nov 2003 14:08:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Iljitsch van Beijnum" > 1. To number systems/interfaces that are only accessible from withing > the local network. >... > In the case of 1. the scope is site local, although the difinition of > "site" may be subject to change. Perhaps it'd clear things up if we changed the common name to "org(anization) local" addresses? I believe that was the intent behind the original site-local addresses, but many/most end-users have more than one phyiscal site and may be confused. > Being able to route these addresses throughout the internet would be > more of a drawback than a usable feature, as packets using these > addresses may not enter or leave the network. I think it would be reasonable to add a section explicitly stating such addresses SHOULD NOT be routed in public networks, but that end-user organizations MAY use them amongst themselves on private connections. 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 15:18:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11133 for ; Mon, 10 Nov 2003 15:18:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJITo-0007dv-IZ for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:17:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKHi4s029373 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJITo-0007dg-CH for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:17:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11036 for ; Mon, 10 Nov 2003 15:17:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJITj-0003qu-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:17:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJITi-0003qr-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:17:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIT8-0007Lq-0s; Mon, 10 Nov 2003 15:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJISZ-0007CG-B6 for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 15:16:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10788 for ; Mon, 10 Nov 2003 15:16:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJISX-0003nv-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:16:26 -0500 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw1.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AJISW-0003n2-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:16:25 -0500 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 1AJIS2-0005hS-00; Mon, 10 Nov 2003 20:15:54 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AJIS2-0005hP-00; Mon, 10 Nov 2003 20:15:54 +0000 Received: from zurich.ibm.com ([9.145.244.160]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hAAKFpv142586; Mon, 10 Nov 2003 20:15:51 GMT Message-ID: <3FAFF1CF.937B603B@zurich.ibm.com> Date: Mon, 10 Nov 2003 21:15:11 +0100 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: Fred Templin , ipv6@ietf.org CC: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <20031110195204.74981.qmail@web80504.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fred and Alain, I am simply not as scared of unregistered prefixes as Alain, because I believe there will always be rogue prefixes. At least you can tell these are rogues simply by looking at the prefix, unlike the case of rogues that are stolen PA prefixes. So I don't accept the thesis that they need registering. Also, registration is not free of cost, so it won't be free of charge, so I don't see the advantage of post facto registration. Anyway, let's see what Bob and Geoff propose. Brian > How about this - what if we let individual users randomly self > generate an address which they then take to the registration > authority. If no one else has previously registered the address, > the registration authority grants the assignment and records > it in the registration database. If the address was already taken, > the user repeats the random self generation process and asks > again to have the registration recorded. The process should > converge after relatively few iterations given a reasonable > random self-generation scheme - especially if the pool of > addresses is large. > > Any thoughts on this idea? > > Fred > osprey67@yahoo.com > > Alain Durand wrote: > > I think that if you were to drop entirely the randomly self generated > addresses > and do not say anything about the fee scruture except it has to > be low cost, it would be a much more swallable pill. > > - Alain. > > > Bob Hinden wrote: > > > Geoff, > > > >> After thinking about this and looking at the evident need to make > >> some progress > >> here I'd like to believe that this level of resolution of potential > >> ambiguity > >> is adequate, given that there is always the option to use a central > >> registry draw to > >> obtain a global id that is assuredly unique. > >> > >> My other issues with the current rev of the draft are still on the > >> table, and of course > >> I'd be happy to work with the authors to come up with some revised > >> words that may find > >> some reasonable (rough) wg consensus, and still remain within the > >> overall spirit > >> and intent of this proposal. > > > > > > Thanks. That would be very helpful. I will contact you off list and > > see if we can get together to come with some wording that could be > > presented to the w.g. during the Thursday session. > > > > Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 15:35:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12096 for ; Mon, 10 Nov 2003 15:35:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIkD-0000Oo-D8 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:34:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKYfvV001528 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIkD-0000OZ-7U for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12033 for ; Mon, 10 Nov 2003 15:34:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIkB-0004Bs-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:34:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIkB-0004Bo-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:34:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIjZ-0008WS-GO; Mon, 10 Nov 2003 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIjN-0008WB-P1 for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 15:33:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11992 for ; Mon, 10 Nov 2003 15:33:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIjM-0004Al-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:33:48 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AJIjL-0004AU-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:33:47 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAAKXFxA012051; Mon, 10 Nov 2003 12:33:15 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAAKXCQ27907; Mon, 10 Nov 2003 21:33:12 +0100 (MET) Date: Mon, 10 Nov 2003 21:32:23 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: anycast-analysis draft To: Jun-ichiro itojun Hagino Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" <20031109143617.91D4393@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , See https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=draft-ietf-ipngwg-ipv6-anycast-analysis&search_rfcnumber=&search_area_acronym=&search_button=SEARCH Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 15:56:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13154 for ; Mon, 10 Nov 2003 15:56:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ57-0002Ch-5f for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:56:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKuHGW008465 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:56:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ56-0002CS-Vw for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:56:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13106 for ; Mon, 10 Nov 2003 15:56:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ55-0004WS-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:56:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJ54-0004WM-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:56:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ3v-0001oM-TE; Mon, 10 Nov 2003 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ2w-0001jU-L2 for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 15:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13013 for ; Mon, 10 Nov 2003 15:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2u-0004UT-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:54:00 -0500 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw1.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2u-0004Tf-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:54:00 -0500 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 1AJJ2O-0006Gx-00; Mon, 10 Nov 2003 20:53:28 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AJJ2O-0006Gu-00; Mon, 10 Nov 2003 20:53:28 +0000 Received: from zurich.ibm.com ([9.145.244.160]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hAAKrPv131224; Mon, 10 Nov 2003 20:53:26 GMT Message-ID: <3FAFFA9E.C52B2F39@zurich.ibm.com> Date: Mon, 10 Nov 2003 21:52:46 +0100 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: Stephen Sprunk CC: Iljitsch van Beijnum , Hans Kruse , ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit How about simply calling whatever we end up with "organizational addresses"? I think that captures it much better than "local", "site local", "private" or whatever. Brian Stephen Sprunk wrote: > > Thus spake "Iljitsch van Beijnum" > > 1. To number systems/interfaces that are only accessible from withing > > the local network. > >... > > In the case of 1. the scope is site local, although the difinition of > > "site" may be subject to change. > > Perhaps it'd clear things up if we changed the common name to > "org(anization) local" addresses? I believe that was the intent behind the > original site-local addresses, but many/most end-users have more than one > phyiscal site and may be confused. > > > Being able to route these addresses throughout the internet would be > > more of a drawback than a usable feature, as packets using these > > addresses may not enter or leave the network. > > I think it would be reasonable to add a section explicitly stating such > addresses SHOULD NOT be routed in public networks, but that end-user > organizations MAY use them amongst themselves on private connections. > > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 16:20:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14107 for ; Mon, 10 Nov 2003 16:20:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJRu-00048E-Af for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 16:19:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALJoq8015876 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 16:19:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJRu-00047x-3c for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:19:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14034 for ; Mon, 10 Nov 2003 16:19:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJRs-0004s3-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:19:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJRr-0004s0-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:19:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJR8-0003p7-LL; Mon, 10 Nov 2003 16:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJQe-0003ny-7G for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 16:18:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13968 for ; Mon, 10 Nov 2003 16:18:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJQc-0004q7-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:18:30 -0500 Received: from web80511.mail.yahoo.com ([66.218.79.81]) by ietf-mx with smtp (Exim 4.12) id 1AJJQb-0004pA-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:18:29 -0500 Message-ID: <20031110211721.64407.qmail@web80511.mail.yahoo.com> Received: from [130.129.140.51] by web80511.mail.yahoo.com via HTTP; Mon, 10 Nov 2003 13:17:21 PST Date: Mon, 10 Nov 2003 13:17:21 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031110173314.23014.qmail@web80510.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1219058509-1068499041=:63762" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1219058509-1068499041=:63762 Content-Type: text/plain; charset=us-ascii Hmm - I may have spoken too soon, as it looks like RFC 2675 has some minimum packet sizing requirements that make it just a bit too big to use over IPv6-in-IPv4 tunnels. Maybe we should (bis) it? Fred osprey67@yahoo.com Fred Templin wrote: P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version --0-1219058509-1068499041=:63762 Content-Type: text/html; charset=us-ascii
Hmm - I may have spoken too soon, as it looks like RFC 2675 has
some minimum packet sizing requirements that make it just a bit
too big to use over IPv6-in-IPv4 tunnels. Maybe we should (bis) it?
 
Fred
osprey67@yahoo.com

Fred Templin <osprey67@yahoo.com> wrote:
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version
--0-1219058509-1068499041=:63762-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 16:38:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14791 for ; Mon, 10 Nov 2003 16:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJjY-0005Ln-4D for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 16:38:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALc3SR020555 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 16:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJjW-0005LN-6B for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:38:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14747 for ; Mon, 10 Nov 2003 16:37:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJjU-00057I-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:38:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJjT-00057C-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJiY-0004qx-N3; Mon, 10 Nov 2003 16:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJhg-0004lv-4n for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 16:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14641 for ; Mon, 10 Nov 2003 16:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJha-00054l-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:36:02 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak3a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AJJhZ-00054i-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:36:01 -0500 Received: from 132.235.232.96 by pm3 (PureMessage); Mon Nov 10 16:10:02 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hAALA1bg812104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 10 Nov 2003 16:10:01 -0500 (EST) Date: Mon, 10 Nov 2003 16:09:07 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <108476046.1068480547@hkruse2003a> In-Reply-To: <3FAFE8AA.6010009@sun.com> References: <4.3.2.7.2.20031110104020.03642440@mailhost.iprg.nokia.com> <3FAFE8AA.6010009@sun.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm3) X-PMX-Start: Mon Nov 10 16:10:02 2003 X-PMX-Stop: Mon Nov 10 16:10:02 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would oppose dropping the self-generated portion. I think we have been pretty clear about the fact that anyone expecting to use locals for long periods of time with some chance of merging later should get the registered kind. There is real value in the self-generated version, and I simply can't see the dire consequences predicted here... --On Monday, November 10, 2003 11:36 -0800 Alain Durand wrote: > I think that if you were to drop entirely the randomly self generated > addresses and do not say anything about the fee scruture except it has to > be low cost, it would be a much more swallable pill. > > - Alain. > 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 16:58:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15803 for ; Mon, 10 Nov 2003 16:58:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK3E-0007Te-J9 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 16:58:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALwOgd028732 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 16:58:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK3E-0007TL-7q for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:58:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15735 for ; Mon, 10 Nov 2003 16:58:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK3B-0005Ug-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:58:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJK3B-0005UW-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:58:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK1u-0007Af-4L; Mon, 10 Nov 2003 16:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK1F-00079q-Kr for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 16:56:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15631 for ; Mon, 10 Nov 2003 16:56:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK1D-0005Sl-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:56:19 -0500 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw1.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AJK1C-0005SG-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:56:19 -0500 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 1AJK0h-0007Ey-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:55:47 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AJK0h-0007Ev-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:55:47 +0000 Received: from zurich.ibm.com (sig-9-145-170-224.de.ibm.com [9.145.170.224]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hAALtjv138856 for ; Mon, 10 Nov 2003 21:55:45 GMT Message-ID: <3FB00938.DB8F326F@zurich.ibm.com> Date: Mon, 10 Nov 2003 22:55:04 +0100 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@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <3F96659F.4040702@innovationslab.net> <3FA0351E.37C3F0CA@zurich.ibm.com> <3FA065B8.3010003@sun.com> <3FA2883A.BA6A93CA@zurich.ibm.com> <3FA2A79F.4040203@sun.com> <027301c3a7d3$886982a0$6401a8c0@ssprunk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: > > Thus spake "Alain Durand" > > Brian E Carpenter wrote: > > >I meant PA because that is all that is in the implementors and > > >registries' hands today. Actually any form of PI would do (they are > > >all equally unrouteable today). I regard the Hinden/Haberman addresses > > >as an easy-to-create form of PI. > > > > I meant traceable, potentially routable PI. Hinden/Haberman addresses > > are not traceable (in the sense that looking at the prefix I can tell > > who it belongs to), and this is a big difference. > > I also object to this part of the draft as well. IMHO, the registry should > list who the registrant is for a particular prefix, but not allow non-exact > searches. I think there are privacy and secrecy-by-hiding reasons why this most likely won't happen, for *any* form of unrouted organizational addresses. The escrow proposal is to allow this privacy to be bypassed in extreme cases. > ...Reverse DNS should also be available if particular registrants > want to list servers. By definition, organizational addresses are not used to "list" servers outside the organization. Obviously, the organization's internal DNS will have to treat these addresses as first-class citizens, but I can't see any reason why we would expect reverse DNS for these things in the global DNS. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 17:19:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17141 for ; Mon, 10 Nov 2003 17:19:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKNS-0000zF-05 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 17:19:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMJHSh003787 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 17:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKNR-0000z0-QI for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17101 for ; Mon, 10 Nov 2003 17:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKNP-0005zv-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 17:19:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKNP-0005zs-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 17:19:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKNC-0000su-5F; Mon, 10 Nov 2003 17:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKMY-0000sR-0D for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 17:18:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17086 for ; Mon, 10 Nov 2003 17:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKMV-0005zN-00 for ipv6@ietf.org; Mon, 10 Nov 2003 17:18:19 -0500 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AJKMU-0005zK-00 for ipv6@ietf.org; Mon, 10 Nov 2003 17:18:18 -0500 Received: from ssprunk (ip154.post-vineyard.dfw.interquest.net [66.135.181.154]) by ns2.sea (8.12.10/8.12.5) with SMTP id hAAMIGJR016776; Mon, 10 Nov 2003 14:18:16 -0800 Message-ID: <02b801c3a7d8$8a28f3a0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Brian E Carpenter" Cc: References: <3F96659F.4040702@innovationslab.net> <3FA0351E.37C3F0CA@zurich.ibm.com> <3FA065B8.3010003@sun.com> <3FA2883A.BA6A93CA@zurich.ibm.com> <3FA2A79F.4040203@sun.com> <027301c3a7d3$886982a0$6401a8c0@ssprunk> <3FB00938.DB8F326F@zurich.ibm.com> Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Mon, 10 Nov 2003 16:14:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Brian E Carpenter" > Stephen Sprunk wrote: > > I also object to this part of the draft as well. IMHO, the registry should > > list who the registrant is for a particular prefix, but not allow non-exact > > searches. > > I think there are privacy and secrecy-by-hiding reasons why this most > likely won't happen, for *any* form of unrouted organizational addresses. > The escrow proposal is to allow this privacy to be bypassed in extreme > cases. > ... > By definition, organizational addresses are not used to "list" servers > outside the organization. Obviously, the organization's internal DNS will > have to treat these addresses as first-class citizens, but I can't see any > reason why we would expect reverse DNS for these things in the global > DNS. My case is this: I believe many orgs will use "local" addresses to interconnect with other orgs via private links, but not via the Internet. In this case, it would be handy to _optionally_ have reverse DNS entries in the public servers so that the mesh of private orgs don't have to muck with adding each others' local address zones into all their DNS servers. Of course, this would be an optional feature for orgs registering local addresses, but I don't see a reason to _prohibit_ it. 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 17:56:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19153 for ; Mon, 10 Nov 2003 17:56:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKxT-0003uU-Eo for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 17:56:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMuVWD015022 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 17:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKxS-0003uD-RM for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:56:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19087 for ; Mon, 10 Nov 2003 17:56:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKxQ-0006g7-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 17:56:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKxP-0006g4-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 17:56:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKx1-0003gd-1g; Mon, 10 Nov 2003 17:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKw0-0003ed-UI for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 17:55:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19032 for ; Mon, 10 Nov 2003 17:54:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKvu-0006eK-00 for ipv6@ietf.org; Mon, 10 Nov 2003 17:54:54 -0500 Received: from 51.cust10.nsw.dsl.ozemail.com.au ([203.103.153.51] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKvt-0006dd-00 for ipv6@ietf.org; Mon, 10 Nov 2003 17:54:54 -0500 Received: from Dupy2.nosense.org (51.cust10.nsw.dsl.ozemail.com.au [203.103.153.51]) by nosense.org (Postfix) with SMTP id F3AB73F017; Tue, 11 Nov 2003 09:25:27 +1030 (CST) Date: Tue, 11 Nov 2003 09:25:27 +1030 From: Mark Smith To: Brian E Carpenter Cc: stephen@sprunk.org, iljitsch@muada.com, kruse@ohio.edu, ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-Id: <20031111092527.2a7176df.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <3FAFFA9E.C52B2F39@zurich.ibm.com> References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 10 Nov 2003 21:52:46 +0100 Brian E Carpenter wrote: > How about simply calling whatever we end up with "organizational addresses"? > I think that captures it much better than "local", "site local", "private" > or whatever. > I agree. I think it is a more descriptive name. In accompanying text, I think it would be good to state that an individual can also be classed as an "organisation" for these purposes. (the name "entity addresses" comes to mind, but I think it is a bit too generic) Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 18:27:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22207 for ; Mon, 10 Nov 2003 18:27:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLRX-0005qB-UH for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 18:27:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANRZQZ022444 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 18:27:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLRX-0005ps-9Y for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 18:27:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22153 for ; Mon, 10 Nov 2003 18:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLRT-0007Jd-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 18:27:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJLRT-0007JZ-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 18:27:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLR0-0005dV-LZ; Mon, 10 Nov 2003 18:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLQo-0005cg-1U for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 18:26:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22107 for ; Mon, 10 Nov 2003 18:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLQk-0007It-00 for ipv6@ietf.org; Mon, 10 Nov 2003 18:26:47 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AJLQk-0007IM-00 for ipv6@ietf.org; Mon, 10 Nov 2003 18:26:46 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAANQB911662; Mon, 10 Nov 2003 15:26:11 -0800 X-mProtect: <200311102326> Nokia Silicon Valley Messaging Protection Received: from dyn142-204.ietf58.ietf.org (130.129.142.204, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdWDD2aB; Mon, 10 Nov 2003 15:26:10 PST Message-Id: <4.3.2.7.2.20031110151630.02a87d08@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 15:25:14 -0800 To: Mark Smith From: Bob Hinden Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Cc: ipv6@ietf.org In-Reply-To: <20031111092527.2a7176df.ipv6@c753173126e0bc8b057a22829880c f26.nosense.org> References: <3FAFFA9E.C52B2F39@zurich.ibm.com> <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 02:55 PM 11/10/2003, Mark Smith wrote: >On Mon, 10 Nov 2003 21:52:46 +0100 >Brian E Carpenter wrote: > > > How about simply calling whatever we end up with "organizational > addresses"? > > I think that captures it much better than "local", "site local", "private" > > or whatever. > > > >I agree. I think it is a more descriptive name. As long as the final name doesn't end up being "Hinden/Haberman" I am open to what every name the working group thinks is best :-) I assume this suggestion means changing the title and text in the document from: Unique Local IPv6 Unicast Addresses to: Unique Organizational IPv6 Unicast Addresses or: Organizational IPv6 Unicast Addresses Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 20:14:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27016 for ; Mon, 10 Nov 2003 20:14:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJN78-0002vk-W0 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 20:14:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB1EcQo011260 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 20:14:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJN78-0002vX-R5 for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 20:14:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26968 for ; Mon, 10 Nov 2003 20:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJN76-0001Vc-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 20:14:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJN76-0001VZ-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 20:14:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJN6X-0002ok-MW; Mon, 10 Nov 2003 20:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJN6A-0002o9-QL for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 20:13:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26945 for ; Mon, 10 Nov 2003 20:13:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJN68-0001Ur-00 for ipv6@ietf.org; Mon, 10 Nov 2003 20:13:36 -0500 Received: from oak.cats.ohiou.edu ([132.235.8.44] helo=oak3a.cats.ohiou.edu) by ietf-mx with esmtp (Exim 4.12) id 1AJN68-0001Uo-00 for ipv6@ietf.org; Mon, 10 Nov 2003 20:13:36 -0500 Received: from 132.235.232.96 by pm3 (PureMessage); Mon Nov 10 19:55:01 2003 Received: from hkruse2003a (dhcp-232-096.cns.ohiou.edu [132.235.232.96]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id hAB0t0bg904660 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 10 Nov 2003 19:55:00 -0500 (EST) Date: Mon, 10 Nov 2003 19:54:05 -0500 From: Hans Kruse To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <121974343.1068494045@hkruse2003a> In-Reply-To: <3FAFFA9E.C52B2F39@zurich.ibm.com> References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-PMX-Spam: Gauge=III, Probability=3%, Report='IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, __CD, __CT, __CTE, __CT_TEXT_PLAIN, __EVITE_CTYPE, __HAS_MSGID, __HAS_X_MAILER, __IN_REP_TO, __MIME_VERSION, __REFERENCES, __SANE_MSGID, __UNUSABLE_MSGID' X-MailScanner-SpamCheck: not spam, PureMessage (score=0, required 5) X-PMX-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-PMX-Version: 4.0.4.77969 (pm3) X-PMX-Start: Mon Nov 10 19:55:00 2003 X-PMX-Stop: Mon Nov 10 19:55:01 2003 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit That works for me... --On Monday, November 10, 2003 21:52 +0100 Brian E Carpenter wrote: > How about simply calling whatever we end up with "organizational > addresses"? I think that captures it much better than "local", "site > local", "private" or whatever. > > Brian 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 20:27:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27741 for ; Mon, 10 Nov 2003 20:27:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNJG-0003nU-NN for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 20:27:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB1RAGH014590 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 20:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNJG-0003nF-HH for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 20:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27704 for ; Mon, 10 Nov 2003 20:26:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNJE-0001kl-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 20:27:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNJD-0001ki-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 20:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNJ7-0003eY-JG; Mon, 10 Nov 2003 20:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNIt-0003eA-Kz for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 20:26:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27686 for ; Mon, 10 Nov 2003 20:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNIr-0001kN-00 for ipv6@ietf.org; Mon, 10 Nov 2003 20:26:45 -0500 Received: from 51.cust10.nsw.dsl.ozemail.com.au ([203.103.153.51] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNIq-0001jy-00 for ipv6@ietf.org; Mon, 10 Nov 2003 20:26:45 -0500 Received: from Dupy2.nosense.org (51.cust10.nsw.dsl.ozemail.com.au [203.103.153.51]) by nosense.org (Postfix) with SMTP id F3D303F017; Tue, 11 Nov 2003 11:57:18 +1030 (CST) Date: Tue, 11 Nov 2003 11:57:18 +1030 From: Mark Smith To: Bob Hinden Cc: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-Id: <20031111115718.60da00f8.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <4.3.2.7.2.20031110151630.02a87d08@mailhost.iprg.nokia.com> References: <3FAFFA9E.C52B2F39@zurich.ibm.com> <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> <4.3.2.7.2.20031110151630.02a87d08@mailhost.iprg.nokia.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 10 Nov 2003 15:25:14 -0800 Bob Hinden wrote: I'd be inclined to go with this one, as it avoids implying a guarantee of uniqueness, which would then imply they could be used as PI addresses from day one. > Organizational IPv6 Unicast Addresses Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 20:50:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28964 for ; Mon, 10 Nov 2003 20:50:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNfg-00057U-6u for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 20:50:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB1oKoQ019674 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 20:50:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNfg-00057F-1c for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 20:50:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28920 for ; Mon, 10 Nov 2003 20:50:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNfd-0002FG-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 20:50:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNfd-0002FD-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 20:50:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNfO-0004wN-MW; Mon, 10 Nov 2003 20:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNfH-0004vi-UE for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 20:49:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28902 for ; Mon, 10 Nov 2003 20:49:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNfF-0002Eh-00 for ipv6@ietf.org; Mon, 10 Nov 2003 20:49:53 -0500 Received: from 51.cust10.nsw.dsl.ozemail.com.au ([203.103.153.51] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNfE-0002E8-00 for ipv6@ietf.org; Mon, 10 Nov 2003 20:49:52 -0500 Received: from Dupy2.nosense.org (51.cust10.nsw.dsl.ozemail.com.au [203.103.153.51]) by nosense.org (Postfix) with SMTP id AE4553F017; Tue, 11 Nov 2003 12:20:28 +1030 (CST) Date: Tue, 11 Nov 2003 12:20:28 +1030 From: Mark Smith To: bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-Id: <20031111122028.615dff9f.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <20031111115718.60da00f8.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> References: <3FAFFA9E.C52B2F39@zurich.ibm.com> <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> <4.3.2.7.2.20031110151630.02a87d08@mailhost.iprg.nokia.com> <20031111115718.60da00f8.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oops, sorry, just looked at the ID again, noticed that it states they are unique. Along those lines "Unique Organizational IPv6 Unicast Addresses" would be an acceptable title. Hmm, at least for me, I would take the word "unique" to guarantee no duplication. With local generation, this isn't a guarantee as the uniqueness can't be validated. Maybe the term "near-unique" could be used throughout the text when describing the local generation case, to better describe what the user is getting a.k.a. truth in advertising. Maybe just "Organizational IPv6 Unicast Addressesing" would be a better name, split into unique and near-unique types of organizational addressing within the document. Thanks, Mark. On Tue, 11 Nov 2003 11:57:18 +1030 Mark Smith wrote: > On Mon, 10 Nov 2003 15:25:14 -0800 > Bob Hinden wrote: > > > I'd be inclined to go with this one, as it avoids implying a guarantee of uniqueness, which would then imply they could be used as PI addresses from day one. > > > Organizational IPv6 Unicast Addresses > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 21:10:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29866 for ; Mon, 10 Nov 2003 21:10:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNyx-0006af-V0 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:10:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2AF1S025327 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:10:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNyx-0006aQ-Q2 for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 21:10:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29824 for ; Mon, 10 Nov 2003 21:10:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNyv-0002ZL-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:10:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNyu-0002ZH-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:10:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNyk-0006UD-UF; Mon, 10 Nov 2003 21:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNyS-0006Ta-6f for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 21:09:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29741 for ; Mon, 10 Nov 2003 21:09:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNyP-0002XZ-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:09:41 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNyO-0002XO-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:09:40 -0500 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 CAA17360 for ; Tue, 11 Nov 2003 02:09:40 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id CAA11780 for ; Tue, 11 Nov 2003 02:09:40 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAB29dx08613 for ipv6@ietf.org; Tue, 11 Nov 2003 02:09:39 GMT Date: Tue, 11 Nov 2003 02:09:39 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <20031111020939.GB8534@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> <121974343.1068494045@hkruse2003a> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <121974343.1068494045@hkruse2003a> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Only nit aside from a flavour of OSI is having to grep for "organi[sz]ational" in drafts/RFCs. Most use of "site local" may be in SOHO networks; not sure the word fits well for home use, but if site local has stigma attached... Tim On Mon, Nov 10, 2003 at 07:54:05PM -0500, Hans Kruse wrote: > That works for me... > > --On Monday, November 10, 2003 21:52 +0100 Brian E Carpenter > wrote: > > >How about simply calling whatever we end up with "organizational > >addresses"? I think that captures it much better than "local", "site > >local", "private" or whatever. > > > > Brian > > > > 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 IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 21:31:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00573 for ; Mon, 10 Nov 2003 21:31:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOJS-0007YE-E4 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:31:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2VQfX029020 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:31:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOJS-0007Xz-83 for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 21:31:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00542 for ; Mon, 10 Nov 2003 21:31:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOJP-0002vO-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:31:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJOJP-0002vL-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:31:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOJ4-0007Rn-Qz; Mon, 10 Nov 2003 21:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOIX-0007Of-7f for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 21:30:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00487 for ; Mon, 10 Nov 2003 21:30:15 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOIU-0002sD-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:30:26 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137] helo=i2kc01-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AJOIT-0002rl-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:30:25 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by i2kc01-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 02:29:55 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 02:29:55 +0000 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" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Tue, 11 Nov 2003 02:29:55 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7003A0CC05@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Thread-Index: AcOnzP7QJeO4jsDJSwWq/V2DHD5DiQALpFRA To: X-OriginalArrivalTime: 11 Nov 2003 02:29:55.0805 (UTC) FILETIME=[B1CBA8D0:01C3A7FB] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > How about simply calling whatever we end up with=20 > "organizational addresses"? > I think that captures it much better than "local", "site=20 > local", "private" > or whatever. as others have pointed out these addresses will be used in non-'organisational' scenarios. therefore i prefer 'local' as it has the widest applicability. what is wrong with 'local'? Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 21:38:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00914 for ; Mon, 10 Nov 2003 21:38:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOPy-0008Vw-HX for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:38:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2cAmU032729 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:38:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOPy-0008Vo-4d for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 21:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00871 for ; Mon, 10 Nov 2003 21:37:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOPv-00033O-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:38:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJOPu-00033K-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOPo-0008P8-RP; Mon, 10 Nov 2003 21:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOPR-0008J5-KR for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 21:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00844 for ; Mon, 10 Nov 2003 21:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOPO-00032f-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:37:34 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AJOPN-00032c-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:37:33 -0500 Received: from ocean.jinmei.org (dyn133-221.ietf58.ietf.org [130.129.133.221]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 29DA41521A; Tue, 11 Nov 2003 11:37:26 +0900 (JST) Date: Tue, 11 Nov 2003 11:37:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: ipv6@ietf.org Subject: Re: WGLC comments about scoping-arch In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Again, thanks for the detailed comments. >>>>> On Mon, 3 Nov 2003 11:26:55 +0200 (EET), >>>>> Pekka Savola said: > substantial > 1) the number of authors is too many (6). No more than 5 is allowed. I'd > suggest removing one, or putting everyone except the current document editor > as only authors and list only one editor of the document. Sorry, I don't understand the latter suggestion. Could you reword this one please? Anyway, I see your point, but I don't have a good idea on how to deal with this. I don't even know if the "no more than 5" rule must strictly be applied here (I guess you meant the third paragraph of Section 2.12(1), draft-rfc-editor-rfc2223bis-07.txt). I'm open to suggestions from wg. > 2) there is some really, really weird text in section 4 about address > scopes: > [1] defines IPv6 addresses with embedded IPv4 addresses as part of > global addresses. Thus, those addresses have global scope, with > regards to the IPv6 scoped address architecture. However, an > implementation may use those addresses as if they had other type of > scopes for convenience. For instance, [7] assigns link-local scope > to IPv4 auto-configuration addresses, and converts those addresses > into IPv4-mapped IPv6 addresses in order for destination address > selection among IPv4 and IPv6 addresses. This would implicitly mean > IPv4-mapped addresses correspondent to IPv4 auto-configuration > addresses have link-local scope. This document does not preclude > such a usage, as long as it is limited within the implementation. > ==> that is, there are no "IPv4 auto-configuration" addresses. This > probably tries to refer to DHCP link-local addresses / zeroconf addresses, > but those are actually *very* far from the intent here. Hmm, it seems that the term "IPv4 auto-configuration" was simply copied from "[7]" (RFC3484). But in any event, you're correct. The wording should be revised appropriately. > Further, note > that the second-last paragraph is not suitably clear about the connection > of the link-local mapped addresses and the equivalent IPv4 addresses. I guess you meant the "second-last sentence" here. And honestly, I don't see a significant difference between the current text and your suggestion, but I'm fine with revising the text as suggested. > I'd suggest e.g. something like: > [1] defines IPv6 addresses with embedded IPv4 addresses as part of > global addresses. Thus, those addresses have global scope, with > regards to the IPv6 scoped address architecture. However, an > implementation may use those addresses as if they had other type of > scopes for convenience. For instance, [7] assigns link-local scope > to IPv4 auto-configured link-local addresses (the addresses > from the prefix 169.254/16 [X]), and converts those addresses > into IPv4-mapped IPv6 addresses in order to perform destination address > selection among IPv4 and IPv6 addresses. This would implicitly mean > the IPv4-mapped IPv6 addresses equivalent to the IPv4 link-local > auto-configuration addresses have link-local scope. This document > does not preclude such a usage, as long as it is limited within the > implementation. This looks fine, thanks for the suggestion. I'll basically replace the paragraph with this one, with one exception: we may need to be consistent about the terms between - IPv4 auto-configured link-local addresses and - IPv4 link-local auto-configuration addresses I'm not sure if the difference was intentional, but I'll probably be consistent by using the former one only. > 3) I think this statement in section 5 needs to be spelled out a bit more: > Each interface belongs to exactly one zone of each possible scope. > .. that is, this could be read either as it's probably intended ("no > interface must belong to more than one zone"), or as "each interface must > be in a zone of each scope, even if it would have no addresses etc. from > that scope". If the intent is the latter, this needs to be spelled out a > bit more, if the former, a different wording should be used. Hmm, I think it is Steve who can answer this question with confidence, but I believe the intention is the latter (including the former one, of course). For example, I believe the latter intention is more consistent with Section 6. I don't know if this is so substantial that we need to revise the text, but I'll think about it more and try to propose a better wording. In any event, I think this is rather an editorial issue and does not cause a significant problem. > 4) I'm not sure whether I see the immediate need for the unique subnet > multicast scope assignment, as below: This one has a follow-up, so I'll answer separately in the follow-up thread. > 5) In the section 7, "sending packets", IMHO it would be useful to actually > describe the process of how the outgoing interface is identified, or refer > to a section describing this (if it's in the default zone, no problem, but > if you have e.g. two link-local interfaces....): > Although identification of an outgoing interface is sufficient to > identify an intended zone (because each interface is attached to no > more than one zone of each scope), that is more specific than desired > in many cases. Sorry, I don't really understand the point...did you mean "how the outgoing *zone* is identified", not "how the outgoing *interface* is identified"? > 6) In the section 9, "Forwarding", I think the text about picking the > destination address zone could be enhanced a bit: > o The zone of the destination address is determined by the scope of > the address and arrival interface of the packet. The next-hop > interface is chosen by looking up the destination address in a > (conceptual) routing table specific to that zone. That routing > table is restricted to refer only to interfaces belonging to that > zone. > ==> that is, this does not seem to spell out whether the routing table > could include more than just the interfaces of destination address zone -- > i.e., in the case of a global destination address, the "interfaces belonging > to that zone" is a bit confusing :-) Hmm, perhaps I was too familiar with the concept, but I don't see the problem. In the case of a global destination address, the zone for the destination address is the single global zone, and the "interfaces belonging to that zone" are all the interfaces that the receiving node has. What is confusing here? > 7) In the section 9, "Forwarding", the second rule about sending an ICMP DU > is specified. Has it already been considered whether this applies to > multicast destination addresses as well? In the past, we've been a bit more > hesitant to send replies to the source of multicast packets (e.g. consider > an almost-global multicast scope that leaks and the source would get e.g. > thousands of "beyond the scope" packets..) ? Ah, good catch. I don't think anyone ever thought this ICMPv6 error message should be sent against a packet with a multicast destination address. And, in fact, draft-ietf-ipngwg-icmp-v3-02.txt almost explicitly prohibits the error message from being sent in this case. I'll revise the text to make it clear that the error message should be applied to a packet with a unicast destination address only. (I saw your second message saying that this is typically a non-issue, which I agree on. But I also agree that it's better to clarify this point.) > 8) multicast routing in section 10 is rather weak. This is a direct > resolution of switching from unicast site-locals to multicast > organization-local addresses. However, with multicast addresses, it is > not appropriate to use the terms "prefixes" to refer to multicast traffic. The > multicast routing is so different from unicast, and the term is not > qualified to convey the intended message here. Some rewording is needed, > maybe express this using (*,G) or (S,G) state creation where the limits are > placed on the group G. (in the citation I've corrected the lack of "not" pointed out in your 2nd message) I see your point. But it seems to me too much to use the term like (*, G) or (S, G). At least (*, G) is a notion very specific to a particular type of multicast routing protocols such as PIM-SM. Isn't it enough to revise the text here using "group" instead of "prefix(es)"? For example, say * All global groups instead of * All global prefixes > 9) I think the EBGP peering example should be removed from section 11.4. > It seems just an > incredibly bad idea to use just link-locals in an IX. This would cause > serious problems e.g. if someone didn't include "next-hop-self" in their > config. Further, this particular problem has already been solved by making > IX-based addressing available through RIR's. So, IMHO, the paragraph should > be removed: I don't think this is "an incredibly bad idea", but I admit the sense on this example might be controversial. In addition, I agree on your second point (this example was written long before the RIR's introduced IX-based addressing, and has not been revised since then. This is probably a good timing to revisit it.) As a conclusion, I agree on removing this example from the document. > 10) Similar bad ideas are described in section 11.7, about how to use IPv6 > addresses in URL's. The text seems to say that the apps should then strip > the zone index and be able to parse it.. This would imply that apps handling > URL's should be made aware of link-local addresses and the zone index > parsing. This seems like a very, very wrong way to go: At least I didn't intend to give an impression that applications need to parse/strip the format with a zone ID. I see the point, however, and I'm willing to revise the text if it makes the point clearer. > ==> suggestion either revise the text significantly or add reword the middle > sentence: > However, the typed URL is often sent on a wire, and it would cause > confusion if an application did not strip the portion > before sending. Note that the applications should not need to care > about which kind of addresses they're using, much less parse or strip out > the portion of the address. Also, the format for non-global > addresses might conflict with the URI syntax [10], since the syntax > defines the delimiter character (%') as the escape character. I don't see a problem with the suggested text. Do you think if it is enough to make the point clear? If so, I'll simply use the rewording. > 11) Note that there is a normative reference to the ICMPv6-bis document, > which has been pretty much stalled for the last 2 years or so. This > document cannot be published before ICMPv6-bis is also published. The > ICMPv6-bis seems integral to this specification, so I think the options are > either to revise the text about sending ICMP DU "beyond the scope of source > address" messages (removing it), or kicking off the effort for getting > ICMPv6-bis out of the door: > [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for > the Internet Protocol Version 6 (IPv6)", Internet Draft draft- > ietf-ipngwg-icmp-v3-02.txt, November 2001. Another good catch. I think you're talking about the rule described in the 3rd paragraph of draft-rfc-editor-rfc2223bis-07.txt, Section 2.7. Hmm, we have an agenda item on icmp-v3-02 in the 1st ipv6 wg meeting tomorrow, so for now I'll see what happens on this. > editorial > --------- > Though the current specification [1] defines unicast site-local > addresses, the IPv6 working group decided to deprecate the syntax and > ==> s/current/current address architecture/ (to be clear not to confuse with > this spec :-) Okay. Fixed in my local copy. > The terms link, interface, node, host, and router are defined in [3]. > The definitions of unicast address scopes (link-local and global) and > multicast address scopes (interface-local, link-local, etc.) are > contained in [1]. > ==> I'd try to find a different word than "contained", but that's ~OK as > well. Hmm, considering poor vocabulary of my own, I'd leave this as is. If some one can suggest a better wording, I'll use it. > Two interfaces to the same Ethernet, > ==> s/Ethernet/Ethernet link/ Okay, fixed. > o The zone of the new destination address is determined by the scope > of the next address in the Routing Header and arrival interface of > the packet. The next-hop interface is chosen just like the first > bullet of the rules above. > ==> reword to something like below, to spell out what the next address was: > (also, add "the" before arrival): > o The zone of the new destination address is determined by the scope > of the next address in the Routing Header (the original destination > address of the received packet) and the arrival interface of > the packet. The next-hop interface is chosen just like the first > bullet of the rules above. > ... This "the next address in the Routing Header" should now be in the destination address of the IPv6 header (swapped with the original destination address of the received packet). Did you mean "(swapped with the original destination address of the received packet)"? Perhaps we can simply say "the next address" (removing "in the Routing Header"). > Note that it is possible, though generally inadvisable, to use a > Routing Header to convey a non-global address across its associated > zone boundary. > ==> I'd be a bit more explicit than this.. the convey in this case means > that a link-local address is encapsulated in the "next address" field but is > not going to be used. Try e.g.: > Note that it is possible, though generally inadvisable, to use a > Routing Header to convey a non-global address across its associated > zone boundary in the previously-used next address field, similar as > one can convey the information in the protocol payloads as well. > (could also omit from "similar.." not sure if that's good..) I don't see the need for the "similar..." part. So I'll revise the text as follows: Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary in the previously-used next address field. > ... > For example, consider a case where a link-border node > (e.g., a router) receives a packet with the destination being a link- > local address. > ==> continute the last sentence like: > local address, and the source address a global address. Hmm, not sure if this is a necessary fix, but I'll change the text as suggested. > Note: since unicast site-local addresses are deprecated, and link- > local addresses does not need routing, the discussion in this section > ==> s/does/do/ Fixed, thanks. > o Interface 3 > * All global prefixes > * All organization prefixes learned from Interface 1, 2, and 3 > ==> s/Interface/Interfaces/ Thanks. I also noticed "Interfaces 5" which should be "Interface 5". Both were fixed in my local copy. > identify a particular zone of the address' scope. Although a zone > ==> s/address'/address's/ Changed. > When an implementation interprets the format, it should construct the > "full" zone ID, which contains the scope type, from the > part and the scope type specified by the
part. > ==> unless I have completely misunderstood the spec, the first "scope type" > should actually be "scope zone" :-) I don't think you misunderstand the spec, but the first "scope type" is correct. It corresponds to the following part of Section 6: Each zone index of a particular scope should contain an information to represent the scope type, so that all indices of all scopes are unique within the node and zone indices themselves can be used for a dedicated purpose. So, at least one person read this to mean differently than originally intended...do we need to be clearer by revising the text? > Here is a concrete example. Consider a multi-linked router, called > "R1", that has at least two point-to-point interfaces (links). Each > of the interfaces is connected to another router, called "R2" and > "R3", respectively. Also assume that the point-to-point interfaces > are "unnumbered", that is, they have link-local addresses only. > ==> this is an "ipv6-centric" definition of unnumbered. Classically, > unnumbered interfaces have no addresses *at all*. Correct, and that's why I used double-quotations followed by the concrete meaning. So, ... > So, I'd use a different > wording than "unnumbered", or maybe "globally unnumbered" would be good > enough even though it sounds odd.. I don't need to revise the text, but we might just remove the "unnumbered", and say Also assume that the point-to-point interfaces have link-local addresses only. The removal of the possibly confusing word doesn't matter, IMO, particularly because this is the only occurrence of "unnumbered". Does this change make sense. > here, since R1 has more than one link and hence the telnet command > cannot detect which link it should try to connect. Instead, we > should type the link-local address with the link index as follows: > ==> s/try to connect/try to use for connecting/ !! (one doesn't connect to > a link.. :-) Okay, I don't think "one does connect to a link" is always odd, but I agree the text in this case is not correct. I'll revise the text as suggested. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 21:50:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01423 for ; Mon, 10 Nov 2003 21:50:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJObc-00012o-01 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:50:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2oBYK004008 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 21:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJObb-00012Y-Lt for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 21:50:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01396 for ; Mon, 10 Nov 2003 21:49:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJObY-0003GI-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:50:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJObY-0003GD-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 21:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJObT-0000wx-Nw; Mon, 10 Nov 2003 21:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOaa-0000vP-KX for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 21:49:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01377 for ; Mon, 10 Nov 2003 21:48:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOaX-0003Fg-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:49:05 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 1AJOaX-0003FR-00 for ipv6@ietf.org; Mon, 10 Nov 2003 21:49:05 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAB2mZVn635536 for ; Mon, 10 Nov 2003 21:48:35 -0500 Received: from d01ml099.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAB2mY2P069624 for ; Mon, 10 Nov 2003 21:48:35 -0500 Subject: test To: ipv6@ietf.org X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: Nicholas Carbone Date: Mon, 10 Nov 2003 21:48:32 -0500 X-MIMETrack: Serialize by Router on D01ML099/01/M/IBM(Release 6.0.2CF2 IGS_HF9|October 28, 2003) at 11/10/2003 21:48:34 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , this is a test -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 22:32:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02642 for ; Mon, 10 Nov 2003 22:32:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPGb-00037K-H0 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 22:32:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3WXoB011976 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 22:32:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPGb-000375-BU for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 22:32:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02615 for ; Mon, 10 Nov 2003 22:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPGY-0003kk-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 22:32:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPGX-0003kh-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 22:32:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPG6-00031E-Rn; Mon, 10 Nov 2003 22:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPFf-00030r-Py for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 22:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02597 for ; Mon, 10 Nov 2003 22:31:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPFc-0003kE-00 for ipv6@ietf.org; Mon, 10 Nov 2003 22:31:32 -0500 Received: from 51.cust10.nsw.dsl.ozemail.com.au ([203.103.153.51] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPFb-0003jq-00 for ipv6@ietf.org; Mon, 10 Nov 2003 22:31:32 -0500 Received: from Dupy2.nosense.org (51.cust10.nsw.dsl.ozemail.com.au [203.103.153.51]) by nosense.org (Postfix) with SMTP id 7599F3F017; Tue, 11 Nov 2003 14:02:06 +1030 (CST) Date: Tue, 11 Nov 2003 14:02:05 +1030 From: Mark Smith To: matthew.ford@bt.com Cc: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-Id: <20031111140205.639fdf08.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <0AAF93247C75E3408638B965DEE11A7003A0CC05@i2km41-ukdy.domain1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A7003A0CC05@i2km41-ukdy.domain1.systemhost.net> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 11 Nov 2003 02:29:55 -0000 matthew.ford@bt.com wrote: > > How about simply calling whatever we end up with > > "organizational addresses"? > > I think that captures it much better than "local", "site > > local", "private" > > or whatever. > > as others have pointed out these addresses will be used in > non-'organisational' scenarios. therefore i prefer 'local' as it has the > widest applicability. what is wrong with 'local'? > I suppose that it tends to have implied geographical connotations if there is no qualifier as to what "local" is referring to. Maybe "entity local IPv6 unicast addresses" ? Still slightly too generic for my mind, but possibly better than "organi[sz]ation" ? Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 22:34:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02847 for ; Mon, 10 Nov 2003 22:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPIB-0003fw-AP for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 22:34:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3YBuV014121 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 22:34:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPIA-0003fe-Rs for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 22:34:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02774 for ; Mon, 10 Nov 2003 22:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPI7-0003mh-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 22:34:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPI7-0003me-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 22:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPI3-0003UA-SS; Mon, 10 Nov 2003 22:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPHz-0003Pn-BG for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 22:34:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02745 for ; Mon, 10 Nov 2003 22:33:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPHv-0003mJ-00 for ipv6@ietf.org; Mon, 10 Nov 2003 22:33:55 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1AJPHv-0003mC-00 for ipv6@ietf.org; Mon, 10 Nov 2003 22:33:55 -0500 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id CA7333F092E; Mon, 10 Nov 2003 22:33:48 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 3E0F87E1E9; Mon, 10 Nov 2003 22:33:46 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Tue, 11 Nov 2003 09:03:46 +0530 X-Sasl-Enc: r/vN9HgK2kd6eziMVN56KQ 1068521626 Cc: "Iljitsch van Beijnum" , "Hans Kruse" , "Brian E Carpenter" , "Stephen Sprunk" Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> In-Reply-To: <3FAFFA9E.C52B2F39@zurich.ibm.com> Message-Id: <20031111033346.3E0F87E1E9@server2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IMHO, "private" is appropriate. As noted in other emails, "organization" is bit too specific. Plus, "Private (IPv4) addresses" is a well known concept, and it would simpler for IPv4 network (home, organization, etc networks) operators to extend the same understanding to IPv6. CP On Mon, 10 Nov 2003 21:52:46 +0100, "Brian E Carpenter" said: > How about simply calling whatever we end up with "organizational > addresses"? I think that captures it much better than "local", "site > local", "private" or whatever. > > Brian > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 10 23:17:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04483 for ; Mon, 10 Nov 2003 23:17:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPxO-0006x5-NX for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 23:16:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB4GkeW026717 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 23:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPxO-0006wq-Eh for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 23:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04422 for ; Mon, 10 Nov 2003 23:16:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPxG-0004OA-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 23:16:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPxG-0004O7-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 23:16:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPwg-0006iI-Bo; Mon, 10 Nov 2003 23:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPwE-0006gU-EF for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 23:15:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04379 for ; Mon, 10 Nov 2003 23:15:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPwB-0004L2-00 for ipv6@ietf.org; Mon, 10 Nov 2003 23:15:31 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPwA-0004KV-00 for ipv6@ietf.org; Mon, 10 Nov 2003 23:15:31 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAB4Euq19566; Tue, 11 Nov 2003 06:14:56 +0200 Date: Tue, 11 Nov 2003 06:14:56 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: Re: WGLC comments about scoping-arch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, Thanks for very careful and thoughful responses. This is the kind of editing we need! :-) Comments to remaining issues inline.. On Tue, 11 Nov 2003, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > > 1) the number of authors is too many (6). No more than 5 is allowed. I'd > > suggest removing one, or putting everyone except the current document editor > > as only authors and list only one editor of the document. > > Sorry, I don't understand the latter suggestion. Could you reword > this one please? > > Anyway, I see your point, but I don't have a good idea on how to deal > with this. I don't even know if the "no more than 5" rule must > strictly be applied here (I guess you meant the third paragraph of > Section 2.12(1), draft-rfc-editor-rfc2223bis-07.txt). I'm open to > suggestions from wg. This issue comes from: http://www.ietf.org/ID-nits.html http://www.rfc-editor.org/policy.html#policy.auth2 The documents with >5 authors at the header need to be specially agreed to with the IESG. So, I think the options are either: 1) get the special agreement with the IESG (would't bother trying) 2) strike off 1-2 most inactive authors and put them in a "Contributors" section 3) replace all the authors with just one entry, like "J. Tatuya (Ed.)" and put everybody down in an "Authors" section .. obviously 2) would IMHO be a best choice if we/you could just decide who to strike off.. > > Further, note > > that the second-last paragraph is not suitably clear about the connection > > of the link-local mapped addresses and the equivalent IPv4 addresses. > > I guess you meant the "second-last sentence" here. And honestly, I > don't see a significant difference between the current text and your > suggestion, but I'm fine with revising the text as suggested. Yes, I meant the sentence, sorry. The my text pointed out the prefix explicitly, and tries to use a better name to properly describe the addresses.. > This looks fine, thanks for the suggestion. I'll basically replace > the paragraph with this one, with one exception: we may need to be > consistent about the terms between > - IPv4 auto-configured link-local addresses > and > - IPv4 link-local auto-configuration addresses > > I'm not sure if the difference was intentional, but I'll probably be > consistent by using the former one only. It was unintentional; good catch. Consistency doesn't hurt :-) > > 3) I think this statement in section 5 needs to be spelled out a bit more: > > > Each interface belongs to exactly one zone of each possible scope. > > > .. that is, this could be read either as it's probably intended ("no > > interface must belong to more than one zone"), or as "each interface must > > be in a zone of each scope, even if it would have no addresses etc. from > > that scope". If the intent is the latter, this needs to be spelled out a > > bit more, if the former, a different wording should be used. > > Hmm, I think it is Steve who can answer this question with confidence, > but I believe the intention is the latter (including the former one, > of course). For example, I believe the latter intention is more > consistent with Section 6. > > I don't know if this is so substantial that we need to revise the > text, but I'll think about it more and try to propose a better wording. > > In any event, I think this is rather an editorial issue and does not > cause a significant problem. Ok. > > 5) In the section 7, "sending packets", IMHO it would be useful to actually > > describe the process of how the outgoing interface is identified, or refer > > to a section describing this (if it's in the default zone, no problem, but > > if you have e.g. two link-local interfaces....): > > > Although identification of an outgoing interface is sufficient to > > identify an intended zone (because each interface is attached to no > > more than one zone of each scope), that is more specific than desired > > in many cases. > > Sorry, I don't really understand the point...did you mean "how the > outgoing *zone* is identified", not "how the outgoing *interface* is > identified"? Not sure, because interface implies the zone. Reading this again, it seems this problem is actually already resolved in the next sentences in the same paragraph. > > 6) In the section 9, "Forwarding", I think the text about picking the > > destination address zone could be enhanced a bit: > > > o The zone of the destination address is determined by the scope of > > the address and arrival interface of the packet. The next-hop > > interface is chosen by looking up the destination address in a > > (conceptual) routing table specific to that zone. That routing > > table is restricted to refer only to interfaces belonging to that > > zone. > > > ==> that is, this does not seem to spell out whether the routing table > > could include more than just the interfaces of destination address zone -- > > i.e., in the case of a global destination address, the "interfaces belonging > > to that zone" is a bit confusing :-) > > Hmm, perhaps I was too familiar with the concept, but I don't see the > problem. In the case of a global destination address, the zone for > the destination address is the single global zone, and the "interfaces > belonging to that zone" are all the interfaces that the receiving node > has. What is confusing here? The last sentence. I guess this is more of the specific global case, that is, referring _only_ to the interfaces belonging to zone X is a bit misnomer, because if you have a global address, all the interfaces are already there, i.e., that "only" is redundant in this case? (I don't feel strongly about this though.) > > 8) multicast routing in section 10 is rather weak. This is a direct > > resolution of switching from unicast site-locals to multicast > > organization-local addresses. However, with multicast addresses, it is > > not appropriate to use the terms "prefixes" to refer to multicast traffic. The > > multicast routing is so different from unicast, and the term is not > > qualified to convey the intended message here. Some rewording is needed, > > maybe express this using (*,G) or (S,G) state creation where the limits are > > placed on the group G. > > (in the citation I've corrected the lack of "not" pointed out in your > 2nd message) > > I see your point. But it seems to me too much to use the term like > (*, G) or (S, G). At least (*, G) is a notion very specific to a > particular type of multicast routing protocols such as PIM-SM. > > Isn't it enough to revise the text here using "group" instead of > "prefix(es)"? For example, > > say > > * All global groups > > instead of > > * All global prefixes This would probably make sense, seems reasonable here at least. > > 10) Similar bad ideas are described in section 11.7, about how to use IPv6 > > addresses in URL's. The text seems to say that the apps should then strip > > the zone index and be able to parse it.. This would imply that apps handling > > URL's should be made aware of link-local addresses and the zone index > > parsing. This seems like a very, very wrong way to go: > > At least I didn't intend to give an impression that applications need > to parse/strip the format with a zone ID. I see the point, however, > and I'm willing to revise the text if it makes the point clearer. Yes, I thought the impression was not intentional, but that's how it could be read, so if an alternative text can be thought of to be less ambiguous, it would probably be best.. > > ==> suggestion either revise the text significantly or add reword the middle > > sentence: > > > However, the typed URL is often sent on a wire, and it would cause > > confusion if an application did not strip the portion > > before sending. Note that the applications should not need to care > > about which kind of addresses they're using, much less parse or strip out > > the portion of the address. Also, the format for non-global > > addresses might conflict with the URI syntax [10], since the syntax > > defines the delimiter character (%') as the escape character. > > I don't see a problem with the suggested text. Do you think if it is > enough to make the point clear? If so, I'll simply use the rewording. This is probably good enough. > > 11) Note that there is a normative reference to the ICMPv6-bis document, > > which has been pretty much stalled for the last 2 years or so. This > > document cannot be published before ICMPv6-bis is also published. The > > ICMPv6-bis seems integral to this specification, so I think the options are > > either to revise the text about sending ICMP DU "beyond the scope of source > > address" messages (removing it), or kicking off the effort for getting > > ICMPv6-bis out of the door: > > > [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for > > the Internet Protocol Version 6 (IPv6)", Internet Draft draft- > > ietf-ipngwg-icmp-v3-02.txt, November 2001. > > Another good catch. I think you're talking about the rule described > in the 3rd paragraph of draft-rfc-editor-rfc2223bis-07.txt, Section > 2.7. Hmm, we have an agenda item on icmp-v3-02 in the 1st ipv6 wg > meeting tomorrow, so for now I'll see what happens on this. Agreed. > > o The zone of the new destination address is determined by the scope > > of the next address in the Routing Header and arrival interface of > > the packet. The next-hop interface is chosen just like the first > > bullet of the rules above. > > > ==> reword to something like below, to spell out what the next address was: > > (also, add "the" before arrival): > > > o The zone of the new destination address is determined by the scope > > of the next address in the Routing Header (the original destination > > address of the received packet) and the arrival interface of > > the packet. The next-hop interface is chosen just like the first > > bullet of the rules above. > > ... > > This "the next address in the Routing Header" should now be in the > destination address of the IPv6 header (swapped with the original > destination address of the received packet). Did you mean "(swapped > with the original destination address of the received packet)"? Yes. > Perhaps we can simply say "the next address" (removing "in the Routing > Header"). OK. > > Note that it is possible, though generally inadvisable, to use a > > Routing Header to convey a non-global address across its associated > > zone boundary. > > > ==> I'd be a bit more explicit than this.. the convey in this case means > > that a link-local address is encapsulated in the "next address" field but is > > not going to be used. Try e.g.: > > > Note that it is possible, though generally inadvisable, to use a > > Routing Header to convey a non-global address across its associated > > zone boundary in the previously-used next address field, similar as > > one can convey the information in the protocol payloads as well. > > > (could also omit from "similar.." not sure if that's good..) > > I don't see the need for the "similar..." part. So I'll revise the > text as follows: > > Note that it is possible, though generally inadvisable, to use a > Routing Header to convey a non-global address across its associated > zone boundary in the previously-used next address field. OK. > > When an implementation interprets the format, it should construct the > > "full" zone ID, which contains the scope type, from the > > part and the scope type specified by the
part. > > > ==> unless I have completely misunderstood the spec, the first "scope type" > > should actually be "scope zone" :-) > > I don't think you misunderstand the spec, but the first "scope type" > is correct. It corresponds to the following part of Section 6: > > Each zone index of a particular scope should contain an information > to represent the scope type, so that all indices of all scopes are > unique within the node and zone indices themselves can be used for a > dedicated purpose. > > So, at least one person read this to mean differently than originally > intended...do we need to be clearer by revising the text? Reading the first snippet (the first above), I got the feeling "but hey, why is full zone ID including the scope type, and the scope type being overridden from the
". So there probably has to be some revision to clarify that? > I don't need to revise the text, but we might just remove the > "unnumbered", and say > > Also assume that the point-to-point interfaces have link-local > addresses only. > > The removal of the possibly confusing word doesn't matter, IMO, > particularly because this is the only occurrence of "unnumbered". > Does this change make sense. The proposal you stated above seems very good to me. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 00:39:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06708 for ; Tue, 11 Nov 2003 00:39:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRFY-0002c0-2p for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 00:39:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB5daZK010037 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 00:39:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRFX-0002bo-RA for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 00:39:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06673 for ; Tue, 11 Nov 2003 00:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJRFV-0005Fi-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 00:39:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJRFU-0005Ff-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 00:39:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJREz-0002W2-84; Tue, 11 Nov 2003 00:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJREE-0002VC-JL for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 00:38:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06656 for ; Tue, 11 Nov 2003 00:38:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJREB-0005F3-00 for ipv6@ietf.org; Tue, 11 Nov 2003 00:38:11 -0500 Received: from widefw.sm.sony.co.jp ([133.138.0.3] helo=nebula.sm.sony.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AJREA-0005Ex-00 for ipv6@ietf.org; Tue, 11 Nov 2003 00:38:10 -0500 Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.12.9p1/8.12.9) with ESMTP id hAB5bmui029852; Tue, 11 Nov 2003 14:37:49 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.12.9p1/8.12.8) id hAB5bDaS001083; Mon, 10 Nov 2003 23:37:13 -0600 (CST) Date: Mon, 10 Nov 2003 23:37:13 -0600 (CST) From: Atsushi Onoe Message-Id: <200311110537.hAB5bDaS001083@nest.sm.sony.co.jp> To: pekkas@netcore.fi Cc: jinmei@isl.rdc.toshiba.co.jp, ipv6@ietf.org Subject: Re: WGLC comments about scoping-arch In-Reply-To: Your message of "Tue, 11 Nov 2003 06:14:56 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031110-1519/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > The documents with >5 authors at the header need to be specially agreed to > with the IESG. > 2) strike off 1-2 most inactive authors and put them in a "Contributors" > section I think there is only a histrical reason why my name is listed in authors, as an author of combined I-D (draft-ietf-ipngwg-scopedaddr-format). Feel free to remove me from authors if it helps proceeding the document quickly. Atsushi Onoe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 07:51:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29541 for ; Tue, 11 Nov 2003 07:51:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJXyu-0007pa-1v for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 07:50:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABCoqpG030096 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 07:50:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJXyt-0007pL-SG for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 07:50:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29507 for ; Tue, 11 Nov 2003 07:50:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJXyt-0002RP-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 07:50:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJXys-0002RM-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 07:50:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJXy7-0007jW-CT; Tue, 11 Nov 2003 07:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJXxB-0007im-Fc for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 07:49:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29478 for ; Tue, 11 Nov 2003 07:48:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJXxA-0002QP-00 for ipv6@ietf.org; Tue, 11 Nov 2003 07:49:04 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AJXxA-0002QF-00 for ipv6@ietf.org; Tue, 11 Nov 2003 07:49:04 -0500 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 32D2D13; Tue, 11 Nov 2003 21:48:59 +0900 (JST) To: Erik Nordmark Cc: ipv6@ietf.org In-reply-to: Erik.Nordmark's message of Mon, 10 Nov 2003 21:32:23 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: anycast-analysis draft From: itojun@iijlab.net Date: Tue, 11 Nov 2003 21:48:59 +0900 Message-Id: <20031111124859.32D2D13@coconut.itojun.org> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >See > >https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=draft-ietf-ipngwg-ipv6-anycast-analysis&search_rfcnumber=&search_area_acronym=&search_button=SEARCH Bob (Hinden) sent me half dozen of AD comments made in August to me on Sunday. why does AD comment have to be queued and delayed at WG chair? they could send them directly to me, then i would have been able to update the draft before IETF58. anyways, sorry for the rant. i will update the draft to reflect AD comments. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 08:16:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00056 for ; Tue, 11 Nov 2003 08:16:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJYNc-0000lw-If for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 08:16:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABDGOEt002965 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 08:16:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJYNc-0000lk-9C for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 08:16:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00020 for ; Tue, 11 Nov 2003 08:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJYNb-0002mi-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 08:16:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJYNa-0002mf-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 08:16:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJYNH-0000cx-74; Tue, 11 Nov 2003 08:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJYND-0000cV-Fx for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 08:15:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00008 for ; Tue, 11 Nov 2003 08:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJYNC-0002mD-00 for ipv6@ietf.org; Tue, 11 Nov 2003 08:15:58 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1AJYNB-0002m8-00 for ipv6@ietf.org; Tue, 11 Nov 2003 08:15:57 -0500 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 1BD473F4A31; Tue, 11 Nov 2003 08:15:56 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id C2D0F8059E; Tue, 11 Nov 2003 08:15:55 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Tue, 11 Nov 2003 18:45:55 +0530 X-Sasl-Enc: tQ/K4k5dK3Dsh8ZPx6L0sQ 1068556555 Cc: "Pekka Savola" Subject: Re: comments on thaler-ndproxy-01 References: ARRAY(0x9f9084c) In-Reply-To: ARRAY(0x9f905b8) Message-Id: <20031111131555.C2D0F8059E@server2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka, Thanks for the detailed comments. See below... CP On Sun, 9 Nov 2003 16:02:50 +0200 (EET), "Pekka Savola" said: > substantial > ----------- > > 1) The impression of the document is that it's underspecified but > workable. If the goal is to make it more fun to implement this > (instead of more boring :-), by omitting the details of the > specification, this document succeeds. If not, the details need to > be added.. Well, the details probably need to be added anyway, > because some of these apparently obvious methods could vary a lot > from person to person (a couple of examples in the semi-editorial > section) We are probably making the implementors life a bit less fun than what you think. :-) The document does contain implementation details about: 1. Maintenance of neighbor cache. 2. Guidance for providing support for unspecified protocols. 3. General philosophy for choosing the outgoing interface. I do agree with your comment. Some of the topics which I am thinking of adding are: 1. Details about number of IP addresses (non-link-local) required by the proxy. 2. Details about payload modification for each packet-type. (I have mentioned this one in response to one of your other comments below) 3. High-level diagram showing where the proxy functions can be implemented in an IPv6 stack. 4. Bringing all the implementation detail under a "Conceptual Model of a Bridge" section. > 2) I'm not sure whether they should be included in the scenarios, but I > think they're very relevant. That is, deploying the ND proxy to > perform bridging firewall functions on a subnet for multiple > reasons.. remember, that's one of the *major* reasons why NATs are > also deployed in more or less transparent/zero-conf manner. Of > course, in most cases, this can be solved with a regular bridging > firewall as well, no need to use an ND proxy. For example as in > scenario 1: > > > | +-------+ +--------+ > local |Ethernet | | Wireless | Access | > +---------+ A +-))) (((-+ +--> rest of network > hosts | | | link | Point | > | +-------+ +--------+ > > > .. assume that local hosts could also, theoretically, have wireless > interfaces themselves, and communicate directly over the wireless link > without the presence of A. Now, a major reason to deploy something > like A would be the ability to add firewall rules in A, to protect all > the local hosts in one go. Seems to be a plausible scenario. Apart from this, I think ND proxy can also take over the function of the NAT in home networks. Scenario 1 ---------- (isp)<-|->(home) | Ethernet Wireless [ISP]---|---[Router]-------+----[NDproxy]-))) (((-[hosts] | | link | | [hosts] Scenario 2 ---------- (isp)<-|->(home) | Ethernet Wireless [ISP]---|---[NDproxy]------+----[NDproxy]-))) (((-[hosts] | | link | | [hosts] > To sum it up, I'm not 100% sure how much of this needs to be spelled > out or not. Maybe one could include a few words on what other > functions the ND proxies (firewalling etc.) could be used to provide > between the segments, with some caveats. Maybe I was a bit ignorant, but when I had read about ND proxy for the first time in the charter, the applicability was not at all obvious. I think it should be useful to add the scenarios as long as the text does not get out of hand. :-) > What would probably also be very useful is to spell out some of the > scenarios where ND proxy is NOT needed, but regular bridging would be > OK as well -- to give a view that bridging and ND-proxying really do > provide a complete set of solutions. (Just to make it easier to show > folks that NATs are really not needed -- this is a bit out of scope of > the original document, but could be really useful if not done somewhere > else (e.g., v6ops solutions documents..)). The various scenarios (ones in the documents, and the ones above) should make it clear that ND proxy can be used instead of a NAT in an IPv6 network. About classic L2 bridging, IMHO, the document quite clearly states, when it should be used, and its limitations. (Section 1). Is this enough? The different scenarios in which L2 bridges are used (and they are the ones in which ND proxy should not be used) are not described because they are well known. > 3) I'm not sure whether specifying the mechanism for IPv4 is within the > mandate of this WG. But it seems to come in free, so, no huge > resistance here. The worry is just that there may be some v4 > features we're not really aware of and making ND proxying work on v4 > might actually take a lot more effort than we realize at first > (difficult to say at this phase). Actually, there is a bit of work involved for IPv4. It does not come for free. :-) For example, implementation details have to be specified for both IPv4, and IPv6. Currently, most of the implementation detail is specific to IPv6. The neighbor cache structure, its state transition table cannot be applied to IPv4. Minor editorial nits (usage of broadcast and multicast) also have to be taken care of. I am sure there are more of such "non-free" areas. IPv4 ARP proxy has been around for a while now, and IMHO there is not much gain by documenting it now. We should probably remove it. > 4) I want the loop-prevention features to be to non-requirements. If > loop prevention is required, the ND-proxy is deployed improperly. > The only thing from loop prevention I'd appreciate is that the > failure mode would be obvious when/if ND proxying was deployed in > such a manner that a loop would occur. (This would result to moving > the loop prevention stuff to an appendix or removing it..) Don't understand completely. 1. Why do you want the loop-prevention features to be non-requirements? Isn't the current form (of an optional requirement) sufficient? 2. Are you implying that there should be some sort of loop detection mechanism instead? > 5) Non-goals has: > o Support Neighbor Discovery, Router Discovery, or DHCPv4 packets > using encryption with an ESP header. We also note that the current > methods for securing these protocols do not use an ESP header. > Where encryption is required, link-layer encryption can be used on > each segment. > > ==> Uhh, isn't the current approach hostile to IPsec AH as well, as the > payload of the packets (e.g. SLLA, TLLA) are modified, unless the ND > proxy acts as some form of authorized intermediary? I'll leave this one, and all other security related questions for Dave. :-) > ==> I'm not sure whether link-layer encryption sentence is accurate. > Let's consider two cases: the L2 encryption uses a shared secret (known > by the proxy) -- OK; the L2 encryption uses stronger methods (usually > the more useful deployment of L2 encryption) -- the ND proxy needs act > as MITM here, but then L2 encryption will fail, right? Seems right to me. > So, it would seem that in the presence of IPsec AH, IPsec ESP, or link- > layer non-shared key encryption the deployment of ND-proxies may be > problematic, but with some restrictions, possible. These will need to > be considered explicitly somewhere, e.g. a deployment or security > considerations section. Dave? >6) I'm not sure if the spec as written supports the seamless movement > between bridged segments, which was a requirement, for example: > > If the received packet is an ICMPv6 Redirect message, then the proxied > packet should be modified as follows. If the proxy has a valid (i.e., > not INCOMPLETE) neighbor entry for the target address on the same > interface as the redirected host, then the TLLA option in the proxied > Redirect simply contains the link-layer address of the target as found > in the proxy's neighbor entry, since the redirected host may reach the > target address directly. > > ==> now, consider the same if the node moved to a different segment > ==> since the neighbor entry was created? > > Or in: > > The NA is received by P, which then processes it as it would any > unicast packet; i.e., it forwards this out interface 1, based on the > neighbor cache. However, before actually sending the packet out, it > inspects it to determine if the packet being sent is one which > requires proxying. Since it is an NA, it updates its neighbor entry > for B to be REACHABLE and records the link-layer address b. P then > replaces the link-layer address in the TLLA option with its own link- > layer address on the outgoing interface, p1. The packet is then sent > out interface 1. > > ==> this doesn't seem to work when moving between segments without a: > 1) a cache timeout, or > 2) the host, immediately after moving, sending a packet, updating the > proxy's cache. If the host is silent before moving and afterwards, > there will be no indication where it has gone. Right? Right. Though, in most cases the host will not be silent (it will get a trigger from L2 about movement), and will attempt to do Router Discovery. Seamless movement between bridged segments is not supported. We did discuss a solution that involved 1) getting a trigger from L2 that the host has moved, and 2) doing a broadcast of any unicast packet for the moved host on all the proxy ports. This way the unicast packet (NA in this case) would reach the destination. The broadcast would continue till the host sends a packet, and updates the cache. You can refer to the past discussions on this issue at http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%206 Another thing that may have not caught your eye is the assumption that ND proxies always have an IP address. Unlike classic L2 bridges, ND proxies require an IP address. IMHO this is debatable...and I am planning to send out a mail regarding this to the WG. If it is accepted that the ND proxies always have an IP address, another scheme wherein the proxy (after detecting host movement) sends an NS to determine the new location of the moved host (the NA from host would populate the cache of other proxies in the path). Messages received for the moved host, before the NA is received, can either be queued or broadcasted. > 7) doesn't the following break the requirements of transparent > introduction -- for both hosts (need to consider the bridge as a > router), and for the router (it needs to be aware of the ND proxy, > right?)v > > From=20an IPv6 perspective, RFC 2461 [ND] already defines the ability > to proxy Neighbor Advertisements. The requirements for securing > proxied messages are similar to those for securing Router > Advertisements, since the receiver must verify that the advertisement > came from a valid router/proxy, rather than from the owner of a > specific address. Dave? > 8) An IPR section is required. Is there known IPR on this? I am not aware of anything. Dave? > 9) The link layer address changes could affect the packet size. Note > that as the length is given in the units of 64 bits, for most (all?) > the applicable link types that indicates that the packet size won't > be changed. Could be worth pointing out. > However, adding MTU option in sect 4.1.3.3 is a different issue > altogether. Actually, it would also be possible to overflow the RA > size by adding the MTU, if the RA is really loaded witrh prefixes. This > is of course very theoretical, but probably needs to be mentioned > explicitly! Agreed. The perils of these borderline cases have to be mentioned explicitly. > semi-editorial > -------------- > > ==> needs a ToC, as it's over 15 pages Agreed. > Expires December 2003 [Page 1] > =0C > > ==> something is wrong with the page breaks Yup. > When a proxy interface comes up, the node puts it in "all- multicast" > mode so that it will receive all multicast packets. It is common for > interfaces to not support full promiscuous mode (e.g., on a wireless > client), but all-multicast mode is generally still supported. > > ==> s/all multicast/all multicast and broadcast/, right? (not sure > whether the definition of multicast explicitly includes broadcast...) Broadcast packets are received up by default. Hence, no need to mention it. Also, "broadcast mode" seems to be non standard terminology. > When any IP or ARP packet is received on a proxy interface, it must be > parsed to see whether it is known to be of a type that negotiates link- > layer addresses. This document covers the following types: ARP, IPv6 > Neighbor Discovery, IPv6 Router Discovery, IPv6 Redirects, and DHCPv4. > > ==> Could you spell out, for clarity, some protocols: > a) which are not supported by this spec, or > b) which do not need to be supported by this spec (but one could think > whether they need be), e.g. DHCPv6? DHCPv6 is supposed to be supported. We did discuss it. :-) All other protocols that are not mentioned are not supported. The document has a guideline section (section 7) to help implementors in supporting other protocols. > The link layer header, and the link-layer address within the payload > for each forwarded packet will be modified as follows: [...] > > ==> as noted above, these are a bit underspecified.. ("where in the > packets"?) Agree. The quoted text is supposed to be the general philosophy of substitution. Specific substitution details for a message should be mentioned in the sub-section corresponding to the message. > As with all forwarded packets, the link-layer header is also new. Any > Authentication Header would also be removed, and a new one may be added > as discussed below under Security Considerations. > > ==> note that Security Consideration doesn't currently discuss this :-) Dave? :-) > When any IPv4 or ARP packet is received on a proxy interface, it must > be parsed to see whether it is known to be one of the following types: > ARP, or DHCPv4. > > ==> again, not specified how ARP or DHCPv4 packets are recognized; this > should be pretty obvious, but is a bit under-specified.. Yes. > ==> I note that IPv4 Redirects are not supported, but this hasn't been > spelled out anywhere. Omission or intentional ? They should be supported. > To support scenario 2, if the MTU of the upstream segment is smaller > than the MTU of the downstream segment then IPv6 Router Advertisements > (RAs) must also be proxied as follows. If the RA contains an MTU > Option, the RA is forwarded unmodified. Otherwise, the proxy adds an > MTU Option with a value of minimum of the link MTUs of the proxy > interfaces, and then proxies it as described above. > > ==> it should probably be spelled out here, due to the non-requirement, > ND-proxying doesn't work at all if the routers are connected to a link > with higher MTU. Yes. > It also creates a neighbor entry for B (on an arbitrary proxy > interface) in the INCOMPLETE state. Since the packet is multicast, P > then needs to proxy the NS out all other proxy interfaces on the > subnet. Before sending the packet out interface 2, it replaces the > link-layer address in the SLLA option with its own link-layer > address, p2. > > ==> the use of terms "all other proxy interfaces", etc. are a bit > misnomers in this particular example of just two interfaces. I'd > suggest expanding the example so that P has three interfaces, but only > with two nodes A and B (one interface is empty) Ok. > Loop prevention can be done done by having the proxy implement the > Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all > proxy interfaces. > > ==> is this really enough of a specification?? :-)) :-) [BRIDGE] specifies STP in great detail, and since there is no interaction of STP with other functions (described in this document), I don't think there is much we can add beyond this sentence. > Operation of the Spanning Tree Protocol (STP) over other types of link > layers is done by encapsulating the STP frame in an IPv6 header as > follows. The Next Header field is set to [TBA by IANA], indicating > that an STP header follows. The Destination Address field is set to > the Link-scoped STP Multicast Group [TBA by IANA]. All proxies > operating on non-IEEE 802 media join this group so they will receive > STP packets. STP packets are never forwarded or proxied. > > ==> which format is used for encapsulation of STP? Directly > afterwards? It is a "terminal header", correct, so no TLV encoding or > similar need be done? Don't understand "format", and "Directly afterwards" in your question. STP header is the terminal header in the IPv6 packet. > ==> Are ND proxies acting as decapsulators/encapsulators for these STP > packets between the links? If nothing is done based on these, how do > they help in the first place? ND proxies will have a complete implementation of STP, and will process STP packets received on both non-802, and 802 interfaces as per the [BRIDGE] specification. Does this answer your question? > 10. Appendix A: Comparison with other approaches > > ==> this section should be reworded to be refer to RA-proxy only, Agree. > ==> or add some other approaches (probably preferable!) such as IPv4 > Proxy ARP (the differences are probably rather interesting..) Will have to think about this one. Do you have any alternate approaches in mind? > editorial > --------- > > o Support Neighbor Discovery, Router Discovery, or DHCPv4 packets > using encryption with an ESP header. We also note that the current > methods for securing these protocols do not use an ESP header. > Where encryption is required, link-layer encryption can be used on > each segment. > > ==> s/ESP/IPsec Encapsulation Security Payload (ESP)/ > ==> s/Where encryption/Where the encryption of these, typically on- > ==> link, neighbor discovery communications/ > > interface on which it arrived; such a packet is instead silently > dropped. > > ==> s/dropped/discarded/ > > ocally but no ARP REPLY is generated immediately. Instead, the ARP > REQUEST is proxied (as described above) and the ARP REPLY will > > ==> use a proper pointer to sect 4.1 instead of "above". (similar > elsewhere..) > > B receives this NS, processing it as usual. Hence it creates a > neighbor entry for A mapping it to the link-layer address p2. It > responds with a Neighbor Advertisement (NA) sent to A containing B's > link-layer address b. The NA is sent using A's neighbor entry, i.e. to > the link-layer address p2. > > ==> s/with a/with a unicast/ > > example, propritery protocols). This section prescribes guidelines > > ==> s/propritery/proprietary/ > > From=20an IPv6 perspective, RFC 2461 [ND] already defines the > > ==> some scrap here, "=20". Agree with all editorial comments. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 11:36:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08742 for ; Tue, 11 Nov 2003 11:36:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbV6-0005Qu-27 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:36:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGaKQS020880 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbV5-0005Qe-Rh for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:36:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08697 for ; Tue, 11 Nov 2003 11:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbV4-0005aJ-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:36:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJbV4-0005aF-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:36:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbTr-00050K-ET; Tue, 11 Nov 2003 11:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbSr-0004uh-4T for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 11:34:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08606 for ; Tue, 11 Nov 2003 11:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbSp-0005YP-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:33:59 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AJbSp-0005Xg-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:33:59 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hABGXOxA001768; Tue, 11 Nov 2003 08:33:25 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hABGXKQ08927; Tue, 11 Nov 2003 17:33:21 +0100 (MET) Date: Tue, 11 Nov 2003 17:32:29 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Fred Templin Cc: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org In-Reply-To: "Your message with ID" <20031110051419.98144.qmail@web80504.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > As I said I would do in my 10/29/2003 note on the ipv6 list under > the subject heading: "Re: RFC 2461bis issue: MTU handling", I am > now prepared to submit a new version of my document on dynamic > MTU determination. (Please note that there are some significant > differences from the previous version.) I looked over the your document and I wonder how it applies to the WG's desire to clarify the transition mechanisms document and move that to Draft Standard soon. Thus I recommend the WG participants read the document so we can discuss that high-level issue on Wednesday. From one reading I see: Using period(?) hop-by-hop options in data packets to probe the IPv6 path MTU; those packets would be processed slowly by IPv6 routers. IPv6 fragmentation by IPv6 routers; not allowed per RFC 2460 Assuming security associations between the encapsulator and decapsulator Having decapsulators that are otherwise hosts send Router Advertisements seems a bit odd. I don't understand how the IPv4 path MTU is detected by the encapsulator/decapsulator somehow. Is this based on ICMPv4 packet too big message or something else? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 11:48:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09337 for ; Tue, 11 Nov 2003 11:48:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbgd-0007HS-BP for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:48:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGmFAO027980 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:48:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbgd-0007HD-5Q for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09296 for ; Tue, 11 Nov 2003 11:48:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbgc-0005pQ-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:48:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJbgb-0005pM-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:48:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbgQ-0007AT-D4; Tue, 11 Nov 2003 11:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbg2-00079Z-8W for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 11:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09282 for ; Tue, 11 Nov 2003 11:47:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbg0-0005p3-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:47:37 -0500 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw1.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AJbg0-0005ol-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:47:36 -0500 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 1AJbfP-0001rX-00; Tue, 11 Nov 2003 16:46:59 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AJbfO-0001rU-00; Tue, 11 Nov 2003 16:46:58 +0000 Received: from zurich.ibm.com (sig-9-145-241-14.de.ibm.com [9.145.241.14]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hABGktv85424; Tue, 11 Nov 2003 16:46:56 GMT Message-ID: <3FB1125A.399F23CF@zurich.ibm.com> Date: Tue, 11 Nov 2003 17:46:18 +0100 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: Chirayu Patel CC: ipv6@ietf.org, Iljitsch van Beijnum , Hans Kruse , Stephen Sprunk Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> <20031111033346.3E0F87E1E9@server2.messagingengine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Private" implies security virtues that they don't have. "Local" implies geographical limitations that they don't have. "Site" ditto. "Organizational" implies usage limitations that they don't have. "Limited scope" upsets people because of the complexity of the scope debate. "Entity" really isn't different from "organization". Does anybody have a thesaurus handy? Brian Chirayu Patel wrote: > > IMHO, "private" is appropriate. As noted in other emails, "organization" > is bit too specific. Plus, "Private (IPv4) addresses" is a well known > concept, and it would simpler for IPv4 network (home, organization, etc > networks) operators to extend the same understanding to IPv6. > > CP > > On Mon, 10 Nov 2003 21:52:46 +0100, "Brian E Carpenter" > said: > > How about simply calling whatever we end up with "organizational > > addresses"? I think that captures it much better than "local", "site > > local", "private" or whatever. > > > > Brian > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 11:57:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09841 for ; Tue, 11 Nov 2003 11:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbpI-00008v-Uc for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:57:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGvC2q000543 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:57:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbpI-00008g-Qr for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:57:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09793 for ; Tue, 11 Nov 2003 11:57:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbpH-0005zC-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:57:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJbpH-0005z9-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:57:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbp7-0008Rj-Nz; Tue, 11 Nov 2003 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJboI-0008OI-4K for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 11:56:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09763 for ; Tue, 11 Nov 2003 11:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJboG-0005yA-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:56:08 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AJboC-0005xv-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:56:05 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AJboA-0008Gi-00 for ; Tue, 11 Nov 2003 16:56:02 +0000 Date: Tue, 11 Nov 2003 16:56:02 +0000 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <20031111165602.GC12839@fysh.org> References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> <20031111033346.3E0F87E1E9@server2.messagingengine.com> <3FB1125A.399F23CF@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB1125A.399F23CF@zurich.ibm.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Brian E Carpenter wrote: >Does anybody have a thesaurus handy? "Non-global"? -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 12:22:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11116 for ; Tue, 11 Nov 2003 12:22:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcDj-00031U-8P for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 12:22:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHMRPa011614 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 12:22:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcDi-00031F-TR for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:22:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11074 for ; Tue, 11 Nov 2003 12:22:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcDh-0006Q1-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 12:22:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcDh-0006Py-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 12:22:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcDJ-0002sc-QK; Tue, 11 Nov 2003 12:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcDB-0002sF-Rg for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 12:21:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11055 for ; Tue, 11 Nov 2003 12:21:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcD8-0006Pb-00 for ipv6@ietf.org; Tue, 11 Nov 2003 12:21:50 -0500 Received: from web80501.mail.yahoo.com ([66.218.79.71]) by ietf-mx with smtp (Exim 4.12) id 1AJcD7-0006PP-00 for ipv6@ietf.org; Tue, 11 Nov 2003 12:21:49 -0500 Message-ID: <20031111172118.4761.qmail@web80501.mail.yahoo.com> Received: from [130.129.133.218] by web80501.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 09:21:18 PST Date: Tue, 11 Nov 2003 09:21:18 -0800 (PST) From: Fred Templin Subject: Re: Sites in draft "Unique Local IPv6 Unicast Addresses" To: NOISETTE Yoann FTRD/DMI/CAE , ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-666432562-1068571278=:4523" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-666432562-1068571278=:4523 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA11061 Content-Transfer-Encoding: quoted-printable RFC 3582 says: A "site" is an entity autonomously operating a network using IP, and in particular, determining the addressing plan and routing policy for that network. This definition is intended to be equivalent to "enterprise" as defined in [2]. =20 where [2] refers to RFC 1918. =20 This is the definition I have been using in my documents. =20 Fred osprey67@yahoo.com NOISETTE Yoann FTRD/DMI/CAE wrote: Hi,=20 I just wanted to point out something that caught my attention when re-rea= ding this draft. In draft-ietf-ipv6-deprecate-site-local-01.txt, section = 2.4, there is an assertion that "Site is an ill-defined concept" followed= by arguments. When reading draft-ietf-ipv6-unique-local-addr-01.txt, w= e can notice that the word "site" is referred many times, often to descri= be or limit some features or operations on the new defined addresses. Then, though both documents are not to be considered as companion documen= ts, I was wondering if it wouldn't be a good thing that draft-ietf-ipv6-u= nique-local-addr-01.txt gives the meaning of "site" as used for the writi= ng, in order to prevent any confusion or amalgamate with the "site" that = is discussed in draft-ietf-ipv6-deprecate-site-local-01.txt. As an exempl= e (well, for what it's worth) we can see "Apart from link-local, scope bo= undaries are ill-defined. What is a site?" (in the deprecate draft, secti= on 2.4) on the one hand and "Well known prefix to allow for easy filterin= g at site boundaries" (in the ULA draft, section 1.0) on the other hand. I think this should be clarified to prevent any misunderstanding. Moreove= r, while the list is discussing the name to be given to the new defined a= ddresses (organi[zs]ation, local or=85 whatever), the fact to position th= e meaning of "site" used throughout the document might be a good thing. I don't want to restart many discussions that took place on the list many= times on "what is a site", but just wonder if it is a good thing to use = "site" so many times in a document describing new addresses alternatives = to "site-local addresses" without clarifying its meaning as far as the do= cument is concerned. Notably, make it clear it isn't linked to any "scope= " meaning but rather to some operational deployment cases (some examples = could be provided from simple one to more complex making use of VPN or Mo= bile Nodes). My two cents, FWIW...=20 Yoann=20 NOISETTE Yoann=20 &francetelecom R&D=20 DMI/SIR/IPI=20 42, rue des Coutures - BP 6243=20 14066 CAEN Cedex 4 - FRANCE=20 ( : +33 (0)2.31.75.90.48 2 : +33 (0)2.31.73.56.26=20 * mailto:yoann.noisette@francetelecom.com=20 --0-666432562-1068571278=:4523 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA11061 Content-Transfer-Encoding: quoted-printable
RFC 3582 says:

   A "site" is an entity autonomously operating a netw= ork using IP, and
   in particular, determining the addressi= ng plan and routing policy for
   that network.  This d= efinition is intended to be equivalent to
   "enterprise" as= defined in [2].
 
where [2] refers to RFC 1918.
 
This is the definition I have been using in my documents.
 
Fred
osprey67@yahoo.com

=
NOISETTE Yoann FTRD/DMI/CAE <yoann.noisette@francetelecom.co= m> wrote:
=

Hi,

I just wanted to point out something that = caught my attention when re-reading this draft. In draft-ietf-ipv6-deprec= ate-site-local-01.txt, section 2.4, there is an assertion that "Site is a= n ill-defined concept" followed by arguments.  When reading  dr= aft-ietf-ipv6-unique-local-addr-01.txt, we can notice that the word "site= " is referred many times, often to describe or limit some features or ope= rations on the new defined addresses.

Then, though both documents are not to be = considered as companion documents, I was wondering if it wouldn't be a go= od thing that draft-ietf-ipv6-unique-local-addr-01.txt gives the meaning = of "site" as used for the writing, in order to prevent any confusion or a= malgamate with the "site" that is discussed in draft-ietf-ipv6-deprecate-= site-local-01.txt. As an exemple (well, for what it's worth) we can see "= Apart from link-local, scope boundaries are ill-defined. What is a site?"= (in the deprecate draft, section 2.4) on the one hand and "Well known pr= efix to allow for easy filtering at site boundaries" (in the ULA draft, s= ection 1.0) on the other hand.

I think this should be clarified to preven= t any misunderstanding. Moreover, while the list is discussing the name t= o be given to the new defined addresses (organi[zs]ation, local or=85 wha= tever), the fact to position the meaning of "site" used throughout the do= cument might be a good thing.

I don't want to restart many discussions t= hat took place on the list many times on "what is a site", but just wonde= r if it is a good thing to use "site" so many times in a document describ= ing new addresses alternatives to "site-local addresses" without clarifyi= ng its meaning as far as the document is concerned. Notably, make it clea= r it isn't linked to any "scope" meaning but rather to some operational d= eployment cases (some examples could be provided from simple one to more = complex making use of VPN or Mobile Nodes).

My two cents, FWIW...

Yoann

NOISET= TE Yoann
 &francetelecom R&D=20

--0-666432562-1068571278=:4523-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 12:24:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11310 for ; Tue, 11 Nov 2003 12:24:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcFM-0003UP-Bw for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 12:24:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHO8Z5013407 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 12:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcFL-0003U8-VO for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:24:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11241 for ; Tue, 11 Nov 2003 12:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcFJ-0006Sb-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 12:24:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcFJ-0006SY-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 12:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcFG-0003Gg-7h; Tue, 11 Nov 2003 12:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcEt-0003D7-DH for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 12:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11176 for ; Tue, 11 Nov 2003 12:23:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcEr-0006RZ-00 for ipv6@ietf.org; Tue, 11 Nov 2003 12:23:37 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcEq-0006Qq-00 for ipv6@ietf.org; Tue, 11 Nov 2003 12:23:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hABHMlN29922; Tue, 11 Nov 2003 19:22:47 +0200 Date: Tue, 11 Nov 2003 19:22:46 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Fred Templin , Christian Huitema , Jun-ichiro itojun Hagino , , Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 11 Nov 2003, Erik Nordmark wrote: > > As I said I would do in my 10/29/2003 note on the ipv6 list under > > the subject heading: "Re: RFC 2461bis issue: MTU handling", I am > > now prepared to submit a new version of my document on dynamic > > MTU determination. (Please note that there are some significant > > differences from the previous version.) > > I looked over the your document and I wonder how it applies to the WG's > desire to clarify the transition mechanisms document and move that > to Draft Standard soon. I completely agre with this sentiment. This enhanced MTU discovery is way too much of a moving target to be included at this point. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 12:49:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13083 for ; Tue, 11 Nov 2003 12:49:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcdq-0005iH-Hv for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 12:49:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHnQfr021955 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 12:49:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcdq-0005i2-AS for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:49:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13062 for ; Tue, 11 Nov 2003 12:49:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcdo-00074R-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 12:49:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcdo-00074O-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 12:49:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcdR-0005cS-LJ; Tue, 11 Nov 2003 12:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJccq-0005Xx-MT for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 12:48:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13045 for ; Tue, 11 Nov 2003 12:48:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcco-00073x-00 for ipv6@ietf.org; Tue, 11 Nov 2003 12:48:22 -0500 Received: from web80511.mail.yahoo.com ([66.218.79.81]) by ietf-mx with smtp (Exim 4.12) id 1AJcco-00073r-00 for ipv6@ietf.org; Tue, 11 Nov 2003 12:48:22 -0500 Message-ID: <20031111174750.18560.qmail@web80511.mail.yahoo.com> Received: from [130.129.133.218] by web80511.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 09:47:50 PST Date: Tue, 11 Nov 2003 09:47:50 -0800 (PST) From: Fred Templin Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt To: Erik Nordmark Cc: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-493392522-1068572870=:17781" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-493392522-1068572870=:17781 Content-Type: text/plain; charset=us-ascii Erik, Thanks for the comments; as you may have seen I just posted an update to the document that fixes at least one of the issues you have identified (the new version is using the correct L2 fragmentation mechanism). See: www.geocities.com/osprey67/tunnelmtu-04.txt As to how the near endpoint of the tunnel detects the MTU of the IPv4 path to the far endpoint, it is done via authenticated IPv6 Router Advertisement messages from the far end that encode MTU values. One of the MTU values is a measure of the largest packet (or, packet fragment) that has been observed by the far end to traverse the tunnel in one piece, and the other two MTU values provide an indication of the far end's receive buffer size and fragment loss due to congestion. Thanks - Fred osprey67@yahoo.com See below: Erik Nordmark wrote: > As I said I would do in my 10/29/2003 note on the ipv6 list under > the subject heading: "Re: RFC 2461bis issue: MTU handling", I am > now prepared to submit a new version of my document on dynamic > MTU determination. (Please note that there are some significant > differences from the previous version.) I looked over the your document and I wonder how it applies to the WG's desire to clarify the transition mechanisms document and move that to Draft Standard soon. Thus I recommend the WG participants read the document so we can discuss that high-level issue on Wednesday. From one reading I see: Using period(?) hop-by-hop options in data packets to probe the IPv6 path MTU; those packets would be processed slowly by IPv6 routers. IPv6 fragmentation by IPv6 routers; not allowed per RFC 2460 Assuming security associations between the encapsulator and decapsulator Having decapsulators that are otherwise hosts send Router Advertisements seems a bit odd. I don't understand how the IPv4 path MTU is detected by the encapsulator/decapsulator somehow. Is this based on ICMPv4 packet too big message or something else? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-493392522-1068572870=:17781 Content-Type: text/html; charset=us-ascii
Erik,
 
Thanks for the comments; as you may have seen I just posted an update
to the document that fixes at least one of the issues you have identified
(the  new version is using the correct L2 fragmentation mechanism). See:
 
 
As to how the near endpoint of the tunnel detects the MTU of the IPv4 path
to the far endpoint, it is done via authenticated IPv6 Router Advertisement
messages from the far end that encode MTU values. One of the MTU values
is a measure of the largest packet (or, packet fragment) that has been
observed by the far end to traverse the tunnel in one piece, and the other
two MTU values provide an indication of the far end's receive buffer size
and fragment loss due to congestion.
 
Thanks - Fred
 
See below:

Erik Nordmark <Erik.Nordmark@sun.com> wrote:

> As I said I would do in my 10/29/2003 note on the ipv6 list under
> the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
> now prepared to submit a new version of my document on dynamic
> MTU determination. (Please note that there are some significant
> differences from the previous version.)

I looked over the your document and I wonder how it applies to the WG's
desire to clarify the transition mechanisms document and move that
to Draft Standard soon. 

Thus I recommend the WG participants read the document so we can
discuss that high-level issue on Wednesday.

From one reading I see:
Using period(?) hop-by-hop options in data packets to probe the IPv6
path MTU; those packets would be processed slowly by IPv6 routers.

IPv6 fragmentation by IPv6 routers; not allowed per RFC 2460

Assuming security associations between the encapsulator and decapsulator

Having decapsulators t! hat are otherwise hosts send Router Advertisements seems
a bit odd.

I don't understand how the IPv4 path MTU is detected by the
encapsulator/decapsulator somehow. Is this based on ICMPv4 packet too big
message or something else?

Erik


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--0-493392522-1068572870=:17781-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 14:25:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16518 for ; Tue, 11 Nov 2003 14:25:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe8x-0004pM-2d for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 14:25:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJPdho018555 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 14:25:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe8w-0004pB-U6 for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 14:25:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16475 for ; Tue, 11 Nov 2003 14:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe8u-0000Vx-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 14:25:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJe8t-0000Vr-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 14:25:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe8O-0004gE-8S; Tue, 11 Nov 2003 14:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe7N-0004ZZ-AE for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 14:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16376 for ; Tue, 11 Nov 2003 14:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe7K-0000UH-00 for ipv6@ietf.org; Tue, 11 Nov 2003 14:23:58 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AJe7K-0000Tn-00 for ipv6@ietf.org; Tue, 11 Nov 2003 14:23:58 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 11 Nov 2003 11:23:26 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Nov 2003 11:23:26 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:23:25 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 Nov 2003 11:23:31 -0800 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.3790.1069); Tue, 11 Nov 2003 11:23:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Tue, 11 Nov 2003 11:23:27 -0800 Message-ID: Thread-Topic: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Thread-Index: AcOodRWOT00+ZFkgTNSf841zSiCPXQAFA5Pw From: "Christian Huitema" To: "Tim Chown" , X-OriginalArrivalTime: 11 Nov 2003 19:23:18.0763 (UTC) FILETIME=[432EC3B0:01C3A889] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > "Private" implies security virtues that they don't have. > > "Local" implies geographical limitations that they don't have. > > "Site" ditto. > > "Organizational" implies usage limitations that they don't have. > > "Limited scope" upsets people because of the complexity of the scope > debate. > > "Entity" really isn't different from "organization". > > > > Does anybody have a thesaurus handy? >=20 > Well, we have Autonomous Systems so maybe autonomous addressing? Or does > that have too much ASN baggage/confusion, or hint too much at > independence? Globally Unique Non Normally Routable Address Class -- GUNNRAC ? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 15:00:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18465 for ; Tue, 11 Nov 2003 15:00:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJegj-0008GW-RY for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 15:00:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABK0X2q031772 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 15:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJegj-0008GN-0m for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 15:00:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18446 for ; Tue, 11 Nov 2003 15:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJegf-0001CL-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 15:00:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJege-0001CI-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 15:00:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJegF-000875-Dl; Tue, 11 Nov 2003 15:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJefU-000863-Kh for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 14:59:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18391 for ; Tue, 11 Nov 2003 14:59:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJefR-0001Bi-00 for ipv6@ietf.org; Tue, 11 Nov 2003 14:59:13 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AJefQ-0001BE-00 for ipv6@ietf.org; Tue, 11 Nov 2003 14:59:12 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 Nov 2003 11:58:41 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Nov 2003 11:58:35 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:58:42 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 Nov 2003 11:58:47 -0800 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.3790.1069); Tue, 11 Nov 2003 11:58:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on thaler-ndproxy-01 Date: Tue, 11 Nov 2003 11:58:38 -0800 Message-ID: Thread-Topic: comments on thaler-ndproxy-01 Thread-Index: AcOmyo8uFGTbtVhtQYuI3Gpray8ZiwBPUVqw From: "Dave Thaler" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 11 Nov 2003 19:58:40.0272 (UTC) FILETIME=[33B35900:01C3A88E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for the comments, Pekka! Pekka Savola writes: > The doc is pretty good but needs more work The most important thing > appears to be identifying the which features we need (considering the > tradeoffs) >=20 > substantial > ----------- >=20 > 1) The impression of the document is that it's underspecified but workable. > If the goal is to make it more fun to implement this (instead of more > boring :-), by omitting the details of the specification, this document > succeeds. If not, the details need to be added.. Well, the details probably > need to be added anyway, because some of these apparently obvious methods > could vary a lot from person to person (a couple of examples in the > semi-editorial section) Oh but we want implementors to have fun, otherwise they'll be implementing boring things like NATs :-) Comments on your specific examples below. > 2) I'm not sure whether they should be included in the scenarios, but I > think they're very relevant. That is, deploying the ND proxy to perform > bridging firewall functions on a subnet for multiple reasons.. remember, > that's one of the *major* reasons why NATs are also deployed in more or less > transparent/zero-conf manner. Of course, in most cases, this can be solved > with a regular bridging firewall as well, no need to use an ND proxy. For > example as in scenario 1: >=20 >=20 > | +-------+ +--------+ > local |Ethernet | | Wireless | Access | > +---------+ A +-))) (((-+ +--> rest of network > hosts | | | link | Point | > | +-------+ +--------+ >=20 > .. assume that local hosts could also, theoretically, have wireless > interfaces themselves, and communicate directly over the wireless link > without the presence of A. Now, a major reason to deploy something like A > would be the ability to add firewall rules in A, to protect all the local > hosts in one go. >=20 > To sum it up, I'm not 100% sure how much of this needs to be spelled out or > not. Maybe one could include a few words on what other functions the ND > proxies (firewalling etc.) could be used to provide between the segments, > with some caveats. I have no strong opinion either way on this. =20 Any other opinions? > What would probably also be very useful is to spell out some of the > scenarios where ND proxy is NOT needed, but regular bridging would > be OK as well -- to give a view that bridging and ND-proxying really do > provide a complete set of solutions. (Just to make it easier to show > folks that NATs are really not needed -- this is a bit out of scope of the > original document, but could be really useful if not done somewhere else > (e.g., v6ops solutions documents..)). The draft currently states "It is expected that whenever possible links will be bridged at the link layer using classic bridge technology [BRIDGE] as opposed to using the mechanisms herein." As you mention it's a bit out of scope to go farther. Any other opinions? > 3) I'm not sure whether specifying the mechanism for IPv4 is within the > mandate of this WG. But it seems to come in free, so, no huge resistance > here. The worry is just that there may be some v4 features we're not really > aware of and making ND proxying work on v4 might actually take a lot more > effort than we realize at first (difficult to say at this phase). Since you have no resistance immediately, I'm not treating this as an=20 official issue to be tracked at this point. We should keep this in=20 mind going forward though. > 4) I want the loop-prevention features to be to non-requirements. If loop > prevention is required, the ND-proxy is deployed improperly. The only thing > from loop prevention I'd appreciate is that the failure mode would be > obvious when/if ND proxying was deployed in such a manner that a loop would > occur. (This would result to moving the loop prevention stuff to an > appendix or removing it..) There have been arguments both ways on this in the past. At the moment the status in the draft is that it is optional (not required), with some guidance as to when it's useful and=20 when it's not useful. > 5) Non-goals has: > o Support Neighbor Discovery, Router Discovery, or DHCPv4 > packets using encryption with an ESP header. We also note > that the current methods for securing these protocols do not > use an ESP header. Where encryption is required, link-layer > encryption can be used on each segment. >=20 > =3D=3D> Uhh, isn't the current approach hostile to IPsec AH as well, = as the > payload of the packets (e.g. SLLA, TLLA) are modified, unless the ND proxy > acts as some form of authorized intermediary? It's not hostile, since the proxy can still remove the original AH. It can't do the same with ESP encryption. > =3D=3D> I'm not sure whether link-layer encryption sentence is = accurate. Let's > consider two cases: the L2 encryption uses a shared secret (known by the > proxy) -- OK; the L2 encryption uses stronger methods (usually the more > useful deployment of L2 encryption) -- the ND proxy needs act as MITM here, > but then L2 encryption will fail, right?=20 Why would it fail? The proxy always uses its own L2 address, not someone else's. Can you give a more specific example? > So, it would seem that in the presence of IPsec AH, IPsec ESP, or link-layer > non-shared key encryption the deployment of ND-proxies may be problematic, > but with some restrictions, possible. These will need to be considered > explicitly somewhere, e.g. a deployment or security considerations section. > 6) I'm not sure if the spec as written supports the seamless movement > between bridged segments, which was a requirement, for example: >=20 > If the received packet is an ICMPv6 Redirect message, then the > proxied packet should be modified as follows. If the proxy has a > valid (i.e., not INCOMPLETE) neighbor entry for the target address > on the same interface as the redirected host, then the TLLA option > in the proxied Redirect simply contains the link-layer address of > the target as found in the proxy's neighbor entry, since the > redirected host may reach the target address directly. >=20 > =3D=3D> now, consider the same if the node moved to a different = segment since > the neighbor entry was created? I didn't follow. Which node? The redirected host? Or the target address? If the redirected host moves away, the redirect will just be dropped since there will be no one at the destinaion link-layer address. > Or in: >=20 > The NA is received by P, which then processes it as it would any > unicast packet; i.e., it forwards this out interface 1, based on > the neighbor cache. However, before actually sending the packet > out, it inspects it to determine if the packet being sent is one=20 > which requires proxying. Since it is an NA, it updates its > neighbor entry for B to be REACHABLE and records the link-layer > address b. P then replaces the link-layer address in the TLLA > option with its own link-layer address on the outgoing interface, > p1. The packet is then sent out interface 1. >=20 > =3D=3D> this doesn't seem to work when moving between segments without = a: > 1) a cache timeout, or > 2) the host, immediately after moving, sending a packet, updating the > proxy's cache. If the host is silent before moving and afterwards, > there will be no indication where it has gone. Right? Offhand, I think that's right. If the host always does DAD after moving, for example, then (2) would be the case, with (1) applying otherwise. Both of these are not specific to this spec - indeed essentially the same thing would happen with a classic bridge or switch. As a result, I don't see anything wrong with the current draft in this regard. It appears to meet the requirement just as well as a classic bridge or switch does. > 7) doesn't the following break the requirements of transparent introduction > -- for both hosts (need to consider the bridge as a router), and for the > router (it needs to be aware of the ND proxy, right?)v >=20 > From=3D20an IPv6 perspective, RFC 2461 [ND] already defines the > ability to proxy Neighbor Advertisements. The requirements for > securing proxied messages are similar to those for securing Router > Advertisements, since the receiver must verify that the > advertisement came from a valid router/proxy, rather than from the > owner of a specific address. It's unclear (to me at least) at this point. I'm not sure there's any other solution than to disable security for RAs. Hence the current position to state the issue and leave it up to the implementor to decide and the SEND WG to consider. If you have a specific proposal, send text :) > 8) An IPR section is required. Is there known IPR on this? Not that I've heard so far. ARP proxy implementations are pretty old. > 9) The link layer address changes could affect the packet size. Note that > as the length is given in the units of 64 bits, for most (all?) the > applicable link types that indicates that the packet size won't be > changed. Could be worth pointing out. True (i.e. I agree it's less of an issue than one might otherwise think). > However, adding MTU option in sect 4.1.3.3 is a different issue > altogether. Actually, it would also be possible to overflow the RA size > by adding the MTU, if the RA is really loaded witrh prefixes. This is of > course very theoretical, but probably needs to be mentioned explicitly! Agree. > semi-editorial > -------------- >=20 > =3D=3D> needs a ToC, as it's over 15 pages >=20 > =3D=3D> something is wrong with the page breaks >=20 > When a proxy interface comes up, the node puts it in "all- > multicast" mode so that it will receive all multicast packets. It > is common for interfaces to not support full promiscuous mode > (e.g., on a wireless client), but all-multicast mode is generally > still supported. >=20 > =3D=3D> s/all multicast/all multicast and broadcast/, right? (not sure whether > the definition of multicast explicitly includes broadcast...) You don't need to enable any special mode to get all broadcast,=20 so in my opinion "all broadcast" should go without saying. > When any IP or ARP packet is received on a proxy interface, it > must be parsed to see whether it is known to be of a type that > negotiates link-layer addresses. This document covers the > following types: ARP, IPv6 Neighbor Discovery, IPv6 Router > Discovery, IPv6 Redirects, and DHCPv4. >=20 > =3D=3D> Could you spell out, for clarity, some protocols: > a) which are not supported by this spec, or None that I know of offhand. > b) which do not need to be supported by this spec (but one could think > whether they need be), e.g. DHCPv6? Right, we could say DHCPv6 needs no special support. > The link layer header, and the link-layer address within the > payload for each forwarded packet will be modified as follows: > [...] >=20 > =3D=3D> as noted above, these are a bit underspecified.. ("where in = the > packets"?) I guess we were hoping it would be obvious to an implementor, but yes the text could be more specific. =20 > As with all forwarded packets, the link-layer header is also new. > Any Authentication Header would also be removed, and a new one may > be added as discussed below under Security Considerations. >=20 > =3D=3D> note that Security Consideration doesn't currently discuss = this :-) >=20 > When any IPv4 or ARP packet is received on a proxy interface, it > must be parsed to see whether it is known to be one of the > following types: ARP, or DHCPv4. >=20 > =3D=3D> again, not specified how ARP or DHCPv4 packets are recognized; this > should be pretty obvious, but is a bit under-specified.. >=20 > =3D=3D> I note that IPv4 Redirects are not supported, but this hasn't = been > spelled out anywhere. Omission or intentional ? >=20 > To support scenario 2, if the MTU of the upstream segment is > smaller than the MTU of the downstream segment then IPv6 Router > Advertisements (RAs) must also be proxied as follows. If the RA > contains an MTU Option, the RA is forwarded unmodified. > Otherwise, the proxy adds an MTU Option with a value of minimum of > the link MTUs of the proxy interfaces, and then proxies it as > described above. >=20 > =3D=3D> it should probably be spelled out here, due to the non-requirement, > ND-proxying doesn't work at all if the routers are connected to a link with > higher MTU. >=20 > It also creates a neighbor entry for B > (on an arbitrary proxy interface) in the INCOMPLETE state. Since > the packet is multicast, P then needs to proxy the NS out all > other proxy interfaces on the subnet. Before sending the packet > out interface 2, it replaces the link-layer address in the SLLA > option with its own link-layer address, p2. >=20 > =3D=3D> the use of terms "all other proxy interfaces", etc. are a bit misnomers > in this particular example of just two interfaces. I'd suggest expanding > the example so that P has three interfaces, but only with two nodes A and B > (one interface is empty) >=20 > Loop prevention can be done done by having the proxy implement the > Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all > proxy interfaces. >=20 > =3D=3D> is this really enough of a specification?? :-)) >=20 > Operation of the Spanning Tree Protocol (STP) over other types of > link layers is done by encapsulating the STP frame in an IPv6 > header as follows. The Next Header field is set to [TBA by IANA], > indicating that an STP header follows. The Destination Address > field is set to the Link-scoped STP Multicast Group [TBA by IANA]. > All proxies operating on non-IEEE 802 media join this group so > they will receive STP packets. STP packets are never forwarded or > proxied. >=20 > =3D=3D> which format is used for encapsulation of STP? Directly afterwards? It > is a "terminal header", correct, so no TLV encoding or similar need be done? Correct. > =3D=3D> Are ND proxies acting as decapsulators/encapsulators for these = STP > packets between the links? If nothing is done based on these, how do they > help in the first place? This is how a proxy that chose to implement loop prevention would send=20 its _own_ STP messages to a neighboring STP speaker, and receive STP=20 messages from the neighbor. That's the point about "never forwarded=20 or proxied". A proxy that chose to implement loop prevention would act on the packets by running the spanning tree algorithm specified in [BRIDGE] to decide whether to ignore an interface or not. > 10. Appendix A: Comparison with other approaches >=20 > =3D=3D> this section should be reworded to be refer to RA-proxy only, = or add > some other approaches (probably preferable!) such as IPv4 Proxy ARP (the > differences are probably rather interesting..) Proposed text would be gratefully accepted. At least one IPv4 Proxy ARP implementation is pretty much the same as what's documented, but it would be nice to hear from any different ones. Another option would be to just remove Appendix A. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 15:58:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21664 for ; Tue, 11 Nov 2003 15:58:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfao-0004PB-LQ for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 15:58:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABKwUQ4016927 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 15:58:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfao-0004Ow-FK for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 15:58:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21625 for ; Tue, 11 Nov 2003 15:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfam-0001za-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 15:58:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJfam-0001zX-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 15:58:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfaL-0004Ie-Io; Tue, 11 Nov 2003 15:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfZN-0004I8-Nc for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 15:57:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21586 for ; Tue, 11 Nov 2003 15:56:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfZM-0001yy-00 for ipv6@ietf.org; Tue, 11 Nov 2003 15:57:00 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AJfZL-0001yv-00 for ipv6@ietf.org; Tue, 11 Nov 2003 15:56:59 -0500 Received: from ocean.jinmei.org (unknown [2001:468:19ff:80:ddc5:c779:617d:c6ec]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 987EF15214; Wed, 12 Nov 2003 05:56:56 +0900 (JST) Date: Wed, 12 Nov 2003 05:56:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: pekkas@netcore.fi, ipv6@ietf.org Subject: Re: WGLC comments about scoping-arch In-Reply-To: <200311031019.hA3AJi0S019077@burp.tkv.asdf.org> References: <200311031019.hA3AJi0S019077@burp.tkv.asdf.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 3 Nov 2003 12:19:44 +0200, >>>>> Markku Savela said: >> 4) I'm not sure whether I see the immediate need for the unique subnet >> multicast scope assignment, as below: >> >> Furthermore, to avoid the need to perform manual configuration in >> most cases, an implementation should, by default, initially assign >> zone indices as follows, and only as follows: >> [...] >> o A unique subnet (multicast "scop" value 3) index for each >> interface >> >> ==> this seems mostly like a flawed concept anyway, because you don't really >> don't have a multicast "subnet" to begin with, because you don't assign >> multicast addresses on interfaces anyway. So, I'd consider removing this >> automatic default and requiring the subnet scope be configured manually. Hmm, I was not very careful to realize that "subnet-local" scope was not adopted in RFC3513 (it was in draft-ietf-ipngwg-addr-arch-v3-10.txt). draft-ietf-ipv6-addr-arch-v4-00.txt still does not have it. I don't remember the discussion, if any, on why this concept was removed from the address architecture, but I agree the concept is not very clear at best. I guess the most reasonable way to deal with this point is to remove the concept of "subnet-local" scope from this document as well. I hope this makes sense for everyone. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 03:54:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11385 for ; Wed, 12 Nov 2003 03:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJqlJ-0004dn-LH for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 03:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC8s5eN017838 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 03:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJqlJ-0004dd-4C for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 03:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11341 for ; Wed, 12 Nov 2003 03:53:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJqlG-0003ef-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 03:54:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJqlG-0003ec-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 03:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJqiM-0004IF-No; Wed, 12 Nov 2003 03:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJqiE-0004Fx-J7 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 03:50:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11218 for ; Wed, 12 Nov 2003 03:50:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJqiB-0003bo-00 for ipv6@ietf.org; Wed, 12 Nov 2003 03:50:51 -0500 Received: from evrtwa1-ar8-4-65-024-025.evrtwa1.dsl-verizon.net ([4.65.24.25] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AJqiB-0003bi-00 for ipv6@ietf.org; Wed, 12 Nov 2003 03:50:51 -0500 Received: from eaglet (127.0.0.1:3409) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 12 Nov 2003 00:50:57 -0800 From: "Tony Hain" To: Subject: Comments about draft-hain-templin-ipv6-limitedrange Date: Wed, 12 Nov 2003 00:50:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcOotO2nNmMwAPCiQDq9C/UMWpjEpw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For those who were not in the room this evening, my comments were that the complaints on the list about the draft fall into a couple of broad categories: One class basically intends to tell people how to run their networks. The IETF defines how the protocols work, not how individual networks are run. Another class basically ignores the reality that network managers will deploy address space for local use, no matter what the IETF does. The IETF can provide a place for those organizations to meet their local requirements, or deal with the randomness that will result. Unfortunately I had to leave at that point for a jury, so I do not know what discussion happened related to Fred's presentation of the draft itself. One comment I did have though was the delay of the milestone as presented by the chairs due to comments seems inappropriate since neither Fred nor I know of any outstanding issues. This document is detailing the reasons that individual network managers use private address space. It really doesn't matter if the IETF believes they are wrong, this is what they do and will continue to do to meet their requirements. The only thing the IETF can do is provide alternatives that are cheaper in each environment. Since consistency plays a significant role in recurring operational costs, to achieve any deployment, the various proposals suggesting that the IETF provide a pile of different approaches for segments of the problem space will need to show these network managers how such a collection is cheaper than the increased training and generally higher clue factor of the operations staff needed to run them. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 08:39:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17028 for ; Wed, 12 Nov 2003 08:39:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJvDS-0002BZ-Hh for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 08:39:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACDdQ2V008395 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 08:39:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJvDS-0002BK-Bx for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 08:39:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16992 for ; Wed, 12 Nov 2003 08:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJvDR-0006Yy-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 08:39:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJvDQ-0006Yv-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 08:39:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJvC6-0001zZ-Ix; Wed, 12 Nov 2003 08:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJvBz-0001ym-J9 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 08:37:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16958 for ; Wed, 12 Nov 2003 08:37:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJvBy-0006Xm-00 for ipv6@ietf.org; Wed, 12 Nov 2003 08:37:54 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AJvBx-0006Xi-00 for ipv6@ietf.org; Wed, 12 Nov 2003 08:37:53 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D5CBBAFC63 for ; Wed, 12 Nov 2003 08:37:52 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19307-04; Wed, 12 Nov 2003 08:37:51 -0500 (EST) Received: from cs.utk.edu (1Cust188.tnt1.minneapolis3.mn.da.uu.net [67.250.209.188]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3D511AFC90; Wed, 12 Nov 2003 08:37:48 -0500 (EST) Date: Wed, 12 Nov 2003 08:38:25 -0500 Subject: myth: IETF cannot tell people how to run their networks Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Keith Moore To: ipv6@ietf.org From: Keith Moore Content-Transfer-Encoding: 7bit Message-Id: <7DD72DE2-1515-11D8-BD59-000393DB5366@cs.utk.edu> X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tony keeps making statements like the one in the subject line of this message. This message attempts to explain why such statements are not helpful generalizations. IETF can, does, and should make various kinds of statements about how people run IP networks. Most of the time, these take the form of constraints on how particular protocols operate, that are encoded in protocol specifications and are expected to be enforced by implementations of these protocols. Sometimes, they take the form of operational rules, such as rules for assignment of IP addresses to hosts. Neither kind of statement is inherently out-of-scope for IETF. Among the kinds of statements that are appropriate for IETF to make are: a. Rules that are necessary to ensure the reliable operation of your network, or reliable interoperation between your network and other networks. We can't stop you from breaking these rules, but we can say that the reliable operation of your network, or interoperation between your network and other networks, cannot be assured if you break those rules. In some cases, failure to adhere to these rules may result in your peers or access providers discontinuing that access. b. Rules that are necessary to ensure reliable interoperation of applications over your network, or between your network and other networks. We can't stop you from breaking these rules, but we can say that adherence to these rules is necessary to provide the services that applications rely on, and that Internet applications are designed and built on the assumption that these rules are followed. Some applications are more sensitive to disruption of these rules than others, and some rules have more of an effect than others. In some cases your traffic may be filtered and/or ignored by potential peers if you fail to adhere to application protocols. c. Rules that are necessary to ensure future extensibility of network functionality, say to support self-configuring networks, mobile networks, automatic renumbering, increased security, etc. We can't stop you from breaking these rules, but if you do break these rules you may find it difficult to support the new functionality once it is defined, and you may find that hosts and/or apps fail to interoperate over your network when those hosts and/or apps begin to support the new functionality. d. Rules that are necessary to prevent harm or abuse, by or from your network or hosts to the rest of the network, or to preserve the public network's ability to support new kinds of applications. We can't stop you from breaking these rules. However in some cases where your network is actively observed to be harming others' networks (like supporting DoS attacks, spam relaying, or transmitting viruses) then this may be cause for your network's external access to be terminated by your peers or access providers. And if networks (individually or collectively) degrade the internet's ability to support new applications then everyone gets less utility out of the network. -- These categories are not mutually-exclusive; a rule may fall into one or more of the above categories. There may exist valid reasons for imposing a rule other than those in the list above. We may discourage the breaking of these rules by various means, including writing specifications for protocols that fail to operate/interoperate when one or more of those rules are broken, and/or by making detection of such rule violations mandatory-to-implement parts of standard specifications. Our goal in doing so is to preserve essential functionality and extensibility of the network and to increase flexibility rather than to limit it. Many people feel that it is appropriate to break one or more rules and accept corresponding limitations in operation of networks, hosts, or applications. In some cases, particularly for small networks intended to support a very limited set of services or applications, such changes may be defensible. However the designs of various aspects of the Internet core protocols, and the interactions between those protocols and applications, are widely varied and often quite subtle. Within IETF, it has been frequently observed that detailed analysis and/or many different kinds of expertise are required to understand these interactions and the implications of changes to design assumptions. It might be relatively easy for a network administrator to understand the effect of bending a rule for a network that supports, say, only a cluster of HTTP servers; it is much more difficult to understand the effect of bending a rule for a network that supports a diverse or sizable user community - particularly so since protocols change over time. Also, there may be a desire to support new protocols that are more affected by the rule-bending than those supported earlier. -- On the other hand, there are certain kinds of rules that IETF does not feel free to make. For example: a. We do not insist that you configure your network to admit or pass any particular kind of traffic from external networks, other than the traffic (e.g. routing protocols) necessary to facilitate such external connection as you choose to make. b. We do not tell you what protocols you must run on your hosts that you connect to the network, except for those protocols that are necessary to provide network connectivity itself (e.g. neighbor discovery). However some applications cannot tolerate arbitrary restrictions on connectivity between participating hosts; if you choose to run those applications you may need to make sure that the participating hosts on your network can communicate with other hosts participating in that application. c. We will not insist that you subject your host or network to security threats beyond those inherent in supporting the protocols or services that you choose to support. (there are probably more of these that we've implicitly adhered to but which I haven't thought of yet) ---- well, this started off as a quick one-off and ended up looking a lot like a draft document. I'll probably turn it into an I-D in a few days. Anyway, I hope that it facilitates more enlightening discussion than the "can't make rules about other people's networks!" "can too!" "can not!" "can too!" exchange. comments welcome. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 10:54:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23836 for ; Wed, 12 Nov 2003 10:54:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxKA-0001eM-08 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 10:54:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFsTTC006341 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 10:54:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxK9-0001eC-RB for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:54:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23800 for ; Wed, 12 Nov 2003 10:54:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxK7-0000xG-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 10:54:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJxK7-0000xD-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 10:54:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxHl-0001Jr-7Q; Wed, 12 Nov 2003 10:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxGo-0000vN-Sg for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 10:51:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23492 for ; Wed, 12 Nov 2003 10:50:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxGm-0000pt-00 for ipv6@ietf.org; Wed, 12 Nov 2003 10:51:00 -0500 Received: from web80502.mail.yahoo.com ([66.218.79.72]) by ietf-mx with smtp (Exim 4.12) id 1AJxGl-0000me-00 for ipv6@ietf.org; Wed, 12 Nov 2003 10:50:59 -0500 Message-ID: <20031112155027.20287.qmail@web80502.mail.yahoo.com> Received: from [130.129.130.130] by web80502.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 07:50:27 PST Date: Wed, 12 Nov 2003 07:50:27 -0800 (PST) From: Fred Templin Subject: Re: Comments about draft-hain-templin-ipv6-limitedrange To: Tony Hain , ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1606217762-1068652227=:19188" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1606217762-1068652227=:19188 Content-Type: text/plain; charset=us-ascii I cannot say which of Tony's points I agree on and which I still might have some uncertainties. But, I will say that our document presents Scenarios and Goals that no one seems to be disputing as a service to the community and these will not go away. I will also say that I think it's time for us to get out of this holding posture and move on, and that will be my only comment at this time. Fred Templin osprey67@yahoo.com Tony Hain wrote: For those who were not in the room this evening, my comments were that the complaints on the list about the draft fall into a couple of broad categories: One class basically intends to tell people how to run their networks. The IETF defines how the protocols work, not how individual networks are run. Another class basically ignores the reality that network managers will deploy address space for local use, no matter what the IETF does. The IETF can provide a place for those organizations to meet their local requirements, or deal with the randomness that will result. Unfortunately I had to leave at that point for a jury, so I do not know what discussion happened related to Fred's presentation of the draft itself. One comment I did have though was the delay of the milestone as presented by the chairs due to comments seems inappropriate since neither Fred nor I know of any outstanding issues. This document is detailing the reasons that individual network managers use private address space. It really doesn't matter if the IETF believes they are wrong, this is what they do and will continue to do to meet their requirements. The only thing the IETF can do is provide alternatives that are cheaper in each environment. Since consistency plays a significant role in recurring operational costs, to achieve any deployment, the various proposals suggesting that the IETF provide a pile of different approaches for segments of the problem space will need to show these network managers how such a collection is cheaper than the increased training and generally higher clue factor of the operations staff needed to run them. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-1606217762-1068652227=:19188 Content-Type: text/html; charset=us-ascii
I cannot say which of Tony's points I agree on and which I still
might have some uncertainties. But, I will say that our document
presents Scenarios and Goals that no one seems to be disputing
as a service to the community and these will not go away. 
 
I will also say that I think it's time for us to get out of this holding
posture and move on, and that will be my only comment at this time.
 
Fred Templin
osprey67@yahoo.com

Tony Hain <alh-ietf@tndh.net> wrote:
For those who were not in the room this evening, my comments were that the
complaints on the list about the draft fall into a couple of broad
categories:

One class basically intends to tell people how to run their networks. The
IETF defines how the protocols work, not how individual networks are run.

Another class basically ignores the reality that network managers will
deploy address space for local use, no matter what the IETF does. The IETF
can provide a place for those organizations to meet their local
requirements, or deal with the randomness that will result.

Unfortunately I had to leave at that point for a jury, so I do not know what
discussion happened related to Fred's presentation of the draft itself. One
comment I did have though was the delay of the milestone as presented by the
chairs due to comments seems inapprop! riate since neither Fred nor I know of
any outstanding issues. This document is detailing the reasons that
individual network managers use private address space. It really doesn't
matter if the IETF believes they are wrong, this is what they do and will
continue to do to meet their requirements. The only thing the IETF can do is
provide alternatives that are cheaper in each environment. Since consistency
plays a significant role in recurring operational costs, to achieve any
deployment, the various proposals suggesting that the IETF provide a pile of
different approaches for segments of the problem space will need to show
these network managers how such a collection is cheaper than the increased
training and generally higher clue factor of the operations staff needed to
run them.

Tony


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Req! uests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-1606217762-1068652227=:19188-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 11:20:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25081 for ; Wed, 12 Nov 2003 11:20:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxia-0004Bk-Uu for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 11:19:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGJiMd016094 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 11:19:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxia-0004BV-OW for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 11:19:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25048 for ; Wed, 12 Nov 2003 11:19:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxiZ-0001Se-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 11:19:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJxiZ-0001Sb-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 11:19:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxht-00041i-Pr; Wed, 12 Nov 2003 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxhl-0003zT-EO for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 11:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24995 for ; Wed, 12 Nov 2003 11:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxhk-0001Rf-00 for ipv6@ietf.org; Wed, 12 Nov 2003 11:18:52 -0500 Received: from web80505.mail.yahoo.com ([66.218.79.75]) by ietf-mx with smtp (Exim 4.12) id 1AJxhj-0001RS-00 for ipv6@ietf.org; Wed, 12 Nov 2003 11:18:51 -0500 Message-ID: <20031112161820.38208.qmail@web80505.mail.yahoo.com> Received: from [130.129.130.130] by web80505.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 08:18:20 PST Date: Wed, 12 Nov 2003 08:18:20 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031111163706.40437.qmail@web80506.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-411227274-1068653900=:37390" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-411227274-1068653900=:37390 Content-Type: text/plain; charset=us-ascii I have one more update to share on this document. It is found at: www.geocities.com/osprey67/tunnelmtu-05.txt Changelog is below: Fred Templin osprey67@yahoo.com Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminated control message overhead. Fred Templin wrote: Folks, I uncovered a few bugs and made some changes since yesterday. (I was using the wrong mechanism for L2 fragmentation! :^/ ) The new document version can be found at: www.geocities.com/osprey67/tunnelmtu-04.txt The changelog appears below: Fred osprey67@yahoo.com Appendix A. Changelog o Specified use of IPv4 fragmentation (instead of IPv6) as the L2 fragmentation mechanism. o Added CongestMTU for use during periods of congestion. o Added support for sending congestion indications not associated with probes. o Clarified DF bit settings. Fred Templin wrote: I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-411227274-1068653900=:37390 Content-Type: text/html; charset=us-ascii
I have one more update to share on this document. It is found at:
 
 
Changelog is below:
 
Fred Templin
 
Appendix A. Changelog

   o  Removed support for IPv4 fragmentation to save state; eliminated
      control message overhead.


Fred Templin <osprey67@yahoo.com> wrote:
Folks,
 
I uncovered a few bugs and made some changes since yesterday.
(I was using the wrong mechanism for L2 fragmentation! :^/ ) The
new document version can be found at:
 
 
The changelog appears below:
 
Fred
 
Appendix A. Changelog

   o  Specified use of IPv4 fragmentation (instead of IPv6) as the L2
      fragmentation mechanism.

   o  Added CongestMTU for use during periods of congestion.

   o  Added support for sending congestion indications not associated
      with probes.

   o  Clarified DF bit settings.



Fred Templin <osprey67@yahoo.com> wrote:
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-411227274-1068653900=:37390-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 12:29:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28747 for ; Wed, 12 Nov 2003 12:29:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJynf-0002Ka-3i for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 12:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACHT3MW008959 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 12:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyne-0002KQ-Jr for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 12:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28707 for ; Wed, 12 Nov 2003 12:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJynd-0002kz-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 12:29:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJync-0002kv-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 12:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJymf-0002EO-PM; Wed, 12 Nov 2003 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJym1-0002Du-LP for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 12:27:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28657 for ; Wed, 12 Nov 2003 12:27:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJym0-0002kT-00 for ipv6@ietf.org; Wed, 12 Nov 2003 12:27:20 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AJylz-0002kQ-00 for ipv6@ietf.org; Wed, 12 Nov 2003 12:27:19 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E423CAFC7A; Wed, 12 Nov 2003 12:27:17 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31104-05; Wed, 12 Nov 2003 12:27:17 -0500 (EST) Received: from cs.utk.edu (dyn132-55.ietf58.ietf.org [130.129.132.55]) by smtp.cs.utk.edu (Postfix) with ESMTP id C47CDAFB80; Wed, 12 Nov 2003 12:27:16 -0500 (EST) Date: Wed, 12 Nov 2003 12:26:23 -0500 Subject: Re: Comments about draft-hain-templin-ipv6-limitedrange Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Keith Moore , To: "Tony Hain" From: Keith Moore In-Reply-To: Message-Id: <56AF4A98-1535-11D8-B1EB-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > For those who were not in the room this evening, my comments were that > the > complaints on the list about the draft fall into a couple of broad > categories: > > One class basically intends to tell people how to run their networks. > The > IETF defines how the protocols work, not how individual networks are > run. I've responded to this in a separate message. > Another class basically ignores the reality that network managers will > deploy address space for local use, no matter what the IETF does. you might be right, but our job is produce designs that actually work. what you are proposing is that we abandon that task, on the assumption that users will break what we do anyway. if you feel that this effort is a waste of your time feel free to concentrate your energies in other directions, but don't expect us the rest of us to give up simply because of your speculation. > One comment I did have though was the delay of the milestone as > presented by the > chairs due to comments seems inappropriate since neither Fred nor I > know of > any outstanding issues. other than that the set of constraints you wish to impose are unworkable? > This document is detailing the reasons that > individual network managers use private address space. It really > doesn't > matter if the IETF believes they are wrong, this is what they do and > will > continue to do to meet their requirements. this is just a re-expression of the myth that everything in IPv6 has to be done like it was done in IPv4. managers can choose to use IPv6 or not based on whether they think IPv6 suits their needs. but if they choose to use IPv6 and expect IPv6 to work well even though they are using IPv6 in a way that conflicts with its design, they're deluded. individuals and vendors who encourage such delusions are not doing their audiences a service. > Since consistency plays a significant role in recurring operational > costs, to achieve any deployment, the various proposals suggesting > that the IETF provide a pile of > different approaches for segments of the problem space will need to > show > these network managers how such a collection is cheaper than the > increased > training and generally higher clue factor of the operations staff > needed to > run them. The notion that this is a single problem space is an illusion, or an artifice. The IP address is a bit like Maslow's hammer - just because you can awkwardly use it as a tool to solve a particular problem does not mean that it's well-suited for all of those problems. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 14:12:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02370 for ; Wed, 12 Nov 2003 14:12:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0Pg-0000LT-7a for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 14:12:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACJCOwk001326 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 14:12:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0Pf-0000LJ-BZ for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 14:12:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02327 for ; Wed, 12 Nov 2003 14:12:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0Pc-00043E-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 14:12:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK0Pb-00043A-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 14:12:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0NN-0008Mt-QH; Wed, 12 Nov 2003 14:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0Ml-0008Ka-Co for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 14:09:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02178 for ; Wed, 12 Nov 2003 14:09:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0Mh-00040O-00 for ipv6@ietf.org; Wed, 12 Nov 2003 14:09:19 -0500 Received: from web80503.mail.yahoo.com ([66.218.79.73]) by ietf-mx with smtp (Exim 4.12) id 1AK0Mg-000405-00 for ipv6@ietf.org; Wed, 12 Nov 2003 14:09:18 -0500 Message-ID: <20031112190845.16713.qmail@web80503.mail.yahoo.com> Received: from [130.129.130.130] by web80503.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 11:08:45 PST Date: Wed, 12 Nov 2003 11:08:45 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031112161820.38208.qmail@web80505.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1473857740-1068664125=:16558" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1473857740-1068664125=:16558 Content-Type: text/plain; charset=us-ascii Yes, it's me again - hopefully one last time. I took out a bit too much in my last iteration on the document. I have added the following new text under "Sending Packets:" "If the packet is 1280 bytes in length and it contains an IPv6 fragment header, the tunnel interface encapsluates the packet in IPv4 then fragments the encapsulated packet to a fragment size of 256 bytes. Each of the five resulting fragments will add a 20 byte IPv4 fragment header making each fragment 276 bytes. Thus, each fragment will fit within the ~200msec human perceptible delay budget for the lowest-common denominator link that may occur over the tunnel, which is 296 bytes for a 9.6kbps link ([RFC3150], section 2.3)." See: www.geocities.com/osprey67/tunnelmtu-06.txt Thanks - Fred osprey67@yahoo.com Fred Templin wrote: I have one more update to share on this document. It is found at: www.geocities.com/osprey67/tunnelmtu-05.txt Changelog is below: Fred Templin osprey67@yahoo.com Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminated control message overhead. Fred Templin wrote: Folks, I uncovered a few bugs and made some changes since yesterday. (I was using the wrong mechanism for L2 fragmentation! :^/ ) The new document version can be found at: www.geocities.com/osprey67/tunnelmtu-04.txt The changelog appears below: Fred osprey67@yahoo.com Appendix A. Changelog o Specified use of IPv4 fragmentation (instead of IPv6) as the L2 fragmentation mechanism. o Added CongestMTU for use during periods of congestion. o Added support for sending congestion indications not associated with probes. o Clarified DF bit settings. Fred Templin wrote: I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-1473857740-1068664125=:16558 Content-Type: text/html; charset=us-ascii
Yes, it's me again - hopefully one last time. I took out a bit too much in
my last iteration on the document. I have added the following new text
under "Sending Packets:"

      "If the packet is 1280 bytes in length and it contains an IPv6
      fragment header, the tunnel interface encapsluates the packet
      in IPv4 then fragments the encapsulated packet to a fragment
      size of 256 bytes. Each of the five resulting fragments will
      add a 20 byte IPv4 fragment header making each fragment 276
      bytes. Thus, each fragment will fit within the ~200msec human
      perceptible delay budget for the lowest-common denominator
      link that may occur over the tunnel, which is 296 bytes for
      a 9.6kbps link ([RFC3150], section 2.3)."
 
See:
 
 
Thanks - Fred
osprey67@yahoo.com


Fred Templin <osprey67@yahoo.com> wrote:
I have one more update to share on this document. It is found at:
 
 
Changelog is below:
 
Fred Templin
 
Appendix A. Changelog

   o  Removed support for IPv4 fragmentation to save state; eliminated
      control message overhead.


Fred Templin <osprey67@yahoo.com> wrote:
Folks,
 
I uncovered a few bugs and made some changes since yesterday.
(I was using the wrong mechanism for L2 fragmentation! :^/ ) The
new document version can be found at:
 
 
The changelog appears below:
 
Fred
 
Appendix A. Changelog

   o  Specified use of IPv4 fragmentation (instead of IPv6) as the L2
      fragmentation mechanism.

   o  Added CongestMTU for use during periods of congestion.

   o  Added support for sending congestion indications not associated
      with probes.

   o  Clarified DF bit settings.



Fred Templin <osprey67@yahoo.com> wrote:
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-1473857740-1068664125=:16558-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 15:01:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04519 for ; Wed, 12 Nov 2003 15:01:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1B9-0003hy-DS for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:01:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACK1R8E014248 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:01:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1B7-0003hP-HV for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04447 for ; Wed, 12 Nov 2003 15:01:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1B2-0004nX-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:01:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1B0-0004nO-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:01:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK19m-0003JD-DT; Wed, 12 Nov 2003 15:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK19I-0003IC-G3 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 14:59:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04344 for ; Wed, 12 Nov 2003 14:59:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK19F-0004iv-00 for ipv6@ietf.org; Wed, 12 Nov 2003 14:59:29 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AK19E-0004is-00 for ipv6@ietf.org; Wed, 12 Nov 2003 14:59:28 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0BD46AFCD9 for ; Wed, 12 Nov 2003 14:59:27 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31631-07; Wed, 12 Nov 2003 14:59:25 -0500 (EST) Received: from cs.utk.edu (dyn129-239.ietf58.ietf.org [130.129.129.239]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7316CAFCDC; Wed, 12 Nov 2003 14:59:25 -0500 (EST) Date: Wed, 12 Nov 2003 15:00:04 -0500 Subject: comments on draft-hain-templin-ipv6-localcomm-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Keith Moore To: ipv6@ietf.org From: Keith Moore Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit These are comments on the document rather than on Tony's presentation yesterday I think the notion of "local-use" address conflates several different things that are better treated as separate subjects. Even if one accepts all of these as valid problems (which I don't), it's not clear that they should all share the same solution. If you want to argue that (managed or self-organizing) networks that are not connected to the public Internet need to be able to get address blocks easily, which allow them to connect with other networks by private agreement, I agree entirely. If you want to argue that networks need stable addresses for internal use that allow local applications to survive renumbering and/or moving the attachment to the public internet, I agree with this also. If you want to argue that nomadic networks (whether "personal area networks" or on a larger scale) need stable address blocks, which can be used to communicate within the network, and which allow them to be connected to and/or merged with other nomadic networks, and which also allow them to intermittently connect to stable networks with or without public internet connectivity, I agree entirely. (I prefer "nomadic networks" to "active sites", since "active networking" has been used to mean something else. And I think the notion of "site" is semantically loaded in a way that is not productive to this discussion - in particular, the scope of a network does not necessarily coincide with a single administrative entity or boundary. Also we need to consider both auto-configured/ad-hoc networks and managed networks, which seems to be inconsistent with the notion of "site".) However if you want to argue that the boundary of a network using a particular kind of prefix is something that hosts or applications should inherently or automatically recognize as a boundary for trustworthiness or as a limit to the range of the services they provide, I strongly disagree. The host or app can detect that a potential peer is using a different network prefix, but that says nothing about "who it is" or even "where it is". It is not appropriate for the host or app to assume anything about the relative trustworthiness of either "local" or "nonlocal" peers. This certainly isn't something we should support as part of the addressing architecture. Long experience indicates that addresses are poor indicators of trustworthiness. So it is NOT the job of an addressing scheme to protect "private" assets from exposure to the public Internet - because the notion of "private" is arbitrary and the policy governing external access can and in many cases should not be based on the address prefixes in use. A nomadic host may move from one address to another, from a local address (e.g. home network) to a global address (public dialup or mobile access network) and then to another local address on a different network that still connects with the first one. The fact that the host moves should not inherently affect its ability to access services, and it's not desirable for the architecture to support an assumption that this is even desirable. If you want to argue that network administrators will filter traffic to sets of hosts, I agree entirely. However they should realize that this technique is not sufficient to ensure the security of those hosts from attack - as experience indicates. Filtering can be useful as part of a defense-in-depth but should not be considered a substitute for authentication. If you want to argue that network administrators will prefer to filter traffic on the basis of network prefix rather than listing specific hosts, I agree entirely. However they should be aware that this approach is somewhat inflexible in several ways, and thus of limited applicability. If you want to argue that it therefore makes sense to encode policy into addresses, and to expect hosts and applications to use the "right" source or destination address for a host in order to negotiate a path through the network to the destination that is consistent with policy, I strongly disagree. This is a far worse overloading of the IP address than say, using the IP address as a host identifier. In general, hosts and apps cannot be expected to be aware of the policy governing use of particular IP address prefixes in particular environments. Nor is it reasonable to expect multi-node applications to implement policy-based routing through such networks. Nor is it even reasonable to expect address selection algorithms to cope with such apparently arbitrary distinctions. Can a network, under some conditions, use filtering of address prefixes as a crude policy mechanism for enforcement of crude policies without doing much harm? Probably, but that's a far cry from claiming that it's generally desirable to encode policies into IPv6 addresses. Nor is the desire to use this as a policy mechanism justification for harming the flexibility of the IPv6 network to support diverse types of applications. Similarly the notion that a designated address prefix provides a "hint" to applications regarding filtering is a dubious one - for a variety of reasons. It conflicts with the desire to be able to interconnect with other private networks. It assumes that the same policy applies to all applications on a network when it's much more realistic for that policy to vary from one host or application to another. Even if the app has a clue that its traffic might be filtered, this really is not useful as a policy indication - should this be taken as an indication that the app cannot communicate with that host at all, or instead as an indication that the app must route its requests through an intermediary? Even if it did not create undesirable conflicts over address assignment, the idea that what is essentially a single bit of policy indication is useful to all hosts and all apps on a network is ridiculous - certainly not something that we should provide for in the architecture. Regarding stability of addresses - a certain amount of stability is necessary for long-running applications, though perhaps indefinite stability is too much to ask. Any network will from time to time be re-organized, hardware will be replaced, etc. An app or host that relies on infinite stability - even in the presence of GUPIs or PUPIs - is probably being unrealistic. There is certainly a need to provide stability during such transitions - in order that they can be handled gracefully - but that's not the same thing as expecting addresses to last forever. Regarding the example of the alarm system, is it really reasonable to expect an alarm system to communicate when external monitors without being able to tolerate changes to the external monitors' addresses? Another problem with encoding policy into IP addresses is that it makes it considerably more difficult to handle interconnections between various types of networks (self-configuring vs. managed, core-connected vs. private) and the transitions between some of those states that occur as the result of new connections or disconnections. Coping with transitions between PA, PI, and 6to4 addresses is already difficult enough; overloading those addresses with policy makes it infeasible. So - yes, we need addresses that can be easily allocated for local use (and perhaps for other purposes also), but they should not carry with them any assumptions about the degree of locality or proximity, trustworthiness, filtering, or policy. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 15:06:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05217 for ; Wed, 12 Nov 2003 15:06:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Fw-0005S1-Tt for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:06:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACK6Olh020947 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Fw-0005Rl-Ou for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:06:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05096 for ; Wed, 12 Nov 2003 15:06:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Ft-0004wk-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:06:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1Fh-0004wW-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Fa-0005DQ-LW; Wed, 12 Nov 2003 15:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1F1-00055I-Qg for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:05:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04965 for ; Wed, 12 Nov 2003 15:05:13 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Ex-0004vS-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:05:24 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Ex-0004vH-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:05:23 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACK5GA08900 for ; Wed, 12 Nov 2003 22:05:17 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 22:05:15 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 22:05:15 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 22:05:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on draft-hain-templin-ipv6-localcomm-03.txt Date: Wed, 12 Nov 2003 22:05:14 +0200 Message-ID: Thread-Topic: comments on draft-hain-templin-ipv6-localcomm-03.txt Thread-Index: AcOpV8pCndWWsP4RTHCQOvOUh0NrigAADyYA To: , X-OriginalArrivalTime: 12 Nov 2003 20:05:15.0051 (UTC) FILETIME=[496B97B0:01C3A958] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Keith, > So - yes, we need addresses that can be easily allocated for local use = > (and perhaps for other purposes also), but they should not carry with=20 > them any assumptions about the degree of locality or proximity,=20 > trustworthiness, filtering, or policy. I agree. I think that in documenting addresses allocated for local use, we should not imply that these addresses have any particular properties, except that they are intended for local use. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 15:18:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06844 for ; Wed, 12 Nov 2003 15:18:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Qy-00076k-7e for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:17:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKHmDQ027316 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Qx-00076V-VX for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:17:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06752 for ; Wed, 12 Nov 2003 15:17:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Qw-0005FZ-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:17:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1Qw-0005FW-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:17:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1OJ-0006eB-Qf; Wed, 12 Nov 2003 15:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1O0-0006dS-0z for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:14:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06370 for ; Wed, 12 Nov 2003 15:14:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Ny-00059G-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:14:42 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Nw-00058T-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:14:40 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hACKE7O19613; Wed, 12 Nov 2003 22:14:07 +0200 Date: Wed, 12 Nov 2003 22:14:07 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 12 Nov 2003, Christian Huitema wrote: > The section "5.4.5 When Duplicate Address Detection Fails" currently > says: > > A tentative address that is determined to be a duplicate as described > above, MUST NOT be assigned to an interface and the node SHOULD log a > system management error. If the address is a link-local address > formed from an interface identifier, the interface SHOULD be > disabled. > > The part about disabling the interface enables a DOS attack: wait for a > target to come on line and send a DAD packet, reply with a deliberate > collision, and poof the target is disconnected from the network. Unless you haven't noted from SEND work, if you have access to the local link, you can do pretty much everything anyway, so this is really not big news. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 15:20:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07099 for ; Wed, 12 Nov 2003 15:20:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Sy-0007Xj-Bh for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:19:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKJqEr028989 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:19:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Sy-0007XU-5a for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:19:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07033 for ; Wed, 12 Nov 2003 15:19:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Sv-0005I0-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:19:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1Sv-0005Hx-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:19:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1S9-0007DS-Bz; Wed, 12 Nov 2003 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Ri-0007Cr-CX for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:18:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06902 for ; Wed, 12 Nov 2003 15:18:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Rg-0005GU-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:18:32 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Rf-0005G8-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:18:32 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hACKHvUP027990 for ; Wed, 12 Nov 2003 12:17:57 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hACKHfQ18683; Wed, 12 Nov 2003 21:17:53 +0100 (MET) Date: Wed, 12 Nov 2003 21:16:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Sending text To: ipv6@ietf.org Cc: erik.nordmark@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , It was suggested I send text on my suggestion for clarification in draft-ietf-ipv6-deprecate-site-local-01.txt. After the second paragraph in section 4 I suggest adding something about the intent: The intent is that any existing code in implementations that assign any special meaning to the site-local prefix will be removed and also to ensure that new implementations do not include such code. While removing such code from existing implementations is important it is not critically urgent. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 15:29:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07525 for ; Wed, 12 Nov 2003 15:29:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1bf-0000OD-Jm for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKSpDQ001491 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:28:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1bf-0000Ny-11 for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07448 for ; Wed, 12 Nov 2003 15:28:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1bd-0005R7-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:28:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1bd-0005Qx-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:28:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1at-0008WL-2P; Wed, 12 Nov 2003 15:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1aH-0008UI-F9 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:27:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07385 for ; Wed, 12 Nov 2003 15:27:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1aF-0005PE-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:27:23 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AK1aD-0005O5-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:27:22 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 7C40A9B; Thu, 13 Nov 2003 05:26:52 +0900 (JST) To: pekkas@netcore.fi Cc: huitema@windows.microsoft.com, ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt In-Reply-To: Your message of "Wed, 12 Nov 2003 22:14:07 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031112202652.7C40A9B@coconut.itojun.org> Date: Thu, 13 Nov 2003 05:26:52 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > On Wed, 12 Nov 2003, Christian Huitema wrote: > > The section "5.4.5 When Duplicate Address Detection Fails" currently > > says: > > > > A tentative address that is determined to be a duplicate as described > > above, MUST NOT be assigned to an interface and the node SHOULD log a > > system management error. If the address is a link-local address > > formed from an interface identifier, the interface SHOULD be > > disabled. > > > > The part about disabling the interface enables a DOS attack: wait for a > > target to come on line and send a DAD packet, reply with a deliberate > > collision, and poof the target is disconnected from the network. > > Unless you haven't noted from SEND work, if you have access to the local > link, you can do pretty much everything anyway, so this is really not big > news. agree completely. if you allow enemy to be on-link you are dead. my suggestion is to leave it SHOULD. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 15:48:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08577 for ; Wed, 12 Nov 2003 15:48:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1uP-0002eG-MV for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:48:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKmDDv010174 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:48:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1uP-0002e1-Gc for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:48:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08540 for ; Wed, 12 Nov 2003 15:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1uN-0005t2-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:48:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1uN-0005sz-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:48:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1uD-0002aD-PJ; Wed, 12 Nov 2003 15:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1tj-0002ZP-1g for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:47:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08500 for ; Wed, 12 Nov 2003 15:47:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1th-0005sG-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:47:29 -0500 Received: from dyn128-167.ietf58.ietf.org ([130.129.128.167] helo=starfruit.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1tg-0005s5-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:47:29 -0500 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id DF861199D0; Thu, 13 Nov 2003 05:47:05 +0900 (JST) To: Vijay Devarapalli Cc: pekkas@netcore.fi, huitema@windows.microsoft.com, ipv6@ietf.org In-reply-to: vijayd's message of Wed, 12 Nov 2003 12:40:50 PST. <3FB29AD2.6040702@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Cc: itojun@iijlab.net From: Jun-ichiro itojun Hagino Date: Thu, 13 Nov 2003 05:47:05 +0900 Message-Id: <20031112204705.DF861199D0@starfruit.itojun.org> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >> my suggestion is to leave it SHOULD. >you didnt justify why. makes no sense on an unprotected network. i did. you did not quote my previous line. >> agree completely. if you allow enemy to be on-link you are dead. >> my suggestion is to leave it SHOULD. this is just like physical security; if you allow people to enter computer room, security mechanisms are pertty moot as bad guys can use sledge hammer to break the computer. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 16:31:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10739 for ; Wed, 12 Nov 2003 16:31:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Za-0008Bu-AS for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:30:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLUkuL031480 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:30:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2ZZ-0008Ba-7Y for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:30:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10590 for ; Wed, 12 Nov 2003 16:30:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2ZX-0006hi-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:30:43 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK2Lt-0006W8-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:16:37 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK25F-0003TV-QR for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:59:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK23u-0004JV-VE; Wed, 12 Nov 2003 15:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK23l-0004J3-QD for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09206 for ; Wed, 12 Nov 2003 15:57:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK23k-00067B-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:57:52 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AK23j-00066D-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:57:51 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 12 Nov 2003 12:57:11 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 Nov 2003 12:57:16 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Nov 2003 12:57:18 -0800 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.6713); Wed, 12 Nov 2003 12:57:18 -0800 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.1069); Wed, 12 Nov 2003 12:57:36 -0800 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.3790.1069); Wed, 12 Nov 2003 12:57:15 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Date: Wed, 12 Nov 2003 12:57:20 -0800 Message-ID: Thread-Topic: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Thread-Index: AcOpXjUrmt7Vymn2StSJTJyf+LTTggAALmrA From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" , "Vijay Devarapalli" Cc: , X-OriginalArrivalTime: 12 Nov 2003 20:57:15.0937 (UTC) FILETIME=[8D9D0110:01C3A95F] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >> my suggestion is to leave it SHOULD. > >you didnt justify why. makes no sense on an unprotected network. >=20 > i did. you did not quote my previous line. >=20 > >> agree completely. if you allow enemy to be on-link you are dead. > >> my suggestion is to leave it SHOULD. >=20 > this is just like physical security; if you allow people to enter > computer room, security mechanisms are pertty moot as bad guys can > use > sledge hammer to break the computer. Well, there are many networks that are open to the general public, for example wifi networks at airports.=20 It is true that a bad guy on-link can do a lot of harm, some of which can be alleviated by SEND. However, most of other attacks require a constant stream of packets, and increase the risk that the attack will be detected and traced. The recommendation to turn off the interface amplifies the powers of this bad guy: they can kick someone off the network with a single packet. In short, just because someone broke in, there is no reason to hand her a sledge hammer. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 16:31:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10756 for ; Wed, 12 Nov 2003 16:31:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Zc-0008CS-M4 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:30:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLUmvN031510 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Za-0008Bz-LD for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:30:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10600 for ; Wed, 12 Nov 2003 16:30:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2ZY-0006hx-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:30:44 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK2Lo-0006W8-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:16:32 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK27C-0003YX-PW for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:01:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK26n-0004jV-Jk; Wed, 12 Nov 2003 16:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK26J-0004iF-VP for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 16:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09402 for ; Wed, 12 Nov 2003 16:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK26I-0006Bw-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:00:30 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AK26G-0006Bc-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:00:29 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hACKxjx19276; Wed, 12 Nov 2003 12:59:45 -0800 X-mProtect: <200311122059> Nokia Silicon Valley Messaging Protection Received: from danira-pool05159.americas.nokia.com (10.241.51.59, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdG3wQWq; Wed, 12 Nov 2003 12:59:44 PST Message-ID: <3FB29F35.30308@iprg.nokia.com> Date: Wed, 12 Nov 2003 12:59:33 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: pekkas@netcore.fi, huitema@windows.microsoft.com, ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt References: <20031112204705.DF861199D0@starfruit.itojun.org> In-Reply-To: <20031112204705.DF861199D0@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: >>> my suggestion is to leave it SHOULD. >> >>you didnt justify why. makes no sense on an unprotected network. > > > i did. you did not quote my previous line. > > >>> agree completely. if you allow enemy to be on-link you are dead. >>> my suggestion is to leave it SHOULD. > > > this is just like physical security; if you allow people to enter > computer room, security mechanisms are pertty moot as bad guys can use > sledge hammer to break the computer. it still does not make sense. even the IETF WLAN network is unprotected. somebody could easily screw up your network interface by replying to your DAD NS solicitation. you are just making it simple for somebody to disable your interface by leaving it as SHOULD. Vijay -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 16:31:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10842 for ; Wed, 12 Nov 2003 16:31:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Zr-0008G0-Ml for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLV39g031730 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Zr-0008Fh-Gh for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10699 for ; Wed, 12 Nov 2003 16:30:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Zd-0006jT-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:30:49 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK2LZ-0006W8-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:16:17 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK2BC-0003d1-QF for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:05:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Af-0005Xx-Pn; Wed, 12 Nov 2003 16:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK29s-0005Rd-0L for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 16:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09553 for ; Wed, 12 Nov 2003 16:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK29q-0006Hh-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:04:10 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AK29o-0006HJ-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:04:09 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hACL3Rk23112; Wed, 12 Nov 2003 13:03:27 -0800 X-mProtect: <200311122103> Nokia Silicon Valley Messaging Protection Received: from danira-pool05159.americas.nokia.com (10.241.51.59, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd81SrpG; Wed, 12 Nov 2003 13:03:25 PST Message-ID: <3FB2A012.9080705@iprg.nokia.com> Date: Wed, 12 Nov 2003 13:03:14 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: pekkas@netcore.fi, huitema@windows.microsoft.com, ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt References: <20031112204705.DF861199D0@starfruit.itojun.org> In-Reply-To: <20031112204705.DF861199D0@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: >>> my suggestion is to leave it SHOULD. >> >>you didnt justify why. makes no sense on an unprotected network. > > > i did. you did not quote my previous line. > > >>> agree completely. if you allow enemy to be on-link you are dead. >>> my suggestion is to leave it SHOULD. > > > this is just like physical security; if you allow people to enter > computer room, security mechanisms are pertty moot as bad guys can use > sledge hammer to break the computer. it still does not make sense. even the IETF WLAN network is unprotected. somebody could easily screw up your network interface by replying to your DAD NS solicitation. you are just making it simple for somebody to disable your interface by leaving it as SHOULD. Vijay -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 16:34:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11111 for ; Wed, 12 Nov 2003 16:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2cq-0000Cg-Az for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:34:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLY82Y000776 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2cq-0000CR-6P for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:34:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11052 for ; Wed, 12 Nov 2003 16:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2co-0006r6-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:34:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK2cn-0006r3-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:34:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2ap-0008IU-IS; Wed, 12 Nov 2003 16:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2a0-0008Gs-JF for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 16:31:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10724 for ; Wed, 12 Nov 2003 16:30:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Zy-0006mh-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:31:10 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AK2Zx-0006me-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:31:09 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 2351989; Thu, 13 Nov 2003 06:31:06 +0900 (JST) To: huitema@windows.microsoft.com Cc: ipv6@ietf.org Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt In-Reply-To: Your message of "Wed, 12 Nov 2003 12:57:20 -0800" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031112213106.2351989@coconut.itojun.org> Date: Thu, 13 Nov 2003 06:31:06 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Well, there are many networks that are open to the general public, for > example wifi networks at airports. > > It is true that a bad guy on-link can do a lot of harm, some of which > can be alleviated by SEND. However, most of other attacks require a > constant stream of packets, and increase the risk that the attack will > be detected and traced. The recommendation to turn off the interface > amplifies the powers of this bad guy: they can kick someone off the > network with a single packet. In short, just because someone broke in, > there is no reason to hand her a sledge hammer. but then, if we change it to MAY, what is the point in running DAD process? if you do not disable interface (or the address on the interface) the owner of the same address will get confused, peers of the address get confused, you will do bad things to the original owner of the address. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 16:35:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11251 for ; Wed, 12 Nov 2003 16:35:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2e9-0000Wl-Po for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:35:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLZTjs002021 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 16:35:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2e9-0000WW-KI for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:35:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11182 for ; Wed, 12 Nov 2003 16:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2e7-0006sq-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:35:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK2e7-0006sn-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 16:35:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2di-0000E1-G5; Wed, 12 Nov 2003 16:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2cw-0000D1-W7 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 16:34:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11063 for ; Wed, 12 Nov 2003 16:34:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2cu-0006rL-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:34:12 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AK2cu-0006qf-00 for ipv6@ietf.org; Wed, 12 Nov 2003 16:34:12 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 12 Nov 2003 13:33:39 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Nov 2003 13:33:41 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 Nov 2003 13:32:48 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 13:33:44 -0800 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.3790.1069); Wed, 12 Nov 2003 13:33:39 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Date: Wed, 12 Nov 2003 13:33:44 -0800 Message-ID: Thread-Topic: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Thread-Index: AcOpZFPQ6WW4hw9CSKGXLD14cSyYOwAADRqw From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 12 Nov 2003 21:33:39.0261 (UTC) FILETIME=[A2F9CED0:01C3A964] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > It is true that a bad guy on-link can do a lot of harm, some of which > > can be alleviated by SEND. However, most of other attacks require a > > constant stream of packets, and increase the risk that the attack will > > be detected and traced. The recommendation to turn off the interface > > amplifies the powers of this bad guy: they can kick someone off the > > network with a single packet. In short, just because someone broke in, > > there is no reason to hand her a sledge hammer. >=20 > but then, if we change it to MAY, what is the point in running DAD > process? if you do not disable interface (or the address on the > interface) the owner of the same address will get confused, > peers of the address get confused, you will do bad things to the > original owner of the address. Disabling the address is OK, as you can always configure a new one. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 17:46:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14019 for ; Wed, 12 Nov 2003 17:46:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3kC-00069K-Cy for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 17:45:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACMjmxv023631 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 17:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3kB-000694-RU for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 17:45:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13926 for ; Wed, 12 Nov 2003 17:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3k9-0000CR-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 17:45:45 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK3j0-00009c-01 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 17:44:35 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK3Ue-0006eF-VK for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 17:29:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3Ty-0004Pa-SU; Wed, 12 Nov 2003 17:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3TN-0004NO-Ve for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 17:28:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13392 for ; Wed, 12 Nov 2003 17:28:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3TL-0007mo-00 for ipv6@ietf.org; Wed, 12 Nov 2003 17:28:23 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AK3T6-0007jP-00 for ipv6@ietf.org; Wed, 12 Nov 2003 17:28:08 -0500 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 hACMR2V02839; Wed, 12 Nov 2003 14:27:02 -0800 Received: from innovationslab.net (dyn134-131.ietf58.ietf.org [130.129.134.131]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hACMUotX015889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 12 Nov 2003 14:31:00 -0800 Message-ID: <3FB2B369.8000003@innovationslab.net> Date: Wed, 12 Nov 2003 17:25:45 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: huitema@windows.microsoft.com, ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt References: <20031112213106.2351989@coconut.itojun.org> In-Reply-To: <20031112213106.2351989@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: >>Well, there are many networks that are open to the general public, for >>example wifi networks at airports. >> >>It is true that a bad guy on-link can do a lot of harm, some of which >>can be alleviated by SEND. However, most of other attacks require a >>constant stream of packets, and increase the risk that the attack will >>be detected and traced. The recommendation to turn off the interface >>amplifies the powers of this bad guy: they can kick someone off the >>network with a single packet. In short, just because someone broke in, >>there is no reason to hand her a sledge hammer. > > > but then, if we change it to MAY, what is the point in running DAD > process? if you do not disable interface (or the address on the > interface) the owner of the same address will get confused, > peers of the address get confused, you will do bad things to the > original owner of the address. > I see disabling the interface and disabling the address on the interface as two separate actions. So, I agree that the interface MAY be disabled. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 18:00:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14584 for ; Wed, 12 Nov 2003 18:00:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3yO-0007Dn-J2 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:00:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACN0SuJ027758 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3yO-0007Dd-E8 for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 18:00:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14523 for ; Wed, 12 Nov 2003 18:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3yL-0000Qx-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:00:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK3yL-0000Qu-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:00:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3y3-00076J-1j; Wed, 12 Nov 2003 18:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3xn-000759-J4 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 17:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14493 for ; Wed, 12 Nov 2003 17:59:37 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3xk-0000Qh-00 for ipv6@ietf.org; Wed, 12 Nov 2003 17:59:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK3xj-0000Qe-00 for ipv6@ietf.org; Wed, 12 Nov 2003 17:59:48 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACMxlA28108 for ; Thu, 13 Nov 2003 00:59:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 00:59:46 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 00:59:46 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 00:59:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Date: Thu, 13 Nov 2003 00:59:45 +0200 Message-ID: Thread-Topic: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Thread-Index: AcOpbKIzxPxc6YKSSDqnArivQh76bgAA+HVg To: , Cc: , X-OriginalArrivalTime: 12 Nov 2003 22:59:46.0296 (UTC) FILETIME=[AAC4C780:01C3A970] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, > > but then, if we change it to MAY, what is the point in running DAD > > process? if you do not disable interface (or the address on the > > interface) the owner of the same address will get confused, > > peers of the address get confused, you will do bad things to the > > original owner of the address. =20 > > >=20 > I see disabling the interface and disabling the address on the = interface > as two separate actions. >=20 > So, I agree that the interface MAY be disabled. Agreed. It is Duplicate ADDRESS Detection, so disabling the address is = reasonable, disabling the interface is probably too strong. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 18:37:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17370 for ; Wed, 12 Nov 2003 18:37:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4YG-0001pL-5C for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:37:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACNbWcm007017 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:37:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4YF-0001oy-Mb for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 18:37:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17323 for ; Wed, 12 Nov 2003 18:37:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4YC-000145-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:37:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK4YC-000142-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4Xl-0001Z1-BA; Wed, 12 Nov 2003 18:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4Ws-0001Xj-0L for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 18:36:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17243 for ; Wed, 12 Nov 2003 18:35:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4Wo-000124-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:36:02 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AK4Wo-000121-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:36:02 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A6396AFD2F; Wed, 12 Nov 2003 18:36:02 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10788-03; Wed, 12 Nov 2003 18:36:01 -0500 (EST) Received: from cs.utk.edu (dyn129-239.ietf58.ietf.org [130.129.129.239]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5C98CAFD3A; Wed, 12 Nov 2003 18:36:01 -0500 (EST) Date: Wed, 12 Nov 2003 18:36:42 -0500 Subject: Re: comments on draft-hain-templin-ipv6-localcomm-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Keith Moore , To: From: Keith Moore In-Reply-To: Message-Id: <11CB6950-1569-11D8-B1EB-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, November 12, 2003, at 03:05 PM, wrote: > Keith, > >> So - yes, we need addresses that can be easily allocated for local use >> (and perhaps for other purposes also), but they should not carry with >> them any assumptions about the degree of locality or proximity, >> trustworthiness, filtering, or policy. > > I agree. I think that in documenting addresses allocated for local > use, we should not imply that these addresses have any particular > properties, except that they are intended for local use. even the word "local" might be too much. it is not out of the question for networks from all over the world to agree to exchange traffic using GUPIs and/or PUPIs. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 18:42:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17553 for ; Wed, 12 Nov 2003 18:42:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4cY-0002O5-Nd for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:41:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACNfwXP009177 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4cY-0002Nw-6V for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 18:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17504 for ; Wed, 12 Nov 2003 18:41:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4cU-00017Z-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:41:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK4cT-00017W-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:41:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4bh-0002EY-2P; Wed, 12 Nov 2003 18:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4ar-0002Cs-MK for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 18:40:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17447 for ; Wed, 12 Nov 2003 18:39:48 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4ae-00016d-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:40:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AK4ad-00016a-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:39:59 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACNdx621070 for ; Thu, 13 Nov 2003 01:39:59 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 01:39:59 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Nov 2003 01:39:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on draft-hain-templin-ipv6-localcomm-03.txt Date: Thu, 13 Nov 2003 01:39:58 +0200 Message-ID: Thread-Topic: comments on draft-hain-templin-ipv6-localcomm-03.txt Thread-Index: AcOpdb6WW3x2mhMkSES1G8DqMlLJOwAAChUQ To: Cc: X-OriginalArrivalTime: 12 Nov 2003 23:39:59.0253 (UTC) FILETIME=[4900CC50:01C3A976] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Keith, > >> So - yes, we need addresses that can be easily allocated=20 > for local use > >> (and perhaps for other purposes also), but they should not=20 > carry with > >> them any assumptions about the degree of locality or proximity, > >> trustworthiness, filtering, or policy. > > > > I agree. I think that in documenting addresses allocated for local > > use, we should not imply that these addresses have any particular > > properties, except that they are intended for local use. >=20 > even the word "local" might be too much. it is not out of the = question=20 > for networks from all over the world to agree to exchange traffic = using=20 > GUPIs and/or PUPIs. Local might still be OK, if you think that the addresses have 'local' = relevance not global relevance. One possible meaning of local is:=20 Not broad or general; not widespread: such as 'local outbreaks of flu.' In that sense, I am happy with the term local, at least until someone = proposes something better. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 18:47:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17824 for ; Wed, 12 Nov 2003 18:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4hc-00030z-32 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:47:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACNlCTO011583 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:47:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4ha-00030i-Sg for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 18:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17779 for ; Wed, 12 Nov 2003 18:46:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4hW-0001Eo-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:47:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK4hV-0001El-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4hR-0002rX-VT; Wed, 12 Nov 2003 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4gx-0002qp-A6 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 18:46:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17725 for ; Wed, 12 Nov 2003 18:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4gu-0001EO-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:46:28 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AK4gt-0001EL-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:46:27 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 82B98AFD41; Wed, 12 Nov 2003 18:46:28 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11930-07; Wed, 12 Nov 2003 18:46:27 -0500 (EST) Received: from cs.utk.edu (dyn129-239.ietf58.ietf.org [130.129.129.239]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7CB32AFD13; Wed, 12 Nov 2003 18:46:27 -0500 (EST) Date: Wed, 12 Nov 2003 18:47:08 -0500 Subject: Re: comments on draft-hain-templin-ipv6-localcomm-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Keith Moore , To: From: Keith Moore In-Reply-To: Message-Id: <87195458-156A-11D8-B1EB-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> even the word "local" might be too much. it is not out of the >> question >> for networks from all over the world to agree to exchange traffic >> using >> GUPIs and/or PUPIs. > > Local might still be OK, if you think that the addresses have 'local' > relevance > not global relevance. One possible meaning of local is: > > Not broad or general; not widespread: such as 'local outbreaks of > flu.' > > In that sense, I am happy with the term local, at least until someone > proposes > something better. it would really seem odd to me to use a "local address" to talk to a host that is halfway across the world. that, and I'm concerned that people will think that "local" means, or is intended for, only the portion of the network that uses that same prefix - and/or that it's reasonable to expect traffic to be filtered at the edges of that portion of the network. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 22:25:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24757 for ; Wed, 12 Nov 2003 22:25:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK86q-0006f7-Nc for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 22:25:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD3PSBT025603 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 22:25:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK86q-0006es-J7 for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 22:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24704 for ; Wed, 12 Nov 2003 22:25:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK86n-0004KQ-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 22:25:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK86n-0004KN-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 22:25:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK86R-0006Z0-Ot; Wed, 12 Nov 2003 22:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK868-0006YY-4N for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 22:24:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24687 for ; Wed, 12 Nov 2003 22:24:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK864-0004JZ-00 for ipv6@ietf.org; Wed, 12 Nov 2003 22:24:40 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AK863-0004JW-00 for ipv6@ietf.org; Wed, 12 Nov 2003 22:24:40 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hAD3NcYT012982 for ; Wed, 12 Nov 2003 20:23:38 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hAD3NCrr022231 for ; Wed, 12 Nov 2003 21:23:14 -0600 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.10/8.12.10) with ESMTP id hAD3OZoF025225 for ; Thu, 13 Nov 2003 14:24:35 +1100 (EST) Message-ID: <3FB2F973.3FD8DB57@motorola.com> Date: Thu, 13 Nov 2003 14:24:35 +1100 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: ipv6@ietf.org Subject: Re: comments on draft-hain-templin-ipv6-localcomm-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think we're missing the point. There is a perceived need by "many" operators for an address space that can be used for 'local' use, where 'local' is 'not part of the global internet'. We can argue until the cows come home whether any given possible use for such a space is good or bad, but the fact remains that there is demand for such a space and that it is thus better to allow for it's allocation in a managed manner rather than have it snatched from whatever ad-hoc place the network manager decides. Fundamentally, there are 2 requirements: - Free (both financially and administratively) - Approximately unique Operationally, we impose an additional requirement: - Using such space should not add to the size of the global routing tables. An unadministered PI scheme that generated unique prefixes would satisfy the first 2 requirements. However, allowing such addresses to be globally routeable has two drawbacks: - affects global routing tables, possibly badly - raises 'approximately unique' requirement to 'unique' Introducing compulsory filtering outside whatever administrative boundaries these addresses have removes these two drawbacks. These addresses become unusable for global communication, but then they are not intended for global communication. Assuming the 'unique enough' mechanism is unique enough, the only difference between a 'local' address and a 'global' address which is administratively filtered is that EVERYBODY is filtering the local address, so if it slips past one filter someone else will probably throw it away. This is NOT a security argument. Local addresses are neither more nor less secure than any other filtered address. Rather, local addresses are intended to provide an easily accessible PI space for people wanting easily accessible PI space, without risking address space conflicts with global addresses. So what changes are needed: - To applications? None. A local address may be treated as a global address, and will function identically to any filtered global address. The only difference is that the local address prefix provides a strong hint that the address WILL be filtered, thus increasing the ability of an application to make address selection choices if it so wishes. - To routers and infrastructure? Many of these devices SHOULD have filters configured to discard local addresses. Those that do not may suffer some increased traffic. Nothing breaks that wont break already. The cost to those that don't want to use these addresses is minimal. And some people gain functionality they particularly want. Where is the problem? I'll offer one comment on the Hinden/Haberman draft. Although I'm generally in favour of it, the draft completely partitions the space into that which is registered and that which is allocated using the provided random algorithm. No space is left for alternative mechanisms, such as MAC based allocation presented in draft-white-auto-subnet-alloc or draft-hinden-ipv6-global-site-local. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 22:37:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25100 for ; Wed, 12 Nov 2003 22:37:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8I8-0007hL-KV for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 22:37:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD3b8XG029579 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 22:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8I7-0007gv-Tv for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 22:37:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25076 for ; Wed, 12 Nov 2003 22:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8I4-0004X0-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 22:37:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK8I4-0004Wx-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 22:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8I2-0007cC-08; Wed, 12 Nov 2003 22:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8HG-0007Xb-Tm for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 22:36:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25059 for ; Wed, 12 Nov 2003 22:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8HD-0004Vx-00 for ipv6@ietf.org; Wed, 12 Nov 2003 22:36:11 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1AK8HC-0004Vg-00 for ipv6@ietf.org; Wed, 12 Nov 2003 22:36:10 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAD3ZfIw386752; Wed, 12 Nov 2003 22:35:41 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-252-13.mts.ibm.com [9.65.252.13]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAD3ZdbQ167012; Wed, 12 Nov 2003 20:35:40 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id hAD3WZ302653; Wed, 12 Nov 2003 21:32:36 -0600 Message-Id: <200311130332.hAD3WZ302653@cichlid.raleigh.ibm.com> To: "Christian Huitema" cc: ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt In-Reply-To: Message from huitema@windows.microsoft.com of "Wed, 12 Nov 2003 12:00:45 PST." Date: Wed, 12 Nov 2003 21:32:35 -0600 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Proposed resolution: write "MAY be disabled" instead. Um, I'd suggest that this by itself isn't really all that helpful. It might help to add some more explanatary text together with recommendations on what to do. E.g., - should an implementation just configure the address and use it anyway? (I doubt this, as this implies we should just punt on DAD) - Assume there is a DOS attack, wait a while, and try again? (hoping the bad guy goes away in the meantime) - generate a new IID and try again? And if so, are there recommendations on what kind of ID? And if there is a DOS attack in progress, why would trying *any* address result in success? - Try generating a new address, but use exponential backoff in delaying after each failed attempt? - something else? (or some combination of the above?) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 22:46:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25474 for ; Wed, 12 Nov 2003 22:46:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8R8-0000J1-Bk for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 22:46:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD3kQXr001169 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 22:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8R7-0000Im-Kq for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 22:46:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25423 for ; Wed, 12 Nov 2003 22:46:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8R4-0004gN-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 22:46:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK8R3-0004dJ-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 22:46:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8Pl-0008Q3-OB; Wed, 12 Nov 2003 22:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8P5-0008PZ-Vt for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 22:44:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25351 for ; Wed, 12 Nov 2003 22:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8P1-0004ci-00 for ipv6@ietf.org; Wed, 12 Nov 2003 22:44:15 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1AK8P0-0004cQ-00 for ipv6@ietf.org; Wed, 12 Nov 2003 22:44:14 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAD3hhkF337524; Wed, 12 Nov 2003 22:43:43 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-218-66.mts.ibm.com [9.65.218.66]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAD3hgbQ148414; Wed, 12 Nov 2003 20:43:42 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id hAD3ecg02727; Wed, 12 Nov 2003 21:40:39 -0600 Message-Id: <200311130340.hAD3ecg02727@cichlid.raleigh.ibm.com> To: "Christian Huitema" , ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt In-Reply-To: Message from narten of "Wed, 12 Nov 2003 21:32:35 CST." Date: Wed, 12 Nov 2003 21:39:58 -0600 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , One more point: One of the original motivations for disabling an interface if DAD fails for the LL address is that if you are running DAD on a LL address generated using the EUI-64 format, in the absence of a DOS attack, if DAD fails, that really means duplicate ethernet addresses are in use. In this case, the device is hosed and configuring another address won't result in a usable network. In fact, it probably makes things worse by creating problems that harder to diagnose than just shutting down the interface. The user will see a partially working network where some things work, and other things won't. BTW, some of the above text might be worth putting into 2462bis as background information. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 23:02:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26078 for ; Wed, 12 Nov 2003 23:02:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8ge-0001IS-J1 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 23:02:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD42S1G004980 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 23:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8ge-0001IF-DF for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 23:02:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26049 for ; Wed, 12 Nov 2003 23:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8gZ-0004wa-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 23:02:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK8gZ-0004wX-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 23:02:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8gH-0001CW-4H; Wed, 12 Nov 2003 23:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8fr-0001AO-1z for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 23:01:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26003 for ; Wed, 12 Nov 2003 23:01:25 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8fn-0004vJ-00 for ipv6@ietf.org; Wed, 12 Nov 2003 23:01:35 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK8fm-0004vG-00 for ipv6@ietf.org; Wed, 12 Nov 2003 23:01:34 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAD41XA28777 for ; Thu, 13 Nov 2003 06:01:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 06:01:31 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 06:01:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Date: Thu, 13 Nov 2003 06:01:30 +0200 Message-ID: Thread-Topic: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Thread-Index: AcOpmKMAsRWsy1sGQci1kjPyCBbX7AAADFmg To: , , X-OriginalArrivalTime: 13 Nov 2003 04:01:30.0886 (UTC) FILETIME=[D1F1FA60:01C3A99A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thomas, > One of the original motivations for disabling an interface if DAD > fails for the LL address is that if you are running DAD on a LL > address generated using the EUI-64 format, in the absence of a DOS > attack, if DAD fails, that really means duplicate ethernet addresses > are in use. In this case, the device is hosed and configuring another > address won't result in a usable network. In fact, it probably makes > things worse by creating problems that harder to diagnose than just > shutting down the interface. The user will see a partially working > network where some things work, and other things won't. >=20 > BTW, some of the above text might be worth putting into 2462bis as > background information. Understood about the original intention, but this may not be the case. 2462 currently says: Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [ADDR-ARCH]. This may not always be the case. See 3GPP, for example. Also, I remember that the MIP folks wanted to be able to use a random number in place of the EUI-64 in case the DAD failed. =20 My question, is the original quote above still a valid assumption? If so, what does 'typically' mean? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 23:16:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26513 for ; Wed, 12 Nov 2003 23:16:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8uA-0002c6-1r for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 23:16:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD4GPVa010040 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 23:16:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8u9-0002br-Fd for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 23:16:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26463 for ; Wed, 12 Nov 2003 23:16:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8u7-00058G-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 23:16:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK8u7-00058D-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 23:16:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8tn-0002Ni-Qx; Wed, 12 Nov 2003 23:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8st-0002Gs-SM for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 23:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26432 for ; Wed, 12 Nov 2003 23:14:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8sr-00054r-00 for ipv6@ietf.org; Wed, 12 Nov 2003 23:15:05 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AK8sq-00054K-00 for ipv6@ietf.org; Wed, 12 Nov 2003 23:15:04 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 20:14:28 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 12 Nov 2003 20:13:47 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Nov 2003 20:14:34 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 Nov 2003 20:13:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 20:14:26 -0800 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.3790.1069); Wed, 12 Nov 2003 20:14:27 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Date: Wed, 12 Nov 2003 20:14:36 -0800 Message-ID: Thread-Topic: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Thread-Index: AcOpl1dHaH9hW22OSeS87PBBH+HYIAABF+0w From: "Christian Huitema" To: "Thomas Narten" Cc: X-OriginalArrivalTime: 13 Nov 2003 04:14:27.0192 (UTC) FILETIME=[A0A8DF80:01C3A99C] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Proposed resolution: write "MAY be disabled" instead. >=20 > Um, I'd suggest that this by itself isn't really all that helpful. It > might help to add some more explanatary text together with > recommendations on what to do. E.g., >=20 > - should an implementation just configure the address and use it > anyway? (I doubt this, as this implies we should just punt on DAD) No, we clarified later that the implementation should disable the address. =20 > - Assume there is a DOS attack, wait a while, and try again? (hoping > the bad guy goes away in the meantime) I would not specify that.. > - generate a new IID and try again? And if so, are there > recommendations on what kind of ID? And if there is a DOS attack > in progress, why would trying *any* address result in success? Yes. The implementation may very well have access to several EUI-64, and may try an alternative. Or, it may try to use a random address. The persistence of DAD collision would indicate with quasi certainty a DOS attack. Forcing the attacker to repeat the attack increases the chances of detection. > - Try generating a new address, but use exponential backoff in > delaying after each failed attempt? That is a variation of the above. It may be useful in some cases, e.g. when turning of the interface briefly saves energy. > - something else? (or some combination of the above?) Maybe. There is no limit to creativity. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 06:06:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20563 for ; Thu, 13 Nov 2003 06:06:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFJA-00026s-Qd for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 06:06:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADB6eqv008106 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 06:06:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFJA-00026f-JX for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 06:06:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20514 for ; Thu, 13 Nov 2003 06:06:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKFJ6-0002nx-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 06:06:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKFJ6-0002n5-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 06:06:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFHa-0001mO-JC; Thu, 13 Nov 2003 06:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFGe-0001lY-Qt for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 06:04:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20463 for ; Thu, 13 Nov 2003 06:03:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKFGa-0002la-00 for ipv6@ietf.org; Thu, 13 Nov 2003 06:04:00 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AKFGa-0002lS-00 for ipv6@ietf.org; Thu, 13 Nov 2003 06:04:00 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 501E989; Thu, 13 Nov 2003 20:03:59 +0900 (JST) To: john.loughney@nokia.com Cc: ipv6@ietf.org Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt In-Reply-To: Your message of "Thu, 13 Nov 2003 00:59:45 +0200" References: X-Mailer: Cue version 0.6 (031029-1524/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031113110359.501E989@coconut.itojun.org> Date: Thu, 13 Nov 2003 20:03:59 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > > but then, if we change it to MAY, what is the point in running DAD > > > process? if you do not disable interface (or the address on the > > > interface) the owner of the same address will get confused, > > > peers of the address get confused, you will do bad things to the > > > original owner of the address. > > > > > > > I see disabling the interface and disabling the address on the interface > > as two separate actions. > > > > So, I agree that the interface MAY be disabled. > > Agreed. It is Duplicate ADDRESS Detection, so disabling the address is reasonable, > disabling the interface is probably too strong. re-read the exact text, and i think the above makes sense. so proposed change: the last part should be changed to "the interface address SHOULD be disabled". (add "address") itojun 5.4.5. When Duplicate Address Detection Fails A tentative address that is determined to be a duplicate as described above, MUST NOT be assigned to an interface and the node SHOULD log a system management error. If the address is a link-local address formed from an interface identifier, the interface SHOULD be disabled. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 06:32:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21140 for ; Thu, 13 Nov 2003 06:32:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFha-0003aH-RQ for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 06:31:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADBVs58013778 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 06:31:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFha-0003a9-HE for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 06:31:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21100 for ; Thu, 13 Nov 2003 06:31:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKFhW-00037S-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 06:31:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKFhW-00037P-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 06:31:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFgj-0003HM-UH; Thu, 13 Nov 2003 06:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKFg4-00039U-1y for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 06:30:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21034 for ; Thu, 13 Nov 2003 06:30:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKFfz-00034B-00 for ipv6@ietf.org; Thu, 13 Nov 2003 06:30:15 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1AKFfz-000347-00 for ipv6@ietf.org; Thu, 13 Nov 2003 06:30:15 -0500 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id E31DC403DD8; Thu, 13 Nov 2003 06:30:15 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id A6D8C80322; Thu, 13 Nov 2003 06:30:15 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Thu, 13 Nov 2003 17:00:15 +0530 X-Sasl-Enc: GMKWau6/BXe45Yqc1jD+5Q 1068723015 Cc: " Jun-ichiro itojun Hagino" , john.loughney@nokia.com Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt References: <20031113110359.501E989@coconut.itojun.org> In-Reply-To: <20031113110359.501E989@coconut.itojun.org> Message-Id: <20031113113015.A6D8C80322@server2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 13 Nov 2003 20:03:59 +0900 (JST), "Jun-ichiro itojun Hagino" said: > > > Agreed. It is Duplicate ADDRESS Detection, so disabling the address > > is reasonable, disabling the interface is probably too strong. > > re-read the exact text, and i think the above makes sense. > > so proposed change: the last part should be changed to "the > interface address SHOULD be disabled". (add "address") Some explanatory text will be needed regarding the semantics of a "disabled" address, and further actions. Points to be discussed will include: 1) How long should an address be disabled for - permanent, or timer based? A timer based disabling mechanism might be useful in case the user is not able to generate an IID, and wants to re-enable the address. 2) If the disabled address is a static address, then how should the user be informed? This one should probably be documented in some API document, though I doubt if it is in the purview of an IETF document. 3) Points raised by Thomas - recommendation for generation of new IID's, and frequency at which the retries (with new IID's) shall be done. CP -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 08:14:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23300 for ; Thu, 13 Nov 2003 08:14:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHI8-00007k-19 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 08:13:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADDDhdQ000473 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 08:13:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHI7-00007X-Ov for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 08:13:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23204 for ; Thu, 13 Nov 2003 08:13:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKHI6-0004DZ-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 08:13:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKHI6-0004DV-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 08:13:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHHS-0008TI-7w; Thu, 13 Nov 2003 08:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHHK-0008T0-Qn for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 08:12:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23189 for ; Thu, 13 Nov 2003 08:12:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKHHJ-0004D9-00 for ipv6@ietf.org; Thu, 13 Nov 2003 08:12:53 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKHHI-0004Cx-00 for ipv6@ietf.org; Thu, 13 Nov 2003 08:12:53 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADDCCk03449; Thu, 13 Nov 2003 15:12:13 +0200 Date: Thu, 13 Nov 2003 15:12:12 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: john.loughney@nokia.com, Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt In-Reply-To: <20031113110359.501E989@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 13 Nov 2003, Jun-ichiro itojun Hagino wrote: > so proposed change: the last part should be changed to "the interface > address SHOULD be disabled". (add "address") If we say something to this effect (i.e., the address), I believe it should be a MUST. There is really zero excuse to continue using an address if DAD fails. On the other hand, there may be some reasons for continuing to use the interface. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 09:59:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29727 for ; Thu, 13 Nov 2003 09:59:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIw7-0007lk-OH for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 09:59:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADEx7I5029858 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 09:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIw7-0007lV-I9 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 09:59:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29664 for ; Thu, 13 Nov 2003 09:58:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIw5-0006DE-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 09:59:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKIw5-0006DB-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 09:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIw2-0007fM-Fk; Thu, 13 Nov 2003 09:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIvN-0007dY-Gv for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 09:58:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29651 for ; Thu, 13 Nov 2003 09:58:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIvL-0006Cn-00 for ipv6@ietf.org; Thu, 13 Nov 2003 09:58:19 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AKIvK-0006Ck-00 for ipv6@ietf.org; Thu, 13 Nov 2003 09:58:18 -0500 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 78FC98A; Thu, 13 Nov 2003 23:58:09 +0900 (JST) To: Fred Templin Cc: ipv6@ietf.org, v6ops@ops.ietf.org In-reply-to: osprey67's message of Thu, 13 Nov 2003 06:53:38 PST. <20031113145338.52776.qmail@web80509.mail.yahoo.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ISATAP in unmanaged networks? From: itojun@iijlab.net Date: Thu, 13 Nov 2003 23:58:09 +0900 Message-Id: <20031113145809.78FC98A@coconut.itojun.org> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >I have not studied this space, but it occurs to me that ISATAP >could be tried as a first alternative to check whether the two >hosts are separated by a NAT. If there is no intervening NAT, >it seems to me that ISATAP would provide the benefit of not >needing the UDP header and "bubble" packets, yielding >greater efficiency. Otherwise, if blocked by a NAT the >initiating host coud after a short timeout try again with >Teredo. ISATAP requires an ISATAP router in a site to advertise RA in a pretty weird fashion, which is clearly a drawback. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 10:03:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00168 for ; Thu, 13 Nov 2003 10:03:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ02-0008RD-Fv for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:03:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADF3AJu032429 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ02-0008Qy-A9 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:03:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00124 for ; Thu, 13 Nov 2003 10:02:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIzw-0006NI-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:03:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKIzw-0006NF-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:03:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIzu-0008K9-59; Thu, 13 Nov 2003 10:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIky-0006C2-Oi for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 09:47:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29142 for ; Thu, 13 Nov 2003 09:47:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIkw-00063l-00 for ipv6@ietf.org; Thu, 13 Nov 2003 09:47:34 -0500 Received: from web80510.mail.yahoo.com ([66.218.79.80]) by ietf-mx with smtp (Exim 4.12) id 1AKIkw-00063B-00 for ipv6@ietf.org; Thu, 13 Nov 2003 09:47:34 -0500 Message-ID: <20031113144702.71379.qmail@web80510.mail.yahoo.com> Received: from [63.197.18.101] by web80510.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 06:47:02 PST Date: Thu, 13 Nov 2003 06:47:02 -0800 (PST) From: Fred Templin Subject: ISATAP in unmanaged networks? To: v6ops@ops.ietf.org, ipv6@ietf.org Cc: osprey67@yahoo.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1699315951-1068734822=:71326" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1699315951-1068734822=:71326 Content-Type: text/plain; charset=us-ascii Hello, It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of the automatic tunneling alternatives, and I wonder why this is so. I have not studied this space, but it occurs to me that ISATAP could be tried as a first alternative to check whether the two hosts are separated by a NAT. If there is no intervening NAT, it seems to me that ISATAP would provide the benefit of not needing the UDP header and "bubble" packets, yielding greater efficiency. Otherwise, if blocked by a NAT the initiating host coud after a short timeout try again with Teredo. I know that ISATAP has been seen as in the Enterprise space, but I see potential applicability here for the unmanaged. Comments? Fred Templin osprey67@yahoo.com --0-1699315951-1068734822=:71326 Content-Type: text/html; charset=us-ascii
Hello,
 
It just now occurs to me that Christian's unmanaged networks
presentiation during v6ops yesterday did not mention ISATAP
as one of the automatic tunneling alternatives, and I wonder
why this is so.
 
I have not studied this space, but it occurs to me that ISATAP
could be tried as a first alternative to check whether the two
hosts are separated by a NAT. If there is no intervening NAT,
it seems to me that ISATAP would provide the benefit of not
needing the UDP header and "bubble" packets, yielding
greater efficiency. Otherwise, if blocked by a NAT the
initiating host coud after a short timeout try again with
Teredo.
 
I know that ISATAP has been seen as in the Enterprise
space, but I see potential applicability here for the
unmanaged. Comments?
 
Fred Templin
 
--0-1699315951-1068734822=:71326-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 10:10:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01167 for ; Thu, 13 Nov 2003 10:10:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ6x-0000w2-EH for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:10:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFAJVs003579 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:10:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ6w-0000vY-TX for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:10:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01097 for ; Thu, 13 Nov 2003 10:10:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJ6t-0006Uf-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:10:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJ6s-0006Uc-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:10:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ6g-0000pi-AJ; Thu, 13 Nov 2003 10:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJ6N-0000oX-At for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 10:09:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01020 for ; Thu, 13 Nov 2003 10:09:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJ6L-0006U7-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:09:41 -0500 Received: from web80509.mail.yahoo.com ([66.218.79.79]) by ietf-mx with smtp (Exim 4.12) id 1AKJ6K-0006Tm-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:09:40 -0500 Message-ID: <20031113150908.55569.qmail@web80509.mail.yahoo.com> Received: from [63.197.18.101] by web80509.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 07:09:08 PST Date: Thu, 13 Nov 2003 07:09:08 -0800 (PST) From: Fred Templin Subject: Re: ISATAP in unmanaged networks? To: itojun@iijlab.net Cc: ipv6@ietf.org, v6ops@ops.ietf.org In-Reply-To: <20031113145809.78FC98A@coconut.itojun.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1155803347-1068736148=:54049" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1155803347-1068736148=:54049 Content-Type: text/plain; charset=us-ascii Itojun, I subscribe to the model that all nodes may indeed be routers. This comes mainly from my background in MANET, but I see the paradigm as possibly appropriate here as well. If each node in the site were a router, we would be sending an RS in the expectation of getting back an RA with more-specific routes and (in most cases) zero in the router_lifetime field. We will certainly still have our default router(s) as told by the Potential Router List. But, if we view the global DNS as an extension to the PRL, we can select ISATAP routers for more specific routes on an on-demand basis. Sorry for not saying all of this at the microphone yesterday, but I was preoccupied with other matters at the time. Thanks - Fred osprey67@yahoo.com itojun@iijlab.net wrote: >I have not studied this space, but it occurs to me that ISATAP >could be tried as a first alternative to check whether the two >hosts are separated by a NAT. If there is no intervening NAT, >it seems to me that ISATAP would provide the benefit of not >needing the UDP header and "bubble" packets, yielding >greater efficiency. Otherwise, if blocked by a NAT the >initiating host coud after a short timeout try again with >Teredo. ISATAP requires an ISATAP router in a site to advertise RA in a pretty weird fashion, which is clearly a drawback. itojun --0-1155803347-1068736148=:54049 Content-Type: text/html; charset=us-ascii
Itojun,
 
I subscribe to the model that all nodes may indeed be routers.
This comes mainly from my background in MANET, but I see
the paradigm as possibly appropriate here as well. If each node
in the site were a router, we would be sending an RS in the
expectation of getting back an RA with more-specific routes
and (in most cases) zero in the router_lifetime field.
 
We will certainly still have our default router(s) as told by the
Potential Router List. But, if we view the global DNS as an
extension to the PRL, we can select ISATAP routers for more
specific routes on an on-demand basis.
 
Sorry for not saying all of this at the microphone yesterday, but
I was preoccupied with other matters at the time.
 
Thanks - Fred
osprey67@yahoo.com
 

itojun@iijlab.net wrote:
>I have not studied this space, but it occurs to me that ISATAP
>could be tried as a first alternative to check whether the two
>hosts are separated by a NAT. If there is no intervening NAT,
>it seems to me that ISATAP would provide the benefit of not
>needing the UDP header and "bubble" packets, yielding
>greater efficiency. Otherwise, if blocked by a NAT the
>initiating host coud after a short timeout try again with
>Teredo.

ISATAP requires an ISATAP router in a site to advertise RA in a
pretty weird fashion, which is clearly a drawback.

itojun
--0-1155803347-1068736148=:54049-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 10:17:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02038 for ; Thu, 13 Nov 2003 10:17:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJDi-0001as-A5 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:17:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFHI76006125 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:17:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJDh-0001ai-Bc for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:17:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01960 for ; Thu, 13 Nov 2003 10:17:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJDf-0006fz-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:17:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJDe-0006fw-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:17:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJDR-0001Ue-UD; Thu, 13 Nov 2003 10:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJCV-0001TB-QZ for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 10:16:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01823 for ; Thu, 13 Nov 2003 10:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJCT-0006dy-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:16:01 -0500 Received: from web80506.mail.yahoo.com ([66.218.79.76]) by ietf-mx with smtp (Exim 4.12) id 1AKJCS-0006b3-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:16:01 -0500 Message-ID: <20031113151529.24772.qmail@web80506.mail.yahoo.com> Received: from [63.197.18.101] by web80506.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 07:15:29 PST Date: Thu, 13 Nov 2003 07:15:29 -0800 (PST) From: Fred Templin Subject: Re: ISATAP in unmanaged networks? To: Pekka Savola Cc: v6ops@ops.ietf.org, ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-249950092-1068736529=:24572" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-249950092-1068736529=:24572 Content-Type: text/plain; charset=us-ascii Pekka, It is not at all true that the cooperation of an ISP is needed to support ISATAP. ISATAP works just fine in intermittently connected/disconnected networks - even of the mobile ad-hoc variety. I spent several years proving this in my previous employment at SRI, and nothing has changed since then. See the "goals for local communications within sites" document in the IPv6 space for other scenarios that would benefit from ISATAP. Fred osprey67@yahoo.com Pekka Savola wrote: I removed ipv6@ietf.org from Cc: to avoid unnecessary cross-posting. On Thu, 13 Nov 2003, Fred Templin wrote: > I have not studied this space, but it occurs to me that ISATAP > could be tried as a first alternative to check whether the two > hosts are separated by a NAT. If there is no intervening NAT, > it seems to me that ISATAP would provide the benefit of not > needing the UDP header and "bubble" packets, yielding > greater efficiency. Otherwise, if blocked by a NAT the > initiating host coud after a short timeout try again with > Teredo. There are multiple cases to consider: - host/router is not behind a NAT: * the ISP is providing the ISATAP service ==> this is a cornercase of tunnel service by the ISP - host/router is behind a NAT: * .. when the ISP is doing the NAT (e.g., GPRS -kind of scenario, also sometimes used for commmon xDSL networks) ==> same as above, the service provided by the ISP I don't think there's really applicability for ISATAP in this space if the ISP is co-operating (which is the requirement for ISATAP anyway). Configured tunneling (+ enhancements) is simpler and more generic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --0-249950092-1068736529=:24572 Content-Type: text/html; charset=us-ascii
Pekka,
 
It is not at all true that the cooperation of an ISP is needed to
support ISATAP. ISATAP works just fine in intermittently
connected/disconnected networks - even of the mobile ad-hoc
variety. I spent several years proving this in my previous
employment at SRI, and nothing has changed since then.
 
See the "goals for local communications within sites" document
in the IPv6 space for other scenarios that would benefit from ISATAP.
 
Fred
osprey67@yahoo.com 

Pekka Savola <pekkas@netcore.fi> wrote:
I removed ipv6@ietf.org from Cc: to avoid unnecessary cross-posting.

On Thu, 13 Nov 2003, Fred Templin wrote:
> I have not studied this space, but it occurs to me that ISATAP
> could be tried as a first alternative to check whether the two
> hosts are separated by a NAT. If there is no intervening NAT,
> it seems to me that ISATAP would provide the benefit of not
> needing the UDP header and "bubble" packets, yielding
> greater efficiency. Otherwise, if blocked by a NAT the
> initiating host coud after a short timeout try again with
> Teredo.

There are multiple cases to consider:

- host/router is not behind a NAT:
* the ISP is providing the ISATAP service
==> this is a cornercase of tunnel service by the ISP

- host/router is behind a NAT:
* .. when the ISP is doing the NAT (e.g., GPRS -kin! d of scenario, also
sometimes used for commmon xDSL networks)
==> same as above, the service provided by the ISP

I don't think there's really applicability for ISATAP in this space if the
ISP is co-operating (which is the requirement for ISATAP anyway).
Configured tunneling (+ enhancements) is simpler and more generic.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--0-249950092-1068736529=:24572-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 10:22:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02423 for ; Thu, 13 Nov 2003 10:22:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJIb-0002Gd-E0 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:22:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFMLJT008709 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:22:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJIb-0002GO-3c for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:22:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02389 for ; Thu, 13 Nov 2003 10:22:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJIY-0006ks-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:22:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJIY-0006kp-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:22:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJIG-00023b-Pj; Thu, 13 Nov 2003 10:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJIB-00023J-UC for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 10:21:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02372 for ; Thu, 13 Nov 2003 10:21:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJI9-0006kS-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:21:53 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1AKJI9-0006kM-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:21:53 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hADFLMIw409144 for ; Thu, 13 Nov 2003 10:21:22 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADFLHc2157734 for ; Thu, 13 Nov 2003 08:21:18 -0700 Subject: Question regarding RFC 2461 To: ipv6@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Lori Napoli Date: Thu, 13 Nov 2003 10:21:13 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/13/2003 08:21:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I have a question about whether a NA sent to all-nodes multicast address with the solicited bit ON is valid or invalid. Here are excerpts from the RFC. For destination address in a NA: For solicited advertisements, the Source Address of an invoking Neighbor Solicitation or, if the solicitation's Source Address is the unspecified address, the all-nodes multicast address This makes it sound like a NA could be sent to the all nodes multicast address and have the solicited bit ON. However, here is what is says under the solicited bit: When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements. This states the solicited bit MUST NOT be set if the NA is destined for a multicast address. Can you please clarify if a NA sent to all-nodes multicast address with solicited bit ON is considered valid or invalid. Thanks! Lori Napoli -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 10:26:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02718 for ; Thu, 13 Nov 2003 10:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJML-0003I6-3F for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:26:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFQDTQ012644 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJMK-0003Hr-TK for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02690 for ; Thu, 13 Nov 2003 10:26:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJMI-0006pW-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:26:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJMH-0006pT-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:26:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJMA-0003AU-L6; Thu, 13 Nov 2003 10:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJLS-00034T-76 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 10:25:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02660 for ; Thu, 13 Nov 2003 10:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJLP-0006os-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:25:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKJLM-0006o1-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:25:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hADFOSE02096; Thu, 13 Nov 2003 07:24:28 -0800 X-mProtect: <200311131524> Nokia Silicon Valley Messaging Protection Received: from dyn131-9.ietf58.ietf.org (130.129.131.9, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdENYb1P; Thu, 13 Nov 2003 07:24:27 PST Message-Id: <4.3.2.7.2.20031113071902.021a0c48@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 07:23:29 -0800 To: ipv6@ietf.org, v6ops@ops.ietf.org From: Bob Hinden Subject: Re: ISATAP in unmanaged networks? Cc: itojun@iijlab.net, Fred Templin In-Reply-To: <20031113150908.55569.qmail@web80509.mail.yahoo.com> References: <20031113145809.78FC98A@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Folks, Please keep this thread on the v6ops list and do not cross post to ipv6. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 10:32:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03006 for ; Thu, 13 Nov 2003 10:32:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJS8-0003wA-9e for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:32:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFWCD1015128 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJS7-0003vv-I7 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:32:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02973 for ; Thu, 13 Nov 2003 10:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJS5-0006wH-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:32:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJS4-0006wE-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJRx-0003qI-Sq; Thu, 13 Nov 2003 10:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJRT-0003pJ-W9 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 10:31:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02962 for ; Thu, 13 Nov 2003 10:31:18 -0500 (EST) From: mariana.nikolova@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJRQ-0006vy-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:31:28 -0500 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 1AKJRP-0006vv-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:31:28 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id EAE422B1F8; Thu, 13 Nov 2003 16:31:25 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 73DC019C45; Thu, 13 Nov 2003 16:31:25 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id C54A919C48; Thu, 13 Nov 2003 16:31:24 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id QAA05946; Thu, 13 Nov 2003 16:31:24 +0100 (MET) To: Fred Templin Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: ISATAP and proto-41 in unmanaged networks? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Nov 2003 16:30:38 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 13/11/2003 16:30:42, Serialize complete at 13/11/2003 16:30:42 Content-Type: multipart/alternative; boundary="=_alternative 00554D99C1256DDD_=" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00554D99C1256DDD_= Content-Type: text/plain; charset="us-ascii" Hi Fred, >It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of >the automatic tunneling alternatives, and I wonder why this is so. I wonder as well. Not only ISATAP but also proto-41 (that Jordi presented later on) were not mentioned in the Christian's presentation. Keeping in mind that both mechanisms (ISATAP for intra-site tunneling and proto-41 for inter-site tunneling) are often used I asked myself why they were kept undercover yesterday. Probably some comments form the designing team of unmanaged networks proposal? >ISATAP requires an ISATAP router in a site to advertise RA in apretty weird fashion, which is clearly a drawback. Itojun, Teredo also requires quite an infrastructure (Teredo servers, Teredo relays) to function properly. In general this is valid remark for all transition mechanisms. However, it is not a reason to ignore some of them and to push others. Greetings, Mariana ----------------------------------------------------------------------------------------------------------------- Dr. Mariana Nikolova Philips Research Laboratories Eindhoven Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com ----------------------------------------------------------------------------------------------------------------- --=_alternative 00554D99C1256DDD_= Content-Type: text/html; charset="us-ascii"
Hi Fred,

>It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of >the automatic tunneling alternatives, and I wonder why this is so.

I wonder as well. Not only ISATAP but also proto-41 (that Jordi presented later on) were not mentioned in the Christian's presentation. Keeping in mind that both mechanisms (ISATAP for intra-site tunneling and proto-41 for inter-site tunneling) are often used I asked myself why they were kept undercover yesterday.

Probably some comments form the designing team of unmanaged networks proposal?

>ISATAP requires an ISATAP router in a site to advertise RA in apretty weird fashion, which is clearly a drawback.

Itojun, Teredo also requires quite an infrastructure (Teredo servers, Teredo relays) to function properly. In general this is valid remark for all transition mechanisms. However, it is not a reason to ignore some of them and to push others.  

Greetings,
Mariana
-----------------------------------------------------------------------------------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
----------------------------------------------------------------------------------------------------------------- --=_alternative 00554D99C1256DDD_=-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 11:30:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06121 for ; Thu, 13 Nov 2003 11:30:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKLj-0001EN-S7 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 11:29:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGTd0O004725 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 11:29:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKLj-0001E8-M4 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:29:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06055 for ; Thu, 13 Nov 2003 11:29:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKLi-0000Ez-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 11:29:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKKLi-0000Ew-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 11:29:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKL9-00017p-3G; Thu, 13 Nov 2003 11:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKKa-0000yn-Db for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 11:28:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05956 for ; Thu, 13 Nov 2003 11:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKKZ-0000Di-00 for ipv6@ietf.org; Thu, 13 Nov 2003 11:28:27 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1AKKKY-0000Df-00 for ipv6@ietf.org; Thu, 13 Nov 2003 11:28:27 -0500 Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L309VKXH8E8WZFGV@vaxh.its.monash.edu.au> for ipv6@ietf.org; Fri, 14 Nov 2003 03:26:53 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id E0414158002; Fri, 14 Nov 2003 03:26:52 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by broink.its.monash.edu.au (Postfix) with ESMTP id D2AFE120005; Fri, 14 Nov 2003 03:26:52 +1100 (EST) Date: Fri, 14 Nov 2003 03:26:52 +1100 From: Gregory Daley Subject: Re: Question regarding RFC 2461 To: Lori Napoli Cc: ipv6@ietf.org Message-id: <317c64317033.317033317c64@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: Lori Napoli Date: Friday, November 14, 2003 2:21 am Subject: Question regarding RFC 2461 > > > > > I have a question about whether a NA sent to all-nodes multicast > addresswith the solicited bit ON is valid or invalid. Here are > excerpts from the > RFC. it's not a valid message, as specified in section 7.1.2 and it will be ignored by receivers. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 12:17:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08823 for ; Thu, 13 Nov 2003 12:17:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKL5q-0005tH-I9 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 12:17:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADHHIwL022644 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 12:17:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKL5q-0005t9-75 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 12:17:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08773 for ; Thu, 13 Nov 2003 12:17:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKL5o-0001Ef-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 12:17:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKL5o-0001Eb-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 12:17:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKL4c-0005Ve-RY; Thu, 13 Nov 2003 12:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKL3h-0005UK-UP for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 12:15:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08633 for ; Thu, 13 Nov 2003 12:14:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKL3g-00018r-00 for ipv6@ietf.org; Thu, 13 Nov 2003 12:15:04 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AKL3f-00018o-00 for ipv6@ietf.org; Thu, 13 Nov 2003 12:15:04 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 26356AFDBE; Thu, 13 Nov 2003 12:15:04 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04125-10; Thu, 13 Nov 2003 12:15:03 -0500 (EST) Received: from cs.utk.edu (dyn129-239.ietf58.ietf.org [130.129.129.239]) by smtp.cs.utk.edu (Postfix) with ESMTP id 903C8AFDBA; Thu, 13 Nov 2003 12:15:02 -0500 (EST) Date: Thu, 13 Nov 2003 12:15:43 -0500 Subject: Re: comments on draft-hain-templin-ipv6-localcomm-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Keith Moore , ipv6@ietf.org To: awhite@arc.corp.mot.com From: Keith Moore In-Reply-To: <3FB2F973.3FD8DB57@motorola.com> Message-Id: <031C85BC-15FD-11D8-9F90-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I think we're missing the point. > > There is a perceived need by "many" operators for an address space > that can > be used for 'local' use, where 'local' is 'not part of the global > internet'. We need to dispel that perception. Operators are free to filter traffic going to and from their networks as they see fit. What's not reasonable is for the architecture to tie policy, or any expectation of filtering, to the kind of address prefix in use. - it over-constrains use of the address space for more legitimate purposes - it conflicts with the desirability of being able to communicate between networks using non-global addresses - the notion of 'local' is too vague and too subject to variation - any attempt to encode policy in address bits is going to be too inflexible to be applied to all apps and/or all hosts on a network - this is true even if you restrict it to "appliance" hosts - the idea that 'local' hosts are somehow trustworthy is a very dubious one - it imposes an onerous burden on apps that are expected to work across "local prefix" boundaries I agree that it's desirable to have a way for the network to communicate policy to hosts and apps, but this isn't a suitable mechanism for doing so. (If we want to overload addresses, there are lots of other ways to overload them that would be useful. e.g. why not encode TOS in address bits? after all, existing routing policy mechanisms would make it easy to implement.) > Fundamentally, there are 2 requirements: > > - Free (both financially and administratively) or within epsilon of free. > - Approximately unique > > Operationally, we impose an additional requirement: > > - Using such space should not add to the size of the global routing > tables. no problem with any of the above - just with the idea that these are "local" as opposed to "non-routable in the public network". and the current proposal satisfies the above criteria quite nicely. > allowing such addresses to be globally > routeable has two drawbacks: > - affects global routing tables, possibly badly > - raises 'approximately unique' requirement to 'unique' > > Introducing compulsory filtering outside whatever administrative > boundaries > these addresses have removes these two drawbacks. That's the wrong way to define it. People need to be able to route between private networks even if some or all of those networks are not connected to the public internet. So we need to be able to route between networks that use nonglobal addresses. > Assuming the 'unique enough' mechanism is unique enough, the only > difference > between a 'local' address and a 'global' address which is > administratively > filtered is that EVERYBODY is filtering the local address, only at the boundaries between their network and the public internet. They're free to filter or not filter such addresses at private interconnections between their networks and other networks. They're free to provide transit for nonglobal addresses also. > - To applications? None. A local address may be treated as a global > address, and will function identically to any filtered global address. > The > only difference is that the local address prefix provides a strong > hint that > the address WILL be filtered, thus increasing the ability of an > application > to make address selection choices if it so wishes. False. Apps can't expect networks to filter all traffic using nonglobal addresses at their boundaries, because there are too many reasons why networks using nonglobal addresses might need to exchange traffic over private links. Apps can't even tell whether a potential peer that uses a global address is unreachable, since some networks using nonglobal addresses will still need to exchange traffic over private links with other networks that use global addresses. > - To routers and infrastructure? Many of these devices SHOULD have > filters > configured to discard local addresses. Except at the boundaries between their networks and the public internet, this is entirely a matter of local network policy. > Nothing breaks that wont break already. False. People can certainly configure their networks now in ways that will break things, and of course this won't change. But what you are proposing is to _encourage_ people to configure their networks in ways that will break things, while at the same time making their networks less flexible. (e.g. by requiring any network that wants to connect with another network to acquire global addresses whether or not it connects to the public network). > The cost to those that don't want > to use these addresses is minimal. False. If we were to adopt what you propose, everyone would be burdened with apps that tried to cope with a hodgepodge of addresses with varying and uncertain reachability. This would increase the cost for everyone. > And some people gain functionality they > particularly want. Where is the problem? See above. Just because people want a certain kind of functionality doesn't mean we should implement in in the way that seems obvious to people who haven't considered all of the implications. > I'll offer one comment on the Hinden/Haberman draft. Although I'm > generally > in favour of it, the draft completely partitions the space into that > which > is registered and that which is allocated using the provided random > algorithm. No space is left for alternative mechanisms, such as MAC > based > allocation presented in draft-white-auto-subnet-alloc or > draft-hinden-ipv6-global-site-local. Good point. Offhand I'd think that a MAC could be used as an alternative way to generate a "random" number - run it through MD5 or some such. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 12:35:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09845 for ; Thu, 13 Nov 2003 12:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLNK-00074O-Ls for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 12:35:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADHZMP1027177 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 12:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLNK-00074G-Em for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 12:35:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09770 for ; Thu, 13 Nov 2003 12:35:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLNI-0001bn-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 12:35:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKLNH-0001bM-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 12:35:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLM2-0006s4-Qz; Thu, 13 Nov 2003 12:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLLf-0006qi-9d for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 12:33:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09612 for ; Thu, 13 Nov 2003 12:33:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLLd-0001YL-00 for ipv6@ietf.org; Thu, 13 Nov 2003 12:33:37 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1AKLLd-0001YH-00 for ipv6@ietf.org; Thu, 13 Nov 2003 12:33:37 -0500 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 1075B4050CB; Thu, 13 Nov 2003 12:33:35 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 9AFED65A3D; Thu, 13 Nov 2003 12:33:34 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Thu, 13 Nov 2003 23:03:34 +0530 X-Sasl-Enc: fNKFksSm/PMMtNTih1K33g 1068744814 Cc: " Jun-ichiro itojun Hagino" , john.loughney@nokia.com Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt References: ARRAY(0xa165544) In-Reply-To: ARRAY(0xa27e3e8) Message-Id: <20031113173334.9AFED65A3D@server2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 13 Nov 2003 20:03:59 +0900 (JST), "Jun-ichiro itojun Hagino" said: > so proposed change: the last part should be changed to "the > interface address SHOULD be disabled". (add "address") > > 5.4.5. When Duplicate Address Detection Fails > > A tentative address that is determined to be a duplicate as > described above, MUST NOT be assigned to an interface and the node > SHOULD log a system management error. If the address is a link- > local address formed from an interface identifier, the interface > SHOULD be disabled. Hi itojun, Replacing interface with address will not be enough. I have attempted to rephrase the paragraph with my comments in brackets. A tentative address that is determined to be a duplicate as described above, MUST NOT be assigned to the interface on which DAD has failed (this allows for the address to be assigned to other interfaces) and the node SHOULD log a system management error. Moreover, the address SHOULD (or MUST?) be disabled. If the address is a link-local address formed from an interface identifier, the complete set of addresses formed with the same interface identifier SHOULD (or MUST?) be disabled. CP -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 13:45:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12373 for ; Thu, 13 Nov 2003 13:45:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMTE-0003Fp-Pr for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 13:45:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADIjWAv012503 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 13:45:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMTE-0003Fa-Jc for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 13:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12319 for ; Thu, 13 Nov 2003 13:45:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMT8-0002bt-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 13:45:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKMT8-0002bq-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 13:45:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMSm-00039J-Ua; Thu, 13 Nov 2003 13:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMSd-00038e-3g for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 13:44:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12282 for ; Thu, 13 Nov 2003 13:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMSa-0002aj-00 for ipv6@ietf.org; Thu, 13 Nov 2003 13:44:52 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AKMSa-0002ag-00 for ipv6@ietf.org; Thu, 13 Nov 2003 13:44:52 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hADIilPh009074 for ; Thu, 13 Nov 2003 11:44:47 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HOB00ABX02LSZ@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 13 Nov 2003 11:44:45 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HOB00FWT02KKW@mail.sun.net> for ipv6@ietf.org; Thu, 13 Nov 2003 11:44:45 -0700 (MST) Date: Thu, 13 Nov 2003 10:47:35 -0800 From: Alain Durand Subject: SL deprecation draft To: ipv6@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I just watched the video of the site local deprecation presentation from Christian Huitema. There is one issue raised in the mailing list that Christian did not mention, that is the current deprecation section does not mention the list of RFCs that are impacted. I strongly object to the publication of this document until this is fixed. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 14:56:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15527 for ; Thu, 13 Nov 2003 14:56:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNa0-0000D7-Kp for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 14:56:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADJuatj000803 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 14:56:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNa0-0000Cs-6k for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 14:56:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15495 for ; Thu, 13 Nov 2003 14:56:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNZx-0003q0-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 14:56:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNZx-0003px-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 14:56:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNZS-0008Uo-FH; Thu, 13 Nov 2003 14:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNZL-0008UW-3f for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 14:55:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15468 for ; Thu, 13 Nov 2003 14:55:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNZI-0003ow-00 for ipv6@ietf.org; Thu, 13 Nov 2003 14:55:52 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNZH-0003ot-00 for ipv6@ietf.org; Thu, 13 Nov 2003 14:55:51 -0500 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 TAA21751 for ; Thu, 13 Nov 2003 19:55:50 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA19926 for ; Thu, 13 Nov 2003 19:55:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hADJtnY05893 for ipv6@ietf.org; Thu, 13 Nov 2003 19:55:49 GMT Date: Thu, 13 Nov 2003 19:55:49 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: SL deprecation draft Message-ID: <20031113195549.GA3473@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, Nov 13, 2003 at 10:47:35AM -0800, Alain Durand wrote: > I just watched the video of the site local deprecation presentation > from Christian Huitema. > There is one issue raised in the mailing list that Christian did not > mention, > that is the current deprecation section does not mention the list of > RFCs that are impacted. > > I strongly object to the publication of this document until this is > fixed. I think this would be a sensible thing to do at this stage (not least in case there is something being overlooked, although this seems exceptionally unlikely). Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 15:03:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15999 for ; Thu, 13 Nov 2003 15:03:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNgN-0000wj-6a for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 15:03:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADK3BU1003631 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 15:03:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNgN-0000wU-1n for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 15:03:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15942 for ; Thu, 13 Nov 2003 15:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNgK-0003zy-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 15:03:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNgJ-0003zv-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 15:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNgE-0000pd-1s; Thu, 13 Nov 2003 15:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNfd-0000nt-Dw for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 15:02:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15846 for ; Thu, 13 Nov 2003 15:02:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNfa-0003yp-00 for ipv6@ietf.org; Thu, 13 Nov 2003 15:02:22 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNfZ-0003yb-00 for ipv6@ietf.org; Thu, 13 Nov 2003 15:02:21 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADK1hx11445; Thu, 13 Nov 2003 22:01:43 +0200 Date: Thu, 13 Nov 2003 22:01:43 +0200 (EET) From: Pekka Savola To: Chirayu Patel , cc: ipv6@ietf.org Subject: Re: comments on thaler-ndproxy-01 In-Reply-To: <20031111131555.C2D0F8059E@server2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Sorry for the delay in responding.. On Tue, 11 Nov 2003, Chirayu Patel wrote: [snip scenarios] > Yep, that's pretty much what I had in mind. The point is that NDproxies in these cases can be often replaced by normal, bridging devices. However, the user probably wants to do stuff like firewalling on the box as well.. which was the reason to at least include this case in the introduction, even if ND-proxies are not necessarily a requirement. > About classic L2 bridging, IMHO, the document quite clearly states, when > it should be used, and its limitations. (Section 1). Is this enough? The > different scenarios in which L2 bridges are used (and they are the ones > in which ND proxy should not be used) are not described because they are > well known. What I meant is e.g. if in your scenario 2 above the ISP <-> user link is also Ethernet, ND-proxy is not required. I.e., summarize the few scenarios where bridging would also be useful and could be used instead of a NAT box. > > 3) I'm not sure whether specifying the mechanism for IPv4 is within the > > mandate of this WG. But it seems to come in free, so, no huge > > resistance here. The worry is just that there may be some v4 > > features we're not really aware of and making ND proxying work on v4 > > might actually take a lot more effort than we realize at first > > (difficult to say at this phase). > > Actually, there is a bit of work involved for IPv4. It does not come for > free. :-) For example, implementation details have to be specified for > both IPv4, and IPv6. Currently, most of the implementation detail is > specific to IPv6. The neighbor cache structure, its state transition > table cannot be applied to IPv4. Minor editorial nits (usage of broadcast > and multicast) also have to be taken care of. I am sure there are more of > such "non-free" areas. > > IPv4 ARP proxy has been around for a while now, and IMHO there is not > much gain by documenting it now. We should probably remove it. I have no objection to removing it. > > > 4) I want the loop-prevention features to be to non-requirements. If > > loop prevention is required, the ND-proxy is deployed improperly. > > The only thing from loop prevention I'd appreciate is that the > > failure mode would be obvious when/if ND proxying was deployed in > > such a manner that a loop would occur. (This would result to moving > > the loop prevention stuff to an appendix or removing it..) > > Don't understand completely. > > 1. Why do you want the loop-prevention features to be non-requirements? > Isn't the current form (of an optional requirement) sufficient? It would seem to imply that ND-proxies would be deployed in scenarios where the topology is very complex. That would be out of the scope of the simple model we're aiming towards -- remember, we're not trying to supplant routed networks, we're just providing a nice way to extend the network transparently in the case adding a router would not be a good idea. > 2. Are you implying that there should be some sort of loop detection > mechanism instead? Not really. What I'm saying is that if a loop occurs, the failure mode should be apparent (i.e., the communications fail). > > 5) Non-goals has: > > o Support Neighbor Discovery, Router Discovery, or DHCPv4 > > packets using encryption with an ESP header. We also note > > that the current methods for securing these protocols do not > > use an ESP header. Where encryption is required, link-layer > > encryption can be used on each segment. > > > > ==> Uhh, isn't the current approach hostile to IPsec AH as well, as the > > payload of the packets (e.g. SLLA, TLLA) are modified, unless the ND proxy > > acts as some form of authorized intermediary? > > It's not hostile, since the proxy can still remove the original AH. > It can't do the same with ESP encryption. Ok, there's two levels of hostility which need to be spelled out better: 1) "doesn't work when the router or a host uses it", or 2) "works by modifying packets, resulting in a different security properties" > > ==> I'm not sure whether link-layer encryption sentence is accurate. Let's > > consider two cases: the L2 encryption uses a shared secret (known by the > > proxy) -- OK; the L2 encryption uses stronger methods (usually the more > > useful deployment of L2 encryption) -- the ND proxy needs act as MITM here, > > but then L2 encryption will fail, right? > > Why would it fail? The proxy always uses its own L2 address, not > someone else's. Can you give a more specific example? I mean a deployment where a host and a router would use L2 encryption, and the transparent bridge would not even be able to decipher L2 frames much less L3 packets? So, if you can't use IPsec ESP, you may be able to use L2 encryption, but only encryption where the bridge can be "on the loop" somehow? > >6) I'm not sure if the spec as written supports the seamless movement > > between bridged segments, which was a requirement, for example: > > > > If the received packet is an ICMPv6 Redirect message, then the proxied > > packet should be modified as follows. If the proxy has a valid (i.e., > > not INCOMPLETE) neighbor entry for the target address on the same > > interface as the redirected host, then the TLLA option in the proxied > > Redirect simply contains the link-layer address of the target as found > > in the proxy's neighbor entry, since the redirected host may reach the > > target address directly. > > > > ==> now, consider the same if the node moved to a different segment > > ==> since the neighbor entry was created? > > [Dave:] > > I didn't follow. Which node? The redirected host? Or the target > address? > > If the redirected host moves away, the redirect will just be dropped > since there will be no one at the destinaion link-layer address. Sorry for ambiguity. I meant the target address, because that includes the lladdr from the cache.. > > Or in: > > > > The NA is received by P, which then processes it as it would any > > unicast packet; i.e., it forwards this out interface 1, based on the > > neighbor cache. However, before actually sending the packet out, it > > inspects it to determine if the packet being sent is one which > > requires proxying. Since it is an NA, it updates its neighbor entry > > for B to be REACHABLE and records the link-layer address b. P then > > replaces the link-layer address in the TLLA option with its own link- > > layer address on the outgoing interface, p1. The packet is then sent > > out interface 1. > > > > ==> this doesn't seem to work when moving between segments without a: > > 1) a cache timeout, or > > 2) the host, immediately after moving, sending a packet, updating the > > proxy's cache. If the host is silent before moving and afterwards, > > there will be no indication where it has gone. Right? > > Right. Though, in most cases the host will not be silent (it will get a > trigger from L2 about movement), and will attempt to do Router Discovery. > > Seamless movement between bridged segments is not supported. We did > discuss a solution that involved 1) getting a trigger from L2 that the > host has moved, and 2) doing a broadcast of any unicast packet for the > moved host on all the proxy ports. This way the unicast packet (NA in > this case) would reach the destination. The broadcast would continue till > the host sends a packet, and updates the cache. > > You can refer to the past discussions on this issue at > http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%206 and: [Dave] > Offhand, I think that's right. If the host always does DAD after > moving, for example, then (2) would be the case, with (1) applying > otherwise. Both of these are not specific to this spec - indeed > essentially the same thing would happen with a classic bridge or > switch. > > As a result, I don't see anything wrong with the current draft in this > regard. It appears to meet the requirement just as well as a classic > bridge or switch does. Do you know what kind of timeout ballpark figures bridges/switches have compared to ND? (I have never noticed problems moving hosts between switch ports.) I don't think the current ND specs say anything about sending a packet or two after they get L2 trigger that link comes up, even though this might be useful for updating the cache, right? > Another thing that may have not caught your eye is the assumption that ND > proxies always have an IP address. Unlike classic L2 bridges, ND proxies > require an IP address. IMHO this is debatable...and I am planning to send > out a mail regarding this to the WG. If it is accepted that the ND > proxies always have an IP address, another scheme wherein the proxy > (after detecting host movement) sends an NS to determine the new location > of the moved host (the NA from host would populate the cache of other > proxies in the path). Messages received for the moved host, before the NA > is received, can either be queued or broadcasted. FWIW, requiring IP address is OK by me. > > 7) doesn't the following break the requirements of transparent > > introduction -- for both hosts (need to consider the bridge as a > > router), and for the router (it needs to be aware of the ND proxy, > > right?)v > > > > From=20an IPv6 perspective, RFC 2461 [ND] already defines the ability > > to proxy Neighbor Advertisements. The requirements for securing > > proxied messages are similar to those for securing Router > > Advertisements, since the receiver must verify that the advertisement > > came from a valid router/proxy, rather than from the owner of a > > specific address. > > [Dave:] > > It's unclear (to me at least) at this point. > I'm not sure there's any other solution than to disable security for > RAs. > Hence the current position to state the issue and leave it up to > the implementor to decide and the SEND WG to consider. > > If you have a specific proposal, send text :) I'm not necessarily against disabling security. I'd just want to spell out the issues here. The text needs beefing up a bit. > > When any IP or ARP packet is received on a proxy interface, it must be > > parsed to see whether it is known to be of a type that negotiates link- > > layer addresses. This document covers the following types: ARP, IPv6 > > Neighbor Discovery, IPv6 Router Discovery, IPv6 Redirects, and DHCPv4. > > > > ==> Could you spell out, for clarity, some protocols: > > a) which are not supported by this spec, or > > b) which do not need to be supported by this spec (but one could think > > whether they need be), e.g. DHCPv6? > > DHCPv6 is supposed to be supported. We did discuss it. :-) All other > protocols that are not mentioned are not supported. The document has a > guideline section (section 7) to help implementors in supporting other > protocols. Yep, the point was to just add examples of already supported protocols (without modifications, e.g. DHCPv6 because DHCPv4 requires special stuff), and protocols which are *NOT* supported, but could be, with extenstions. > > As with all forwarded packets, the link-layer header is also new. Any > > Authentication Header would also be removed, and a new one may be added > > as discussed below under Security Considerations. > > > > ==> note that Security Consideration doesn't currently discuss this :-) > > Dave? :-) Didn't respond.. > > Operation of the Spanning Tree Protocol (STP) over other types of link > > layers is done by encapsulating the STP frame in an IPv6 header as > > follows. The Next Header field is set to [TBA by IANA], indicating > > that an STP header follows. The Destination Address field is set to > > the Link-scoped STP Multicast Group [TBA by IANA]. All proxies > > operating on non-IEEE 802 media join this group so they will receive > > STP packets. STP packets are never forwarded or proxied. > > > > ==> which format is used for encapsulation of STP? Directly > > afterwards? It is a "terminal header", correct, so no TLV encoding or > > similar need be done? > > Don't understand "format", and "Directly afterwards" in your question. > STP header is the terminal header in the IPv6 packet. Right; the comment was not applicable because of that. > > ==> Are ND proxies acting as decapsulators/encapsulators for these STP > > packets between the links? If nothing is done based on these, how do > > they help in the first place? > > ND proxies will have a complete implementation of STP, and will process > STP packets received on both non-802, and 802 interfaces as per the > [BRIDGE] specification. Does this answer your question? [Dave:] > This is how a proxy that chose to implement loop prevention would send > its _own_ STP messages to a neighboring STP speaker, and receive STP > messages from the neighbor. That's the point about "never forwarded > or proxied". A proxy that chose to implement loop prevention would > act on the packets by running the spanning tree algorithm specified > in [BRIDGE] to decide whether to ignore an interface or not. Ok, I guess Dave's explanation answers this point; not having looked into the details of STP, I hope it propagates the information of the neighbors in the payload, otherwise it would be useless :-) > > 10. Appendix A: Comparison with other approaches > > > > ==> this section should be reworded to be refer to RA-proxy only, > > Agree. > > > ==> or add some other approaches (probably preferable!) such as IPv4 > > Proxy ARP (the differences are probably rather interesting..) > > Will have to think about this one. Do you have any alternate > approaches in mind? [Dave:] > Proposed text would be gratefully accepted. > > At least one IPv4 Proxy ARP implementation is pretty much the same > as what's documented, but it would be nice to hear from any different > ones. > > Another option would be to just remove Appendix A. I don't have ones in mind, but I'd think that there are typically changes especially in the ND/ARP behaviour on the ND bridge. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 15:45:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19509 for ; Thu, 13 Nov 2003 15:45:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOL9-0004y5-CI for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 15:45:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADKjJAL019097 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 15:45:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOL8-0004xw-Uy for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 15:45:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19448 for ; Thu, 13 Nov 2003 15:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOL7-0004r0-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 15:45:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKOL7-0004qx-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 15:45:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOKs-0004o2-T3; Thu, 13 Nov 2003 15:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKOKY-0004n0-Lb for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 15:44:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19393 for ; Thu, 13 Nov 2003 15:44:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKOKW-0004pz-00 for ipv6@ietf.org; Thu, 13 Nov 2003 15:44:40 -0500 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw1.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AKOKV-0004p8-00 for ipv6@ietf.org; Thu, 13 Nov 2003 15:44:39 -0500 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 1AKOJV-0004dr-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:43:37 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AKOJV-0004do-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:43:37 +0000 Received: from zurich.ibm.com ([9.145.151.149]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hADKhav28242 for ; Thu, 13 Nov 2003 20:43:36 GMT Message-ID: <3FB3ECD1.CF6995DD@zurich.ibm.com> Date: Thu, 13 Nov 2003 21:42:57 +0100 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@ietf.org Subject: Re: SL deprecation draft References: <20031113195549.GA3473@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain, Yes, you're correct that we should add that. There was a slight lack of preparation for the session between me and Christian so this was overlooked, but I don't think it is contentious. Brian Tim Chown wrote: > > On Thu, Nov 13, 2003 at 10:47:35AM -0800, Alain Durand wrote: > > I just watched the video of the site local deprecation presentation > > from Christian Huitema. > > There is one issue raised in the mailing list that Christian did not > > mention, > > that is the current deprecation section does not mention the list of > > RFCs that are impacted. > > > > I strongly object to the publication of this document until this is > > fixed. > > I think this would be a sensible thing to do at this stage (not least > in case there is something being overlooked, although this seems > exceptionally unlikely). > > Tim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 17:39:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25393 for ; Thu, 13 Nov 2003 17:39:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ7a-0005Jm-SA for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 17:39:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADMdQU5020438 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 17:39:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ7a-0005JZ-Lq for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 17:39:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25353 for ; Thu, 13 Nov 2003 17:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ7Y-0006xc-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 17:39:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQ7X-0006xZ-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 17:39:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ7C-0005Dn-Ep; Thu, 13 Nov 2003 17:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ6G-0004xn-I4 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 17:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25286 for ; Thu, 13 Nov 2003 17:37:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ6D-0006wP-00 for ipv6@ietf.org; Thu, 13 Nov 2003 17:38:01 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ6D-0006vz-00 for ipv6@ietf.org; Thu, 13 Nov 2003 17:38:01 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 14:37:30 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 14:37:30 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 14:37:26 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 14:37:25 -0800 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.3790.1069); Thu, 13 Nov 2003 14:37:16 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: SL deprecation draft Date: Thu, 13 Nov 2003 14:37:34 -0800 Message-ID: Thread-Topic: SL deprecation draft Thread-Index: AcOqJyu9cIo09mgmQSWtE87eogn+ZgAD38rQ From: "Christian Huitema" To: "Brian E Carpenter" , X-OriginalArrivalTime: 13 Nov 2003 22:37:16.0211 (UTC) FILETIME=[B077E830:01C3AA36] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable By the way, does someone has a list of these RFC?=20 > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Brian > E Carpenter > Sent: Thursday, November 13, 2003 12:43 PM > To: ipv6@ietf.org > Subject: Re: SL deprecation draft >=20 > Alain, >=20 > Yes, you're correct that we should add that. There was a slight lack of > preparation > for the session between me and Christian so this was overlooked, but I > don't think it is contentious. >=20 > Brian >=20 > Tim Chown wrote: > > > > On Thu, Nov 13, 2003 at 10:47:35AM -0800, Alain Durand wrote: > > > I just watched the video of the site local deprecation presentation > > > from Christian Huitema. > > > There is one issue raised in the mailing list that Christian did not > > > mention, > > > that is the current deprecation section does not mention the list of > > > RFCs that are impacted. > > > > > > I strongly object to the publication of this document until this is > > > fixed. > > > > I think this would be a sensible thing to do at this stage (not least > > in case there is something being overlooked, although this seems > > exceptionally unlikely). > > > > Tim > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM >=20 > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 18:08:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27319 for ; Thu, 13 Nov 2003 18:08:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQZW-0007RQ-7O for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 18:08:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADN8IxJ028598 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 18:08:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQZW-0007RB-1l for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27203 for ; Thu, 13 Nov 2003 18:08:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQZT-0007Tm-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 18:08:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQZS-0007Tj-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 18:08:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQZH-0007JR-Sx; Thu, 13 Nov 2003 18:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQZ9-0007HI-K8 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 18:07:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27138 for ; Thu, 13 Nov 2003 18:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQZ6-0007Sz-00 for ipv6@ietf.org; Thu, 13 Nov 2003 18:07:52 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1AKQZ5-0007Rn-00 for ipv6@ietf.org; Thu, 13 Nov 2003 18:07:52 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hADN4qCW065902; Thu, 13 Nov 2003 23:04:53 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADN7LBE248104; Fri, 14 Nov 2003 00:07:21 +0100 Received: from zurich.ibm.com ([9.145.244.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA44234; Fri, 14 Nov 2003 00:07:18 +0100 Message-ID: <3FB40E7E.A0A62F16@zurich.ibm.com> Date: Fri, 14 Nov 2003 00:06:38 +0100 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: Christian Huitema CC: ipv6@ietf.org Subject: Re: SL deprecation draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Back in August, Alain wrote: > I just did a grep if the RFC database of "site local" and feco > I found only few meaningful references: > > RFC2772, 6bone routing practise > RFC2894, router renumbering (an example contains FEC0) > RFC3111, SLP (an example contains FEC0) > RFC3142, TRT (an example contains FEC0) > RFC3177, recommendation on /48, some text about site local beeing /48 > RFC3082, Notification and Subscription for SLP, an example talks about > site local > RFC3484, default address selection > RFC3513, IPv6 addr architecture > > It seems to me that the main one to revisit is 3483. [I guess he meant 3484] > > - Alain. > Brian Christian Huitema wrote: > > By the way, does someone has a list of these RFC? > > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Brian > > E Carpenter > > Sent: Thursday, November 13, 2003 12:43 PM > > To: ipv6@ietf.org > > Subject: Re: SL deprecation draft > > > > Alain, > > > > Yes, you're correct that we should add that. There was a slight lack > of > > preparation > > for the session between me and Christian so this was overlooked, but I > > don't think it is contentious. > > > > Brian > > > > Tim Chown wrote: > > > > > > On Thu, Nov 13, 2003 at 10:47:35AM -0800, Alain Durand wrote: > > > > I just watched the video of the site local deprecation > presentation > > > > from Christian Huitema. > > > > There is one issue raised in the mailing list that Christian did > not > > > > mention, > > > > that is the current deprecation section does not mention the list > of > > > > RFCs that are impacted. > > > > > > > > I strongly object to the publication of this document until this > is > > > > fixed. > > > > > > I think this would be a sensible thing to do at this stage (not > least > > > in case there is something being overlooked, although this seems > > > exceptionally unlikely). > > > > > > Tim > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 18:36:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29543 for ; Thu, 13 Nov 2003 18:36:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR0b-0001If-Lq for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 18:36:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADNaHcg004996 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 18:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR0b-0001IV-B2 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:36:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29507 for ; Thu, 13 Nov 2003 18:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR0V-0000Eh-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 18:36:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKR0V-0000Ee-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 18:36:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR0L-0001Cj-MA; Thu, 13 Nov 2003 18:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQzx-0001CH-PQ for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 18:35:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29496 for ; Thu, 13 Nov 2003 18:35:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQzu-0000EO-00 for ipv6@ietf.org; Thu, 13 Nov 2003 18:35:34 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKQzu-0000E3-00 for ipv6@ietf.org; Thu, 13 Nov 2003 18:35:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hADNZ3r25002; Thu, 13 Nov 2003 15:35:03 -0800 X-mProtect: <200311132335> Nokia Silicon Valley Messaging Protection Received: from dyn131-9.ietf58.ietf.org (130.129.131.9, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdlEg6z5; Thu, 13 Nov 2003 15:35:01 PST Message-Id: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 15:34:02 -0800 To: ipv6@ietf.org From: Bob Hinden Subject: Re: SL deprecation draft Cc: Brian E Carpenter , Christian Huitema In-Reply-To: <3FB40E7E.A0A62F16@zurich.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I personally don't think it is necessary to update most of these RFCs. Specifically: > > RFC2772, 6bone routing practise The 6bone is being turned off. > > RFC2894, router renumbering (an example contains FEC0) > > RFC3111, SLP (an example contains FEC0) > > RFC3142, TRT (an example contains FEC0) If it's only used in an example, then I don't think an update is required. If these documents get redone for some other reason it would be good to change the examples. But it not worth the effort required to recycle these documents to just remove site-local from an example. > > RFC3177, recommendation on /48, some text about site local beeing /48 This is only a recommendation and updating it would likely open up Pandora's box for other changes. > > RFC3082, Notification and Subscription for SLP, an example talks about > > site local Same as examples above. > > RFC3484, default address selection I think this would be good to update. > > RFC3513, IPv6 addr architecture Very important and work underway. > > It seems to me that the main one to revisit is 3483. >[I guess he meant 3484] > > So my take is that only the Address Architecture and Default Address Selection documents need to be listed. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 20:18:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03068 for ; Thu, 13 Nov 2003 20:18:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSap-0008K1-DS for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 20:17:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1HlgU031990 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 20:17:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSap-0008Jt-4A for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:17:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03004 for ; Thu, 13 Nov 2003 20:17:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSam-0001rm-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 20:17:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKSam-0001rY-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 20:17:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSa6-00084U-8W; Thu, 13 Nov 2003 20:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSa2-00083G-SS for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 20:16:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02963 for ; Thu, 13 Nov 2003 20:16:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSa0-0001qj-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:16:56 -0500 Received: from dyn133-220.ietf58.ietf.org ([130.129.133.220] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1AKSa0-0001qg-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:16:56 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAE1GlU01555; Fri, 14 Nov 2003 02:16:48 +0100 Message-ID: <3FB42CFF.2020105@it.su.se> Date: Fri, 14 Nov 2003 02:16:47 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Bob Hinden CC: ipv6@ietf.org, Brian E Carpenter , Christian Huitema Subject: Re: SL deprecation draft References: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> In-Reply-To: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | |> > RFC2894, router renumbering (an example contains FEC0) |> > RFC3111, SLP (an example contains FEC0) |> > RFC3142, TRT (an example contains FEC0) | | | If it's only used in an example, then I don't think an update is | required. If these documents get redone for some other reason it would | be good to change the examples. But it not worth the effort required to | recycle these documents to just remove site-local from an example. | Can't we just notify the authors and let them decide? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/tCz/8Jx8FtbMZncRAm0TAKCFAcEH8J+RdBBS9l9WDgbTNMaXagCffBAc avenXqZxh/SvFxK3qdo4qkI= =Rao7 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 20:25:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03398 for ; Thu, 13 Nov 2003 20:25:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKShy-0000OQ-Oo for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 20:25:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1PAkk001504 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 20:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKShy-0000OB-F6 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:25:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03366 for ; Thu, 13 Nov 2003 20:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSht-0001zF-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 20:25:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKSht-0001zC-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 20:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKShr-0000Ij-Q1; Thu, 13 Nov 2003 20:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSgz-0000HN-T4 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 20:24:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03341 for ; Thu, 13 Nov 2003 20:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSgx-0001yE-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:24:07 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSgw-0001xa-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:24:07 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAE1NaR17114; Fri, 14 Nov 2003 03:23:36 +0200 Date: Fri, 14 Nov 2003 03:23:35 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: ipv6@ietf.org, Brian E Carpenter , Christian Huitema Subject: Re: SL deprecation draft In-Reply-To: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 13 Nov 2003, Bob Hinden wrote: > So my take is that only the Address Architecture and Default Address > Selection documents need to be listed. FWIW, totally agree here. Listing those which had no issues of substance only confuse the reader. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 20:32:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03691 for ; Thu, 13 Nov 2003 20:32:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSok-0001Dn-9h for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 20:32:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1WA4a004689 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 20:32:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSok-0001DY-31 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:32:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03655 for ; Thu, 13 Nov 2003 20:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSoh-000278-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 20:32:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKSoh-000275-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 20:32:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSod-00016d-6C; Thu, 13 Nov 2003 20:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSo0-00015f-U9 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 20:31:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03601 for ; Thu, 13 Nov 2003 20:31:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSny-00026Y-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:31:22 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSnx-00026V-00 for ipv6@ietf.org; Thu, 13 Nov 2003 20:31:21 -0500 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 BAA27892 for ; Fri, 14 Nov 2003 01:31:16 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id BAA23081 for ; Fri, 14 Nov 2003 01:31:15 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAE1VEq09845 for ipv6@ietf.org; Fri, 14 Nov 2003 01:31:14 GMT Date: Fri, 14 Nov 2003 01:31:14 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: SL deprecation draft Message-ID: <20031114013114.GA9831@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> <3FB42CFF.2020105@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB42CFF.2020105@it.su.se> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, Nov 14, 2003 at 02:16:47AM +0100, Leif Johansson wrote: > > Can't we just notify the authors and let them decide? I hope so. If we don't notify the authors they may not know to make the site local update at any subsequent bis version... Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 21:03:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04864 for ; Thu, 13 Nov 2003 21:03:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTIr-0003cy-RH for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 21:03:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE23H51013938 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 21:03:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTIr-0003cj-Lt for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:03:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04831 for ; Thu, 13 Nov 2003 21:03:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTIp-0002be-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 21:03:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKTIo-0002bb-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 21:03:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTGh-0003D5-QN; Thu, 13 Nov 2003 21:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTGb-0003CC-6F for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 21:00:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04639 for ; Thu, 13 Nov 2003 21:00:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTGY-0002X1-00 for ipv6@ietf.org; Thu, 13 Nov 2003 21:00:54 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx with esmtp (Exim 4.12) id 1AKTGX-0002UM-00 for ipv6@ietf.org; Thu, 13 Nov 2003 21:00:53 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAE20Mho442680 for ; Thu, 13 Nov 2003 21:00:22 -0500 Received: from d01ml099.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAE20L58115410 for ; Thu, 13 Nov 2003 21:00:21 -0500 Subject: comment on RFC3542 To: ipv6@ietf.org X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: Nicholas Carbone Date: Thu, 13 Nov 2003 21:00:21 -0500 X-MIMETrack: Serialize by Router on D01ML099/01/M/IBM(Release 6.0.2CF2 IGS_HF9|October 28, 2003) at 11/13/2003 21:00:21 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I am working on the implementation of the APIs that build routing headers and options headers from RFC3542. Is there a particular reason that non-standard type uint_t is used for the align argument to inet6_opt_append()? Nick Carbone IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 22:04:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08088 for ; Thu, 13 Nov 2003 22:04:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUFo-0008Gj-Q1 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 22:04:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE34C6A031778 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 22:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUFo-0008GT-LY for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 22:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08051 for ; Thu, 13 Nov 2003 22:04:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUFl-0003sg-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 22:04:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKUFl-0003sc-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 22:04:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUFe-00087y-Oy; Thu, 13 Nov 2003 22:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUEv-00086q-TD for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 22:03:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08033 for ; Thu, 13 Nov 2003 22:03:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUEs-0003sE-00 for ipv6@ietf.org; Thu, 13 Nov 2003 22:03:14 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUEs-0003sB-00 for ipv6@ietf.org; Thu, 13 Nov 2003 22:03:14 -0500 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 DAA29073 for ; Fri, 14 Nov 2003 03:03:10 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id DAA23593 for ; Fri, 14 Nov 2003 03:03:09 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAE339x08692 for ipv6@ietf.org; Fri, 14 Nov 2003 03:03:09 GMT Date: Fri, 14 Nov 2003 03:03:09 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: SL deprecation draft Message-ID: <20031114030309.GJ9831@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <3FB444DB.497FB2ED@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB444DB.497FB2ED@zurich.ibm.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, Nov 14, 2003 at 03:58:35AM +0100, Brian E Carpenter wrote: > > That isn't completely clear to me. We could say something like: > > This deprecation will require substantive updates to the Address Architecture > and Default Address Selection documents [ref, ref]. > > The site local prefix is also mentioned in several other documents which need > at most minor editorial updates [ref, ref, ref...]. I agree. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 13 22:37:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09450 for ; Thu, 13 Nov 2003 22:37:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUlG-0001za-Ma for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 22:36:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3ag7R007652 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 22:36:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUlG-0001zJ-GV for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 22:36:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09369 for ; Thu, 13 Nov 2003 22:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUlD-0004UP-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 22:36:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKUlC-0004UJ-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 22:36:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUkc-0001lB-AL; Thu, 13 Nov 2003 22:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUkX-0001kp-C4 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 22:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09262 for ; Thu, 13 Nov 2003 22:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUkT-0004RA-00 for ipv6@ietf.org; Thu, 13 Nov 2003 22:35:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKUkT-0004QG-00 for ipv6@ietf.org; Thu, 13 Nov 2003 22:35:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAE3ZG110978; Thu, 13 Nov 2003 19:35:16 -0800 X-mProtect: <200311140335> Nokia Silicon Valley Messaging Protection Received: from dyn131-9.ietf58.ietf.org (130.129.131.9, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdPBdjiw; Thu, 13 Nov 2003 19:35:14 PST Message-Id: <4.3.2.7.2.20031113191120.021b46f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 19:34:13 -0800 To: Brian E Carpenter From: Bob Hinden Subject: Re: SL deprecation draft Cc: ipv6@ietf.org In-Reply-To: <3FB444DB.497FB2ED@zurich.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Brian, >This deprecation will require substantive updates to the Address Architecture >and Default Address Selection documents [ref, ref]. > >The site local prefix is also mentioned in several other documents which need >at most minor editorial updates [ref, ref, ref...]. OK, as long as it is written such that the updates to the latter set of documents don't have to be done immediately. I still think that a few of them (e.g., RFC3177 and RFC2772) don't need to be in this list. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 14 11:04:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17477 for ; Fri, 14 Nov 2003 11:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgQg-0001fu-VX for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 11:04:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEG4Epe006432 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 11:04:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgQg-0001ff-Q8 for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 11:04:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17418 for ; Fri, 14 Nov 2003 11:03:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgQe-0007jB-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 11:04:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKgQd-0007j8-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 11:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgPV-0001Ty-QN; Fri, 14 Nov 2003 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgOb-0001OF-Tm for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 11:02:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17362 for ; Fri, 14 Nov 2003 11:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgOZ-0007iP-00 for ipv6@ietf.org; Fri, 14 Nov 2003 11:02:03 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgOY-0007iL-00 for ipv6@ietf.org; Fri, 14 Nov 2003 11:02:02 -0500 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 QAA17320 for ; Fri, 14 Nov 2003 16:02:00 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA18069 for ; Fri, 14 Nov 2003 16:02:00 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAEG1xg19951 for ipv6@ietf.org; Fri, 14 Nov 2003 16:01:59 GMT Date: Fri, 14 Nov 2003 16:01:59 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <20031114160159.GD19013@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, Nov 10, 2003 at 09:36:29PM +1100, Geoff Huston wrote: > > After thinking about this and looking at the evident need to make some > progress > here I'd like to believe that this level of resolution of potential > ambiguity > is adequate, given that there is always the option to use a central > registry draw to > obtain a global id that is assuredly unique. I think we will see a lot of people using fd00::/48 or fd00::/64 for their sites/links purely becuase it's less effort to type. Ideally if deployments were as plug and play as they might be, then this would not be as likely. We thus need simple methods by which networks can be deployed and easily use a pseudo-random local prefix generated under fd00::/8. I could foresee a "generate pseudo-random prefix" button on my home DSL router's web config screen, but the more important case is more likely the larger hierarchically routed enterprise? Presumably an admin would use parallel subnet numbering for their globally unique 2001:xxxx:xxxx::/48 prefix and fd00::/48 prefix, if they chose to have site-local addressing for stable internal communications. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 14 12:29:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21454 for ; Fri, 14 Nov 2003 12:29:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhl9-0000WM-50 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 12:29:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEHTRXr001996 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 12:29:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhl8-0000W7-U9 for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 12:29:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21396 for ; Fri, 14 Nov 2003 12:29:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKhl7-0001R8-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 12:29:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKhl7-0001R3-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 12:29:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhjl-0000J8-Tq; Fri, 14 Nov 2003 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhiq-0000IW-EV for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 12:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21372 for ; Fri, 14 Nov 2003 12:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKhio-0001QR-00 for ipv6@ietf.org; Fri, 14 Nov 2003 12:27:02 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AKhio-0001Pa-00 for ipv6@ietf.org; Fri, 14 Nov 2003 12:27:02 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 14 Nov 2003 09:26:27 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Nov 2003 09:26:30 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Nov 2003 09:26:32 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Nov 2003 09:26:30 -0800 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.3790.1069); Fri, 14 Nov 2003 09:25:58 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: SL deprecation draft Date: Fri, 14 Nov 2003 09:26:36 -0800 Message-ID: Thread-Topic: SL deprecation draft Thread-Index: AcOqPt87foIZ7MwmTvygkrcCTb/8/AAFrECg From: "Christian Huitema" To: "Bob Hinden" , Cc: "Brian E Carpenter" X-OriginalArrivalTime: 14 Nov 2003 17:25:58.0912 (UTC) FILETIME=[5E580000:01C3AAD4] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable So, what about a text such as: Several IETF documents mention site local addresses [RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, RFC3177]. These mentions should be removed if and when these documents are updated. In particular, the references to site local addresses should be removed from the revision of the Default Address Selection for Internet Protocol version 6 [RFC3484] and from the revision of the Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC3513]. -- Christian Huitema > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com] > Sent: Thursday, November 13, 2003 3:34 PM > To: ipv6@ietf.org > Cc: Brian E Carpenter; Christian Huitema > Subject: Re: SL deprecation draft >=20 > I personally don't think it is necessary to update most of these > RFCs. Specifically: >=20 > > > RFC2772, 6bone routing practise >=20 > The 6bone is being turned off. >=20 > > > RFC2894, router renumbering (an example contains FEC0) > > > RFC3111, SLP (an example contains FEC0) > > > RFC3142, TRT (an example contains FEC0) >=20 > If it's only used in an example, then I don't think an update is > required. If these documents get redone for some other reason it would be > good to change the examples. But it not worth the effort required to > recycle these documents to just remove site-local from an example. >=20 > > > RFC3177, recommendation on /48, some text about site local beeing /48 >=20 > This is only a recommendation and updating it would likely open up > Pandora's box for other changes. >=20 > > > RFC3082, Notification and Subscription for SLP, an example talks about > > > site local >=20 > Same as examples above. >=20 > > > RFC3484, default address selection >=20 > I think this would be good to update. >=20 > > > RFC3513, IPv6 addr architecture >=20 > Very important and work underway. >=20 > > > It seems to me that the main one to revisit is 3483. > >[I guess he meant 3484] > > > >=20 > So my take is that only the Address Architecture and Default Address > Selection documents need to be listed. >=20 > Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 14 13:07:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22750 for ; Fri, 14 Nov 2003 13:07:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiM2-0003NM-AO for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 13:07:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEI7YRb012970 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 13:07:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiM1-0003Mw-OH for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 13:07:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22696 for ; Fri, 14 Nov 2003 13:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiLz-00020l-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 13:07:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKiLz-00020h-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 13:07:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiLY-0003Dp-Fd; Fri, 14 Nov 2003 13:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiLH-0003CR-Sc for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 13:06:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22672 for ; Fri, 14 Nov 2003 13:06:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiLF-0001zy-00 for ipv6@ietf.org; Fri, 14 Nov 2003 13:06:45 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AKiLF-0001zv-00 for ipv6@ietf.org; Fri, 14 Nov 2003 13:06:45 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAEI6i5u014043 for ; Fri, 14 Nov 2003 11:06:44 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HOC00HOXSZ7IE@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 14 Nov 2003 11:06:43 -0700 (MST) Received: from sun.com ([129.146.11.166]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HOC006T3SZ6GG@mail.sun.net> for ipv6@ietf.org; Fri, 14 Nov 2003 11:06:43 -0700 (MST) Date: Fri, 14 Nov 2003 10:06:42 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" To: Tim Chown Cc: ipv6@ietf.org Message-id: <3FB519B2.8040802@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: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> <20031114160159.GD19013@login.ecs.soton.ac.uk> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Tim Chown wrote: >I think we will see a lot of people using fd00::/48 or fd00::/64 for >their sites/links purely becuase it's less effort to type. > > If this is the case, what will we have gained from fec0::/48? One year of extremely heated discussion, appeal, gazillions of email, just to replace the prefix fec0 by fd00 ? - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 14 13:57:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24439 for ; Fri, 14 Nov 2003 13:57:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKj89-0007z7-Ht for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 13:57:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEIvHCj030687 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 13:57:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKj89-0007ys-A5 for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 13:57:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24401 for ; Fri, 14 Nov 2003 13:57:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKj86-0002gd-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 13:57:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKj86-0002ga-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 13:57:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKj6v-0007R9-Qk; Fri, 14 Nov 2003 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKj6D-0007QA-Ea for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 13:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24305 for ; Fri, 14 Nov 2003 13:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKj6B-0002e1-00 for ipv6@ietf.org; Fri, 14 Nov 2003 13:55:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKj6A-0002de-00 for ipv6@ietf.org; Fri, 14 Nov 2003 13:55:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAEIsZQ10193; Fri, 14 Nov 2003 10:54:35 -0800 X-mProtect: <200311141854> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBvsNCc; Fri, 14 Nov 2003 10:54:33 PST Message-ID: <3FB52688.2020701@iprg.nokia.com> Date: Fri, 14 Nov 2003 11:01:28 -0800 From: Fred 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: Alain Durand CC: Tim Chown , ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> <20031114160159.GD19013@login.ecs.soton.ac.uk> <3FB519B2.8040802@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain Durand wrote: > > > Tim Chown wrote: > >> I think we will see a lot of people using fd00::/48 or fd00::/64 for >> their sites/links purely becuase it's less effort to type. >> > If this is the case, what will we have gained from fec0::/48? > One year of extremely heated discussion, appeal, gazillions > of email, just to replace the prefix fec0 by fd00 ? I believe we have gained community realization of what is needed. Whether this took one e-mail or one gazillion will be seen as a minor detail many years down the road from now. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 14 14:44:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25965 for ; Fri, 14 Nov 2003 14:44:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjrj-0002u1-HD for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 14:44:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEJiN0H011151 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 14:44:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjrj-0002tm-Bs for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 14:44:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25931 for ; Fri, 14 Nov 2003 14:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjrg-0003IB-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 14:44:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKjrg-0003I8-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 14:44:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjrO-0002oE-C1; Fri, 14 Nov 2003 14:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjqv-0002nj-6a for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 14:43:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25912 for ; Fri, 14 Nov 2003 14:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjqs-0003HX-00 for ipv6@ietf.org; Fri, 14 Nov 2003 14:43:30 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AKjqr-0003HU-00 for ipv6@ietf.org; Fri, 14 Nov 2003 14:43:29 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AKjql-0007QZ-00 for ; Fri, 14 Nov 2003 19:43:23 +0000 Date: Fri, 14 Nov 2003 19:43:23 +0000 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <20031114194323.GA28152@fysh.org> References: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> <20031114160159.GD19013@login.ecs.soton.ac.uk> <3FB519B2.8040802@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB519B2.8040802@sun.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Alain Durand wrote: >Tim Chown wrote: >>I think we will see a lot of people using fd00::/48 or fd00::/64 for >>their sites/links purely becuase it's less effort to type. >> >If this is the case, what will we have gained from fec0::/48? The opportunity to avoid this numbering clash. Idiots who use fd00::/48 will clash with each other, but the rest of us avoid clashes with each other and with the idiots. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 14 14:58:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26346 for ; Fri, 14 Nov 2003 14:58:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKk4k-0004Ku-DR for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 14:57:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEJvofp016669 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 14:57:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKk4k-0004Km-82 for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 14:57:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26312 for ; Fri, 14 Nov 2003 14:57:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKk4h-0003Sw-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 14:57:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKk4h-0003Ss-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 14:57:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKk3x-00048I-Bg; Fri, 14 Nov 2003 14:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKk3P-00047c-Un for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 14:56:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26294 for ; Fri, 14 Nov 2003 14:56:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKk3M-0003Ru-00 for ipv6@ietf.org; Fri, 14 Nov 2003 14:56:24 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AKk3M-0003Rr-00 for ipv6@ietf.org; Fri, 14 Nov 2003 14:56:24 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAEJuO5u003907 for ; Fri, 14 Nov 2003 12:56:24 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HOC005UBY1Z00@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Fri, 14 Nov 2003 12:56:24 -0700 (MST) Received: from sun.com ([129.146.11.166]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HOC00DS3Y1Y3O@mail.sun.net> for ipv6@ietf.org; Fri, 14 Nov 2003 12:56:23 -0700 (MST) Date: Fri, 14 Nov 2003 11:56:22 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" To: Zefram Cc: ipv6@ietf.org Message-id: <3FB53366.5090007@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: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> <20031114160159.GD19013@login.ecs.soton.ac.uk> <3FB519B2.8040802@sun.com> <20031114194323.GA28152@fysh.org> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Zefram wrote: >Alain Durand wrote: > > >>If this is the case, what will we have gained from fec0::/48? >> >> > >The opportunity to avoid this numbering clash. Idiots who use fd00::/48 >will clash with each other, but the rest of us avoid clashes with each >other and with the idiots. > If you look at RFC3513, site locals were defined as fec0::/10 (and not fec0::/48) so you could have done exactly what you describe. There is nothing new. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 14 20:51:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09228 for ; Fri, 14 Nov 2003 20:51:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKpb4-0004LY-7l for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 20:51:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAF1pYfr016707 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 20:51:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKpb4-0004LO-2M for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 20:51:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09198 for ; Fri, 14 Nov 2003 20:51:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKpb1-0000IQ-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 20:51:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKpb1-0000IN-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 20:51:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKpaY-0004FK-Mu; Fri, 14 Nov 2003 20:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKpZw-0004Dv-9c for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 20:50:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09177; Fri, 14 Nov 2003 20:50:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKpZt-0000He-00; Fri, 14 Nov 2003 20:50:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKpZt-0000HP-00; Fri, 14 Nov 2003 20:50:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF1noJ08641; Fri, 14 Nov 2003 17:49:50 -0800 X-mProtect: <200311150149> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLCZnxU; Fri, 14 Nov 2003 17:49:49 PST Message-ID: <3FB587DD.6060906@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:56:45 -0800 From: Fred 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: dccp@ietf.org, pmtud@ietf.org CC: Fred Templin , ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <1068827087.4798.322.camel@lap10-c703.uibk.ac.at> <20031114163817.6006E8A@coconut.itojun.org> <3FB516E7.5040702@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit BTW, one last parting thought on this subject (and then I'll shut up) is that we have perhaps an opportunity to specify the following good thing: A packetization layer should set an ECN codepoint in the packets it sends IFF it is also doing Packetization Layer Path MTU Discovery (PLPMTUD) and is not expecting to get ICMP's back from the network in response to too-large packets being dropped. I have already implied this in my document, which should hit the I-D repository soon. See: www.geocities.com/osprey67/tunnelmtu-06.txt But, perhaps this needs to be spelled out in a more general-use type of document, e.g., a per-hop behavoir (PHB) document for RFC 3168? Thanks - Fred ftemplin@iprg.nokia.com Fred Templin wrote: > I hate to say it, but frankly I think this whole PMTU business is > a bunch of hooey. We have RFCs 1191 and 1981 as the service for > packetization layers that require network level feedback, and those > packetization layers can happily continue doing what they've been > doing for the past decade or so. > > But, new packetization layers that take the example of PLPMTUD > require no feedback from the network and so they should have a > means by which to turn the network layer feedback off. This should > eventually dampen the noise from the unnecessary ICMP's as the > new packetization layers supplant the old. > > Anyway, that's my story and I'm sticking to it. > > Fred > ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 15 07:30:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06174 for ; Sat, 15 Nov 2003 07:30:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKzYf-0002Ws-J2 for ipv6-archive@odin.ietf.org; Sat, 15 Nov 2003 07:29:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFCTjaF009723 for ipv6-archive@odin.ietf.org; Sat, 15 Nov 2003 07:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKzYf-0002Wk-Bq for ipv6-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 07:29:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06127 for ; Sat, 15 Nov 2003 07:29:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKzYe-0007FM-00 for ipv6-web-archive@ietf.org; Sat, 15 Nov 2003 07:29:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKzYe-0007FJ-00 for ipv6-web-archive@ietf.org; Sat, 15 Nov 2003 07:29:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKzXy-0002R8-9m; Sat, 15 Nov 2003 07:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKzXX-0002Qp-NQ for ipv6@optimus.ietf.org; Sat, 15 Nov 2003 07:28:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06112 for ; Sat, 15 Nov 2003 07:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKzXW-0007Eq-00 for ipv6@ietf.org; Sat, 15 Nov 2003 07:28:34 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKzXW-0007EW-00 for ipv6@ietf.org; Sat, 15 Nov 2003 07:28:34 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAFCS1111635 for ; Sat, 15 Nov 2003 14:28:02 +0200 Date: Sat, 15 Nov 2003 14:28:01 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: draft-hain-templin-ipv6-localcomm-03 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, well, the document seems like to completely concentrate on an addressing-based solution model.. which it probably should not. Anyone even glancing at the document can be 100% sure of this. Or was it only supposed to be agnostic of whether local-use addressing was needed? There's a difference there.. So, I agree 100% with Erik's earlier comments on the "coloring" and the "background" of the document.. (I only read the beginning of the draft, got too big a headache..) substantial ----------- 1) the whole section 3.2 Maintaining Confidentiality of the Address Space is pretty much bogus. Remember, we're talking about using local communications with *IPv6*. With IPv4, you would be required to record the address prefixes in the RIR registries etc. -- but these are no longer relevant. You get one /48, put it in the registry, that's it. No exposing needed. Beyond that, all the exposing you'd do is what you choose to do yourself. If you don't want to give e.g. people the ability to traceroute through the network to learn the network properties, you can prevent that. In summary, this whole section should be removed or seriously reworded. 2) I don't see the point of section 3.3 myself: Test networks are frequently large, elaborate networks with a mix of public and private address space. Use of random unallocated space runs the risk of collision with legitimate addresses on remote networks if the test network is ever connected to the Internet. ==> what kind of test network are you talking about? why would you ever connect a test to the Internet, except through some DMZ hosts/routers etc? With IPv6, you have enough addresses to play around if you want to connect something to the net. If you don't, you can just invent something (most TAC etc. labs probably certaintly do). No magic there... Needs rewording to bring up the point better or remove.. 3) there is solutionism/assuming the addressing is the answer in many of the goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8. Intentional? 4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the text), could be removed ? 5) section 3.7 is a bit incomprehensible: 3.7 Asset Protection in Enterprise Networks Enterprise networks that protect private corporate assets (e.g., printers, faxes, robotics, sensors, etc.) require an addressing scheme that remains stable even when VPN connections from outside sites occur. ==> how on earth would VPN connections from outside disturb a stable addressing scheme?!? 6) it's no surprise that section 4 on goals presupposes an addressing-based solution. Is this intentional? In any case, the titles are: 4.1 Easy to Acquire 4.2 Stable 4.3 Multiple Link Support 4.4 Prefix Filtering and Hints to Applications 4.5 Globally Unique 4.6 Usable in the Absence of a Provider 4.7 Applicable in Managed/Unmanaged Environments 4.8 Compatible with Site Naming System 4.9 Compatible with VPN 4.10 Multiple Addressing one could generalize and reword these to: 4.1 Easy to Take to Use 4.2 Session Stability 4.3 Multiple Link Support 4.4 Application Awareness of Policy 4.5 Locality Between Multiple Sites 4.6 Usable in the Absence of a Provider 4.7 Applicable in Managed/Unmanaged Environments 4.8 Compatible with Site Naming System 4.9 Compatible with VPN (XXX: ?) 4.10 Provision for Both Local and Global Communications semi-editorial -------------- Abstract The IPv6 addressing architecture specifies global and local-use unicast addressing schemes, but provides no operational guidelines for their use. and: 1. Introduction The IPv6 addressing architecture [RFC3513] specifies global and local-use unicast addresses. Global addresses are understood to have unlimited range and may be used as the source and destination addresses in packets that originate from any point on the connected global IPv6 Internet. Local-use addresses are intended for use only within the range of a single link/site, but their specification does not address operational considerations for real-world deployment scenarios. ==> the critical local-use addressing part is to be removed before this becomes relevant, so I don't think it's appropriate to refer to these documents here. Suggest removing or serious rewording. .... . As such, the address prefixes used in each PAN should be globally unique to avoid collisions and provide a means for verifying ownership to resolve conflicts. ==> this (in 3.5) doesn't seem to be relevant to the local communications, remove? editorial --------- . Of utmost importance is that the systems on board the ship all function, ==> s/Of utmost importance is/It's of utmost importance/ -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 15 07:44:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06551 for ; Sat, 15 Nov 2003 07:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKzmc-0003s2-B0 for ipv6-archive@odin.ietf.org; Sat, 15 Nov 2003 07:44:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFCiA15014872 for ipv6-archive@odin.ietf.org; Sat, 15 Nov 2003 07:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKzmc-0003rn-4u for ipv6-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 07:44:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06505 for ; Sat, 15 Nov 2003 07:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKzmb-0007QZ-00 for ipv6-web-archive@ietf.org; Sat, 15 Nov 2003 07:44:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKzma-0007QV-00 for ipv6-web-archive@ietf.org; Sat, 15 Nov 2003 07:44:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKzmT-0003jE-TV; Sat, 15 Nov 2003 07:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKqk8-0000Hr-Uw for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 22:05:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11264; Fri, 14 Nov 2003 22:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKqk5-0001DZ-00; Fri, 14 Nov 2003 22:04:57 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1AKqk4-0001DW-00; Fri, 14 Nov 2003 22:04:57 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hAF34uIe031104; Fri, 14 Nov 2003 19:04:56 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200311150304.hAF34uIe031104@coyote.icir.org> To: Fred Templin cc: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues In-Reply-To: Message from Fred Templin of "Fri, 14 Nov 2003 17:56:45 PST." <3FB587DD.6060906@iprg.nokia.com> Date: Fri, 14 Nov 2003 19:04:56 -0800 From: Eddie Kohler Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > A packetization layer should set an ECN codepoint in > the packets it sends IFF it is also doing Packetization > Layer Path MTU Discovery (PLPMTUD) and is not > expecting to get ICMP's back from the network in > response to too-large packets being dropped. Why overload the ECN bit this way? ECN should be used to indicate end-to-end congestion control compliance. In fact RFC 3168 requires that: "... the transport protocol must be capable of reacting appropriately to the receipt of CE packets." THat's independent of MTU discovery, or at least should be pointed out. Eddie -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 16 00:03:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04822 for ; Sun, 16 Nov 2003 00:03:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALF3a-0005Ki-S8 for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 00:02:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAG52g4c020499 for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 00:02:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALF3a-0005KY-LI for ipv6-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 00:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04804 for ; Sun, 16 Nov 2003 00:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALF3X-00053g-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 00:02:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALF3X-00053c-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 00:02:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALF2v-0005Ey-9X; Sun, 16 Nov 2003 00:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALF1y-0005Bq-LZ for ipv6@optimus.ietf.org; Sun, 16 Nov 2003 00:01:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04772 for ; Sun, 16 Nov 2003 00:00:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALF1v-0004zm-00 for ipv6@ietf.org; Sun, 16 Nov 2003 00:00:59 -0500 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1ALF1u-0004xx-00 for ipv6@ietf.org; Sun, 16 Nov 2003 00:00:58 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 10E5068 for ; Sun, 16 Nov 2003 00:00:29 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 16 Nov 2003 00:00:29 -0500 Message-Id: <20031116050029.10E5068@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 9.09% | 13 | 13.20% | 110570 | osprey67@yahoo.com 10.49% | 15 | 8.87% | 74285 | brc@zurich.ibm.com 6.99% | 10 | 9.32% | 78115 | pekkas@netcore.fi 5.59% | 8 | 4.85% | 40680 | huitema@windows.microsoft.com 5.59% | 8 | 4.12% | 34495 | tjc@ecs.soton.ac.uk 4.20% | 6 | 5.10% | 42721 | moore@cs.utk.edu 4.90% | 7 | 3.61% | 30269 | alain.durand@sun.com 4.90% | 7 | 3.47% | 29091 | john.loughney@nokia.com 4.90% | 7 | 3.34% | 28000 | bob.hinden@nokia.com 2.10% | 3 | 6.09% | 51019 | narten@us.ibm.com 2.80% | 4 | 4.71% | 39484 | jinmei@isl.rdc.toshiba.co.jp 2.80% | 4 | 4.13% | 34624 | chirayu@chirayu.org 3.50% | 5 | 2.26% | 18914 | itojun@itojun.org 2.80% | 4 | 2.07% | 17331 | stephen@sprunk.org 2.80% | 4 | 1.90% | 15939 | ipv6@c753173126e0bc8b057a22829880cf26.nosense.org 2.80% | 4 | 1.63% | 13626 | itojun@iijlab.net 2.10% | 3 | 1.60% | 13419 | greg.daley@eng.monash.edu.au 2.10% | 3 | 1.46% | 12217 | ftemplin@iprg.nokia.com 2.10% | 3 | 1.41% | 11805 | vijayd@iprg.nokia.com 2.10% | 3 | 1.37% | 11461 | leifj@it.su.se 2.10% | 3 | 1.29% | 10817 | erik.nordmark@sun.com 0.70% | 1 | 2.25% | 18831 | dthaler@windows.microsoft.com 0.70% | 1 | 1.94% | 16234 | elwynd@nortelnetworks.com 1.40% | 2 | 1.04% | 8715 | kruse@ohio.edu 1.40% | 2 | 0.77% | 6444 | zefram@fysh.org 0.70% | 1 | 1.22% | 10249 | yoann.noisette@francetelecom.com 0.70% | 1 | 0.82% | 6869 | mariana.nikolova@philips.com 0.70% | 1 | 0.75% | 6270 | andrew.e.white@motorola.com 0.70% | 1 | 0.71% | 5920 | jim.bound@hp.com 0.70% | 1 | 0.68% | 5701 | gih@telstra.net 0.70% | 1 | 0.67% | 5647 | sra+ipng@hactrn.net 0.70% | 1 | 0.60% | 5011 | rbrabson@us.ibm.com 0.70% | 1 | 0.53% | 4456 | brian@innovationslab.net 0.70% | 1 | 0.53% | 4435 | alh-ietf@tndh.net 0.70% | 1 | 0.49% | 4070 | lanapoli@us.ibm.com 0.70% | 1 | 0.42% | 3541 | matthew.ford@bt.com 0.70% | 1 | 0.41% | 3426 | onoe@sm.sony.co.jp 0.70% | 1 | 0.38% | 3207 | pizza@us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 143 |100.00% | 837908 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 16 10:23:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00462 for ; Sun, 16 Nov 2003 10:23:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALOkU-0003K0-K9 for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 10:23:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAGFNcKn012769 for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 10:23:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALOkS-0003Js-Rw for ipv6-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 10:23:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00442 for ; Sun, 16 Nov 2003 10:23:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALOkQ-0005z6-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 10:23:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALOkQ-0005z3-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 10:23:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALOju-0003EE-0N; Sun, 16 Nov 2003 10:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALOjG-0003Dq-5M for ipv6@optimus.ietf.org; Sun, 16 Nov 2003 10:22:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00428 for ; Sun, 16 Nov 2003 10:22:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALOjC-0005yk-00 for ipv6@ietf.org; Sun, 16 Nov 2003 10:22:18 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1ALOjC-0005yh-00 for ipv6@ietf.org; Sun, 16 Nov 2003 10:22:18 -0500 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 8758E40FBCB for ; Sun, 16 Nov 2003 10:21:23 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id 949D88054D; Sun, 16 Nov 2003 10:21:22 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Sun, 16 Nov 2003 20:51:22 +0530 X-Sasl-Enc: L8OSY978OyrKbw/etvBIgg 1068996082 Subject: comments on unman-scenarios-03 Message-Id: <20031116152122.949D88054D@server2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Few comments on the unman-scenarios-03 draft. CP High-Level ---------- 1. None of the cases consider a dual-stack gateway that is connected to the ISP. # [Host1]----------v # [Gateway]------[Gateway]------------[ISP] # [Host2]----------^ | # | # | # [Host3]-------------------------+ Internal gateways may be IPv4-only, or dual-stack or IPv6 only. I think some general text should be mentioned about connectivity, naming, and application support in hosts that are located behind an internal gateway (IPv4-only, dual, and IPv6-only) for each of the cases. For example, in case C, if the network has an IPv4 only gateway, then it might not be possible certain local applications on the hosts behind this gateway. 2. All hosts that have static (IPv6) addresses can host servers. With that in mind, I think the text related to server applications in case A should be modified. The current text reads, ,---- | Server applications are also not a primary focus of Case A. Server | applications require DNS support, which is difficult to engineer for | clients located behind a NAT, which is likely to be present in this | case. Besides, server applications at present cater mostly to IPv4 | clients; putting up an IPv6-only server is not very attractive. `---- As long as the IPv6 host has a static address, the ease/difficulty of providing DNS support will be similar to case B or C. The other assumption regarding attractiveness will not hold true if the global scenario is that the unmanaged network is late in getting IPv6 support, and the rest (or a large part) of the world is already using IPv6. Semi-editorial -------------- 3. ,---- | Deploying servers usually requires providing each server with a | stable DNS name, and associating a global IPv4 address with that | name, whether the address be that of the server itself or that of | the router acting as a firewall or NAT. Since updating DNS is a | management task, it falls somewhat outside the scope of an unmanaged | network. On the other hand, it is also possible to use out-of-band | techniques (such as cut-and-paste into an instant message system) to | pass around the address of the target server. `---- I think for the purposes of this document, and the companion (eval) document, updating DNS should not be considered as a management task whose scope is outside the scope of an unmanaged network. In my opinion the availability of stable addresses, and broadband will actually trigger the demand to simplify the infrastructure needed to host servers in home networks. I propose s/Since updating DNS is a management task, it falls somewhat outside the scope of an unmanaged network.// 4. ,---- | As we transition to IPv6, we must meet the requirements of the | various applications, which we can summarize in the following way: | applications that used to work well with IPv4 should continue | working well during the transition; it should be possible to use | IPv6 to deploy new applications that are currently hard to deploy in | IPv4 networks; and the deployment of these IPv6 applications should | be simple and easy to manage, but the solutions should also be | robust and secure. `---- Few requirements are missing: a) During the transition applications must work well with with both IPv4 and IPv6 networks to ease application deployment. b) Interworking may have to be defined for applications that will execute on IPv4-only networks, and IPv6-only networks. (I am unable to phrase this one properly). For example, a p2p application on a IPv4 only network may want to interact with a peer on a IPv6 network. For this interworking technology, and gateways have to be developed. 3. ,---- | Client applications require global connectivity. In an IPv6 network, | we would expect the client to use a global IPv6 address, which will | have to remain stable for the duration of the client-server session. `---- The second sentence "In an IPv6 network..." seems out of place. This section is list requirements of client applications in home networks (independent of the network technology). The second sentence can probably be replaced with: "Client applications need a global address that will remain stable for the duration of the client-server session." 4. ,---- | Many servers try to look up a DNS name associated to the IP address | of the client. In an IPv4 network, this IP address will often be | allocated by the Internet service provider to the gateway, and the | corresponding PTR record will be maintained by the ISP. In many | cases, these PTR records are perfunctory, derived in an algorithmic | fashion from the IPv4 address; the main information that they | contain is the domain name of the ISP. Whether or not an equivalent | function should be provided in an IPv6 network is unclear. `---- It might help to appreciate the last sentence better, if it is mentioned that even though few servers do a reverse lookup, there are many IPv4 ISP's that do not provide reverse lookup databases. 5. Section 4.3 Naming requirements for P2P applications are not mentioned. 6. ,---- | Private conversations by one of the authors with developers of peer- | to-peer applications suggest that many would be willing to consider | an "IPv6-only" model if they can get two guarantees: | | 1) That there is no regression from IPv4, i.e. that all customers | who could participate in a peer-to-peer application using IPv4 | can also be reached by IPv6. | | 2) That IPv6 provides a solution for at least some of their hard | problems, e.g. enabling peers located behind an IPv4 NAT to | participate in a peer-to-peer application. `---- This text can be removed/reworded. Point 1, is already covered in the requirement summary in beginning of section 4. Point 2, can be reworded, and merged with the first paragraph in this section (Requirements of peer-to- peer applications). 7. [DNSOPV6] has expired, and if a new version is not going to be released, relevant parts of that draft should be moved to this document. Probably section 5.2.2 should mention that if a DNS server is being deployed in the network then it should accessible over both IPv4, and IPv6. 8. ,---- | Network level translation poses similar problems: in practice, | network level actions must be complemented by "application layer | gateways" that will rewrite references to IP addresses in the | protocol, and while these relays are not necessary for every | application, they are necessary for enough applications to make any | sort of generalized translation quite problematic; hosts may need to | be parameterized to use the translation service; and designing the | right algorithm to decide when to translate DNS requests has proven | very difficult. `---- I don't quite follow "the right algorithm to decide when to translate DNS requests". Is there any reference, or has this issue been discussed in the past? 9. ,---- | Not assuming translation services in the network appears to be both | more practical and more robust. If the market requirement for a new | device requires that it interact with both IPv4 and IPv6 hosts, we | may expect the manufacturers of these devices to program them with a | dual stack capability; in particular, we expect general purpose | systems such as personal computers to be effectively dual-stack. `---- Instead of using the words "device", "device interaction with hosts", "client", and "server applications" should be used as this section takls of these applications, The paragraph can be rephrased to : "Not assuming translation services in the network appears to be both more practical and more robust. If the market requirement for a new application requires that it interact with both IPv4 and IPv6 hosts, we may expect the developers of these applications to program them with support for both IPv4, and IPv6. Hence, the devices that are expected to run these applications will have to be dual-stack." 10. Section 5.2.2 ,---- | In Case B, the upgraded gateway will act as an IPv6 router; it | will... `---- Should it not be: "In Case B, the upgraded gateway will act either as an IPv6 router, or as a ND proxy [NDPROXY]; it will..." 11. ,---- | several solutions will be assessed in a companion memo [EVAL]. `---- -or- ,---- | Possible solutions will be compared in the evaluation draft. `---- Such instances should be removed from the text, and the purpose of the [EVAL] document should be made clear in the Introduction. 12. Section 5.2.2 It would not hurt, if it is mentioned that the the type of IPv6 connectivity for the hosts is native. 13. ,---- | There are multiple solutions, including domain name delegation. `---- What are the other solutions? 14. ,---- | A delegation of some domain name is required in order to publish the | IPv6 addresses of servers in the DNS. `---- This point is suppossed to be different for case B, and case C. I am unable to see the difference. Both the cases require a domain name delegation. 15. ,---- | - the requirement that tunneling protocols used for IPv6 access over | IPv4 be designed for secure use `---- This requirement is more of a transition mechanism requirement, and less of an application requirement. I also could not find where this requirement is discussed. The only thing I could find is a general requirement for all solutions to be secure, which is listed in section 16. 17. ,---- | The security solutions currently used in IPv4 networks include a | combination of firewall functions in the gateway, authentication and | authorization functions in the applications, encryption and | authentication services provides by IP security, Transport Layer | Security and application specific services, and host-based security | products such as anti-virus software, and host firewalls. The | applicability of these tools in IPv6 unmanaged networks will be | studied in a companion document. `---- I think this one should be mentioned upfront in the Introduction section as it will help to clarify the scope of the document. Is the document mentioned in the last sentence published? Editorial --------- 18. ,---- | There are some cases in which the "gateway" is replaced by a layer-2 | bridge. In such deployments, the hosts have direct access to the ISP | service. In order to avoid lengthy developments, we will treat these | cases as if the gateway was not present, i.e. as if each host was | connected directly to the ISP. `---- I am unsure if word developments is correctly used. Plus, the text about connected directly to the ISP is repeated. I propose to rephrase the paragraph to: "There are some cases in which the "gateway" is replaced by a layer-2 bridge. In such deployments, the hosts have direct access to the ISP service, and the gateway is assumed to be absent." 19. Modify the section titles so that the words start with upper case. 20. ,---- | The application requirements for IPv6 Unmanaged Networks fall into | three general categories: connectivity, naming, and security. | Connectivity issues include the provision of IPv6 addresses and | their quality: do hosts need global addresses, should these `---- s/The application requirements/The requirements related to applications/ I was confused when I had initially read the first sentence. I could not make out if the sentence meant requirements of the network, or the requirements of the application. 4. Section 4.4 I am a bit lost...what does collateral effect mean? :-) 5. ,---- | In order to get some clarity, we distinguish three entities involved | in the transition of an unmanaged network: the ISP (possibly | including ISP consumer premise equipment (CPE)), the home gateway, | and the hosts (computers and appliances). Each can support IPv4- | only, both IPv4 and IPv6 or IPv6-only. That gives us 27 | possibilities. `---- Reword to "In order to get some clarity, we distinguish three entities involved in the transition of an unmanaged network: the ISP, the home gateway, and the hosts (computers and appliances). Each can support IPv4-only, both IPv4 and IPv6 or IPv6-only. This gives us 27 possibilities. Note, that ISP transition may also include the transition of the ISP provided home gateway, aka, CPE (Customer Premise Equipment)." 6. We describe the most important cases. We will assume that in all cases the hosts are a combination of IPv4-only, dual stack and (perhaps) IPv6- only hosts. s/(perhaps)// 7. ,---- | In fact, we can consider three non-NAT variants: directly connected | host; gateway acting as a bridge; and gateway acting as a non-NAT IP | router. `---- s/In fact, we can consider three non-NAT variants:/There are three types of non-NAT variants:/ 8. Section names of 5.x should be made consistent with the actual case name. For example, section 5.1 should be renamed to "Case A, gateway without IPv6 support". 9. ,---- | There are two variations of this case, depending on the type of | service implemented by the gateway. In many cases, the gateway is a | direct obstacle to the deployment of IPv6, but a gateway which is | some form of bridge-mode CPE or which is a plain (neither filtering | nor NAT) router does not really fall into this category. `---- Rephrase. Just to make it a bit more clear. "There are two variations of this case, depending on the type of service implemented by the gateway. In many cases, the gateway is a direct obstacle to the deployment of IPv6. In other cases, the gateway is some form of bridge-mode CPE or a plain (neither filtering nor NAT) router." 10. ,---- | If the local gateway provides global IPv4 addresses to the local | hosts, then these hosts can individually exercise the mechanisms | described in case C, "IPv6 connectivity without provider support." | If the local gateway implements a NAT function, another type of | mechanism is needed. The mechanism to provide connectivity to peers | behind NAT should be easy to deploy, and light weight; it will have | to involve tunneling over a protocol that can easily traverse NAT, | either TCP or preferably UDP, as tunneling over TCP can result in | poor performances in case of time-outs and retransmission. If | servers are needed, these servers will in practice have to be | deployed as part of the "support infrastructure" for the peer-to- | peer network or for an IPv6-based service; economic reality implies | that the cost of running these servers should be as low as possible. `---- The lines starting from "If servers are needed..." should be moved to 10.1.1. I am not sure what they are suppossed to convey. Maybe they can be removed. 11. ,---- | problems: first, one must develop relays for all applications; | second, one must develop a management infrastructure to provision | the host with the addresses of the relays; in addition, the | application may have to be modified if one wants to use the relay `---- s/; in addition/, and third/ 12. s/peer to peer/peer-to-peer/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 16 14:01:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03873 for ; Sun, 16 Nov 2003 14:01:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALS8e-0001eU-HB for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 14:00:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAGJ0mUp006344 for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 14:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALS8e-0001eF-9H for ipv6-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 14:00:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03837 for ; Sun, 16 Nov 2003 14:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALS8b-0000aC-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 14:00:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALS8b-0000a9-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 14:00:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALS7x-0001UG-0L; Sun, 16 Nov 2003 14:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALS7g-0001TO-GQ for ipv6@optimus.ietf.org; Sun, 16 Nov 2003 13:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03806 for ; Sun, 16 Nov 2003 13:59:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALS7e-0000Yl-00 for ipv6@ietf.org; Sun, 16 Nov 2003 13:59:46 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1ALS7d-0000Yg-00 for ipv6@ietf.org; Sun, 16 Nov 2003 13:59:45 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAGIxPs10318; Sun, 16 Nov 2003 19:59:30 +0100 Message-ID: <3FB7C90D.3030407@it.su.se> Date: Sun, 16 Nov 2003 19:59:25 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Christian Huitema CC: Bob Hinden , ipv6@ietf.org, Brian E Carpenter Subject: Re: SL deprecation draft References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Huitema wrote: | So, what about a text such as: | | Several IETF documents mention site local addresses [RFC2772, RFC2894, | RFC3082, RFC3111, RFC3142, RFC3177]. These mentions should be removed if | and when these documents are updated. In particular, the references to | site local addresses should be removed from the revision of the Default | Address Selection for Internet Protocol version 6 [RFC3484] and from the | revision of the Internet Protocol Version 6 (IPv6) Addressing | Architecture [RFC3513]. | s/should/MUST/g imo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/t8kN8Jx8FtbMZncRAvbMAKCgEZaxt/CivawcJ0MUOwDNSXR/yQCgj82r dTjfGEC01X5FlziSw5FHAP0= =TRWv -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 16 17:19:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09063 for ; Sun, 16 Nov 2003 17:19:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALVEj-0008ED-8y for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 17:19:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAGMJHFa031623 for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 17:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALVEj-0008Dy-4Z for ipv6-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 17:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08991 for ; Sun, 16 Nov 2003 17:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALVEg-0003t6-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 17:19:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALVEg-0003t3-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 17:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALVDW-00082g-DW; Sun, 16 Nov 2003 17:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALVCj-00082J-FI for ipv6@optimus.ietf.org; Sun, 16 Nov 2003 17:17:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08948 for ; Sun, 16 Nov 2003 17:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALVCh-0003rk-00 for ipv6@ietf.org; Sun, 16 Nov 2003 17:17:11 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1ALVCg-0003rh-00 for ipv6@ietf.org; Sun, 16 Nov 2003 17:17:10 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAGMH9x01516 for ; Sun, 16 Nov 2003 23:17:09 +0100 Message-ID: <3FB7F765.4000208@it.su.se> Date: Sun, 16 Nov 2003 23:17:09 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 CC: ipv6@ietf.org Subject: Re: comments on draft-hain-templin-ipv6-localcomm-03.txt References: <3FB2F973.3FD8DB57@motorola.com> In-Reply-To: <3FB2F973.3FD8DB57@motorola.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | An unadministered PI scheme that generated unique prefixes would satisfy the | first 2 requirements. However, allowing such addresses to be globally | routeable has two drawbacks: | - affects global routing tables, possibly badly | - raises 'approximately unique' requirement to 'unique' The global-routing-table-size argument crops up often. Could someone produce a link to a document which explains exactly what the problem is (I know what the problem is believed to be) and why it is considered a biggie. I have heard figures to the effect that current usage of v4 PI translated into v6 PI would require on the order of 1G memory in bgp routers. I just can't figure out why 1G memory is considered a lot in this game - my graphics card will probably have next to that much in a couple of years and I haven't bought a pc with less memory for a couple of years now... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/t/dl8Jx8FtbMZncRAuuUAJ4sBQlnsMir1XJP4z80ESCkYyW84QCeLymT +iv0T062VwPMbZP9B8BdP7w= =9Y7v -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 16 20:47:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14684 for ; Sun, 16 Nov 2003 20:47:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALYUG-0006gF-LH for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 20:47:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAH1lWgD025673 for ipv6-archive@odin.ietf.org; Sun, 16 Nov 2003 20:47:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALYUG-0006g0-Fg for ipv6-web-archive@optimus.ietf.org; Sun, 16 Nov 2003 20:47:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14654 for ; Sun, 16 Nov 2003 20:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALYUE-0006Gd-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 20:47:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALYUD-0006Ga-00 for ipv6-web-archive@ietf.org; Sun, 16 Nov 2003 20:47:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALYTl-0006bW-NA; Sun, 16 Nov 2003 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALYT1-0006ax-TY for ipv6@optimus.ietf.org; Sun, 16 Nov 2003 20:46:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14616 for ; Sun, 16 Nov 2003 20:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALYSz-0006FI-00 for ipv6@ietf.org; Sun, 16 Nov 2003 20:46:13 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1ALYSy-0006FE-00 for ipv6@ietf.org; Sun, 16 Nov 2003 20:46:12 -0500 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id 593CF41FE42 for ; Sun, 16 Nov 2003 20:46:11 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id A266F77783; Sun, 16 Nov 2003 20:46:10 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: ipv6@ietf.org Date: Mon, 17 Nov 2003 07:16:10 +0530 X-Sasl-Enc: ZaBBR8BTW3dFrhp9sCUJYg 1069033570 Subject: Re: comments on unman-scenarios-03 References: <20031116152122.949D88054D@server2.messagingengine.com> In-Reply-To: <20031116152122.949D88054D@server2.messagingengine.com> Message-Id: <20031117014610.A266F77783@server2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please ignore. I was probably too tired to notice the incorrect "To" address while sending it. The mail has now been sent to its correct destination. CP On Sun, 16 Nov 2003 20:51:22 +0530, "Chirayu Patel" said: > Hello, > > Few comments on the unman-scenarios-03 draft. > > CP > > > High-Level > ---------- > > 1. > > None of the cases consider a dual-stack gateway that is connected > to the ISP. > > # [Host1]----------v > # [Gateway]------[Gateway]------------[ISP] > # [Host2]----------^ | > # | > # | > # [Host3]-------------------------+ > > Internal gateways may be IPv4-only, or dual-stack or IPv6 only. > > I think some general text should be mentioned about connectivity, naming, > and application support in hosts that are located behind an internal > gateway (IPv4-only, dual, and IPv6-only) for each of the cases. > > For example, in case C, if the network has an IPv4 only gateway, then it > might not be possible certain local applications on the hosts behind > this gateway. > > 2. > > All hosts that have static (IPv6) addresses can host servers. With that > in mind, I think the text related to server applications in case A should > be modified. > > The current text reads, > > ,---- > | Server applications are also not a primary focus of Case A. Server > | applications require DNS support, which is difficult to engineer for > | clients located behind a NAT, which is likely to be present in this > | case. Besides, server applications at present cater mostly to IPv4 > | clients; putting up an IPv6-only server is not very attractive. > `---- > > As long as the IPv6 host has a static address, the ease/difficulty of > providing DNS support will be similar to case B or C. The other > assumption regarding attractiveness will not hold true if the global > scenario is that the unmanaged network is late in getting IPv6 support, > and the rest (or a large part) of the world is already using IPv6. > > > Semi-editorial > -------------- > > 3. > > ,---- > | Deploying servers usually requires providing each server with a > | stable DNS name, and associating a global IPv4 address with that > | name, whether the address be that of the server itself or that of > | the router acting as a firewall or NAT. Since updating DNS is a > | management task, it falls somewhat outside the scope of an unmanaged > | network. On the other hand, it is also possible to use out-of-band > | techniques (such as cut-and-paste into an instant message system) to > | pass around the address of the target server. > `---- > > I think for the purposes of this document, and the companion (eval) > document, updating DNS should not be considered as a management task > whose scope is outside the scope of an unmanaged network. In my opinion > the availability of stable addresses, and broadband will actually > trigger the demand to simplify the infrastructure needed to host servers > in home networks. > > I propose s/Since updating DNS is a management task, it falls somewhat > outside the scope of an unmanaged network.// > > 4. > > ,---- > | As we transition to IPv6, we must meet the requirements of the > | various applications, which we can summarize in the following way: > | applications that used to work well with IPv4 should continue > | working well during the transition; it should be possible to use > | IPv6 to deploy new applications that are currently hard to deploy in > | IPv4 networks; and the deployment of these IPv6 applications should > | be simple and easy to manage, but the solutions should also be > | robust and secure. > `---- > > Few requirements are missing: > > a) During the transition applications must work well with with both > IPv4 and IPv6 networks to ease application deployment. > > b) Interworking may have to be defined for applications that will > execute on IPv4-only networks, and IPv6-only networks. (I am unable > to phrase this one properly). For example, a p2p application on a > IPv4 only network may want to interact with a peer on a IPv6 > network. For this interworking technology, and gateways have to be > developed. > > 3. > > ,---- > | Client applications require global connectivity. In an IPv6 network, > | we would expect the client to use a global IPv6 address, which will > | have to remain stable for the duration of the client-server session. > `---- > > The second sentence "In an IPv6 network..." seems out of place. This > section is list requirements of client applications in home networks > (independent of the network technology). The second sentence can probably > be replaced with: > > "Client applications need a global address that will remain stable for > the duration of the client-server session." > > 4. > > ,---- > | Many servers try to look up a DNS name associated to the IP address > | of the client. In an IPv4 network, this IP address will often be > | allocated by the Internet service provider to the gateway, and the > | corresponding PTR record will be maintained by the ISP. In many > | cases, these PTR records are perfunctory, derived in an algorithmic > | fashion from the IPv4 address; the main information that they > | contain is the domain name of the ISP. Whether or not an equivalent > | function should be provided in an IPv6 network is unclear. > `---- > > It might help to appreciate the last sentence better, if it is mentioned > that even though few servers do a reverse lookup, there are many IPv4 > ISP's that do not provide reverse lookup databases. > > 5. Section 4.3 > > Naming requirements for P2P applications are not mentioned. > > 6. > > ,---- > | Private conversations by one of the authors with developers of peer- > | to-peer applications suggest that many would be willing to consider > | an "IPv6-only" model if they can get two guarantees: > | > | 1) That there is no regression from IPv4, i.e. that all customers > | who could participate in a peer-to-peer application using IPv4 > | can also be reached by IPv6. > | > | 2) That IPv6 provides a solution for at least some of their hard > | problems, e.g. enabling peers located behind an IPv4 NAT to > | participate in a peer-to-peer application. > `---- > > This text can be removed/reworded. Point 1, is already covered in the > requirement summary in beginning of section 4. Point 2, can be reworded, > and merged with the first paragraph in this section (Requirements of > peer-to- > peer applications). > > 7. [DNSOPV6] has expired, and if a new version is not going to be > released, relevant parts of that draft should be moved to this > document. Probably section 5.2.2 should mention that if a DNS server > is being deployed in the network then it should accessible over both > IPv4, and IPv6. > > 8. > > ,---- > | Network level translation poses similar problems: in practice, > | network level actions must be complemented by "application layer > | gateways" that will rewrite references to IP addresses in the > | protocol, and while these relays are not necessary for every > | application, they are necessary for enough applications to make any > | sort of generalized translation quite problematic; hosts may need to > | be parameterized to use the translation service; and designing the > | right algorithm to decide when to translate DNS requests has proven > | very difficult. > `---- > > I don't quite follow "the right algorithm to decide when to translate > DNS requests". Is there any reference, or has this issue been discussed > in the past? > > 9. > > ,---- > | Not assuming translation services in the network appears to be both > | more practical and more robust. If the market requirement for a new > | device requires that it interact with both IPv4 and IPv6 hosts, we > | may expect the manufacturers of these devices to program them with a > | dual stack capability; in particular, we expect general purpose > | systems such as personal computers to be effectively dual-stack. > `---- > > Instead of using the words "device", "device interaction with hosts", > "client", and "server applications" should be used as this section takls > of these applications, The paragraph can be rephrased to : > > "Not assuming translation services in the network appears to be both more > practical and more robust. If the market requirement for a new > application requires that it interact with both IPv4 and IPv6 hosts, we > may expect the developers of these applications to program them with > support for both IPv4, and IPv6. Hence, the devices that are expected to > run these applications will have to be dual-stack." > > 10. Section 5.2.2 > > ,---- > | In Case B, the upgraded gateway will act as an IPv6 router; it > | will... > `---- > > Should it not be: > > "In Case B, the upgraded gateway will act either as an IPv6 router, or as > a ND proxy [NDPROXY]; it will..." > > 11. > > ,---- > | several solutions will be assessed in a companion memo [EVAL]. > `---- > > -or- > > ,---- > | Possible solutions will be compared in the evaluation draft. > `---- > > Such instances should be removed from the text, and the purpose of the > [EVAL] document should be made clear in the Introduction. > > 12. Section 5.2.2 > > It would not hurt, if it is mentioned that the the type of IPv6 > connectivity for the hosts is native. > > 13. > > ,---- > | There are multiple solutions, including domain name delegation. > `---- > > What are the other solutions? > > 14. > > ,---- > | A delegation of some domain name is required in order to publish the > | IPv6 addresses of servers in the DNS. > `---- > > This point is suppossed to be different for case B, and case C. I am > unable to see the difference. Both the cases require a domain name > delegation. > > 15. > > ,---- > | - the requirement that tunneling protocols used for IPv6 access over > | IPv4 be designed for secure use > `---- > > This requirement is more of a transition mechanism requirement, and less > of an application requirement. I also could not find where this > requirement is discussed. The only thing I could find is a general > requirement for all solutions to be secure, which is listed in section > 16. > > 17. > > ,---- > | The security solutions currently used in IPv4 networks include a > | combination of firewall functions in the gateway, authentication and > | authorization functions in the applications, encryption and > | authentication services provides by IP security, Transport Layer > | Security and application specific services, and host-based security > | products such as anti-virus software, and host firewalls. The > | applicability of these tools in IPv6 unmanaged networks will be > | studied in a companion document. > `---- > > I think this one should be mentioned upfront in the Introduction section > as it will help to clarify the scope of the document. > > Is the document mentioned in the last sentence published? > > Editorial > --------- > > 18. > > ,---- > | There are some cases in which the "gateway" is replaced by a layer-2 > | bridge. In such deployments, the hosts have direct access to the ISP > | service. In order to avoid lengthy developments, we will treat these > | cases as if the gateway was not present, i.e. as if each host was > | connected directly to the ISP. > `---- > > I am unsure if word developments is correctly used. Plus, the text about > connected directly to the ISP is repeated. I propose to rephrase the > paragraph to: > > "There are some cases in which the "gateway" is replaced by a layer-2 > bridge. In such deployments, the hosts have direct access to the ISP > service, and the gateway is assumed to be absent." > > 19. Modify the section titles so that the words start with upper case. > > 20. > > ,---- > | The application requirements for IPv6 Unmanaged Networks fall into > | three general categories: connectivity, naming, and security. > | Connectivity issues include the provision of IPv6 addresses and > | their quality: do hosts need global addresses, should these > `---- > > s/The application requirements/The requirements related to applications/ > > I was confused when I had initially read the first sentence. I could not > make out if the sentence meant requirements of the network, or the > requirements of the application. > > 4. Section 4.4 > > I am a bit lost...what does collateral effect mean? :-) > > 5. > > ,---- > | In order to get some clarity, we distinguish three entities involved > | in the transition of an unmanaged network: the ISP (possibly > | including ISP consumer premise equipment (CPE)), the home gateway, > | and the hosts (computers and appliances). Each can support IPv4- > | only, both IPv4 and IPv6 or IPv6-only. That gives us 27 > | possibilities. > `---- > > Reword to > > "In order to get some clarity, we distinguish three entities involved in > the transition of an unmanaged network: the ISP, the home gateway, and > the hosts (computers and appliances). Each can support IPv4-only, both > IPv4 and IPv6 or IPv6-only. This gives us 27 possibilities. Note, that > ISP transition may also include the transition of the ISP provided home > gateway, aka, CPE (Customer Premise Equipment)." > > 6. > > We describe the most important cases. We will assume that in all cases > the hosts are a combination of IPv4-only, dual stack and (perhaps) > IPv6- > only hosts. > > s/(perhaps)// > > 7. > > ,---- > | In fact, we can consider three non-NAT variants: directly connected > | host; gateway acting as a bridge; and gateway acting as a non-NAT IP > | router. > `---- > > s/In fact, we can consider three non-NAT variants:/There are three types > of non-NAT variants:/ > > 8. Section names of 5.x should be made consistent with the actual case > name. For example, section 5.1 should be renamed to "Case A, gateway > without IPv6 support". > > 9. > > ,---- > | There are two variations of this case, depending on the type of > | service implemented by the gateway. In many cases, the gateway is a > | direct obstacle to the deployment of IPv6, but a gateway which is > | some form of bridge-mode CPE or which is a plain (neither filtering > | nor NAT) router does not really fall into this category. > `---- > > Rephrase. Just to make it a bit more clear. > > "There are two variations of this case, depending on the type of service > implemented by the gateway. In many cases, the gateway is a direct > obstacle to the deployment of IPv6. In other cases, the gateway is some > form of bridge-mode CPE or a plain (neither filtering nor NAT) router." > > 10. > > ,---- > | If the local gateway provides global IPv4 addresses to the local > | hosts, then these hosts can individually exercise the mechanisms > | described in case C, "IPv6 connectivity without provider support." > | If the local gateway implements a NAT function, another type of > | mechanism is needed. The mechanism to provide connectivity to peers > | behind NAT should be easy to deploy, and light weight; it will have > | to involve tunneling over a protocol that can easily traverse NAT, > | either TCP or preferably UDP, as tunneling over TCP can result in > | poor performances in case of time-outs and retransmission. If > | servers are needed, these servers will in practice have to be > | deployed as part of the "support infrastructure" for the peer-to- > | peer network or for an IPv6-based service; economic reality implies > | that the cost of running these servers should be as low as possible. > `---- > > The lines starting from "If servers are needed..." should be moved to > 10.1.1. I am not sure what they are suppossed to convey. Maybe they can > be removed. > > 11. > > ,---- > | problems: first, one must develop relays for all applications; > | second, one must develop a management infrastructure to provision > | the host with the addresses of the relays; in addition, the > | application may have to be modified if one wants to use the relay > `---- > > s/; in addition/, and third/ > > 12. > > s/peer to peer/peer-to-peer/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 08:19:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10769 for ; Mon, 17 Nov 2003 08:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjHR-0005xZ-8j for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 08:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHDJ1Aw022905 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 08:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjHR-0005xK-1M for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 08:19:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10744 for ; Mon, 17 Nov 2003 08:18:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjHQ-0006Ld-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 08:19:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALjHP-0006LZ-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 08:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjGT-0005rI-R9; Mon, 17 Nov 2003 08:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjFz-0005qX-BS for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 08:17:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10681 for ; Mon, 17 Nov 2003 08:17:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjFy-0006KW-00 for ipv6@ietf.org; Mon, 17 Nov 2003 08:17:30 -0500 Received: from h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1ALjFx-0006KT-00 for ipv6@ietf.org; Mon, 17 Nov 2003 08:17:29 -0500 Received: (cpmta 274 invoked from network); 17 Nov 2003 05:17:27 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.121) with SMTP; 17 Nov 2003 05:17:27 -0800 X-Sent: 17 Nov 2003 13:17:27 GMT Message-ID: <003d01c3ad0d$4d8a1160$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> <3FB42CFF.2020105@it.su.se> Subject: Re: SL deprecation draft Date: Mon, 17 Nov 2003 15:18:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think the most basic RFC one was missed from the list: RFC1918. Especially since the NATv6 group is probably working under the presumptions that these addresses, or ones like them, still exist in IPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 08:44:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11470 for ; Mon, 17 Nov 2003 08:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjfn-0007KV-0u for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 08:44:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHDiACR028169 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 08:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjfm-0007KG-QU for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 08:44:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11438 for ; Mon, 17 Nov 2003 08:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjfl-0006eu-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 08:44:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALjfl-0006er-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 08:44:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjfe-0007GV-5q; Mon, 17 Nov 2003 08:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjfV-0007Fv-F2 for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 08:43:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11427 for ; Mon, 17 Nov 2003 08:43:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjfU-0006eW-00 for ipv6@ietf.org; Mon, 17 Nov 2003 08:43:52 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1ALjfT-0006eN-00 for ipv6@ietf.org; Mon, 17 Nov 2003 08:43:51 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAHDhGwj086968 for ; Mon, 17 Nov 2003 13:43:18 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAHDgxxC230578 for ; Mon, 17 Nov 2003 14:42:59 +0100 Received: from zurich.ibm.com (sig-9-145-171-122.de.ibm.com [9.145.171.122]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA13602 for ; Mon, 17 Nov 2003 14:42:51 +0100 Message-ID: <3FB8D033.6FE07B56@zurich.ibm.com> Date: Mon, 17 Nov 2003 14:42:11 +0100 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@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" References: <5.1.0.14.2.20031110213627.01bf4bc0@localhost> <20031114160159.GD19013@login.ecs.soton.ac.uk> <3FB519B2.8040802@sun.com> <20031114194323.GA28152@fysh.org> <3FB53366.5090007@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain Durand wrote: > > Zefram wrote: > > >Alain Durand wrote: > > > > > >>If this is the case, what will we have gained from fec0::/48? > >> > >> > > > >The opportunity to avoid this numbering clash. Idiots who use fd00::/48 > >will clash with each other, but the rest of us avoid clashes with each > >other and with the idiots. > > > If you look at RFC3513, site locals were defined as fec0::/10 (and not > fec0::/48) > so you could have done exactly what you describe. There is nothing new. There is something new: we will have given people a way to get a unique or effectively unique /48. I think Tim's implementation suggestion (the "make me a prefix" button) is a good idea, but of course it's outside IETF scope. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 10:27:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15571 for ; Mon, 17 Nov 2003 10:27:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlH1-0003eV-8w for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 10:26:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHFQhJg014033 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 10:26:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlH1-0003eG-0u for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 10:26:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15533 for ; Mon, 17 Nov 2003 10:26:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALlGx-0007mW-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 10:26:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALlGx-0007mT-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 10:26:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlGM-0003Ws-OT; Mon, 17 Nov 2003 10:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlFU-0003SB-BC for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 10:25:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15425 for ; Mon, 17 Nov 2003 10:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALlFS-0007kI-00 for ipv6@ietf.org; Mon, 17 Nov 2003 10:25:06 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1ALlFR-0007jU-00 for ipv6@ietf.org; Mon, 17 Nov 2003 10:25:05 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAHFOMGs088520; Mon, 17 Nov 2003 15:24:24 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAHFODaH187192; Mon, 17 Nov 2003 16:24:13 +0100 Received: from zurich.ibm.com (sig-9-145-171-122.de.ibm.com [9.145.171.122]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA32396; Mon, 17 Nov 2003 16:24:12 +0100 Message-ID: <3FB8E7F3.5A41C5E1@zurich.ibm.com> Date: Mon, 17 Nov 2003 16:23:31 +0100 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: EricLKlein CC: ipv6@ietf.org Subject: Re: SL deprecation draft References: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> <3FB42CFF.2020105@it.su.se> <003d01c3ad0d$4d8a1160$ec061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit While I'd personally love to declare RFC 1918 "Historic", it really is completely IPv4 specific so we have no reason to reference it. Where can I find the NATv6 group? I have a few things I'd like to say to them... Brian EricLKlein wrote: > > I think the most basic RFC one was missed from the list: RFC1918. Especially > since the NATv6 group is probably working under the presumptions that these > addresses, or ones like them, still exist in IPv6. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 14:45:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00206 for ; Mon, 17 Nov 2003 14:45:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpIh-0001Jx-9Z for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 14:44:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHJihFI005077 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 14:44:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpIg-0001Jn-A9 for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 14:44:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00164 for ; Mon, 17 Nov 2003 14:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpId-0004x3-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 14:44:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpId-0004x0-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 14:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpI2-00019x-H0; Mon, 17 Nov 2003 14:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpHu-00018c-7w for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 14:43:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00095 for ; Mon, 17 Nov 2003 14:43:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpHr-0004vk-00 for ipv6@ietf.org; Mon, 17 Nov 2003 14:43:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ALpHq-0004v6-00 for ipv6@ietf.org; Mon, 17 Nov 2003 14:43:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAHJhCQ07872; Mon, 17 Nov 2003 11:43:12 -0800 X-mProtect: <200311171943> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVccbpi; Mon, 17 Nov 2003 11:43:10 PST Message-ID: <3FB9267E.1020601@iprg.nokia.com> Date: Mon, 17 Nov 2003 11:50:22 -0800 From: Fred 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: Pekka Savola CC: ipv6@ietf.org Subject: Re: draft-hain-templin-ipv6-localcomm-03 comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >Hi, > >well, the document seems like to completely concentrate on an >addressing-based solution model.. which it probably should not. Anyone >even glancing at the document can be 100% sure of this. > >Or was it only supposed to be agnostic of whether local-use addressing was >needed? There's a difference there.. > >So, I agree 100% with Erik's earlier comments on the "coloring" and the >"background" of the document.. > I'm still waiting to see the specific comments that will correct this often-expressed wrong impression. Maybe they will appear below; I'll respond as I go and see where we end up. >(I only read the beginning of the draft, got too big a headache..) > Take some aspirin, then. >substantial >----------- > >1) the whole section 3.2 Maintaining Confidentiality of the Address Space is >pretty much bogus. Remember, we're talking about using local communications >with *IPv6*. With IPv4, you would be required to record the address >prefixes in the RIR registries etc. -- but these are no longer relevant. >You get one /48, put it in the registry, that's it. No exposing needed. > >Beyond that, all the exposing you'd do is what you choose to do yourself. >If you don't want to give e.g. people the ability to traceroute through the >network to learn the network properties, you can prevent that. > >In summary, this whole section should be removed or seriously reworded. > I disagree. Network managers should be empowered to self-select addresses to be used for internal-only communications and with no pre-arrangement with a RIR. For example, in IPv4 I know that network 15/8 is owned by HP, network 16/8 is (was?) owned by Digital Equipment Corporation, etc. But, general knowledge of this is nothing more than a burden on the party holding the registration, since they now need to concern themselves with liabilities for misuse of the RIR prefixes. In IPv6, there should be no reason for even this level of exposure if the addresses are indeed to be used only for local communications. Thus, the ability for network managers to self-select addresses would be an improvement over the existing condition for IPv4. >2) I don't see the point of section 3.3 myself: > > Test networks are frequently large, elaborate networks with a mix of > public and private address space. Use of random unallocated space > runs the risk of collision with legitimate addresses on remote > networks if the test network is ever connected to the Internet. > >==> what kind of test network are you talking about? >why would you ever connect a test to the Internet, except through some DMZ >hosts/routers etc? > >With IPv6, you have enough addresses to play around if you want to connect >something to the net. If you don't, you can just invent something (most TAC >etc. labs probably certaintly do). No magic there... > >Needs rewording to bring up the point better or remove.. > OK, how about this: "Test networks often provide a vehicle for limited experimentation with new Internetworking technologies prior to widescale deployment, but they may need to connect to the Internet to facilitate the experiment. Such experiments may entail large, elaborate networks with a mix of public and private address space, but the use of random unallocated space runs the risk of collision with legitimate addresses on remote networks." But, is this enough to warrant a new document revision? I don't think so. >3) there is solutionism/assuming the addressing is the answer in many of the >goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8. Intentional? > Please provide specific examples of text that you believe assumes a particular solution alternative, since there was no intention to dictate a particular alternative. If certain solution alternatives seem to suggest themselves based on the scenarios, then the document is doing its work - but this is NOT due to the intentional manipulation of the authors (see changelogs and acknolwedgements for the substantial community input already taken). >4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the >text), could be removed ? > This is a valid point, but I prefer to say that sections 3.6.2 and 3.5 could be consolidated rather than removing one or the other. Does this warrant another revision, though? My take is no. >5) section 3.7 is a bit incomprehensible: > >3.7 Asset Protection in Enterprise Networks > > Enterprise networks that protect private corporate assets (e.g., > printers, faxes, robotics, sensors, etc.) require an addressing > scheme that remains stable even when VPN connections from outside > sites occur. > >==> how on earth would VPN connections from outside disturb a stable >addressing scheme?!? > We are talking here about site mergers, which becomes apparent in the subsequent sentences of that paragraph. When two sites merge, ongoing local communications which were in-progress within the two seperate sites should continue without breaking when the two sites become one. The sentences you cite above are taken out of context, and the meaning seems clear enough when they are considered within the context of the entire section. >6) it's no surprise that section 4 on goals presupposes an addressing-based >solution. Is this intentional? In any case, the titles are: > >4.1 Easy to Acquire >4.2 Stable >4.3 Multiple Link Support >4.4 Prefix Filtering and Hints to Applications >4.5 Globally Unique >4.6 Usable in the Absence of a Provider >4.7 Applicable in Managed/Unmanaged Environments >4.8 Compatible with Site Naming System >4.9 Compatible with VPN >4.10 Multiple Addressing > >one could generalize and reword these to: > >4.1 Easy to Take to Use >4.2 Session Stability >4.3 Multiple Link Support >4.4 Application Awareness of Policy >4.5 Locality Between Multiple Sites >4.6 Usable in the Absence of a Provider >4.7 Applicable in Managed/Unmanaged Environments >4.8 Compatible with Site Naming System >4.9 Compatible with VPN (XXX: ?) >4.10 Provision for Both Local and Global Communications > One could always re-word, yes, but re-wording can always be done ad-inifinitum. I don't see anything in any of these suggestions that provides any beneficial clarification. >semi-editorial >-------------- > >Abstract > > The IPv6 addressing architecture specifies global and local-use > unicast addressing schemes, but provides no operational guidelines > for their use. > >and: > >1. Introduction > > The IPv6 addressing architecture [RFC3513] specifies global and > local-use unicast addresses. Global addresses are understood to have > unlimited range and may be used as the source and destination > addresses in packets that originate from any point on the connected > global IPv6 Internet. Local-use addresses are intended for use only > within the range of a single link/site, but their specification does > not address operational considerations for real-world deployment > scenarios. > >==> the critical local-use addressing part is to be removed before this >becomes relevant, so I don't think it's appropriate to refer to these >documents here. Suggest removing or serious rewording. > Update from [RFC3513] to [RFC3513(bis)] you mean? I don't see this in and of itself necessitating a document update; in fact, the role of the hain-templin document is to set the target in motion - not to track the target as it moves. >.... > >. As such, > the address prefixes used in each PAN should be globally unique to > avoid collisions and provide a means for verifying ownership to > resolve conflicts. > >==> this (in 3.5) doesn't seem to be relevant to the local communications, >remove? > This goes with the above comment on consolidating sections 3.5 and 3.6.2, but do these alone warrant a new document revision? My take is that they don't. >editorial >--------- > >. Of > utmost importance is that the systems on board the ship all function, > >==> s/Of utmost importance is/It's of utmost importance/ > Noted. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 15:07:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01978 for ; Mon, 17 Nov 2003 15:07:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpe8-0002mM-JR for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 15:06:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHK6q0d010682 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 15:06:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpe8-0002mC-9J for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 15:06:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01891 for ; Mon, 17 Nov 2003 15:06:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpe5-0005PH-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 15:06:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpe4-0005PB-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 15:06:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpdK-0002RQ-Tr; Mon, 17 Nov 2003 15:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpct-0002Q0-Lu for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 15:05:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01672; Mon, 17 Nov 2003 15:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpcq-0005MU-00; Mon, 17 Nov 2003 15:05:32 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ALpcp-0005Lo-00; Mon, 17 Nov 2003 15:05:31 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAHK50c25003; Mon, 17 Nov 2003 12:05:00 -0800 X-mProtect: <200311172005> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCQSaLe; Mon, 17 Nov 2003 12:04:59 PST Message-ID: <3FB92B9A.8020409@iprg.nokia.com> Date: Mon, 17 Nov 2003 12:12:10 -0800 From: Fred 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: Eddie Kohler CC: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <200311150304.hAF34uIe031104@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddie, A transport protocol that is smart enough to react to the receipt of CE packets should also be smart enough to figure out the size of the largest piece of data that can traverse the network without incurring fragmentation. Such a "smart transport" should be able to figure this out with *no* feedback from unreliable and untrustworthy ICMP messages from the network if the example from Packetization Layer Path MTU Discovery (PLPMTUD) is taken. So, if the ICMP's are unneeded, I believe it is desireable to have a way to turn them off. This would serve the beneficial purpose of reducing the overall congestion in the Internet as deployment of transports that don't need the ICMPs ramps up Thanks - Fred ftemplin@iprg.nokia.com Eddie Kohler wrote: >> A packetization layer should set an ECN codepoint in >> the packets it sends IFF it is also doing Packetization >> Layer Path MTU Discovery (PLPMTUD) and is not >> expecting to get ICMP's back from the network in >> response to too-large packets being dropped. >> >> > >Why overload the ECN bit this way? ECN should be used to indicate >end-to-end congestion control compliance. In fact RFC 3168 requires that: >"... the transport protocol must be capable of reacting appropriately to >the receipt of CE packets." THat's independent of MTU discovery, or at >least should be pointed out. > >Eddie > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 16:44:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07242 for ; Mon, 17 Nov 2003 16:44:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr9r-0008PT-JC for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 16:43:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHLhhKQ032323 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 16:43:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr9r-0008PG-DE for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 16:43:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07213 for ; Mon, 17 Nov 2003 16:43:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr9p-0006sS-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 16:43:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALr9p-0006sP-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 16:43:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr9C-0008CF-Lw; Mon, 17 Nov 2003 16:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr8N-0008BL-FK for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 16:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07118 for ; Mon, 17 Nov 2003 16:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr8L-0006qi-00 for ipv6@ietf.org; Mon, 17 Nov 2003 16:42:09 -0500 Received: from srexchimc2.lss.emc.com ([168.159.100.11] helo=srexchimc2.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1ALr8K-0006pw-00 for ipv6@ietf.org; Mon, 17 Nov 2003 16:42:09 -0500 Received: by srexchimc2.lss.emc.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Nov 2003 16:41:32 -0500 Message-ID: <33CE6457C7003A478381BCD0B584DEC50274139D@srmoon.eng.emc.com> From: "sasson, shuki" To: ipv6@ietf.org Subject: Implementing DNS client for support IPv6/IPv4 Date: Mon, 17 Nov 2003 16:41:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AD53.8DFFFDF5" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , 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_01C3AD53.8DFFFDF5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have been reading the RFCs related to extending DNS support = for IPv6 and I am a bit confused. I understand that there 2 types of RR that may represent IPv6 entries basically AAAA and A6. These entries will be on to of the previous type = A. On top of that from the Transition Mechanism RFC a DNS resolver may = return only the requested type as an answer. The AAAA RFC states that the all = other IPv4/IPv6 address should be returned on the additional information = field. =20 Our host is aiming on Dual Stack implementation, basically we need to implement the following 3 requests: =20 1. Give up all the addresses IPv6 or IPv4 for a name. 2. Give us all the IPv4 addresses. 3. Give us all the IPv6 addresses. =20 My questions are: 1. What QTYPE should I use in order to get all the IPv4 and IPv6 addresses A, AAAA, A6? Is that possible through one query or multiple queries are needed? 2. What QTYPE should I use in order to get all the IPv6 address AAAA or A6? Should we apply two separate queries for A6 and For AAAA? 3. What is the status of A6 since I saw an informational RFC recommending to stay away from implementing A6 RR: ftp://ftp.rfc-editor.org/in-notes/rfc3363.txt =20 =20 Thanks for your help! Shuki Sasson=20 Principal Engineer, Network Storage Group=20 EMC=B2=20 where information lives=20 Phone: 508 305 8515=20 Cell: 617 834 4258 Pager: 877 919 0794=20 Email: sasson_shuki@emc.com=20 =20 ------_=_NextPart_001_01C3AD53.8DFFFDF5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all, I have been reading the RFCs related to = extending DNS support for IPv6 and I am a bit confused.

I understand that there 2 types of RR that may = represent IPv6 entries basically AAAA and A6. These entries will be on to of the = previous type A.

On top of that from the Transition Mechanism RFC a = DNS resolver may return only the requested type as an answer. The AAAA RFC = states that the all other IPv4/IPv6 address should be returned on the = additional information field.

=A0=A0

Our host is aiming on Dual Stack implementation, = basically we need to implement the following 3 requests:

 

  1. Give up all the addresses IPv6 or IPv4 for a = name.
  2. Give us all the IPv4 = addresses.
  3. Give us all the IPv6 = addresses.

 

My questions are:

  1. What QTYPE should I use in order to get all the = IPv4 and IPv6 addresses A, AAAA, A6? Is that possible through one query = or multiple queries are needed?
  2. What QTYPE should I use in order to get all the = IPv6 address AAAA or A6? Should we apply two separate queries for A6 = and For AAAA?
  3. What is the status of A6 since I saw an = informational RFC recommending to stay away from implementing A6 RR: ftp://ftp.rfc-edi= tor.org/in-notes/rfc3363.txt

 

Thanks for your help!

Shuki Sasson
Principal Engineer, Network Storage = Group
EMC=B2
where = information lives
Phone: 508 305 8515 
Cell:     617 834 4258
Pager: 877 919 0794
Email: sasson_shuki@emc.com

 

------_=_NextPart_001_01C3AD53.8DFFFDF5-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 17:05:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08634 for ; Mon, 17 Nov 2003 17:05:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrUp-0001QB-2J for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 17:05:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHM5N6P005459 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 17:05:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrUo-0001Py-Qd for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:05:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08589 for ; Mon, 17 Nov 2003 17:05:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrUm-0007QZ-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 17:05:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrUm-0007QW-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 17:05:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrUW-0001F2-KS; Mon, 17 Nov 2003 17:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrUL-0001CI-DJ for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 17:04:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08547 for ; Mon, 17 Nov 2003 17:04:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrUJ-0007PY-00 for ipv6@ietf.org; Mon, 17 Nov 2003 17:04:51 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]) by ietf-mx with esmtp (Exim 4.12) id 1ALrUI-0007PT-00 for ipv6@ietf.org; Mon, 17 Nov 2003 17:04:50 -0500 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 729E52903C; Mon, 17 Nov 2003 23:04:49 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 773D0156E; Mon, 17 Nov 2003 23:04:47 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAHM4lCM026803; Mon, 17 Nov 2003 23:04:47 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAHM4hSJ026799; Mon, 17 Nov 2003 23:04:44 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "sasson, shuki" Cc: ipv6@ietf.org Subject: Re: Implementing DNS client for support IPv6/IPv4 References: <33CE6457C7003A478381BCD0B584DEC50274139D@srmoon.eng.emc.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 17 Nov 2003 23:04:43 +0100 In-Reply-To: <33CE6457C7003A478381BCD0B584DEC50274139D@srmoon.eng.emc.com> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit "sasson, shuki" writes: > 1. What QTYPE should I use in order to get all the IPv4 and IPv6 > addresses A, AAAA, A6? Is that possible through one query or multiple > queries are needed? I'n not really a DNS expert, but I've been hacking the adns resolver to add IPv6 support, and my conclusions are as follows: 1. Make two separate requests for A and AAAA. Preferably, send both in parallel. In theory, you could make a single request with QDCOUNT=2, but then bind (and probably other name server software as well) will refuse to answer your requests. 2. Don't bother with A6. A6 is controversial, and not needed for IPv6 support in the forseeable future. I doubt (and hope) that A6 will never be deployed. If you only want IPv4 addresses, you naturally send only one request, for A records. If you only want IPv6 addresses, you may want to send requests for both A and AAAA addresses anyway, and convert any received A records into "IPv4-mapped IPv6"-addresses to be returned to the application. Regards, /Niels -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 18:18:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13274 for ; Mon, 17 Nov 2003 18:18:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsdb-0006hF-Hg for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 18:18:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHNIV93025737 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 18:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsdb-0006gz-9x for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 18:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13246 for ; Mon, 17 Nov 2003 18:18:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsdX-00019v-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 18:18:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALsdW-00019s-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 18:18:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsd7-0006ax-Ua; Mon, 17 Nov 2003 18:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsch-0006aG-HL for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 18:17:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13223 for ; Mon, 17 Nov 2003 18:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsce-00019H-00 for ipv6@ietf.org; Mon, 17 Nov 2003 18:17:32 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1ALsce-00018p-00 for ipv6@ietf.org; Mon, 17 Nov 2003 18:17:32 -0500 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAHNH2xA015329 for ; Mon, 17 Nov 2003 15:17:02 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with SMTP id hAHNH17m237100; Mon, 17 Nov 2003 15:17:02 -0800 (PST) Message-Id: <200311172317.hAHNH17m237100@jurassic.eng.sun.com> Date: Mon, 17 Nov 2003 15:18:27 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Comments on Address Selection API draft ? To: ipv6@ietf.org Cc: erik.nordmark@sun.com, julien.laganier@sun.com, samita.chakrabarti@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9zVYllDDECWYwRr+2XZWaw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_31 SunOS 5.10 sun4u sparc Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hello: I am reposting this message to solicit working group input on the address selection API draft, as per request of the chairs. Please see the changes from last revision as indicated in the attached mail. We would like to know if folks in the wg think if this draft should be a working group item ? Thanks, -Samita ------------- Begin Forwarded Message ------------- X-Unix-From: Samita.Chakrabarti@eng.sun.com Tue Nov 4 14:02:31 2003 Date: Tue, 4 Nov 2003 14:02:19 -0800 (PST) From: Samita Chakrabarti Subject: Address Selection API draft To: ipv6@ietf.org Cc: erik.nordmark@sun.com, julien.laganier@sun.com, samita.chakrabarti@sun.com, mip6@ietf.org MIME-Version: 1.0 Content-MD5: eHxfkK7voWH0pRCTrZKT3A== X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , A revised version of Address Selection API draft, http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-02.txt has been published recently. At Vienna IETF, the working group was polled to see if this document should become a WG item - I understand that more people wanted to read the draft to make a final decision. The following updates have been made as per working group input since then: * Added comments on JAVA API which might use this draft as a guideline. (section 1) * A section on design alternatives of API (section 2) * The Address selection API draft now addresses specific destination address selection as well as source address selection. socket option is changed from IPV6_SRC_PREFERENCES to IPV6_ADDR_PREFERENCES (section 4) * Introduced new flags for altering rules of default selection of destination address scope (section 4 and 5) * Discusses application requirement to support this API draft and implementation notes (section 6 and 7) * Discusses the choice of address selection rules from RFC3484 in the context of usefulness of this API (section 8) ---------------------------------------------- Please provide comments on this draft to the ipv6@ietf.org list and to the authors (CC'ed). Since it has been identified in the IPv6 group that a API is necessary for application specific control of address selection on a rfc3484 compliant system, the authors like to close any remaining issues on the list and request the working group to take this work as a working group item. Thanks, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------------- End Forwarded Message ------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 20:38:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17644 for ; Mon, 17 Nov 2003 20:38:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALup7-0006Dt-0X for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 20:38:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI1cWhm023915 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 20:38:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALup6-0006De-Q1 for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 20:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17605 for ; Mon, 17 Nov 2003 20:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALup4-0003B5-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 20:38:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALup4-0003B2-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 20:38:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuoe-00061b-AB; Mon, 17 Nov 2003 20:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuo3-0005qg-1W for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 20:37:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17571 for ; Mon, 17 Nov 2003 20:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALuo0-0003A9-00 for ipv6@ietf.org; Mon, 17 Nov 2003 20:37:24 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ALunz-00039k-00 for ipv6@ietf.org; Mon, 17 Nov 2003 20:37:24 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAI1aqw5024019; Mon, 17 Nov 2003 17:36:52 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR03616; Mon, 17 Nov 2003 17:36:50 -0800 (PST) Date: Mon, 17 Nov 2003 17:36:50 -0800 (PST) From: Suresh Satapati To: Niels =?iso-8859-1?q?M=F6ller?= cc: "sasson, shuki" , ipv6@ietf.org Subject: Re: Implementing DNS client for support IPv6/IPv4 In-Reply-To: Message-ID: References: <33CE6457C7003A478381BCD0B584DEC50274139D@srmoon.eng.emc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > for A records. If you only want IPv6 addresses, you may want to send > requests for both A and AAAA addresses anyway, and convert any > received A records into "IPv4-mapped IPv6"-addresses to be returned to > the application. I would say, just send AAAA request if you only want IPv6 address. Do not convert A records into "IPv4-mapped IPv6"-addresses, as mentioned above. There are problems w/ using mapped addresses. Refer to: http://community.roxen.com/developers/idocs/drafts/draft-itojun-v6ops-v4mapped-harmful-02.html -- Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 21:40:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19208 for ; Mon, 17 Nov 2003 21:40:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvmX-0000ik-VJ for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 21:39:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI2dv1k002764 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 21:39:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvmX-0000iV-Gg for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 21:39:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19190 for ; Mon, 17 Nov 2003 21:39:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALvmU-0003sV-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 21:39:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALvmU-0003sS-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 21:39:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvle-0000co-6U; Mon, 17 Nov 2003 21:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvl5-0000cB-7I for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 21:38:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19180 for ; Mon, 17 Nov 2003 21:38:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALvl2-0003s5-00 for ipv6@ietf.org; Mon, 17 Nov 2003 21:38:24 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1ALvl1-0003rm-00 for ipv6@ietf.org; Mon, 17 Nov 2003 21:38:23 -0500 Received: by mercury.lss.emc.com with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Nov 2003 21:37:54 -0500 Message-ID: <33CE6457C7003A478381BCD0B584DEC5027413A2@srmoon.eng.emc.com> From: "sasson, shuki" To: "'Suresh Satapati'" , =?iso-8859-1?Q?Niels_M=F6ll?= =?iso-8859-1?Q?er?= Cc: "sasson, shuki" , ipv6@ietf.org Subject: RE: Implementing DNS client for support IPv6/IPv4 Date: Mon, 17 Nov 2003 21:37:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Suresh & Niels, the left question for me is can both IPv4 and = IPv6 addresses can be acquired by one DNS request? I know that the AAAA RFC says that the response by the DNS server = should include the IPv4 addresses in the additianal information field. Can I = rely on this? Shuki -----Original Message----- From: Suresh Satapati [mailto:satapati@cisco.com] Sent: Monday, November 17, 2003 8:37 PM To: Niels M=F6ller Cc: sasson, shuki; ipv6@ietf.org Subject: Re: Implementing DNS client for support IPv6/IPv4 > for A records. If you only want IPv6 addresses, you may want to send > requests for both A and AAAA addresses anyway, and convert any > received A records into "IPv4-mapped IPv6"-addresses to be returned = to > the application. I would say, just send AAAA request if you only want IPv6 address. Do not convert A records into "IPv4-mapped IPv6"-addresses, as = mentioned above. There are problems w/ using mapped addresses. Refer to: http://community.roxen.com/developers/idocs/drafts/draft-itojun-v6ops-v4= mapp ed-harmful-02.html -- Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 17 22:27:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20820 for ; Mon, 17 Nov 2003 22:27:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALwVx-0002tS-T7 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 22:26:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI3Qrex011116 for ipv6-archive@odin.ietf.org; Mon, 17 Nov 2003 22:26:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALwVx-0002tD-MP for ipv6-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 22:26:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20776 for ; Mon, 17 Nov 2003 22:26:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALwVu-0004a8-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 22:26:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALwVu-0004a5-00 for ipv6-web-archive@ietf.org; Mon, 17 Nov 2003 22:26:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALwV9-0002cB-Ag; Mon, 17 Nov 2003 22:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALwUC-0002bK-3M for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 22:25:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20725 for ; Mon, 17 Nov 2003 22:24:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALwU8-0004YK-00 for ipv6@ietf.org; Mon, 17 Nov 2003 22:25:00 -0500 Received: from c211-30-118-161.carlnfd2.nsw.optusnet.com.au ([211.30.118.161] helo=drugs.dv.isc.org) by ietf-mx with esmtp (Exim 4.12) id 1ALwU7-0004YH-00 for ipv6@ietf.org; Mon, 17 Nov 2003 22:25:00 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hAI3OjDW011199; Tue, 18 Nov 2003 14:24:45 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200311180324.hAI3OjDW011199@drugs.dv.isc.org> To: "sasson, shuki" Cc: "'Suresh Satapati'" , =?iso-8859-1?Q?Niels_M=F6ll?= =?iso-8859-1?Q?er?= , ipv6@ietf.org From: Mark.Andrews@isc.org Subject: Re: Implementing DNS client for support IPv6/IPv4 In-reply-to: Your message of "Mon, 17 Nov 2003 21:37:44 CDT." <33CE6457C7003A478381BCD0B584DEC5027413A2@srmoon.eng.emc.com> Date: Tue, 18 Nov 2003 14:24:45 +1100 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Thanks Suresh & Niels, the left question for me is can both IPv4 and IPv6 > addresses can be acquired by one DNS request? > I know that the AAAA RFC says that the response by the DNS server should > include the IPv4 addresses in the additianal information field. Can I rely > on this? Actually RFC3565 does NOT say to return A records in the additional section in response to AAAA queries. It does say that both AAAA and A records should be returned if additional section processing would have previously returned just A record Mark > > Shuki -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 02:34:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08673 for ; Tue, 18 Nov 2003 02:34:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0Mp-0006Ge-NM for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 02:33:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI7Xh2c024093 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 02:33:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0Mp-0006GW-9b for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 02:33:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08627 for ; Tue, 18 Nov 2003 02:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM0Ml-0007Wj-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 02:33:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM0Ml-0007Wg-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 02:33:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0LC-00060V-Gw; Tue, 18 Nov 2003 02:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0Ke-0005yP-QJ for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 02:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08565 for ; Tue, 18 Nov 2003 02:31:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM0Ka-0007V8-00 for ipv6@ietf.org; Tue, 18 Nov 2003 02:31:24 -0500 Received: from h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AM0Ka-0007V5-00 for ipv6@ietf.org; Tue, 18 Nov 2003 02:31:24 -0500 Received: (cpmta 3348 invoked from network); 17 Nov 2003 23:31:23 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.114) with SMTP; 17 Nov 2003 23:31:23 -0800 X-Sent: 18 Nov 2003 07:31:23 GMT Message-ID: <00b001c3ada6$200fab20$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: Subject: Re: SL deprecation draft Date: Tue, 18 Nov 2003 09:32:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > While I'd personally love to declare RFC 1918 "Historic", it really is > completely IPv4 specific so we have no reason to reference it. I would agree that RFC1918 is pure v4 issue, but we will need take into account that when these IPv4 networks are connected as part of IPv6 networks we could get flooded with a lot of the ::10.x.x.x addresses that are supposed to be "site local" under IPv4, but are now neither site local nor unique under IPv6. This is where we need to put in text in the Depriciation document, othewise we will end up with a lot of congestion and leakage from what used to be behind NATv4 or just local RFC1918 local site addresses. > > Where can I find the NATv6 group? I have a few things I'd like to > say to them... It looks like v6ops@ops.ietf.org or ngtrans@ops.ietf.org the group working on the NAT issues. > > Brian > > EricLKlein wrote: > > > > I think the most basic RFC one was missed from the list: RFC1918. Especially > > since the NATv6 group is probably working under the presumptions that these > > addresses, or ones like them, still exist in IPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 05:33:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13480 for ; Tue, 18 Nov 2003 05:33:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3Af-0001iP-Ve for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:33:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIAXL46006587 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3Af-0001iA-QW for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13426 for ; Tue, 18 Nov 2003 05:33:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3Ac-0002GA-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:33:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM3Ab-0002G7-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:33:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM39P-0001HO-7z; Tue, 18 Nov 2003 05:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM39C-0001Gz-Dh for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 05:31:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13380 for ; Tue, 18 Nov 2003 05:31:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM398-0002Ej-00 for ipv6@ietf.org; Tue, 18 Nov 2003 05:31:46 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM398-0002E7-00 for ipv6@ietf.org; Tue, 18 Nov 2003 05:31:46 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIAV9f17498; Tue, 18 Nov 2003 12:31:09 +0200 Date: Tue, 18 Nov 2003 12:31:09 +0200 (EET) From: Pekka Savola To: Tim Chown cc: ipv6@ietf.org Subject: Re: IPv4 compatible deprecation? (addr-arch-v4) In-Reply-To: <20031118102453.GE18738@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 18 Nov 2003, Tim Chown wrote: > If we want to deprecate IPv4-compatible addressing, then we need to look > at section 2.5.5 of the addressing architecture document that was > re-released with site local updates last month: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt [...] > If a separate deprecation document is required as per site local deprecation > I would be happy to author/help on that. I don't think compatible addresses are as contentious as site-local addresses, so I believe we can do without a separate deprecation document :-) -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 05:41:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13680 for ; Tue, 18 Nov 2003 05:41:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3I1-0002d7-QB for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:40:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIAevFa010103 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:40:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3I1-0002cs-Hx for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:40:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13662 for ; Tue, 18 Nov 2003 05:40:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3Hx-0002LL-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:40:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM3Hx-0002Kd-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:40:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3GA-0002Gy-Qz; Tue, 18 Nov 2003 05:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3Fo-0002Fr-9q for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 05:38:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13573 for ; Tue, 18 Nov 2003 05:38:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3Fk-0002JE-00 for ipv6@ietf.org; Tue, 18 Nov 2003 05:38:36 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3Fk-0002JA-00 for ipv6@ietf.org; Tue, 18 Nov 2003 05:38:36 -0500 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 KAA27741 for ; Tue, 18 Nov 2003 10:38:36 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA09341 for ; Tue, 18 Nov 2003 10:38:36 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIAca419201 for ipv6@ietf.org; Tue, 18 Nov 2003 10:38:36 GMT Date: Tue, 18 Nov 2003 10:38:36 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv4 compatible deprecation? (addr-arch-v4) Message-ID: <20031118103836.GJ18738@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20031118102453.GE18738@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Nov 18, 2003 at 12:31:09PM +0200, Pekka Savola wrote: > > I don't think compatible addresses are as contentious as site-local > addresses, so I believe we can do without a separate deprecation document > :-) I agree, but a) It's a question we have to ask b) We might want to look back in 4-5 years to check why we did it. It would only be a one-pager, almost... :) Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 06:13:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14482 for ; Tue, 18 Nov 2003 06:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3n5-0004Ki-En for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 06:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBD3I4016650 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 06:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3n5-0004KT-9I for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 06:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14449 for ; Tue, 18 Nov 2003 06:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3n1-0002gf-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 06:12:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM3n0-0002gX-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 06:12:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3m6-00041r-P9; Tue, 18 Nov 2003 06:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3lf-0003yr-N1 for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 06:11:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14363 for ; Tue, 18 Nov 2003 06:11:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3lb-0002eu-00 for ipv6@ietf.org; Tue, 18 Nov 2003 06:11:31 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AM3lb-0002eb-00 for ipv6@ietf.org; Tue, 18 Nov 2003 06:11:31 -0500 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 hAIBB1V22626; Tue, 18 Nov 2003 03:11:01 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAIBFJtX014917 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Nov 2003 03:15:23 -0800 Message-ID: <3FB9FE19.60604@innovationslab.net> Date: Tue, 18 Nov 2003 06:10:17 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: ipv6@ietf.org Subject: Re: IPv4 compatible deprecation? (addr-arch-v4) References: <20031118102453.GE18738@login.ecs.soton.ac.uk> In-Reply-To: <20031118102453.GE18738@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [wg co-chair hat off] What about their use in the basic socket API (rfc 3493)? Brian Tim Chown wrote: > Hi, > > A discussion on v6ops made me realise that while I thought we were > deprecating IPv4 compatible addresses, this actually isn't the case. > I have a feeling many people have assumed their use is "deprecated" > but this isn't formally documented? > > IPv4 compatibles have now been removed from the latest update of the > Basic Transition Mechanisms document that is just going through v6ops: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt > > If we want to deprecate IPv4-compatible addressing, then we need to look > at section 2.5.5 of the addressing architecture document that was > re-released with site local updates last month: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt > > We should catch this one while the text is being updated for site locals. > We would presumably update the text in a similar way to the site local > text update to section 2.5.7. > > If a separate deprecation document is required as per site local deprecation > I would be happy to author/help on that. For reference, the site local > deprecation is defined here: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt > > This deprecation would not affect mapped addresses. > > Tim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 06:29:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16328 for ; Tue, 18 Nov 2003 06:29:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM42Z-0005Nl-Nh for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 06:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBT3GI020683 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 06:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM42Z-0005NW-Jf for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 06:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16277 for ; Tue, 18 Nov 2003 06:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM42V-00036o-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 06:28:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM42V-00036l-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 06:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM41a-000582-B1; Tue, 18 Nov 2003 06:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM414-00057a-P6 for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 06:27:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16039 for ; Tue, 18 Nov 2003 06:27:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM410-00033n-00 for ipv6@ietf.org; Tue, 18 Nov 2003 06:27:26 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM410-00033Y-00 for ipv6@ietf.org; Tue, 18 Nov 2003 06:27:26 -0500 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 LAA29584 for ; Tue, 18 Nov 2003 11:27:20 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA13415 for ; Tue, 18 Nov 2003 11:27:19 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIBRJu20654 for ipv6@ietf.org; Tue, 18 Nov 2003 11:27:19 GMT Date: Tue, 18 Nov 2003 11:27:19 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv4 compatible deprecation? (addr-arch-v4) Message-ID: <20031118112719.GX18738@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20031118102453.GE18738@login.ecs.soton.ac.uk> <3FB9FE19.60604@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB9FE19.60604@innovationslab.net> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Good point, section 6.2 would need massaging on the next update of this spec. I'll run a check against other documents. Tim On Tue, Nov 18, 2003 at 06:10:17AM -0500, Brian Haberman wrote: > [wg co-chair hat off] > > What about their use in the basic socket API (rfc 3493)? > > Brian > > Tim Chown wrote: > > >Hi, > > > >A discussion on v6ops made me realise that while I thought we were > >deprecating IPv4 compatible addresses, this actually isn't the case. > >I have a feeling many people have assumed their use is "deprecated" > >but this isn't formally documented? > > > >IPv4 compatibles have now been removed from the latest update of the > >Basic Transition Mechanisms document that is just going through v6ops: > >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt > > > >If we want to deprecate IPv4-compatible addressing, then we need to look > >at section 2.5.5 of the addressing architecture document that was > >re-released with site local updates last month: > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt > > > >We should catch this one while the text is being updated for site locals. > >We would presumably update the text in a similar way to the site local > >text update to section 2.5.7. > > > >If a separate deprecation document is required as per site local > >deprecation > >I would be happy to author/help on that. For reference, the site local > >deprecation is defined here: > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt > > > >This deprecation would not affect mapped addresses. > > > >Tim > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 08:28:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20150 for ; Tue, 18 Nov 2003 08:28:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM5uF-00048S-Ve for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 08:28:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIDSZVF015890 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 08:28:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM5uF-00048D-NU for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 08:28:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20117 for ; Tue, 18 Nov 2003 08:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM5uE-0005BA-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 08:28:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM5uE-0005B4-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 08:28:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM5sj-0003uQ-T7; Tue, 18 Nov 2003 08:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM5sA-0003tj-WE for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 08:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20059 for ; Tue, 18 Nov 2003 08:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM5s9-00058C-00 for ipv6@ietf.org; Tue, 18 Nov 2003 08:26:25 -0500 Received: from h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AM5s9-000585-00 for ipv6@ietf.org; Tue, 18 Nov 2003 08:26:25 -0500 Received: (cpmta 12992 invoked from network); 18 Nov 2003 05:26:22 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.115) with SMTP; 18 Nov 2003 05:26:22 -0800 X-Sent: 18 Nov 2003 13:26:22 GMT Message-ID: <002301c3add7$b7521690$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <20031118102453.GE18738@login.ecs.soton.ac.uk> <3FB9FE19.60604@innovationslab.net> <20031118112719.GX18738@login.ecs.soton.ac.uk> <20031118113352.GA6467@sverresborg.uninett.no> Subject: Re: IPv4 compatible deprecation? (addr-arch-v4) Date: Tue, 18 Nov 2003 15:27:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stig Venaas wrote: > I don't think RFC 3493 is a problem. I had a quick look, and all I can > find is that if getnameinfo() is passed a compatible address, it's > supposed to extract the IPv4 address and do a lookup on that. > > That it describes what should happen when passed a compatible address, > doesn't prevent deprecating it I think. Don't think it needs to be > updated. My concern is what happens when it is passed an RFC1918 site local address (10..., 127... etc) these should not be passing these on, the look for these should be hardcoded to not route them. Otherwise we will have many leaks onto the public network. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 10:48:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26584 for ; Tue, 18 Nov 2003 10:48:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM857-0003OX-L5 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 10:47:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIFlv6s013033 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 10:47:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM857-0003Nk-EB for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 10:47:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26569 for ; Tue, 18 Nov 2003 10:47:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM855-0007DC-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 10:47:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM854-0007D9-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 10:47:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7sc-0002Om-8E; Tue, 18 Nov 2003 10:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7rw-0002M8-0M for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 10:34:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25930 for ; Tue, 18 Nov 2003 10:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7rt-0006zA-00 for ipv6@ietf.org; Tue, 18 Nov 2003 10:34:17 -0500 Received: from usea-naimss1.unisys.com ([192.61.61.103]) by ietf-mx with esmtp (Exim 4.12) id 1AM7rs-0006ys-00 for ipv6@ietf.org; Tue, 18 Nov 2003 10:34:17 -0500 Received: from usea-nagw3.na.uis.unisys.com ([129.224.72.20]unverified) by 192.61.61.103 with InterScan Messaging Security Suite; Tue, 18 Nov 2003 09:29:30 -0600 Received: from usea-nagw3.na.uis.unisys.com ([129.224.72.55]) by usea-nagw3.na.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Nov 2003 09:27:01 -0600 Received: from USRV-EXCH2.na.uis.unisys.com ([192.61.245.210]) by usrv-exch3.na.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Nov 2003 09:26:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: SL deprecation draft Date: Tue, 18 Nov 2003 09:26:52 -0600 Message-ID: Thread-Topic: SL deprecation draft Thread-Index: AcOq1L3gjH9d3WtpQT+ZmjIgPRcZqADDvZCw From: "Sellers, Julian P" To: "Christian Huitema" Cc: X-OriginalArrivalTime: 18 Nov 2003 15:27:01.0894 (UTC) FILETIME=[6A007A60:01C3ADE8] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable (Editorial) In the suggested paragraph, the urgent matter (revising 3484 and 3513) = is presented as following from the less significant matter expressed in = the first two sentences. I would put it like this: References to site local addresses should be removed as soon as = practical from Default Address Selection for Internet Protocol version 6 = (IPv6) [RFC3484] and from the revision of Internet Protocol Version 6 = (IPv6) Addressing Architecture [RFC3513]. Incidental references to site = local addresses should be removed from other IETF documents if and when = they are updated. These documents include [RFC2772, RFC2894, RFC3082, = RFC3111, RFC3142, RFC3177]. Julian >-----Original Message----- >From: Christian Huitema [mailto:huitema@windows.microsoft.com] >Sent: Friday, November 14, 2003 11:27 AM >To: Bob Hinden; ipv6@ietf.org >Cc: Brian E Carpenter >Subject: RE: SL deprecation draft > > >So, what about a text such as: > >Several IETF documents mention site local addresses [RFC2772, RFC2894, >RFC3082, RFC3111, RFC3142, RFC3177]. These mentions should be=20 >removed if >and when these documents are updated. In particular, the references to >site local addresses should be removed from the revision of the Default >Address Selection for Internet Protocol version 6 [RFC3484]=20 >and from the >revision of the Internet Protocol Version 6 (IPv6) Addressing >Architecture [RFC3513]. > >-- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 12:37:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03163 for ; Tue, 18 Nov 2003 12:37:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9mV-0003Fi-3f for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 12:36:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIHap8c012498 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 12:36:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9mU-0003FV-SN for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 12:36:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03114 for ; Tue, 18 Nov 2003 12:36:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9mT-0001ny-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 12:36:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM9mS-0001nN-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 12:36:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9kk-0002uV-LO; Tue, 18 Nov 2003 12:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9k5-0002tW-CC for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 12:34:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03025 for ; Tue, 18 Nov 2003 12:34:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9k3-0001l6-00 for ipv6@ietf.org; Tue, 18 Nov 2003 12:34:19 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AM9k3-0001kK-00 for ipv6@ietf.org; Tue, 18 Nov 2003 12:34:19 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 09:33:33 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 Nov 2003 09:33:49 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Nov 2003 09:33:47 -0800 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); Tue, 18 Nov 2003 09:33:25 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 09:32:49 -0800 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.3790.1069); Tue, 18 Nov 2003 09:33:46 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: SL deprecation draft Date: Tue, 18 Nov 2003 09:33:49 -0800 Message-ID: Thread-Topic: SL deprecation draft Thread-Index: AcOtvr8UZAFNLi0OQMyJmc/fIBtESwAOlM7w From: "Christian Huitema" To: "EricLKlein" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 18 Nov 2003 17:33:46.0330 (UTC) FILETIME=[1E9953A0:01C3ADFA] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > While I'd personally love to declare RFC 1918 "Historic", it really is > > completely IPv4 specific so we have no reason to reference it. >=20 > I would agree that RFC1918 is pure v4 issue, but we will need take into > account that when these IPv4 networks are connected as part of IPv6 > networks > we could get flooded with a lot of the ::10.x.x.x addresses that are > supposed to be "site local" under IPv4, but are now neither site local nor > unique under IPv6. Frankly, I don't believe that we should worry about net 10 in the site local deprecation draft. The site local deprecation document is specifically about the prefix 0xFEC0::/10. In any case, such addresses are explicitly banned in the IPv6 addressing architecture. Section 2.5.5 of RFC 3513 states: Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address. Why should we deprecate an address format that is already illegal?=20 -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 14:05:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07388 for ; Tue, 18 Nov 2003 14:05:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMB9s-0000AX-Uq for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 14:05:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIJ541k000643 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 14:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMB9s-0000AI-J5 for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 14:05:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07328 for ; Tue, 18 Nov 2003 14:04:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMB9q-0003LT-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 14:05:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMB9p-0003LQ-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 14:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMB8r-0008Pw-LM; Tue, 18 Nov 2003 14:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9SM-00024I-UD for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 12:16:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01628; Tue, 18 Nov 2003 12:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9SK-0001E6-00; Tue, 18 Nov 2003 12:16:00 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AM9SK-0001Dk-00; Tue, 18 Nov 2003 12:16:00 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAIHFTlf004089; Tue, 18 Nov 2003 12:15:29 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Tue, 18 Nov 2003 12:15:22 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Nov 2003 12:15:22 -0500 Message-ID: From: "Phelan, Tom" To: "'Eddie Kohler'" , Fred Templin Cc: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [dccp] PMTU issues Date: Tue, 18 Nov 2003 12:15:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Eddie, Well, when I opened this can of worms, I had no idea of how big it was :-). It might be worthwhile to restate the original problem I was trying to solve. That is, it will be common that the initial PMTU estimate made by DCCP (based on the first-hop MTU) will be wrong, and therefore an application that wants to use large packets, and relies on that initial estimate will lose its first few packets. So, how big a problem is this? A few points: 1) A DCCP app must be able to deal with lost packets at any time, so a DCCP app must build the necessary recovery mechanisms anyway. 2) Recovering from packet loss requires some extra effort when it happens, and recovering from the loss of the initial packets is often higher effort than recovering from the loss of later packets. 3) No one wants to gratuitously lose packets. 4) Many DCCP apps will not use large packets. Large packets often imply some delay while the data is accumulated, and many DCCP apps will want to avoid that delay. A simple solution, for apps that are bothered by this problem, is to use something smaller than the initial PMTU DCCP gives. Maybe the IPv6 min MTU of 1280 (minus IP and DCCP headers), or maybe say 64 bytes less than the initial DCCP PMTU (enough to hold an IPv4 IPsec tunnel header and a little more). This guideline might cover enough cases to be worthwhile, and the resulting inefficiency doesn't seem to me to be terrible. It's also possible for DCCP to get a better initial estimate of the PMTU, and apparently there are other problems with the current DCCP PMTUD mechanism (using ICMP "can't fragment" messages). Since DCCP is an unreliable packet service rather than a reliable stream service, the PLPMTUD proposal requires some extensive translation. Eddie's idea of an initial probe with padded Acks fits better, and gets around some of the further issues involved in relying on ICMP messages. However, it doesn't seem to me that we can completely abandon IMCP messages. Since DCCP is unreliable, that would require some kind of continuous probing to detect mid-connection changes. So, my question for the DCCP people, is it worth changing DCCP PMTUD? Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Monday, November 17, 2003 8:39 PM > To: Fred Templin > Cc: dccp@ietf.org; pmtud@ietf.org; ipv6@ietf.org; v6ops@ops.ietf.org > Subject: Re: [pmtud] Re: [dccp] PMTU issues > > > Hi Fred, > > * PLPMTUD is useful. > * Designing PMTUD so that it works in the absence of ICMP > feedback seems > necessary. > > BUT > > * Suitable ICMP feedback hints might significantly improve > the performance > of a transport protocol. > * We can program our transports to react to ICMP as a hint -- > i.e., not > trust it, but use it to optimize performance. > * So ICMP should not be "needed", but it might, and probably > would, be quite > helpful in some cases. > * For instance, not all packetization layers have as easy a > time as TCP > with packet size changes. The smooth ramp-up suggested in > PLPMTUD may > require intervention from the application for example. For good > performance, these applications may apply PMTUD in > unexpected ways -- > they might start large, for example. ICMP feedback would > really help > them. > * ICMP is not a significant cause of Internet congestion and > need not ever > become one (mark it less-than-best-effort). > > I still think your overloading of ECN capable as "PLPMTUD > capable, don't > send ICMP" is not necessary, a bad idea, and will not fly. > > Eddie > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 15:12:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11919 for ; Tue, 18 Nov 2003 15:12:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCCq-0004lT-Sf for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 15:12:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIKCCRT018308 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 15:12:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCCq-0004lD-Jz for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 15:12:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11855 for ; Tue, 18 Nov 2003 15:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMCCp-0004dn-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 15:12:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMCCo-0004dh-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 15:12:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCBj-0004Ns-3N; Tue, 18 Nov 2003 15:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCAs-0004MT-51 for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 15:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11502 for ; Tue, 18 Nov 2003 15:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMCAp-0004be-00 for ipv6@ietf.org; Tue, 18 Nov 2003 15:10:07 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMCAo-0004bM-00 for ipv6@ietf.org; Tue, 18 Nov 2003 15:10:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAIK9Yn11580; Tue, 18 Nov 2003 12:09:34 -0800 X-mProtect: <200311182009> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdUNIQbb; Tue, 18 Nov 2003 12:09:32 PST Message-Id: <4.3.2.7.2.20031118120553.036e0410@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Nov 2003 12:08:28 -0800 To: Christian Huitema From: Bob Hinden Subject: RE: SL deprecation draft Cc: ipv6@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >Frankly, I don't believe that we should worry about net 10 in the site >local deprecation draft. The site local deprecation document is >specifically about the prefix 0xFEC0::/10. In any case, such addresses >are explicitly banned in the IPv6 addressing architecture. Section 2.5.5 >of RFC 3513 states: > > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > >Why should we deprecate an address format that is already illegal? That's my view as well. The Site-Local deprecation document should focus on deprecating Site-Local addresses. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 18:43:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26107 for ; Tue, 18 Nov 2003 18:43:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFVC-0001c4-CM for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 18:43:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAINhMQ7006194 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 18:43:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFVC-0001bp-70 for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 18:43:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26082 for ; Tue, 18 Nov 2003 18:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMFV9-0002ct-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 18:43:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMFUw-0002ci-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 18:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFTt-0001Hv-Pz; Tue, 18 Nov 2003 18:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMFT4-0001FQ-Gf for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 18:41:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25990; Tue, 18 Nov 2003 18:40:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMFT1-0002aY-00; Tue, 18 Nov 2003 18:41:07 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMFT0-0002ZB-00; Tue, 18 Nov 2003 18:41:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAINeZi20312; Tue, 18 Nov 2003 15:40:35 -0800 X-mProtect: <200311182340> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLYnMfh; Tue, 18 Nov 2003 15:40:34 PST Message-ID: <3FBAAFA8.3000106@iprg.nokia.com> Date: Tue, 18 Nov 2003 15:47:52 -0800 From: Fred 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: Eddie Kohler CC: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <200311180139.hAI1dJIe059714@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddie, Your opinion is from the perspective of a modern-day expert technologist with specific insight into the problem space, and I have a great deal of respect for that. My opinion brings an historical perspective that I believe also bears consideration: I was very close to "ground-zero" when the current RFC-1191 style Path MTU discovery method took shape. In 1988-1990, I was heading up the team that developed ULTRIX support for Digital's initial FDDI product offering. The initial offering included an FDDI wiring concentrator (i.e., a fancy hub), two host adapters, and an Ethernet-to-FDDI L2 bridge. This latter product presented the interesting problem of how to support path MTU discovery in the presence of bridged media with diverse MTUs. The oft-cited problem case was the "dumbell configuration" in which two FDDI rings were on either side of an Ethernet pipe - in this example, how could hosts A and B on FDDI rings know whether an Ethernet was on the path? Some interesting alternatives were kicked around, including marking L2 packet headers with a bit to indicate that an Ethernet was traversed. But, a vocal minority at that time insisted that the only way to go was to either have the bridge support IPv4 fragmentation, or have it send "fragmentation needed" messages when dropping a packet with the DF bit set. The vocal minority got their way, but the chosen alternatives disqualified the opportunity to support transparent L2 bridging between media with diverse MTUs. Some made valiant attempts to market "brouter" or "transluscent bridge" products, but the vocal minority was easily able to shoot these down with counter- marketing and the advent of L3 routing (i.e., "smart networks") took flight. Since then, we have seen the boom and subsequent bust of the Internet revolution. It would be a far stretch to say that this all came as result of the path MTU discovery decisions, but I do believe it fair to say that a harmful precedent was set: folks started to believe they could engineer the network with no regard for the End-to-End Principle. So, where does this leave us today? We have an unreliable, untrustworthy (and, frankly, noisy) network-based mechanism that only works when forwarding nodes get involved with inspecting IPv4 packet headers. We'd like to be able to hook a dumb 9KB MTU Gbps Ethernet hub to a dumb 1500B MTU 10/100 Ethernet hub and enable the larger MTUs, but we can't because we blew the option out of the water back in the good old days and we have based so many of our architectural decisions on that precedent since. Now, with the emergence of techniques like PLPMTUD, we have the opportunity for healing by allowing new packetization layers, APIs, etc to gracefully supplant the old network-based mechanism. I envision an Internet restored to the End-to-End Principles, with new opportunities for innovation enabled by seamless support for L2 media with diverse MTUs. So, in response to a network that keeps endlessly screaming: "Packet Too Big!" "Fragment Needed!" I say: "Turn Off The Noise!" Fred ftemplin@iprg.nokia.com Eddie Kohler wrote: >Hi Fred, > >* PLPMTUD is useful. >* Designing PMTUD so that it works in the absence of ICMP feedback seems > necessary. > >BUT > >* Suitable ICMP feedback hints might significantly improve the performance > of a transport protocol. >* We can program our transports to react to ICMP as a hint -- i.e., not > trust it, but use it to optimize performance. >* So ICMP should not be "needed", but it might, and probably would, be quite > helpful in some cases. >* For instance, not all packetization layers have as easy a time as TCP > with packet size changes. The smooth ramp-up suggested in PLPMTUD may > require intervention from the application for example. For good > performance, these applications may apply PMTUD in unexpected ways -- > they might start large, for example. ICMP feedback would really help > them. >* ICMP is not a significant cause of Internet congestion and need not ever > become one (mark it less-than-best-effort). > >I still think your overloading of ECN capable as "PLPMTUD capable, don't >send ICMP" is not necessary, a bad idea, and will not fly. > >Eddie > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 18 20:24:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29926 for ; Tue, 18 Nov 2003 20:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMH4p-00079V-LP for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 20:24:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ1OFe7027492 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 20:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMH4p-00079K-EQ for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 20:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29896 for ; Tue, 18 Nov 2003 20:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMH4n-0004l6-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 20:24:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMH4m-0004l3-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 20:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMH3d-0006lG-AT; Tue, 18 Nov 2003 20:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMH30-0006kZ-Lp for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 20:22:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29837; Tue, 18 Nov 2003 20:22:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMH2y-0004jU-00; Tue, 18 Nov 2003 20:22:20 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMH2x-0004jQ-00; Tue, 18 Nov 2003 20:22:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJ1Lmu04757; Tue, 18 Nov 2003 17:21:48 -0800 X-mProtect: <200311190121> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6YTyvN; Tue, 18 Nov 2003 17:21:46 PST Message-ID: <3FBAC761.3040102@iprg.nokia.com> Date: Tue, 18 Nov 2003 17:29:05 -0800 From: Fred 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: Eddie Kohler CC: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues References: <200311190050.hAJ0obIe068359@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddie Kohler wrote: >Well, I wouldn't want to be responsible for any further destruction of the >Internet revolution, but most of this seems besides the point. Old-style >PMTUD, which *depended* on the delivery of ICMPs, is a far cry from >new-style PMTUD, which *can benefit* from the delivery of ICMPs. The >problem was the PMTU algorithm, not the idea of ICMPs. And the network >isn't full of useless ICMPs. > Nonetheless, I believe we should keep options open and investigate ways to support L2 devices that don't send ICMPs and don't support IP fragmentation without relegating them to second-class citizens. PLPMTUD gives us one such tool, but does it *really need* the ICMPs? We got this wrong on the first iteration some 15 years ago, and if there is now an opportunity to set things right we should at least give it serious consideration and make the right informed decisions. Thanks - Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 02:23:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29943 for ; Wed, 19 Nov 2003 02:23:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMgQ-0007i5-Td for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 02:23:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ7NQIF029634 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 02:23:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMgQ-0007ht-Bd for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 02:23:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29331 for ; Wed, 19 Nov 2003 02:23:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMMgM-0001sz-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 02:23:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMMgM-0001sw-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 02:23:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMf9-0007Mo-3R; Wed, 19 Nov 2003 02:22:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMef-0007Ko-GE for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 02:21:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27379 for ; Wed, 19 Nov 2003 02:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMMeb-0001r3-00 for ipv6@ietf.org; Wed, 19 Nov 2003 02:21:33 -0500 Received: from h013.c001.snv.cp.net ([209.228.32.127] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AMMea-0001qz-00 for ipv6@ietf.org; Wed, 19 Nov 2003 02:21:33 -0500 Received: (cpmta 16218 invoked from network); 18 Nov 2003 23:21:32 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 18 Nov 2003 23:21:32 -0800 X-Sent: 19 Nov 2003 07:21:32 GMT Message-ID: <002101c3ae6d$ea5f2c80$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: SL deprecation draft Date: Wed, 19 Nov 2003 09:22:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Frankly, I don't believe that we should worry about net 10 in the site > local deprecation draft. The site local deprecation document is > specifically about the prefix 0xFEC0::/10. In any case, such addresses > are explicitly banned in the IPv6 addressing architecture. Section 2.5.5 > of RFC 3513 states: > > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > Why should we deprecate an address format that is already illegal? I would agree with this, but I would feel more comfortable with an explicit statement rather than an implicit one. I have been speaking to different companies here in Israel, and the basic answer is that if I can not have site locals and NAT then I will not move to IPv6. This is people speaking strictly from a perceived security issue where they do not what the (bank, telephone company, or other fill in the blank here) to have their private secure data addressable from the internet just because there is a change in the IP version. It seems that based on the security failures in the various NT servers and firewalls they are sticking to unreachability as they key security option. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 06:06:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12455 for ; Wed, 19 Nov 2003 06:06:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQAN-0001vq-JM for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 06:06:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJB6ZrZ007425 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 06:06:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQAN-0001vg-C8 for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 06:06:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12428 for ; Wed, 19 Nov 2003 06:06:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQAJ-0004wl-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 06:06:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMQAJ-0004wi-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 06:06:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQ8t-0001iE-S9; Wed, 19 Nov 2003 06:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQ8T-0001gB-3o for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 06:04:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12389 for ; Wed, 19 Nov 2003 06:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQ8P-0004vV-00 for ipv6@ietf.org; Wed, 19 Nov 2003 06:04:33 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQ8O-0004vE-00 for ipv6@ietf.org; Wed, 19 Nov 2003 06:04:32 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJB3t610953; Wed, 19 Nov 2003 13:03:55 +0200 Date: Wed, 19 Nov 2003 13:03:55 +0200 (EET) From: Pekka Savola To: Fred Templin cc: ipv6@ietf.org Subject: Re: draft-hain-templin-ipv6-localcomm-03 comments In-Reply-To: <3FB9267E.1020601@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, I just about used up all my aspirin and tranquilizers trying to read this message constructively and trying to write a constructive reply to this message but failed. I don't think this document is constructive as a requirements document, and I'll strongly oppose it being adopted as WG document at any point of time. On Mon, 17 Nov 2003, Fred Templin wrote: > >well, the document seems like to completely concentrate on an > >addressing-based solution model.. which it probably should not. Anyone > >even glancing at the document can be 100% sure of this. > > > >Or was it only supposed to be agnostic of whether local-use addressing was > >needed? There's a difference there.. > > > >So, I agree 100% with Erik's earlier comments on the "coloring" and the > >"background" of the document.. > > > > I'm still waiting to see the specific comments that will correct this > often-expressed wrong impression. Maybe they will appear below; > I'll respond as I go and see where we end up. > > >(I only read the beginning of the draft, got too big a headache..) > > > > Take some aspirin, then. > > >substantial > >----------- > > > >1) the whole section 3.2 Maintaining Confidentiality of the Address Space is > >pretty much bogus. Remember, we're talking about using local communications > >with *IPv6*. With IPv4, you would be required to record the address > >prefixes in the RIR registries etc. -- but these are no longer relevant. > >You get one /48, put it in the registry, that's it. No exposing needed. > > > >Beyond that, all the exposing you'd do is what you choose to do yourself. > >If you don't want to give e.g. people the ability to traceroute through the > >network to learn the network properties, you can prevent that. > > > >In summary, this whole section should be removed or seriously reworded. > > > > I disagree. Network managers should be empowered to self-select > addresses to be used for internal-only communications and with > no pre-arrangement with a RIR. For example, in IPv4 I know that > network 15/8 is owned by HP, network 16/8 is (was?) owned by > Digital Equipment Corporation, etc. But, general knowledge of > this is nothing more than a burden on the party holding the > registration, since they now need to concern themselves with > liabilities for misuse of the RIR prefixes. > > In IPv6, there should be no reason for even this level of > exposure if the addresses are indeed to be used only for local > communications. Thus, the ability for network managers to > self-select addresses would be an improvement over the existing > condition for IPv4. > > >2) I don't see the point of section 3.3 myself: > > > > Test networks are frequently large, elaborate networks with a mix of > > public and private address space. Use of random unallocated space > > runs the risk of collision with legitimate addresses on remote > > networks if the test network is ever connected to the Internet. > > > >==> what kind of test network are you talking about? > >why would you ever connect a test to the Internet, except through some DMZ > >hosts/routers etc? > > > >With IPv6, you have enough addresses to play around if you want to connect > >something to the net. If you don't, you can just invent something (most TAC > >etc. labs probably certaintly do). No magic there... > > > >Needs rewording to bring up the point better or remove.. > > > > OK, how about this: > > "Test networks often provide a vehicle for limited experimentation > with new Internetworking technologies prior to widescale deployment, > but they may need to connect to the Internet to facilitate the > experiment. > Such experiments may entail large, elaborate networks with a mix of > public and private address space, but the use of random unallocated > space runs the risk of collision with legitimate addresses on remote > networks." > > But, is this enough to warrant a new document revision? I > don't think so. > > >3) there is solutionism/assuming the addressing is the answer in many of the > >goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8. Intentional? > > > > Please provide specific examples of text that you believe assumes > a particular solution alternative, since there was no intention to > dictate a particular alternative. > > If certain solution alternatives seem to suggest themselves based on > the scenarios, then the document is doing its work - but this is NOT > due to the intentional manipulation of the authors (see changelogs > and acknolwedgements for the substantial community input already > taken). > > >4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the > >text), could be removed ? > > > > This is a valid point, but I prefer to say that sections 3.6.2 and 3.5 > could be consolidated rather than removing one or the other. Does > this warrant another revision, though? My take is no. > > >5) section 3.7 is a bit incomprehensible: > > > >3.7 Asset Protection in Enterprise Networks > > > > Enterprise networks that protect private corporate assets (e.g., > > printers, faxes, robotics, sensors, etc.) require an addressing > > scheme that remains stable even when VPN connections from outside > > sites occur. > > > >==> how on earth would VPN connections from outside disturb a stable > >addressing scheme?!? > > > > We are talking here about site mergers, which becomes apparent > in the subsequent sentences of that paragraph. When two sites > merge, ongoing local communications which were in-progress > within the two seperate sites should continue without breaking > when the two sites become one. > > The sentences you cite above are taken out of context, and the > meaning seems clear enough when they are considered within > the context of the entire section. > > >6) it's no surprise that section 4 on goals presupposes an addressing-based > >solution. Is this intentional? In any case, the titles are: > > > >4.1 Easy to Acquire > >4.2 Stable > >4.3 Multiple Link Support > >4.4 Prefix Filtering and Hints to Applications > >4.5 Globally Unique > >4.6 Usable in the Absence of a Provider > >4.7 Applicable in Managed/Unmanaged Environments > >4.8 Compatible with Site Naming System > >4.9 Compatible with VPN > >4.10 Multiple Addressing > > > >one could generalize and reword these to: > > > >4.1 Easy to Take to Use > >4.2 Session Stability > >4.3 Multiple Link Support > >4.4 Application Awareness of Policy > >4.5 Locality Between Multiple Sites > >4.6 Usable in the Absence of a Provider > >4.7 Applicable in Managed/Unmanaged Environments > >4.8 Compatible with Site Naming System > >4.9 Compatible with VPN (XXX: ?) > >4.10 Provision for Both Local and Global Communications > > > > One could always re-word, yes, but re-wording can always > be done ad-inifinitum. I don't see anything in any of these > suggestions that provides any beneficial clarification. > > >semi-editorial > >-------------- > > > >Abstract > > > > The IPv6 addressing architecture specifies global and local-use > > unicast addressing schemes, but provides no operational guidelines > > for their use. > > > >and: > > > >1. Introduction > > > > The IPv6 addressing architecture [RFC3513] specifies global and > > local-use unicast addresses. Global addresses are understood to have > > unlimited range and may be used as the source and destination > > addresses in packets that originate from any point on the connected > > global IPv6 Internet. Local-use addresses are intended for use only > > within the range of a single link/site, but their specification does > > not address operational considerations for real-world deployment > > scenarios. > > > >==> the critical local-use addressing part is to be removed before this > >becomes relevant, so I don't think it's appropriate to refer to these > >documents here. Suggest removing or serious rewording. > > > > Update from [RFC3513] to [RFC3513(bis)] you mean? > I don't see this in and of itself necessitating a document > update; in fact, the role of the hain-templin document is > to set the target in motion - not to track the target as it > moves. > > >.... > > > >. As such, > > the address prefixes used in each PAN should be globally unique to > > avoid collisions and provide a means for verifying ownership to > > resolve conflicts. > > > >==> this (in 3.5) doesn't seem to be relevant to the local communications, > >remove? > > > > This goes with the above comment on consolidating sections 3.5 > and 3.6.2, but do these alone warrant a new document revision? > My take is that they don't. > > > >editorial > >--------- > > > >. Of > > utmost importance is that the systems on board the ship all function, > > > >==> s/Of utmost importance is/It's of utmost importance/ > > > > Noted. > > Fred > ftemplin@iprg.nokia.com > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 07:29:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14326 for ; Wed, 19 Nov 2003 07:29:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRSF-0005fA-4F for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 07:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJCT7RW021762 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 07:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRSE-0005ev-TM for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 07:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14288 for ; Wed, 19 Nov 2003 07:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRSE-00068v-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 07:29:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMRSE-00068s-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 07:29:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRRC-0005R3-9b; Wed, 19 Nov 2003 07:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMGYK-0005EA-Lh for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 19:50:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28602; Tue, 18 Nov 2003 19:50:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMGYI-0004E0-00; Tue, 18 Nov 2003 19:50:38 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1AMGYH-0004Dw-00; Tue, 18 Nov 2003 19:50:38 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hAJ0obIe068359; Tue, 18 Nov 2003 16:50:37 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200311190050.hAJ0obIe068359@coyote.icir.org> To: Fred Templin cc: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues In-Reply-To: Message from Fred Templin of "Tue, 18 Nov 2003 15:47:52 PST." <3FBAAFA8.3000106@iprg.nokia.com> Date: Tue, 18 Nov 2003 16:50:37 -0800 From: Eddie Kohler Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Since then, we have seen the boom and subsequent bust of the > Internet revolution. It would be a far stretch to say that this all > came as result of the path MTU discovery decisions, but I do > believe it fair to say that a harmful precedent was set: ... > So, where does this leave us today? We have an unreliable, > untrustworthy (and, frankly, noisy) network-based mechanism > that only works when forwarding nodes get involved with > inspecting IPv4 packet headers. ... Well, I wouldn't want to be responsible for any further destruction of the Internet revolution, but most of this seems besides the point. Old-style PMTUD, which *depended* on the delivery of ICMPs, is a far cry from new-style PMTUD, which *can benefit* from the delivery of ICMPs. The problem was the PMTU algorithm, not the idea of ICMPs. And the network isn't full of useless ICMPs. Eddie -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 07:56:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14895 for ; Wed, 19 Nov 2003 07:56:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRs9-000782-FD for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 07:55:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJCtrsR027403 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 07:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRs9-00077u-85 for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 07:55:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14861 for ; Wed, 19 Nov 2003 07:55:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRs8-0006SW-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 07:55:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMRs8-0006ST-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 07:55:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRrK-0006pD-UM; Wed, 19 Nov 2003 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRqj-0006oH-0S for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 07:54:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14821 for ; Wed, 19 Nov 2003 07:54:12 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRqi-0006RD-00 for ipv6@ietf.org; Wed, 19 Nov 2003 07:54:24 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMRqh-0006RA-00 for ipv6@ietf.org; Wed, 19 Nov 2003 07:54:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJCsM607878 for ; Wed, 19 Nov 2003 14:54:22 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 14:54:21 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 06:54:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SL deprecation draft Date: Wed, 19 Nov 2003 07:54:11 -0500 Message-ID: Thread-Topic: SL deprecation draft Thread-Index: AcOubiNFYFUsvmWWRtWjZaAubTY4nwALYKhQ To: , X-OriginalArrivalTime: 19 Nov 2003 12:54:12.0553 (UTC) FILETIME=[3B0FD390:01C3AE9C] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Eric, > I have been speaking to different > companies here in Israel, and the basic answer is that if I=20 > can not have site locals and NAT then I will not move to IPv6.=20 If these people are happy with IPv4 NAT, why would they want=20 to move to IPv6? They couldn't need more address space (net 10 is huge), they obviously don't care about peer-to-peer or end-to-end connectivity outside their organization, I can't imagine that they want to deploy any IPv6-only applications or services... Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 08:13:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15472 for ; Wed, 19 Nov 2003 08:13:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMS8Y-00005K-Ew for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 08:12:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJDCocc000320 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 08:12:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMS8Y-000055-5d for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 08:12:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15424 for ; Wed, 19 Nov 2003 08:12:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMS8X-0006gE-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 08:12:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMS8W-0006gB-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 08:12:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMS7m-0008IC-9d; Wed, 19 Nov 2003 08:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMS71-0008Hi-74 for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 08:11:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15399 for ; Wed, 19 Nov 2003 08:11:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMS70-0006fI-00 for ipv6@ietf.org; Wed, 19 Nov 2003 08:11:14 -0500 Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AMS6z-0006fF-00 for ipv6@ietf.org; Wed, 19 Nov 2003 08:11:13 -0500 Received: (cpmta 23585 invoked from network); 19 Nov 2003 05:11:11 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.119) with SMTP; 19 Nov 2003 05:11:11 -0800 X-Sent: 19 Nov 2003 13:11:11 GMT Message-ID: <001b01c3ae9e$c2f81590$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: Subject: Re: SL deprecation draft Date: Wed, 19 Nov 2003 15:12:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret.Wasserman wrote > > I have been speaking to different > > companies here in Israel, and the basic answer is that if I > > can not have site locals and NAT then I will not move to IPv6. > If these people are happy with IPv4 NAT, why would they want > to move to IPv6? They couldn't need more address space (net 10 > is huge), they obviously don't care about peer-to-peer or > end-to-end connectivity outside their organization, I can't > imagine that they want to deploy any IPv6-only applications > or services... Margret, you are correct. The way that one network person put it "if there are no local addresses then we will just stay with IPv4 for our secure applications, until it is no longer supported." This is not the first time that I have heard that someone was willing to skip IPv6 because of the percieved pain and security threat that standards compliance would entail. But then again these are all people that take security and network administration very personal and very seriously, and the idea of having the accounts recievable (or worse payable) computer with a globaly reachable address scares them to heck. To be honest I stated these concerns back in the spring, and I still haven't seen anything that would work to convince me that this is not what we as a WG are proposing. If someone converts their existing network to a globaly unique address range then what is responsible for filtering all of the critical addresses from sending or recieving packets from the network over the network Interent router? I see this as being moved from the protocol level to that of the network technician, who now needs to explicitly deny individual addresses (or ranges) rather and explicityl allow the permited ranges. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 08:25:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15733 for ; Wed, 19 Nov 2003 08:25:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSKV-0000j6-6V for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 08:25:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJDPBGp002786 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 08:25:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSKV-0000ir-06 for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 08:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15703 for ; Wed, 19 Nov 2003 08:24:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSKT-0006po-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 08:25:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMSKT-0006pl-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 08:25:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSKN-0000fA-74; Wed, 19 Nov 2003 08:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSJc-0000Zp-PR for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 08:24:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15694 for ; Wed, 19 Nov 2003 08:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSJb-0006pa-00 for ipv6@ietf.org; Wed, 19 Nov 2003 08:24:15 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1AMSJa-0006pX-00 for ipv6@ietf.org; Wed, 19 Nov 2003 08:24:15 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAJDO7m12085; Wed, 19 Nov 2003 14:24:07 +0100 Message-ID: <3FBB6EF7.9060904@it.su.se> Date: Wed, 19 Nov 2003 14:24:07 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Margaret.Wasserman@nokia.com CC: eric@mehr.ws, ipv6@ietf.org Subject: Re: SL deprecation draft References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Margaret.Wasserman@nokia.com wrote: | Hi Eric, | | |>I have been speaking to different |>companies here in Israel, and the basic answer is that if I |>can not have site locals and NAT then I will not move to IPv6. | | | If these people are happy with IPv4 NAT, why would they want | to move to IPv6? They couldn't need more address space (net 10 | is huge), they obviously don't care about peer-to-peer or | end-to-end connectivity outside their organization, I can't | imagine that they want to deploy any IPv6-only applications | or services... | | Margaret | Right on. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/u2738Jx8FtbMZncRAqU7AJ44rfIJFVMlpdwVX8xK7/E7ZlZw3gCaAldK T2stP11svJvYXT2V1tjfVbU= =e3s8 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 08:33:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16026 for ; Wed, 19 Nov 2003 08:33:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSSh-0001Lp-51 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 08:33:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJDXdo6005186 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 08:33:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSSg-0001LZ-Vj for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 08:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16003 for ; Wed, 19 Nov 2003 08:33:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSSf-0006yU-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 08:33:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMSSf-0006yQ-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 08:33:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSS5-0001Ft-Qw; Wed, 19 Nov 2003 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMSRu-0001FU-UZ for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 08:32:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15988 for ; Wed, 19 Nov 2003 08:32:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSRt-0006yA-00 for ipv6@ietf.org; Wed, 19 Nov 2003 08:32:49 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMSRt-0006y7-00 for ipv6@ietf.org; Wed, 19 Nov 2003 08:32:49 -0500 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 NAA11211 for ; Wed, 19 Nov 2003 13:32:47 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA02985 for ; Wed, 19 Nov 2003 13:32:47 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAJDWlR11893 for ipv6@ietf.org; Wed, 19 Nov 2003 13:32:47 GMT Date: Wed, 19 Nov 2003 13:32:47 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: SL deprecation draft Message-ID: <20031119133247.GI11170@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <001b01c3ae9e$c2f81590$ec061eac@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001b01c3ae9e$c2f81590$ec061eac@ttitelecom.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, Nov 19, 2003 at 03:12:16PM +0200, EricLKlein wrote: > > This is not the first time that I have heard that someone was willing to > skip IPv6 because of the percieved pain and security threat that standards > compliance would entail. But then again these are all people that take > security and network administration very personal and very seriously, and > the idea of having the accounts recievable (or worse payable) computer with > a globaly reachable address scares them to heck. I think Margaret is spot on... there is noone forcing sites to migrate to use IPv6. Stick with IPv4+NAT if you think that meets your requirements. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 09:18:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17377 for ; Wed, 19 Nov 2003 09:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMT9v-0003f1-0B for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:18:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJEIIRx014065 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMT9u-0003el-Ln for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:18:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17355 for ; Wed, 19 Nov 2003 09:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMT9t-0007eS-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:18:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMT9s-0007eP-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMT9c-0003Z7-Tn; Wed, 19 Nov 2003 09:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMT8r-0003Yb-TN for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 09:17:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17345 for ; Wed, 19 Nov 2003 09:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMT8q-0007e0-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:17:12 -0500 Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMT8p-0007dT-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:17:11 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAJEGeX7722586; Wed, 19 Nov 2003 09:16:40 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAJEGdPC111604; Wed, 19 Nov 2003 09:16:39 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hAJEGVoA026213; Wed, 19 Nov 2003 09:16:31 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hAJEGVQ5026208; Wed, 19 Nov 2003 09:16:31 -0500 Message-Id: <200311191416.hAJEGVQ5026208@rotala.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipv6@ietf.org Subject: Issue 19 of draft-ietf-ipv6-node-requirements-05.txt In-Reply-To: Message from john.loughney@nokia.com of "Wed, 24 Sep 2003 14:17:00 +0300." Date: Wed, 19 Nov 2003 09:16:31 -0500 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , john.loughney@nokia.com writes: > > > Nodes MUST always be able to receive fragment headers. However, if it > > > does not implement path MTU discovery it may not need to send > > > fragment headers. However, nodes that do not implement transmission > > > of fragment headers need to impose a limitation to the payload size > > > of layer 4 protocols. > > > > This would seem inconsistent with the following wording in RFC 2460: > > > > In response to an IPv6 packet that is sent to an IPv4 destination > > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > > originating IPv6 node may receive an ICMP Packet Too Big message > > reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node > > is not required to reduce the size of subsequent packets to less than > > 1280, but must include a Fragment header in those packets so that the > > IPv6-to-IPv4 translating router can obtain a suitable Identification > > value to use in resulting IPv4 fragments. Note that this means the > > payload may have to be reduced to 1232 octets (1280 minus 40 for the > > IPv6 header and 8 for the Fragment header), and smaller still if > > additional extension headers are used. > So, this should be changed to: > Nodes MUST always be able to send and receive fragment headers. (rest of > the text deleted) how about: Nodes MUST always be able to send and receive fragment headers. Note that even in the case where a sender does not implement or use Path MTU discovery [RFC 1981], the sender must still be prepared to send fragment headers, even for packets that are smaller than the minimal IPv6 link MTU of 1280 octets. See Section 5 of [RFC 2460] for details. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 09:37:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17982 for ; Wed, 19 Nov 2003 09:37:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTSN-0004kI-2t for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:37:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJEbNFQ018235 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:37:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTSM-0004jv-DG for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:37:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17961 for ; Wed, 19 Nov 2003 09:37:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTSK-00005x-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:37:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTSK-00005u-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:37:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTS1-0004bC-MP; Wed, 19 Nov 2003 09:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTRp-0004aU-CN for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 09:36:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17950 for ; Wed, 19 Nov 2003 09:36:35 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTRn-00005J-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:36:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMTRn-00005G-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:36:47 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJEajA13872 for ; Wed, 19 Nov 2003 16:36:46 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 16:36:45 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 16:36:45 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 16:36:45 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 19 of draft-ietf-ipv6-node-requirements-05.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 19 Nov 2003 16:36:44 +0200 Message-ID: Thread-Topic: Issue 19 of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcOup/5qFKL//MLsR4KLp78xAZaZSgAAmcKw To: Cc: X-OriginalArrivalTime: 19 Nov 2003 14:36:45.0385 (UTC) FILETIME=[8E6F7B90:01C3AEAA] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thomas, > how about: >=20 > Nodes MUST always be able to send and receive fragment > headers. Note that even in the case where a sender does not > implement or use Path MTU discovery [RFC 1981], the sender > must still be prepared to send fragment headers, even for > packets that are smaller than the minimal IPv6 link MTU of > 1280 octets. See Section 5 of [RFC 2460] for details. I'm OK with the proposed text, except Pekka Savola asked me if it should be changed to: Nodes MUST always be able to send, receive and process fragment ^^^^^^^^^^^ headers. Note that even in the case where a sender does not=20 .... Let me know if this is OK. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 09:43:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18241 for ; Wed, 19 Nov 2003 09:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTY0-0005YQ-P4 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJEhC2D021344 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:43:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTY0-0005YB-J0 for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:43:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18223 for ; Wed, 19 Nov 2003 09:42:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTXy-0000C0-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:43:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTXy-0000Bx-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:43:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTXq-0005PR-M3; Wed, 19 Nov 2003 09:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTXc-0005Ou-L2 for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 09:42:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18206 for ; Wed, 19 Nov 2003 09:42:34 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTXa-0000Bi-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:42:46 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMTXa-0000Ba-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:42:46 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJEgj605744 for ; Wed, 19 Nov 2003 16:42:45 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Nov 2003 16:42:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 16:42:44 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 16:42:44 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AD REVIEW: IPv6 Node Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 19 Nov 2003 16:42:44 +0200 Message-ID: Thread-Topic: IPv6 Node Requirements Thread-Index: AcOt6aYnICqt+pPSQzCSB5DbEz6reAAAA2/wADBnRgA= To: X-OriginalArrivalTime: 19 Nov 2003 14:42:44.0773 (UTC) FILETIME=[64A5BD50:01C3AEAB] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here are some comments from Margaret. John > -----Original Message----- > From: Wasserman Margaret (NRC/Boston)=20 > Hi John, >=20 > I have reviewed the IPv6 Node Requirements draft. In general, > I think tha the document looks good, but I do have several comments=20 > (attached). I believe that an update will be required before this=20 > draft will be ready to go to IESG review. >=20 > Margaret >=20 > --- >=20 > My comments are marked with '>>'. I've tried to included enough > context to make it clear what section I'm commenting on, but if=20 > there is any question, please ask. >=20 > As it is not always possible for an implementer to know the exact > usage of IPv6 in a node, an overriding requirement for=20 > IPv6 nodes is > that they should adhere to John Postel's Robustness Principle: >=20 > Be conservative in what you do, be liberal in what you=20 > accept from > others. [RFC-793]. >=20 > >> s/John Postel/Jon Postel/ >=20 > >> General comment: The organization of this document is a bit > >> awkward. It would probably read better to start with the > >> IP layer and put the Sub-IP Layer at the end. >=20 > 3. Sub-IP Layer > An IPv6 node must follow the RFC related to the link-layer that is > sending packets. By definition, these specifications are required > based upon what layer-2 is used. In general, it is=20 > reasonable to be > a conformant IPv6 node and NOT support some legacy interfaces. >=20 > >> It is not clear to me what this paragraph is trying to indicate. > >> Perhaps: > >> An IPv6 node must include support for one or more IPv6 link-layer > >> specifications. Which link-layer specifications are included=20 > >> will depend upon what link-layers are supported by the hardware > >> available on the system. It is possible for a conformant IPv6 > >> node to support IPv6 on some of its interfaces and not on others. >=20 > Nodes MUST always be able to receive fragment headers.=20 > However, if it > does not implement path MTU discovery it may not need to send > fragment headers. However, nodes that do not implement=20 > transmission > of fragment headers need to impose a limitation to the payload size > of layer 4 protocols. >=20 > >> There is no connection, as far as I know between implementing > >> Path MTU discovery and the need to implement fragmentation. > >> Path MTU is optional, and if it is not included the IP layer > >> will not send any packet over 1280 bytes (per RFC 2460). =20 > >> Fragmentation isn't optional, because it is not always possible > >> for an upper layer to know the effective MTU, as the upper layers > >> may not know which interface will be used and/or what options > >> will be included in its packets. The IP layer must be capable > >> of fragmenting longer packets to the discovered Path MTU or > >> 1280. >=20 > The capability of being a final destination MUST be supported, > whereas the capability of being an intermediate destination MAY be > supported (i.e. - host functionality vs. router functionality). >=20 > >> Is there a reason for this particular wording? "Intermediate=20 > >> destination" is not a term that I'm familiar with. Perhaps > >> this could be better said: "All conformant IPv6 implementations > >> MUST be capable of sending and receving IPv6 packets; forwarding > >> functionality MAY be supported"? Or are you trying to say more > >> here? >=20 > 4.5 Addressing >=20 > Currently, there is discussion on support for site-local=20 > addressing. >=20 > >> Either say more or leave this out? When published as an RFC, this > >> document will live long term, so the word "currently" is a bit > >> vague. Since we are deprecating site-local, I think that you > >> could just omit any mention of it. >=20 > 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 >=20 > If an application is going to join any-source multicast group > addresses, it SHOULD implement MLDv1. When MLD is used,=20 > the rules in > "Source Address Selection for the Multicast Listener=20 > Discovery (MLD) > Protocol" [RFC-3590] MUST be followed. >=20 > >> If I understand correctly, these nodes could support either > >> MLDv1 or MLDv2. >=20 > 5.1 Transport Layer >=20 > 5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 >=20 > This specification MUST be supported if jumbograms are implemented > [RFC-2675]. One open issue is if this document needs to=20 > be updated, > as it refers to an obsoleted document. >=20 > >> An open issue for whom? I wouldn't include open issues for > >> other documents in this document. >=20 > Format for Literal IPv6 Addresses in URL's" [RFC-2732] MUST be > supported if applications on the node use URL's. >=20 > >> s/Format/"Format/ ?? >=20 > 5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 >=20 > RFC 2732 MUST be supported if applications on the node use URL's. >=20 > >> This is redundant with the last line of the previous section. >=20 > 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 >=20 > >> I think that you should be explicit, throughout this section, > >> that you are talking about DHCPv6. In other words, replace > >> all occurances of DHCP with DHCPv6. It is possible that nodes > >> may implement DHCP(v4), but not DHCPv6. >=20 > 10.1 Management Information Base Modules (MIBs) >=20 > The following two MIBs SHOULD be supported MIBs by nodes=20 > that support > an SNMP agent. >=20 > >> s/supported MIBs by/supported by/ >=20 > 11. Security Considerations >=20 > >> In the IPsec section, you mention that other security issues > >> will be covered in the Security Considerations section, but > >> I don't see any issues here... =20 > >> > >> Why aren't privacy addresses covered in this document? > >> > >> Also, did you consider a recommendation that IPv6 nodes should > >> implement SEND? Perhaps you should at least mention the=20 > >> security issues with ND and indicate that the SEND group is > >> working to resolve them? >=20 >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 10:10:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20387 for ; Wed, 19 Nov 2003 10:10:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTyC-00087V-5v for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 10:10:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFAGuJ031210 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 10:10:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTyB-00087J-GQ for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:10:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20309 for ; Wed, 19 Nov 2003 10:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTy9-0000me-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 10:10:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTy9-0000mb-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 10:10:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTxz-00081X-1X; Wed, 19 Nov 2003 10:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTxI-00080X-Cw for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 10:09:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20231 for ; Wed, 19 Nov 2003 10:09:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTxG-0000lb-00 for ipv6@ietf.org; Wed, 19 Nov 2003 10:09:18 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMTxF-0000lX-00 for ipv6@ietf.org; Wed, 19 Nov 2003 10:09:17 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 504516A90D; Wed, 19 Nov 2003 17:09:15 +0200 (EET) Message-ID: <3FBB8698.8040106@kolumbus.fi> Date: Wed, 19 Nov 2003 17:04:56 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: john.loughney@nokia.com, ipv6@ietf.org Subject: Re: Issue 19 of draft-ietf-ipv6-node-requirements-05.txt References: <200311191416.hAJEGVQ5026208@rotala.raleigh.ibm.com> In-Reply-To: <200311191416.hAJEGVQ5026208@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas Narten wrote: >>>> Nodes MUST always be able to receive fragment headers. However, if it >>>> does not implement path MTU discovery it may not need to send >>>> fragment headers. However, nodes that do not implement transmission >>>> of fragment headers need to impose a limitation to the payload size >>>> of layer 4 protocols. >>> >>> >>>This would seem inconsistent with the following wording in RFC 2460: >>> >>> In response to an IPv6 packet that is sent to an IPv4 destination >>> (i.e., a packet that undergoes translation from IPv6 to IPv4), the >>> originating IPv6 node may receive an ICMP Packet Too Big message >>> reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node >>> is not required to reduce the size of subsequent packets to less than >>> 1280, but must include a Fragment header in those packets so that the >>> IPv6-to-IPv4 translating router can obtain a suitable Identification >>> value to use in resulting IPv4 fragments. Note that this means the >>> payload may have to be reduced to 1232 octets (1280 minus 40 for the >>> IPv6 header and 8 for the Fragment header), and smaller still if >>> additional extension headers are used. Oops, yes. >>So, this should be changed to: > > >> Nodes MUST always be able to send and receive fragment headers. (rest of >> the text deleted) > > > how about: > > Nodes MUST always be able to send and receive fragment > headers. Note that even in the case where a sender does not > implement or use Path MTU discovery [RFC 1981], the sender > must still be prepared to send fragment headers, even for > packets that are smaller than the minimal IPv6 link MTU of > 1280 octets. See Section 5 of [RFC 2460] for details. Sounds good. Pekka Savola's slight modification of this is OK, too. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 10:12:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20700 for ; Wed, 19 Nov 2003 10:12:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU0E-0000B6-NQ for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 10:12:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFCMqw000678 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 10:12:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU0E-0000AZ-GW for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:12:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20578 for ; Wed, 19 Nov 2003 10:12:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMU0A-0000pc-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 10:12:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMU09-0000pZ-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 10:12:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTzu-0008MW-FN; Wed, 19 Nov 2003 10:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTD6-0003y2-OY for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 09:21:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17502; Wed, 19 Nov 2003 09:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTD4-0007hj-00; Wed, 19 Nov 2003 09:21:34 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1AMTD4-0007hg-00; Wed, 19 Nov 2003 09:21:34 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hAJELXIe072495; Wed, 19 Nov 2003 06:21:33 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200311191421.hAJELXIe072495@coyote.icir.org> To: "Phelan, Tom" cc: Fred Templin , dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [dccp] PMTU issues In-Reply-To: Message from "Phelan, Tom" of "Tue, 18 Nov 2003 12:15:21 EST." Date: Wed, 19 Nov 2003 06:21:33 -0800 From: Eddie Kohler Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > It's also possible for DCCP to get a better initial estimate of the PMTU, > and apparently there are other problems with the current DCCP PMTUD > mechanism (using ICMP "can't fragment" messages). Yes -- The current draft tries to make clear (but fails to) that a new, PLPMTUD-style MTU discovery mechanism is acceptable. There are API problems with such a scheme, but we absolutely allow it. If you can accept an extra RTT or two at connection initiation time, I think you can do pretty well: Request --> <-- Response then, all in 1 RTT: Padded Sync(512 bytes) --> /* actual #s would need to fit CC Padded Sync(1280 bytes) --> mechanism */ Padded Sync(4000 bytes) --> <-- SyncReply(1) /* SyncReplies sent only for those <-- SyncReply(2) packets that got through */ <-- SyncReply(3) > So, my question for the DCCP people, is it worth changing DCCP PMTUD? It's certainly worth describing it better, and perhaps mentioning a set of acceptable procedures. Have you any suggestions for useful procedures here? Eddie -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 10:45:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22741 for ; Wed, 19 Nov 2003 10:45:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUVY-0002L6-2I for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 10:44:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFii0I008986 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 10:44:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUVX-0002Kr-Qk for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:44:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22723 for ; Wed, 19 Nov 2003 10:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUVV-0001RP-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 10:44:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMUVU-0001RM-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 10:44:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUUs-0002Dp-OD; Wed, 19 Nov 2003 10:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMUUm-0002DZ-Sw for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 10:43:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22705 for ; Wed, 19 Nov 2003 10:43:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMUUk-0001Qu-00 for ipv6@ietf.org; Wed, 19 Nov 2003 10:43:54 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMUUj-0001Qr-00 for ipv6@ietf.org; Wed, 19 Nov 2003 10:43:54 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ED3806A90D; Wed, 19 Nov 2003 17:43:52 +0200 (EET) Message-ID: <3FBB8EB6.50707@kolumbus.fi> Date: Wed, 19 Nov 2003 17:39:34 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: ipv6@ietf.org, Margaret Wasserman Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>>An IPv6 node must include support for one or more IPv6 link-layer >>>specifications. Which link-layer specifications are included >>>will depend upon what link-layers are supported by the hardware >>>available on the system. It is possible for a conformant IPv6 >>>node to support IPv6 on some of its interfaces and not on others. > > > proposed text is good. Yes. > The capability of being a final destination MUST be supported, > whereas the capability of being an intermediate destination MAY be > supported (i.e. - host functionality vs. router functionality). > > >>>Is there a reason for this particular wording? "Intermediate >>>destination" is not a term that I'm familiar with. Perhaps >>>this could be better said: "All conformant IPv6 implementations >>>MUST be capable of sending and receving IPv6 packets; forwarding >>>functionality MAY be supported"? Or are you trying to say more >>>here? > > > proposed text is good. Yes. > 4.5 Addressing > > Currently, there is discussion on support for site-local addressing. > > >>>Either say more or leave this out? When published as an RFC, this >>>document will live long term, so the word "currently" is a bit >>>vague. Since we are deprecating site-local, I think that you >>>could just omit any mention of it. > > > proposal is good. Right. > 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 > > If an application is going to join any-source multicast group > addresses, it SHOULD implement MLDv1. When MLD is used, the rules in > "Source Address Selection for the Multicast Listener Discovery (MLD) > Protocol" [RFC-3590] MUST be followed. > > >>>If I understand correctly, these nodes could support either >>>MLDv1 or MLDv2. The document already allows either MLDv1 or MLDv2 to be used. And yes, MLDv2 is backwards compatible to MLDv1 as John pointed out. Perhaps the only question that I have left is... whether IPv6 nodes should support MLDv2 instead of MLDv1. The node requirements document and the MLDv2 draft intro gives the impression that the only difference is source-specific filtering. Then the current node reqs rules make sense. But Appendix B of the MLDv2 draft seems to list a number of other modifications, including some enhancements to robustness. Are these important? I'm not an expert enough to determine that. > 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 > > >>>I think that you should be explicit, throughout this section, >>>that you are talking about DHCPv6. In other words, replace >>>all occurances of DHCP with DHCPv6. It is possible that nodes >>>may implement DHCP(v4), but not DHCPv6. > > > Thought that would go without saying, but I'll be explicit noone > gets confused. Yes, DHCPv6 is better because we don't want to appear to be saying anything about IPv4... --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 11:19:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24260 for ; Wed, 19 Nov 2003 11:19:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMV2z-0004J0-DG for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 11:19:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJGJHGY016544 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 11:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMV2y-0004Il-Ui for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 11:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24228 for ; Wed, 19 Nov 2003 11:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMV2y-0002Bk-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 11:19:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMV2x-0002Bh-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 11:19:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMV2k-0004AB-AT; Wed, 19 Nov 2003 11:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMV2f-00049X-RM for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 11:18:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24203 for ; Wed, 19 Nov 2003 11:18:44 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMV2e-0002B2-00 for ipv6@ietf.org; Wed, 19 Nov 2003 11:18:56 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMV2d-0002Ay-00 for ipv6@ietf.org; Wed, 19 Nov 2003 11:18:56 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJGIs613634 for ; Wed, 19 Nov 2003 18:18:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 18:18:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Nov 2003 18:18:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 29: AD REVIEW: IPv6 Node Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 19 Nov 2003 18:18:53 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOus/AjlHsGgn4qRWiqd+bDchABRQABLwXQ To: Cc: , X-OriginalArrivalTime: 19 Nov 2003 16:18:53.0916 (UTC) FILETIME=[D35319C0:01C3AEB8] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jari, > > 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 > >=20 > > If an application is going to join any-source multicast group > > addresses, it SHOULD implement MLDv1. When MLD is used, the rules = in > > "Source Address Selection for the Multicast Listener Discovery = (MLD) > > Protocol" [RFC-3590] MUST be followed. > >=20 > >=20 > >>>If I understand correctly, these nodes could support either > >>>MLDv1 or MLDv2. >=20 > The document already allows either MLDv1 or MLDv2 to > be used. And yes, MLDv2 is backwards compatible to > MLDv1 as John pointed out. >=20 > Perhaps the only question that I have left is... whether > IPv6 nodes should support MLDv2 instead of MLDv1. The > node requirements document and the MLDv2 draft intro > gives the impression that the only difference is > source-specific filtering. Then the current node > reqs rules make sense. But Appendix B of the MLDv2 > draft seems to list a number of other modifications, > including some enhancements to robustness. Are these > important? I'm not an expert enough to determine that. Appendicies are non-normative, so I think that we don't need to worry about it in the Node Requirements document, though=20 I am by no means an MLD expert. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 11:34:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24925 for ; Wed, 19 Nov 2003 11:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVHQ-0004ve-Nr for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 11:34:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJGYC9h018940 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 11:34:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVHQ-0004vP-9g for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 11:34:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24885 for ; Wed, 19 Nov 2003 11:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVHP-0002WT-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 11:34:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVHO-0002WQ-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 11:34:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVHG-0004pv-6C; Wed, 19 Nov 2003 11:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVGg-0004ox-1i for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 11:33:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24860 for ; Wed, 19 Nov 2003 11:33:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVGf-0002Vl-00 for ipv6@ietf.org; Wed, 19 Nov 2003 11:33:25 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AMVGe-0002VC-00 for ipv6@ietf.org; Wed, 19 Nov 2003 11:33:24 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAJGWpcF338154; Wed, 19 Nov 2003 11:32:51 -0500 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAJGWoU7334126; Wed, 19 Nov 2003 09:32:50 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hAJGWdoA026838; Wed, 19 Nov 2003 11:32:39 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hAJGWdCG026833; Wed, 19 Nov 2003 11:32:39 -0500 Message-Id: <200311191632.hAJGWdCG026833@rotala.raleigh.ibm.com> To: john.loughney@nokia.com cc: ipv6@ietf.org Subject: Re: Issue 19 of draft-ietf-ipv6-node-requirements-05.txt In-Reply-To: Message from john.loughney@nokia.com of "Wed, 19 Nov 2003 16:36:44 +0200." Date: Wed, 19 Nov 2003 11:32:39 -0500 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I'm OK with the proposed text, except Pekka Savola asked me if it should > be changed to: > Nodes MUST always be able to send, receive and process fragment > ^^^^^^^^^^^ > headers. Note that even in the case where a sender does not > .... > Let me know if this is OK. OK with me. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 11:39:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25254 for ; Wed, 19 Nov 2003 11:39:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVMJ-0005qh-7I for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 11:39:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJGdFXu022477 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 11:39:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVMJ-0005qS-1p for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 11:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25194 for ; Wed, 19 Nov 2003 11:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVMI-0002dk-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 11:39:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVMH-0002dg-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 11:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVM7-0005h1-Bf; Wed, 19 Nov 2003 11:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVM4-0005gI-Uu for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 11:39:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25178 for ; Wed, 19 Nov 2003 11:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVM2-0002dH-00 for ipv6@ietf.org; Wed, 19 Nov 2003 11:38:58 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMVM1-0002dD-00 for ipv6@ietf.org; Wed, 19 Nov 2003 11:38:58 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 52C7C6A90D; Wed, 19 Nov 2003 18:38:57 +0200 (EET) Message-ID: <3FBB9B9E.8030402@kolumbus.fi> Date: Wed, 19 Nov 2003 18:34:38 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com, brian@innovationslab.net Cc: ipv6@ietf.org, mrw@windriver.com Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>Perhaps the only question that I have left is... whether >>IPv6 nodes should support MLDv2 instead of MLDv1. The >>node requirements document and the MLDv2 draft intro >>gives the impression that the only difference is >>source-specific filtering. Then the current node >>reqs rules make sense. But Appendix B of the MLDv2 >>draft seems to list a number of other modifications, >>including some enhancements to robustness. Are these >>important? I'm not an expert enough to determine that. > > > Appendicies are non-normative, so I think that we don't need to > worry about it in the Node Requirements document, though > I am by no means an MLD expert. Appendix B of the MLDv2 draft is simply a list of changes from MLDv1. While this list is non-normative, I think the changes are in the body... so my question is whether there's really a bit more to MLDv2 than source-specific multicast. But lets stop the discussion between MLD non-experts and ask someone who knows: Brian, are there other improvements in MLDv2 than source-specific multicast? If yes, are those significant enough that nodes should migrate to MLDv2 even if they don't use the source-specific multicast feature? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 12:40:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28890 for ; Wed, 19 Nov 2003 12:40:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWJl-00027A-3Y for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 12:40:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHeeMD008121 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 12:40:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWJf-00026s-1b for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:40:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28847 for ; Wed, 19 Nov 2003 12:40:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWJd-0004Sj-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 12:40:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWJd-0004Sg-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 12:40:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWJC-00020g-SJ; Wed, 19 Nov 2003 12:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWJ5-0001zl-IV for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 12:39:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28819 for ; Wed, 19 Nov 2003 12:39:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWJ3-0004Rf-00 for ipv6@ietf.org; Wed, 19 Nov 2003 12:39:58 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AMWJ2-0004Qb-00 for ipv6@ietf.org; Wed, 19 Nov 2003 12:39:57 -0500 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 hAJHakV02148; Wed, 19 Nov 2003 09:36:46 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAJHf2tX021500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Nov 2003 09:41:13 -0800 Message-ID: <3FBBAA1C.6060702@innovationslab.net> Date: Wed, 19 Nov 2003 12:36:28 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: john.loughney@nokia.com, ipv6@ietf.org, Margaret Wasserman Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBB8EB6.50707@kolumbus.fi> In-Reply-To: <3FBB8EB6.50707@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 >> >> If an application is going to join any-source multicast group >> addresses, it SHOULD implement MLDv1. When MLD is used, the rules in >> "Source Address Selection for the Multicast Listener Discovery (MLD) >> Protocol" [RFC-3590] MUST be followed. >> >> >>>> If I understand correctly, these nodes could support either >>>> MLDv1 or MLDv2. > > > The document already allows either MLDv1 or MLDv2 to > be used. And yes, MLDv2 is backwards compatible to > MLDv1 as John pointed out. > > Perhaps the only question that I have left is... whether > IPv6 nodes should support MLDv2 instead of MLDv1. The > node requirements document and the MLDv2 draft intro > gives the impression that the only difference is > source-specific filtering. Then the current node > reqs rules make sense. But Appendix B of the MLDv2 > draft seems to list a number of other modifications, > including some enhancements to robustness. Are these > important? I'm not an expert enough to determine that. I had suggested awhile back that MLDv2 should be the preferred choice for group management in the node requirements. At that time, MLDv2 was still being worked in the MAGMA WG so people didn't want to hold up this document on the MLDv2 spec. The key advantage of MLDv2 is the source filtering ability. And with people talking/complaining about the lack of SSM support in v6 implementations, I think node reqs should lean heavier on MLDv2. There is no lack of traditional multicast capability since MLDv2 supports MLDv1 for backwards compatability. The discussions in the MLDv2 appendix are helpful in understanding the changes in protocol behavior, but they aren't as important as the source filtering. So, unless people want to re-open the discussion on what group management protocol should be put forth (which I don't, I am happy with what is there), I think the doc is fine. Regards, Brian (without either chair hat on) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 12:48:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29303 for ; Wed, 19 Nov 2003 12:48:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWRL-0002s6-4M for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 12:48:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHmVWL011032 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 12:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWRK-0002rr-S2 for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:48:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29257 for ; Wed, 19 Nov 2003 12:48:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWRJ-0004kA-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 12:48:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWRI-0004k7-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 12:48:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWQt-0002e9-Cp; Wed, 19 Nov 2003 12:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWQo-0002dc-1T for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 12:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29199 for ; Wed, 19 Nov 2003 12:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWQm-0004j8-00 for ipv6@ietf.org; Wed, 19 Nov 2003 12:47:56 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AMWQj-0004hY-00 for ipv6@ietf.org; Wed, 19 Nov 2003 12:47:53 -0500 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 hAJHjPV02239; Wed, 19 Nov 2003 09:45:25 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAJHnitX021613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Nov 2003 09:49:52 -0800 Message-ID: <3FBBAC25.7050209@innovationslab.net> Date: Wed, 19 Nov 2003 12:45:09 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: john.loughney@nokia.com, ipv6@ietf.org, mrw@windriver.com Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBB9B9E.8030402@kolumbus.fi> In-Reply-To: <3FBB9B9E.8030402@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > john.loughney@nokia.com wrote: > >>> Perhaps the only question that I have left is... whether >>> IPv6 nodes should support MLDv2 instead of MLDv1. The >>> node requirements document and the MLDv2 draft intro >>> gives the impression that the only difference is >>> source-specific filtering. Then the current node >>> reqs rules make sense. But Appendix B of the MLDv2 >>> draft seems to list a number of other modifications, >>> including some enhancements to robustness. Are these >>> important? I'm not an expert enough to determine that. >> >> >> >> Appendicies are non-normative, so I think that we don't need to >> worry about it in the Node Requirements document, though I am by no >> means an MLD expert. > > > Appendix B of the MLDv2 draft is simply a list of changes > from MLDv1. While this list is non-normative, I think the > changes are in the body... so my question is whether there's > really a bit more to MLDv2 than source-specific multicast. > But lets stop the discussion between MLD non-experts and > ask someone who knows: Brian, are there other improvements > in MLDv2 than source-specific multicast? If yes, are those > significant enough that nodes should migrate to MLDv2 > even if they don't use the source-specific multicast feature? So, I think I answered this already in an earlier message, but let me clarify something here. The IP stack layer really does not know what kinds of multicast applications are going to be run on it. A user could arbitrarily install an SSM application just as easily as an ASM application, if the stack supports multicast at all. With that in mind, if a stack developer knows for sure that his stack couldn't be used for a certain flavor of multicast application (SSM or ASM), then he can use the current guidelines in the node reqs to determine whether MLDv1 or MLDv2 should be supported. In all other cases, I would prefer MLDv2 for flexibility reasons. So, if I back off my answer in the last post a little, perhaps the wording for any-source should be something like "SHOULD support MLDv2 but MAY support MLDv1". Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 12:48:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29325 for ; Wed, 19 Nov 2003 12:48:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWRL-0002sO-JT for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 12:48:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHmVjW011050 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 12:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWRL-0002s9-DI for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29260 for ; Wed, 19 Nov 2003 12:48:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWRJ-0004kD-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 12:48:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWRI-0004k6-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 12:48:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWQr-0002dt-U9; Wed, 19 Nov 2003 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWQH-0002dB-Bt for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 12:47:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29150 for ; Wed, 19 Nov 2003 12:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWQF-0004hd-00 for ipv6@ietf.org; Wed, 19 Nov 2003 12:47:23 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMWQF-0004gH-00 for ipv6@ietf.org; Wed, 19 Nov 2003 12:47:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJHkiD17220; Wed, 19 Nov 2003 09:46:44 -0800 X-mProtect: <200311191746> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPLoShk; Wed, 19 Nov 2003 09:46:43 PST Message-ID: <3FBBAE3E.3070500@iprg.nokia.com> Date: Wed, 19 Nov 2003 09:54:06 -0800 From: Fred 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: Pekka Savola CC: ipv6@ietf.org Subject: Re: draft-hain-templin-ipv6-localcomm-03 comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The attitude you're expressing does not seem to be in the spirit of collaborative discussion, which I find somewhat unusual and disappointing coming from you. But, if that is your position you are certainly entitled to it and I have no problem with it. Thanks - Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >Hi, > >I just about used up all my aspirin and tranquilizers trying to read >this message constructively and trying to write a constructive reply >to this message but failed. > >I don't think this document is constructive as a requirements >document, and I'll strongly oppose it being adopted as WG document >at any point of time. > >On Mon, 17 Nov 2003, Fred Templin wrote: > > >>>well, the document seems like to completely concentrate on an >>>addressing-based solution model.. which it probably should not. Anyone >>>even glancing at the document can be 100% sure of this. >>> >>>Or was it only supposed to be agnostic of whether local-use addressing was >>>needed? There's a difference there.. >>> >>>So, I agree 100% with Erik's earlier comments on the "coloring" and the >>>"background" of the document.. >>> >>> >>> >>I'm still waiting to see the specific comments that will correct this >>often-expressed wrong impression. Maybe they will appear below; >>I'll respond as I go and see where we end up. >> >> >> >>>(I only read the beginning of the draft, got too big a headache..) >>> >>> >>> >>Take some aspirin, then. >> >> >> >>>substantial >>>----------- >>> >>>1) the whole section 3.2 Maintaining Confidentiality of the Address Space is >>>pretty much bogus. Remember, we're talking about using local communications >>>with *IPv6*. With IPv4, you would be required to record the address >>>prefixes in the RIR registries etc. -- but these are no longer relevant. >>>You get one /48, put it in the registry, that's it. No exposing needed. >>> >>>Beyond that, all the exposing you'd do is what you choose to do yourself. >>>If you don't want to give e.g. people the ability to traceroute through the >>>network to learn the network properties, you can prevent that. >>> >>>In summary, this whole section should be removed or seriously reworded. >>> >>> >>> >>I disagree. Network managers should be empowered to self-select >>addresses to be used for internal-only communications and with >>no pre-arrangement with a RIR. For example, in IPv4 I know that >>network 15/8 is owned by HP, network 16/8 is (was?) owned by >>Digital Equipment Corporation, etc. But, general knowledge of >>this is nothing more than a burden on the party holding the >>registration, since they now need to concern themselves with >>liabilities for misuse of the RIR prefixes. >> >>In IPv6, there should be no reason for even this level of >>exposure if the addresses are indeed to be used only for local >>communications. Thus, the ability for network managers to >>self-select addresses would be an improvement over the existing >>condition for IPv4. >> >> >> >>>2) I don't see the point of section 3.3 myself: >>> >>> Test networks are frequently large, elaborate networks with a mix of >>> public and private address space. Use of random unallocated space >>> runs the risk of collision with legitimate addresses on remote >>> networks if the test network is ever connected to the Internet. >>> >>>==> what kind of test network are you talking about? >>>why would you ever connect a test to the Internet, except through some DMZ >>>hosts/routers etc? >>> >>>With IPv6, you have enough addresses to play around if you want to connect >>>something to the net. If you don't, you can just invent something (most TAC >>>etc. labs probably certaintly do). No magic there... >>> >>>Needs rewording to bring up the point better or remove.. >>> >>> >>> >>OK, how about this: >> >> "Test networks often provide a vehicle for limited experimentation >> with new Internetworking technologies prior to widescale deployment, >> but they may need to connect to the Internet to facilitate the >>experiment. >> Such experiments may entail large, elaborate networks with a mix of >> public and private address space, but the use of random unallocated >> space runs the risk of collision with legitimate addresses on remote >> networks." >> >>But, is this enough to warrant a new document revision? I >>don't think so. >> >> >> >>>3) there is solutionism/assuming the addressing is the answer in many of the >>>goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8. Intentional? >>> >>> >>> >>Please provide specific examples of text that you believe assumes >>a particular solution alternative, since there was no intention to >>dictate a particular alternative. >> >>If certain solution alternatives seem to suggest themselves based on >>the scenarios, then the document is doing its work - but this is NOT >>due to the intentional manipulation of the authors (see changelogs >>and acknolwedgements for the substantial community input already >>taken). >> >> >> >>>4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the >>>text), could be removed ? >>> >>> >>> >>This is a valid point, but I prefer to say that sections 3.6.2 and 3.5 >>could be consolidated rather than removing one or the other. Does >>this warrant another revision, though? My take is no. >> >> >> >>>5) section 3.7 is a bit incomprehensible: >>> >>>3.7 Asset Protection in Enterprise Networks >>> >>> Enterprise networks that protect private corporate assets (e.g., >>> printers, faxes, robotics, sensors, etc.) require an addressing >>> scheme that remains stable even when VPN connections from outside >>> sites occur. >>> >>>==> how on earth would VPN connections from outside disturb a stable >>>addressing scheme?!? >>> >>> >>> >>We are talking here about site mergers, which becomes apparent >>in the subsequent sentences of that paragraph. When two sites >>merge, ongoing local communications which were in-progress >>within the two seperate sites should continue without breaking >>when the two sites become one. >> >>The sentences you cite above are taken out of context, and the >>meaning seems clear enough when they are considered within >>the context of the entire section. >> >> >> >>>6) it's no surprise that section 4 on goals presupposes an addressing-based >>>solution. Is this intentional? In any case, the titles are: >>> >>>4.1 Easy to Acquire >>>4.2 Stable >>>4.3 Multiple Link Support >>>4.4 Prefix Filtering and Hints to Applications >>>4.5 Globally Unique >>>4.6 Usable in the Absence of a Provider >>>4.7 Applicable in Managed/Unmanaged Environments >>>4.8 Compatible with Site Naming System >>>4.9 Compatible with VPN >>>4.10 Multiple Addressing >>> >>>one could generalize and reword these to: >>> >>>4.1 Easy to Take to Use >>>4.2 Session Stability >>>4.3 Multiple Link Support >>>4.4 Application Awareness of Policy >>>4.5 Locality Between Multiple Sites >>>4.6 Usable in the Absence of a Provider >>>4.7 Applicable in Managed/Unmanaged Environments >>>4.8 Compatible with Site Naming System >>>4.9 Compatible with VPN (XXX: ?) >>>4.10 Provision for Both Local and Global Communications >>> >>> >>> >>One could always re-word, yes, but re-wording can always >>be done ad-inifinitum. I don't see anything in any of these >>suggestions that provides any beneficial clarification. >> >> >> >>>semi-editorial >>>-------------- >>> >>>Abstract >>> >>> The IPv6 addressing architecture specifies global and local-use >>> unicast addressing schemes, but provides no operational guidelines >>> for their use. >>> >>>and: >>> >>>1. Introduction >>> >>> The IPv6 addressing architecture [RFC3513] specifies global and >>> local-use unicast addresses. Global addresses are understood to have >>> unlimited range and may be used as the source and destination >>> addresses in packets that originate from any point on the connected >>> global IPv6 Internet. Local-use addresses are intended for use only >>> within the range of a single link/site, but their specification does >>> not address operational considerations for real-world deployment >>> scenarios. >>> >>>==> the critical local-use addressing part is to be removed before this >>>becomes relevant, so I don't think it's appropriate to refer to these >>>documents here. Suggest removing or serious rewording. >>> >>> >>> >>Update from [RFC3513] to [RFC3513(bis)] you mean? >>I don't see this in and of itself necessitating a document >>update; in fact, the role of the hain-templin document is >>to set the target in motion - not to track the target as it >>moves. >> >> >> >>>.... >>> >>>. As such, >>> the address prefixes used in each PAN should be globally unique to >>> avoid collisions and provide a means for verifying ownership to >>> resolve conflicts. >>> >>>==> this (in 3.5) doesn't seem to be relevant to the local communications, >>>remove? >>> >>> >>> >>This goes with the above comment on consolidating sections 3.5 >>and 3.6.2, but do these alone warrant a new document revision? >>My take is that they don't. >> >> >> >> >>>editorial >>>--------- >>> >>>. Of >>> utmost importance is that the systems on board the ship all function, >>> >>>==> s/Of utmost importance is/It's of utmost importance/ >>> >>> >>> >>Noted. >> >>Fred >>ftemplin@iprg.nokia.com >> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >> >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 13:03:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00082 for ; Wed, 19 Nov 2003 13:03:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfe-0003xH-E6 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 13:03:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJI3HPd015194 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 13:03:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfd-0003va-Hj for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 13:03:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29986 for ; Wed, 19 Nov 2003 13:03:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWfb-0005AD-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 13:03:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWfa-0005A9-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 13:03:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfN-0003kA-UA; Wed, 19 Nov 2003 13:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWen-0003iv-Q4 for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 13:02:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29951 for ; Wed, 19 Nov 2003 13:02:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWel-00058k-00 for ipv6@ietf.org; Wed, 19 Nov 2003 13:02:23 -0500 Received: from sixnet.u-strasbg.fr ([130.79.90.153]) by ietf-mx with esmtp (Exim 4.12) id 1AMWek-00058d-00 for ipv6@ietf.org; Wed, 19 Nov 2003 13:02:23 -0500 Received: from crc.u-strasbg.fr (localhost [127.0.0.1]) by sixnet.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id hAJI2JX0001654; Wed, 19 Nov 2003 19:02:19 +0100 (CET) (envelope-from Jean-Jacques.Pansiot@crc.u-strasbg.fr) Message-ID: <3FBBB02B.3000504@crc.u-strasbg.fr> Date: Wed, 19 Nov 2003 19:02:19 +0100 From: Jean-Jacques Pansiot Organization: ULP LSIIT & Departement d'Informatique User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020811 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: ipv6@ietf.org CC: Brian Haberman , Jari Arkko , john.loughney@nokia.com, mrw@windriver.com Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBB9B9E.8030402@kolumbus.fi> <3FBBAC25.7050209@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian Haberman wrote: > > > Jari Arkko wrote: > >> john.loughney@nokia.com wrote: >> >>>> Perhaps the only question that I have left is... whether >>>> IPv6 nodes should support MLDv2 instead of MLDv1. The >>>> node requirements document and the MLDv2 draft intro >>>> gives the impression that the only difference is >>>> source-specific filtering. Then the current node >>>> reqs rules make sense. But Appendix B of the MLDv2 >>>> draft seems to list a number of other modifications, >>>> including some enhancements to robustness. Are these >>>> important? I'm not an expert enough to determine that. >>> >>> >>> >>> >>> Appendicies are non-normative, so I think that we don't need to >>> worry about it in the Node Requirements document, though I am by no >>> means an MLD expert. >> >> >> >> Appendix B of the MLDv2 draft is simply a list of changes >> from MLDv1. While this list is non-normative, I think the >> changes are in the body... so my question is whether there's >> really a bit more to MLDv2 than source-specific multicast. >> But lets stop the discussion between MLD non-experts and >> ask someone who knows: Brian, are there other improvements >> in MLDv2 than source-specific multicast? If yes, are those >> significant enough that nodes should migrate to MLDv2 >> even if they don't use the source-specific multicast feature? > > > So, I think I answered this already in an earlier message, but let > me clarify something here. The IP stack layer really does not know > what kinds of multicast applications are going to be run on it. > A user could arbitrarily install an SSM application just as easily > as an ASM application, if the stack supports multicast at all. > > With that in mind, if a stack developer knows for sure that his stack > couldn't be used for a certain flavor of multicast application (SSM > or ASM), then he can use the current guidelines in the node reqs to > determine whether MLDv1 or MLDv2 should be supported. > > In all other cases, I would prefer MLDv2 for flexibility reasons. > > So, if I back off my answer in the last post a little, perhaps the > wording for any-source should be something like "SHOULD support MLDv2 > but MAY support MLDv1". Hi, I think that running MLDv1 on a host has consequences on other hosts on the same link : if a host send a MLDv1 report for a group G, then the router (Querier) must run in MLDv1 compatibility mode. In effect, this prevents other hosts on the same link to use MLDv2 and source selection for this group Jean-Jacques > > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 13:23:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01287 for ; Wed, 19 Nov 2003 13:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWyy-0005bw-D1 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 13:23:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJINGfX021562 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 13:23:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWyy-0005bh-7n for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 13:23:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01262 for ; Wed, 19 Nov 2003 13:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWyu-0005pd-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 13:23:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWyu-0005pa-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 13:23:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWyk-0005Ut-5o; Wed, 19 Nov 2003 13:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWyA-0005Tf-JU for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 13:22:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01225; Wed, 19 Nov 2003 13:22:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWy8-0005o3-00; Wed, 19 Nov 2003 13:22:24 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMWy7-0005nS-00; Wed, 19 Nov 2003 13:22:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJILmP19161; Wed, 19 Nov 2003 10:21:48 -0800 X-mProtect: <200311191821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ7MgF4; Wed, 19 Nov 2003 10:21:46 PST Message-ID: <3FBBB658.7000108@iprg.nokia.com> Date: Wed, 19 Nov 2003 10:28:40 -0800 From: Fred 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: Eddie Kohler CC: "Phelan, Tom" , dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [dccp] PMTU issues References: <200311191421.hAJELXIe072495@coyote.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddie, Yes, I agree with the idea of initially "plumbing" the path MTU when a connection starts up. If the application has lots of data to send, it might initially try to plumb out to the largest possible MTU; if only a little, it might be less aggressive during startup. It might also be desireable to piggyback the plumbing process onto other messages that require a RTT before the connection can be tried. For example, IPv6 neighbor discovery messages (e.g., Router Solicitations) can be null-padded to any length out to 64KB when they are sent over an IPv6-in-IPv4 tunnel interface. See the next to last paragraph in section 3.6 of: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt Thanks - Fred ftemplin@iprg.nokia.com Eddie Kohler wrote: >>It's also possible for DCCP to get a better initial estimate of the PMTU, >>and apparently there are other problems with the current DCCP PMTUD >>mechanism (using ICMP "can't fragment" messages). >> >> > >Yes -- The current draft tries to make clear (but fails to) that a new, >PLPMTUD-style MTU discovery mechanism is acceptable. There are API problems >with such a scheme, but we absolutely allow it. > >If you can accept an extra RTT or two at connection initiation time, I >think you can do pretty well: > > Request --> > <-- Response > then, all in 1 RTT: > Padded Sync(512 bytes) --> /* actual #s would need to fit CC > Padded Sync(1280 bytes) --> mechanism */ > Padded Sync(4000 bytes) --> > <-- SyncReply(1) /* SyncReplies sent only for those > <-- SyncReply(2) packets that got through */ > <-- SyncReply(3) > > > >>So, my question for the DCCP people, is it worth changing DCCP PMTUD? >> >> > >It's certainly worth describing it better, and perhaps mentioning a set of >acceptable procedures. Have you any suggestions for useful procedures >here? > >Eddie > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 13:31:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01730 for ; Wed, 19 Nov 2003 13:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMX6j-0006QK-Bj for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 13:31:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJIVHma024690 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 13:31:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMX6i-0006Q9-SY for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 13:31:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01660 for ; Wed, 19 Nov 2003 13:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMX6g-00063r-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 13:31:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMX6g-00062c-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 13:31:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMX6U-0006C9-NK; Wed, 19 Nov 2003 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMX61-0006B5-3z for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 13:30:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01619; Wed, 19 Nov 2003 13:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMX5y-00061J-00; Wed, 19 Nov 2003 13:30:30 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMX5y-00060R-00; Wed, 19 Nov 2003 13:30:30 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAJITfb19176; Wed, 19 Nov 2003 20:29:41 +0200 Date: Wed, 19 Nov 2003 20:29:41 +0200 (EET) From: Pekka Savola To: Eddie Kohler cc: "Phelan, Tom" , Fred Templin , , , , Subject: Re: [dccp] PMTU issues In-Reply-To: <200311191421.hAJELXIe072495@coyote.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Everyone, Please discontinue this discussion at v6ops@ops.ietf.org list. Thanks, Pekka writing as v6-ops co-chair On Wed, 19 Nov 2003, Eddie Kohler wrote: > > It's also possible for DCCP to get a better initial estimate of the PMTU, > > and apparently there are other problems with the current DCCP PMTUD > > mechanism (using ICMP "can't fragment" messages). > > Yes -- The current draft tries to make clear (but fails to) that a new, > PLPMTUD-style MTU discovery mechanism is acceptable. There are API problems > with such a scheme, but we absolutely allow it. > > If you can accept an extra RTT or two at connection initiation time, I > think you can do pretty well: > > Request --> > <-- Response > then, all in 1 RTT: > Padded Sync(512 bytes) --> /* actual #s would need to fit CC > Padded Sync(1280 bytes) --> mechanism */ > Padded Sync(4000 bytes) --> > <-- SyncReply(1) /* SyncReplies sent only for those > <-- SyncReply(2) packets that got through */ > <-- SyncReply(3) > > > So, my question for the DCCP people, is it worth changing DCCP PMTUD? > > It's certainly worth describing it better, and perhaps mentioning a set of > acceptable procedures. Have you any suggestions for useful procedures > here? > > Eddie > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 14:14:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04583 for ; Wed, 19 Nov 2003 14:14:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXmX-0000T0-Jh for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 14:14:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJJETeZ001780 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 14:14:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXmW-0000Sd-BZ for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 14:14:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04524 for ; Wed, 19 Nov 2003 14:14:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXmT-0007LJ-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 14:14:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMXmT-0007LG-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 14:14:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXm6-0000Mr-Hx; Wed, 19 Nov 2003 14:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXm4-0000MY-5B for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 14:14:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04510 for ; Wed, 19 Nov 2003 14:13:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXm1-0007Kb-00 for ipv6@ietf.org; Wed, 19 Nov 2003 14:13:57 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMXm1-0007Jw-00 for ipv6@ietf.org; Wed, 19 Nov 2003 14:13:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJJCXa03559; Wed, 19 Nov 2003 11:12:33 -0800 X-mProtect: <200311191912> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5cBMN9; Wed, 19 Nov 2003 11:12:31 PST Message-ID: <3FBBC25C.9050106@iprg.nokia.com> Date: Wed, 19 Nov 2003 11:19:56 -0800 From: Fred 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: john.loughney@nokia.com CC: narten@us.ibm.com, ipv6@ietf.org Subject: Re: Issue 19 of draft-ietf-ipv6-node-requirements-05.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Agreed with both Thomas' text and Pekka's additional: "and process"; that part is important. Fred ftemplin@iprg.nokia.com john.loughney@nokia.com wrote: >Thomas, > > > >>how about: >> >> Nodes MUST always be able to send and receive fragment >> headers. Note that even in the case where a sender does not >> implement or use Path MTU discovery [RFC 1981], the sender >> must still be prepared to send fragment headers, even for >> packets that are smaller than the minimal IPv6 link MTU of >> 1280 octets. See Section 5 of [RFC 2460] for details. >> >> > >I'm OK with the proposed text, except Pekka Savola asked me if it should >be changed to: > > Nodes MUST always be able to send, receive and process fragment > ^^^^^^^^^^^ > headers. Note that even in the case where a sender does not > .... > >Let me know if this is OK. > >John > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 14:46:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06054 for ; Wed, 19 Nov 2003 14:46:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYHZ-0002Pu-JE for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 14:46:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJJkXrM009289 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 14:46:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYHZ-0002Pk-5t for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 14:46:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06015 for ; Wed, 19 Nov 2003 14:46:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYHW-0000Tj-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 14:46:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMYHV-0000Tg-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 14:46:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYH3-0002DT-WB; Wed, 19 Nov 2003 14:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYGz-0002D7-Cs for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 14:45:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05979 for ; Wed, 19 Nov 2003 14:45:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYGw-0000Qn-00 for ipv6@ietf.org; Wed, 19 Nov 2003 14:45:54 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AMYGv-0000QE-00 for ipv6@ietf.org; Wed, 19 Nov 2003 14:45:53 -0500 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 hAJJh9V03142; Wed, 19 Nov 2003 11:43:09 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAJJlWtX022112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Nov 2003 11:47:36 -0800 Message-ID: <3FBBC7BF.7050205@innovationslab.net> Date: Wed, 19 Nov 2003 14:42:55 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Jacques Pansiot CC: ipv6@ietf.org, Jari Arkko , john.loughney@nokia.com, mrw@windriver.com Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBB9B9E.8030402@kolumbus.fi> <3FBBAC25.7050209@innovationslab.net> <3FBBB02B.3000504@crc.u-strasbg.fr> In-Reply-To: <3FBBB02B.3000504@crc.u-strasbg.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jean-Jacques Pansiot wrote: > Brian Haberman wrote: > >> >> >> Jari Arkko wrote: >> >>> john.loughney@nokia.com wrote: >>> >>>>> Perhaps the only question that I have left is... whether >>>>> IPv6 nodes should support MLDv2 instead of MLDv1. The >>>>> node requirements document and the MLDv2 draft intro >>>>> gives the impression that the only difference is >>>>> source-specific filtering. Then the current node >>>>> reqs rules make sense. But Appendix B of the MLDv2 >>>>> draft seems to list a number of other modifications, >>>>> including some enhancements to robustness. Are these >>>>> important? I'm not an expert enough to determine that. >>>> >>>> >>>> >>>> >>>> >>>> Appendicies are non-normative, so I think that we don't need to >>>> worry about it in the Node Requirements document, though I am by no >>>> means an MLD expert. >>> >>> >>> >>> >>> Appendix B of the MLDv2 draft is simply a list of changes >>> from MLDv1. While this list is non-normative, I think the >>> changes are in the body... so my question is whether there's >>> really a bit more to MLDv2 than source-specific multicast. >>> But lets stop the discussion between MLD non-experts and >>> ask someone who knows: Brian, are there other improvements >>> in MLDv2 than source-specific multicast? If yes, are those >>> significant enough that nodes should migrate to MLDv2 >>> even if they don't use the source-specific multicast feature? >> >> >> >> So, I think I answered this already in an earlier message, but let >> me clarify something here. The IP stack layer really does not know >> what kinds of multicast applications are going to be run on it. >> A user could arbitrarily install an SSM application just as easily >> as an ASM application, if the stack supports multicast at all. >> >> With that in mind, if a stack developer knows for sure that his stack >> couldn't be used for a certain flavor of multicast application (SSM >> or ASM), then he can use the current guidelines in the node reqs to >> determine whether MLDv1 or MLDv2 should be supported. >> >> In all other cases, I would prefer MLDv2 for flexibility reasons. >> >> So, if I back off my answer in the last post a little, perhaps the >> wording for any-source should be something like "SHOULD support MLDv2 >> but MAY support MLDv1". > > Hi, > > I think that running MLDv1 on a host has consequences on other hosts > on the same link : if a host send a MLDv1 report for a group G, > then the router (Querier) must run in MLDv1 compatibility mode. > In effect, this prevents other hosts on the same link to use MLDv2 > and source selection for this group. The limitation is per group. That is, the querying router will operate in MLDv1 compatability mode for G when it sees an MLDv1 Report for G. All other groups will remain in MLDv2 mode. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 15:29:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09960 for ; Wed, 19 Nov 2003 15:29:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYwM-0005ck-L7 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 15:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKSgPQ021612 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 15:28:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYwM-0005cV-H4 for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15:28:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09896 for ; Wed, 19 Nov 2003 15:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYwI-0001XC-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 15:28:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMYwH-0001X8-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 15:28:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYvi-0005QH-Rk; Wed, 19 Nov 2003 15:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYvI-0005M0-KM for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 15:27:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09661 for ; Wed, 19 Nov 2003 15:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYv4-0001VD-00 for ipv6@ietf.org; Wed, 19 Nov 2003 15:27:22 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMYv4-0001V9-00 for ipv6@ietf.org; Wed, 19 Nov 2003 15:27:22 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 750C26A90D; Wed, 19 Nov 2003 22:27:15 +0200 (EET) Message-ID: <3FBBC711.4080707@kolumbus.fi> Date: Wed, 19 Nov 2003 21:40:01 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBB9B9E.8030402@kolumbus.fi> <3FBBAC25.7050209@innovationslab.net> In-Reply-To: <3FBBAC25.7050209@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian Haberman wrote: > So, I think I answered this already in an earlier message, but let > me clarify something here. The IP stack layer really does not know > what kinds of multicast applications are going to be run on it. > A user could arbitrarily install an SSM application just as easily > as an ASM application, if the stack supports multicast at all. > > With that in mind, if a stack developer knows for sure that his stack > couldn't be used for a certain flavor of multicast application (SSM > or ASM), then he can use the current guidelines in the node reqs to > determine whether MLDv1 or MLDv2 should be supported. > > In all other cases, I would prefer MLDv2 for flexibility reasons. > > So, if I back off my answer in the last post a little, perhaps the > wording for any-source should be something like "SHOULD support MLDv2 > but MAY support MLDv1". With your explanation of the stack - app issues, I think this would make sense. If others agree, and suitable text can be crafted, of course. Anyway, this is not a crucial issue for me but I just wanted to understand the implications. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 19 15:29:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09975 for ; Wed, 19 Nov 2003 15:29:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYwK-0005cO-9s for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 15:28:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKSeSN021594 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 15:28:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYwJ-0005cD-TC for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15:28:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09894 for ; Wed, 19 Nov 2003 15:28:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYwI-0001XF-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 15:28:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMYwI-0001XA-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 15:28:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYvk-0005QT-Gi; Wed, 19 Nov 2003 15:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYvI-0005M1-KP for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 15:27:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09662 for ; Wed, 19 Nov 2003 15:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYv4-0001VF-00 for ipv6@ietf.org; Wed, 19 Nov 2003 15:27:22 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMYv4-0001V8-00 for ipv6@ietf.org; Wed, 19 Nov 2003 15:27:22 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 464816A911; Wed, 19 Nov 2003 22:27:20 +0200 (EET) Message-ID: <3FBBCF9D.5030309@kolumbus.fi> Date: Wed, 19 Nov 2003 22:16:29 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com, Margaret Wasserman Cc: ipv6@ietf.org Subject: Re: Node Req. Issue 28: Security Considerations References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>>In the IPsec section, you mention that other security issues >>>will be covered in the Security Considerations section, but >>>I don't see any issues here... There used to be some things, but they got removed because people felt that those things belong to the individual protocol RFCs, or their future updates. >>>Why aren't privacy addresses covered in this document? > > > Should this be covered in the security section? Already, section > 4.5.3 talks about privacy extensions. Do we need more? As I mentioned, there's been a debate whether the specific issues belong here or in the individual RFCs. As John says, we already have a section for RFC 3041 and I am not aware of any specific IPv6 security issues it would raise beyond those mentioned in the document itself. As we were working on RFC 3316 (cellular hosts), we did discuss privacy issues a little bit in the security considerations section. But there we had a reason, as we explained the specific implications and benefits (or lack thereof) of using RFC 3041 in cellular networks. As an example, since every host had its own prefix, obfuscating the interface identifier did not help quite as much as it did in Ethernet. Here we don't have that specific situation. >>>Also, did you consider a recommendation that IPv6 nodes should >>>implement SEND? Perhaps you should at least mention the >>>security issues with ND and indicate that the SEND group is >>>working to resolve them? > > > I believe we did not want this kind of forward reference to stuff > that is on-going. However, if people feel that the SEND stuff > is stable enough, we could put in a reference. Borderline. Back in IETF-56 & 57 we believed node reqs would be done much sooner than SEND. Now in SEND we have a plan to finish all work and have the WG go to sleep; the draft will be reissued once within a couple of weeks, then reviewed, and then reissued again and sent to IESG. So it might be off to the IESG this year. Assuming I find time to edit the draft ;-) If it gets there in time before node reqs is approved, we probably should add a reference. But it looks like we might agree about node reqs soon, so SEND probably completes slightly later. In that case there's no sense in waiting for SEND. Anyway, that reminds me that while redoing RFC 2461, we should probably tone down the language a bit regarding the use of AH; there's widely known issues with that (send documents some of these, draft-arkko-icmpv6-ike-effects talks about others). I'm not sure we should present AH any more as general solution. Perhaps SEND is done by the time that 2461bis is ready, so it could reference some of the SEND documents. Also, I'm not sure I agree with the RFC 2460 statement that the node requirements document quotes: The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401]. I don't agree because we appear to have a number of other security features in IPv6 in addition to IPsec. MIPv6 RR, ND options for certs and CGAs in SEND, etc. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 00:45:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05117 for ; Thu, 20 Nov 2003 00:45:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhdF-0006Ox-ND for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 00:45:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK5jXo0024603 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 00:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhdF-0006Ok-IZ for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 00:45:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05084 for ; Thu, 20 Nov 2003 00:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMhdC-0003wY-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 00:45:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMhdC-0003wV-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 00:45:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhcl-0006J2-0n; Thu, 20 Nov 2003 00:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMhcV-0006IX-PW for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 00:44:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05063 for ; Thu, 20 Nov 2003 00:44:32 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMhcS-0003vr-00 for ipv6@ietf.org; Thu, 20 Nov 2003 00:44:45 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMhcS-0003vo-00 for ipv6@ietf.org; Thu, 20 Nov 2003 00:44:44 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK5ih602364 for ; Thu, 20 Nov 2003 07:44:43 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 07:44:41 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 07:44:40 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 07:44:39 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 29: AD REVIEW: IPv6 Node Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 07:44:39 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOu28t59wimqBXLTtSXmpW7Q1lZygATYa/A To: , Cc: X-OriginalArrivalTime: 20 Nov 2003 05:44:39.0994 (UTC) FILETIME=[63D529A0:01C3AF29] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jari, Brian, > > So, I think I answered this already in an earlier message, but let > > me clarify something here. The IP stack layer really does not know > > what kinds of multicast applications are going to be run on it. > > A user could arbitrarily install an SSM application just as easily > > as an ASM application, if the stack supports multicast at all. > >=20 > > With that in mind, if a stack developer knows for sure that=20 > his stack > > couldn't be used for a certain flavor of multicast application (SSM > > or ASM), then he can use the current guidelines in the node reqs to > > determine whether MLDv1 or MLDv2 should be supported. > >=20 > > In all other cases, I would prefer MLDv2 for flexibility reasons. > >=20 > > So, if I back off my answer in the last post a little, perhaps the > > wording for any-source should be something like "SHOULD support = MLDv2 > > but MAY support MLDv1". >=20 > With your explanation of the stack - app issues, I think this > would make sense. If others agree, and suitable text can be > crafted, of course. Anyway, this is not a crucial issue for > me but I just wanted to understand the implications. I agree. I'll add the suggested text. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 02:35:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20944 for ; Thu, 20 Nov 2003 02:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjLW-0004cj-3P for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 02:35:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK7ZMwW017773 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 02:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjLV-0004cZ-KV for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 02:35:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20875 for ; Thu, 20 Nov 2003 02:35:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjLS-0005VL-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 02:35:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjLS-0005VI-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 02:35:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjKF-0004Af-St; Thu, 20 Nov 2003 02:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjK4-00046s-MO for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 02:33:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20749 for ; Thu, 20 Nov 2003 02:33:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjK1-0005So-00 for ipv6@ietf.org; Thu, 20 Nov 2003 02:33:49 -0500 Received: from sixnet.u-strasbg.fr ([130.79.90.153]) by ietf-mx with esmtp (Exim 4.12) id 1AMjK1-0005Sj-00 for ipv6@ietf.org; Thu, 20 Nov 2003 02:33:49 -0500 Received: from crc.u-strasbg.fr (localhost [127.0.0.1]) by sixnet.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id hAJI2JX0001654; Wed, 19 Nov 2003 19:02:19 +0100 (CET) (envelope-from Jean-Jacques.Pansiot@crc.u-strasbg.fr) Message-ID: <3FBBB02B.3000504@crc.u-strasbg.fr> Date: Wed, 19 Nov 2003 19:02:19 +0100 From: Jean-Jacques Pansiot Organization: ULP LSIIT & Departement d'Informatique User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020811 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: ipv6@ietf.org CC: Brian Haberman , Jari Arkko , john.loughney@nokia.com, mrw@windriver.com Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBB9B9E.8030402@kolumbus.fi> <3FBBAC25.7050209@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian Haberman wrote: > > > Jari Arkko wrote: > >> john.loughney@nokia.com wrote: >> >>>> Perhaps the only question that I have left is... whether >>>> IPv6 nodes should support MLDv2 instead of MLDv1. The >>>> node requirements document and the MLDv2 draft intro >>>> gives the impression that the only difference is >>>> source-specific filtering. Then the current node >>>> reqs rules make sense. But Appendix B of the MLDv2 >>>> draft seems to list a number of other modifications, >>>> including some enhancements to robustness. Are these >>>> important? I'm not an expert enough to determine that. >>> >>> >>> >>> >>> Appendicies are non-normative, so I think that we don't need to >>> worry about it in the Node Requirements document, though I am by no >>> means an MLD expert. >> >> >> >> Appendix B of the MLDv2 draft is simply a list of changes >> from MLDv1. While this list is non-normative, I think the >> changes are in the body... so my question is whether there's >> really a bit more to MLDv2 than source-specific multicast. >> But lets stop the discussion between MLD non-experts and >> ask someone who knows: Brian, are there other improvements >> in MLDv2 than source-specific multicast? If yes, are those >> significant enough that nodes should migrate to MLDv2 >> even if they don't use the source-specific multicast feature? > > > So, I think I answered this already in an earlier message, but let > me clarify something here. The IP stack layer really does not know > what kinds of multicast applications are going to be run on it. > A user could arbitrarily install an SSM application just as easily > as an ASM application, if the stack supports multicast at all. > > With that in mind, if a stack developer knows for sure that his stack > couldn't be used for a certain flavor of multicast application (SSM > or ASM), then he can use the current guidelines in the node reqs to > determine whether MLDv1 or MLDv2 should be supported. > > In all other cases, I would prefer MLDv2 for flexibility reasons. > > So, if I back off my answer in the last post a little, perhaps the > wording for any-source should be something like "SHOULD support MLDv2 > but MAY support MLDv1". Hi, I think that running MLDv1 on a host has consequences on other hosts on the same link : if a host send a MLDv1 report for a group G, then the router (Querier) must run in MLDv1 compatibility mode. In effect, this prevents other hosts on the same link to use MLDv2 and source selection for this group Jean-Jacques > > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 02:52:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21665 for ; Thu, 20 Nov 2003 02:52:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjbV-0005yj-5V for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 02:51:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK7prVk022981 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 02:51:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjbU-0005yW-HB for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 02:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21620 for ; Thu, 20 Nov 2003 02:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjbR-0005kN-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 02:51:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjbR-0005kE-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 02:51:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjaf-0005fz-Ns; Thu, 20 Nov 2003 02:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjZq-0005eV-DD for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 02:50:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21549 for ; Thu, 20 Nov 2003 02:49:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjZn-0005ip-00 for ipv6@ietf.org; Thu, 20 Nov 2003 02:50:07 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AMjZm-0005ho-00 for ipv6@ietf.org; Thu, 20 Nov 2003 02:50:06 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAK7nSBs103334; Thu, 20 Nov 2003 07:49:28 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAK7nRLE244836; Thu, 20 Nov 2003 08:49:27 +0100 Received: from zurich.ibm.com (sig-9-145-145-243.de.ibm.com [9.145.145.243]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA37020; Thu, 20 Nov 2003 08:49:24 +0100 Message-ID: <3FBBBA9A.2807ED2F@zurich.ibm.com> Date: Wed, 19 Nov 2003 19:46:50 +0100 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: EricLKlein CC: ipv6@ietf.org Subject: Re: SL deprecation draft References: <001b01c3ae9e$c2f81590$ec061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, Take your argument to the people opposing the Hain/Templin draft, because your point is clearly made in that document. Brian EricLKlein wrote: > > Margaret.Wasserman wrote > > > I have been speaking to different > > > companies here in Israel, and the basic answer is that if I > > > can not have site locals and NAT then I will not move to IPv6. > > > If these people are happy with IPv4 NAT, why would they want > > to move to IPv6? They couldn't need more address space (net 10 > > is huge), they obviously don't care about peer-to-peer or > > end-to-end connectivity outside their organization, I can't > > imagine that they want to deploy any IPv6-only applications > > or services... > > Margret, you are correct. The way that one network person put it "if there > are no local addresses then we will just stay with IPv4 for our secure > applications, until it is no longer supported." > > This is not the first time that I have heard that someone was willing to > skip IPv6 because of the percieved pain and security threat that standards > compliance would entail. But then again these are all people that take > security and network administration very personal and very seriously, and > the idea of having the accounts recievable (or worse payable) computer with > a globaly reachable address scares them to heck. > > To be honest I stated these concerns back in the spring, and I still haven't > seen anything that would work to convince me that this is not what we as a > WG are proposing. If someone converts their existing network to a globaly > unique address range then what is responsible for filtering all of the > critical addresses from sending or recieving packets from the network over > the network Interent router? I see this as being moved from the protocol > level to that of the network technician, who now needs to explicitly deny > individual addresses (or ranges) rather and explicityl allow the permited > ranges. > > Eric > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 03:07:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23700 for ; Thu, 20 Nov 2003 03:07:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjqB-00077l-6R for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:07:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK8739X027384 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjqA-00077W-2T for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 03:07:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23670 for ; Thu, 20 Nov 2003 03:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjq6-0006Ej-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:06:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjq6-0006Eg-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjpE-0006ni-Is; Thu, 20 Nov 2003 03:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjp8-0006kw-0u for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 03:05:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23609 for ; Thu, 20 Nov 2003 03:05:41 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjp2-0006D4-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:05:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMjp2-0006Cz-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:05:52 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK85pA27920 for ; Thu, 20 Nov 2003 10:05:51 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 10:05:34 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:05:33 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 29: AD REVIEW: IPv6 Node Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 10:05:33 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOvOKe6WcjtSEUVQzOGbE9tersH4gABDrOQ To: , Cc: , , X-OriginalArrivalTime: 20 Nov 2003 08:05:33.0642 (UTC) FILETIME=[12997AA0:01C3AF3D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jean-Jacques, > I think that running MLDv1 on a host has consequences on other hosts > on the same link : if a host send a MLDv1 report for a group G, > then the router (Querier) must run in MLDv1 compatibility mode. > In effect, this prevents other hosts on the same link to use MLDv2 > and source selection for this group Does it also work the other way around? If hosts are already using = MLDv2 and source selection for a group, can another host start running MLDv1=20 in the same group? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 03:14:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23983 for ; Thu, 20 Nov 2003 03:14:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjx2-0007ts-Fw for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:14:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK8E8Xg030368 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjx1-0007tj-5w for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 03:14:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23942 for ; Thu, 20 Nov 2003 03:13:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjwz-0006KF-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:14:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjwv-0006KC-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjvx-0007as-8o; Thu, 20 Nov 2003 03:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjv5-0007ZP-S2 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 03:12:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23866 for ; Thu, 20 Nov 2003 03:11:55 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjv4-0006IV-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:12:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMjv3-0006IM-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:12:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK8C0A06498 for ; Thu, 20 Nov 2003 10:12:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 10:11:59 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:11:59 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Issue 30: MLDv1 vs MLDv2 text X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 10:11:58 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOu28t59wimqBXLTtSXmpW7Q1lZygATYa/AAAUl4qA= To: , , Cc: X-OriginalArrivalTime: 20 Nov 2003 08:11:59.0094 (UTC) FILETIME=[F858C960:01C3AF3D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Assigned as issue 30. > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext > john.loughney@nokia.com > Sent: 20 November, 2003 07:45 > To: jari.arkko@kolumbus.fi; brian@innovationslab.net > Cc: ipv6@ietf.org > Subject: RE: Issue 29: AD REVIEW: IPv6 Node Requirements >=20 >=20 > Hi Jari, Brian, >=20 > > > So, I think I answered this already in an earlier message, but let > > > me clarify something here. The IP stack layer really=20 > does not know > > > what kinds of multicast applications are going to be run on it. > > > A user could arbitrarily install an SSM application just as easily > > > as an ASM application, if the stack supports multicast at all. > > >=20 > > > With that in mind, if a stack developer knows for sure that=20 > > his stack > > > couldn't be used for a certain flavor of multicast=20 > application (SSM > > > or ASM), then he can use the current guidelines in the=20 > node reqs to > > > determine whether MLDv1 or MLDv2 should be supported. > > >=20 > > > In all other cases, I would prefer MLDv2 for flexibility reasons. > > >=20 > > > So, if I back off my answer in the last post a little, perhaps the > > > wording for any-source should be something like "SHOULD=20 > support MLDv2 > > > but MAY support MLDv1". > >=20 > > With your explanation of the stack - app issues, I think this > > would make sense. If others agree, and suitable text can be > > crafted, of course. Anyway, this is not a crucial issue for > > me but I just wanted to understand the implications. >=20 > I agree. I'll add the suggested text. >=20 > John >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 03:18:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24219 for ; Thu, 20 Nov 2003 03:18:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk0g-0008L8-Iw for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:17:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK8HsOq032047 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk0e-0008Ko-Cc for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 03:17:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24170 for ; Thu, 20 Nov 2003 03:17:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMk0d-0006Qa-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:17:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMk0c-0006QX-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:17:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjzq-00081S-2m; Thu, 20 Nov 2003 03:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjyq-0007zw-OW for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 03:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24082 for ; Thu, 20 Nov 2003 03:15:48 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjyp-0006MH-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:15:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMjyo-0006ME-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:15:58 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK8EWA09991 for ; Thu, 20 Nov 2003 10:15:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 10:14:31 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:14:31 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req. Issue 28: Security Considerations X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 10:14:30 +0200 Message-ID: Thread-Topic: Node Req. Issue 28: Security Considerations Thread-Index: AcOu24mX7TsKs2IsTYWTEStHAQ694AAYo1Tw To: , Cc: X-OriginalArrivalTime: 20 Nov 2003 08:14:31.0120 (UTC) FILETIME=[52F61D00:01C3AF3E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jari, > >>>In the IPsec section, you mention that other security issues > >>>will be covered in the Security Considerations section, but > >>>I don't see any issues here... =20 >=20 > There used to be some things, but they got removed because > people felt that those things belong to the individual > protocol RFCs, or their future updates. Agreed. No changes needed in current doc. =20 > >>>Why aren't privacy addresses covered in this document? > >=20 > >=20 > > Should this be covered in the security section? Already, section > > 4.5.3 talks about privacy extensions. Do we need more? >=20 > As I mentioned, there's been a debate whether the specific > issues belong here or in the individual RFCs. As John says, > we already have a section for RFC 3041 and I am not aware > of any specific IPv6 security issues it would raise beyond > those mentioned in the document itself. >=20 > As we were working on RFC 3316 (cellular hosts), we did > discuss privacy issues a little bit in the security considerations > section. But there we had a reason, as we explained the specific > implications and benefits (or lack thereof) of using RFC 3041 > in cellular networks. As an example, since every host had its > own prefix, obfuscating the interface identifier did not help > quite as much as it did in Ethernet. >=20 > Here we don't have that specific situation. Agreed. =20 > >>>Also, did you consider a recommendation that IPv6 nodes should > >>>implement SEND? Perhaps you should at least mention the=20 > >>>security issues with ND and indicate that the SEND group is > >>>working to resolve them? > >=20 > >=20 > > I believe we did not want this kind of forward reference to stuff > > that is on-going. However, if people feel that the SEND stuff > > is stable enough, we could put in a reference. >=20 > Borderline. Back in IETF-56 & 57 we believed node reqs would be > done much sooner than SEND. Now in SEND we have a plan to finish > all work and have the WG go to sleep; the draft will be reissued > once within a couple of weeks, then reviewed, and then reissued > again and sent to IESG. So it might be off to the IESG this year. > Assuming I find time to edit the draft ;-) >=20 > If it gets there in time before node reqs is approved, we probably > should add a reference. But it looks like we might agree about > node reqs soon, so SEND probably completes slightly later. > In that case there's no sense in waiting for SEND. Agreed. =20 > Anyway, that reminds me that while redoing RFC 2461, we should > probably tone down the language a bit regarding the use of AH; > there's widely known issues with that (send documents some of > these, draft-arkko-icmpv6-ike-effects talks about others). I'm > not sure we should present AH any more as general solution. > Perhaps SEND is done by the time that 2461bis is ready, so > it could reference some of the SEND documents. Also, I'm not > sure I agree with the RFC 2460 statement that the node requirements > document quotes: >=20 > The security features of IPv6 are described in the Security > Architecture for the Internet Protocol [RFC-2401]. >=20 > I don't agree because we appear to have a number of other security > features in IPv6 in addition to IPsec. MIPv6 RR, ND options for > certs and CGAs in SEND, etc. Suggested re-write: Many of the the security features of IPv6 are described in the = Security Architecture for the Internet Protocol [RFC-2401]. However, your above text seems to indicate that 2401 requires a = substantial re-write. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 03:24:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24586 for ; Thu, 20 Nov 2003 03:24:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk6T-0000XU-Q0 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:23:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK8Nrkd002066 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:23:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk6S-0000XF-Je for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 03:23:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24509 for ; Thu, 20 Nov 2003 03:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMk6R-0006X0-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:23:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMk6Q-0006Wu-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:23:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk5e-0000EB-Cr; Thu, 20 Nov 2003 03:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk4u-0000Cs-Ah for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 03:22:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24427 for ; Thu, 20 Nov 2003 03:22:03 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMk4s-0006VM-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:22:14 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMk4s-0006VH-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:22:14 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK8MA619051 for ; Thu, 20 Nov 2003 10:22:10 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 10:22:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:22:09 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:22:09 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 29: AD REVIEW: IPv6 Node Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 10:22:08 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOu28t59wimqBXLTtSXmpW7Q1lZygAY2hTw To: , Cc: X-OriginalArrivalTime: 20 Nov 2003 08:22:09.0432 (UTC) FILETIME=[6422F980:01C3AF3F] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, The 2nd paragraph in 4.6 looks like: If an application is going to support Source-Specific Multicast,=20 it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the=20 Source-Specific Multicast overview document [RFC3569]; refer to=20 Source-Specific Multicast architecture document for details [SSMARCH]. I think that is sufficient strength to address Jean-Jacques concern, as SHOULD is quite strong. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 03:28:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24876 for ; Thu, 20 Nov 2003 03:28:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMkAH-0000vv-0N for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:27:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK8RmDA003588 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:27:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMkAG-0000vm-BI for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 03:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24799 for ; Thu, 20 Nov 2003 03:27:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMkAE-0006ca-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:27:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMkAE-0006cX-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:27:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk9W-0000cj-Ki; Thu, 20 Nov 2003 03:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMk9M-0000c0-Vl for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 03:26:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24739 for ; Thu, 20 Nov 2003 03:26:40 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMk9L-0006ak-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:26:51 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMk9K-0006ah-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:26:50 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK8Qn625423 for ; Thu, 20 Nov 2003 10:26:50 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Nov 2003 10:26:49 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:26:48 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:26:48 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue31: DHCPv6 text X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 10:26:48 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOux1B4G1HE4C0cQz2KBK0zYQ058QAeIsbA To: X-OriginalArrivalTime: 20 Nov 2003 08:26:48.0543 (UTC) FILETIME=[0A7FEEF0:01C3AF40] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, Pekka Savola raised a few editorial fixes on the node requirements, but this is somewhat more substantial, so I'd like to see if the WG is OK with it. reword: For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. to: Nodes that implement DHCPv6 MUST use DHCP upon the receipt of a=20 Router Advertisement with the 'M' flag set (see section 5.5.3 of=20 RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCPv6 MUST attempt to use DHCPv6. In this = context, 'use DHCP' means trying to obtain both address(es) and=20 other configuration information through DHCP. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 04:14:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26106 for ; Thu, 20 Nov 2003 04:14:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMktc-0003gC-0G for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 04:14:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK9EdX4014140 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 04:14:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMktb-0003fz-3k for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 04:14:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26048 for ; Thu, 20 Nov 2003 04:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMktZ-0007AB-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 04:14:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMktY-00079U-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 04:14:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMks2-0003LG-Mb; Thu, 20 Nov 2003 04:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMkrx-0003Kn-Ch for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 04:12:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25986 for ; Thu, 20 Nov 2003 04:12:43 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMkrv-00078h-00 for ipv6@ietf.org; Thu, 20 Nov 2003 04:12:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMkru-00078e-00 for ipv6@ietf.org; Thu, 20 Nov 2003 04:12:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK9Cr600288 for ; Thu, 20 Nov 2003 11:12:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Nov 2003 11:12:51 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Nov 2003 11:12:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 11:12:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req: Issue31: DHCPv6 text (ignore previous mails) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 11:12:52 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOux1B4G1HE4C0cQz2KBK0zYQ058QAeIsbAAAGiZFA= To: X-OriginalArrivalTime: 20 Nov 2003 09:12:53.0230 (UTC) FILETIME=[7A61B0E0:01C3AF46] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, Please ignore previous mails on this topic, here is the proposed text: thanks, John > > In addition, in the absence of a router, > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > >=20 > > =3D=3D> what does "in the absence of a router" mean? maybe this = needs to be > > made slightly more explicit to be unambiguous.. >=20 > Suggested text? reword: For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. to: Nodes that implement DHCP MUST use DHCP upon the receipt of a=20 Router Advertisement with the 'M' flag set (see section 5.5.3 of=20 RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this=20 context, 'use DHCP' means trying to obtain both address(es) and=20 other configuration information through DHCP. > > For those IPv6 Nodes (acting as hosts) that implement DHCP, those > > nodes MUST use DHCP upon the receipt of a Router Advertisement = with > > the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in = the > > absence of a router, hosts that implement DHCP MUST attempt to = use > > DHCP. > >=20 > > =3D=3D> attempt to use DHCP _for what_ ? Getting stateful = information, of > > course, not the addresses? >=20 > Suggested text? reword: For those IPv6 Nodes (acting as hosts) that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a Router Advertisement can be ignored. Furthermore, in the absence of a router, these types of node are not required to initiate DHCP. to: IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon=20 the receipt of a Router Advertisement with the 'O' flag set (see=20 section 5.5.3 of RFC2462). In addition, in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. In this context, 'use DHCP' means trying to obtain only other=20 configuration information through DHCP, not address(es). IPv6 Nodes that do not implement DHCP can ignore the 'O' flag=20 of a Router Advertisement. Furthermore, in the absence of a router, these types of node are not required to initiate DHCP. (these are not only editorial issues IMHO, especially the latter one,=20 if someone is envisioning that in absence of a router, DHCP should try=20 to get an address as well, from the context of other config=20 information) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 06:51:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29951 for ; Thu, 20 Nov 2003 06:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnL7-0002Wt-TM for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 06:51:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKBpDFd009717 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 06:51:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnL7-0002We-Os for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 06:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29915 for ; Thu, 20 Nov 2003 06:50:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnL4-0001Fm-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 06:51:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMnL4-0001Fi-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 06:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnK2-0002CT-W2; Thu, 20 Nov 2003 06:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnJ3-00029w-2s for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 06:49:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29809 for ; Thu, 20 Nov 2003 06:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnIz-0001Dd-00 for ipv6@ietf.org; Thu, 20 Nov 2003 06:49:01 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AMnIy-0001DN-00 for ipv6@ietf.org; Thu, 20 Nov 2003 06:49:01 -0500 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 hAKBmAV08578; Thu, 20 Nov 2003 03:48:10 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAKBqctX024805 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Nov 2003 03:52:41 -0800 Message-ID: <3FBCA9E0.9070503@innovationslab.net> Date: Thu, 20 Nov 2003 06:47:44 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: jari.arkko@kolumbus.fi, ipv6@ietf.org Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, john.loughney@nokia.com wrote: > Hi all, > > The 2nd paragraph in 4.6 looks like: > > If an application is going to support Source-Specific Multicast, > it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the > Source-Specific Multicast overview document [RFC3569]; refer to > Source-Specific Multicast architecture document for details [SSMARCH]. > > I think that is sufficient strength to address Jean-Jacques concern, > as SHOULD is quite strong. I don't think that works. MLDv2 is required in order to support SSM as per [SSMARCH] and draft-holbrook-idmr-igmpv3-ssm-05.txt. So, it needs to be worded as it was originally written. The issue with MLDv1 and MLDv2 interaction described very well in the MLDv2 spec. There is nothing that needs to be in node reqs to deal with that case imho. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 07:02:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00490 for ; Thu, 20 Nov 2003 07:02:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnVL-0003Tj-IW for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:01:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKC1lNK013372 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:01:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnVL-0003Tb-EE for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 07:01:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00372 for ; Thu, 20 Nov 2003 07:01:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnVI-0001SL-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:01:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMnVH-0001SI-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:01:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnUc-0003B3-Nu; Thu, 20 Nov 2003 07:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnUW-0003AV-OT for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 07:00:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00335 for ; Thu, 20 Nov 2003 07:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnUT-0001Pe-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:00:53 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AMnUS-0001PR-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:00:53 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 251566A90A; Thu, 20 Nov 2003 14:00:47 +0200 (EET) Message-ID: <3FBCABEC.7050301@kolumbus.fi> Date: Thu, 20 Nov 2003 13:56:28 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: brian@innovationslab.net, ipv6@ietf.org Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi all, > > The 2nd paragraph in 4.6 looks like: > > If an application is going to support Source-Specific Multicast, > it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the > Source-Specific Multicast overview document [RFC3569]; refer to > Source-Specific Multicast architecture document for details [SSMARCH]. > > I think that is sufficient strength to address Jean-Jacques concern, > as SHOULD is quite strong. Hmm.... I think RFC 3569 says that you can only do SSM with MLDv2, not with MLDv1. Also, I wouldn't put an informative document like 3569 after a keyword. We need to put Brian's SHOULD..MAY suggestion into the text, but in a slightly different form. Here is one suggested rewrite: 4.6 Multicast Listener Discovery (MLD) Nodes that need to join multicast groups SHOULD implement MLDv2 [MLDv2]. However, if the node has applications which only need support for Any-Source Multicast [RFC3569], the node MAY implement MLDv1 [MLDv1] instead. If the node has applications which need support for Source-Specific Multicast [RFC3569, SSMARCH], the node MUST support MLDv2 [MLDv2]. When MLD is used, the rules in "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be followed. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 07:34:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01698 for ; Thu, 20 Nov 2003 07:34:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo0X-00054m-Eu for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKCY19c019496 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo0W-00054N-Sv for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 07:34:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01630 for ; Thu, 20 Nov 2003 07:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMo0W-00020N-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:34:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMo0V-00020G-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:33:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnzb-0004lY-L0; Thu, 20 Nov 2003 07:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnzL-0004jy-FX for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 07:32:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01486 for ; Thu, 20 Nov 2003 07:32:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnzK-0001wK-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:32:46 -0500 Received: from sixnet.u-strasbg.fr ([130.79.90.153]) by ietf-mx with esmtp (Exim 4.12) id 1AMnzK-0001wH-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:32:46 -0500 Received: from crc.u-strasbg.fr (localhost [127.0.0.1]) by sixnet.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id hAKCWelU000991; Thu, 20 Nov 2003 13:32:41 +0100 (CET) (envelope-from Jean-Jacques.Pansiot@crc.u-strasbg.fr) Message-ID: <3FBCB468.3060508@crc.u-strasbg.fr> Date: Thu, 20 Nov 2003 13:32:40 +0100 From: Jean-Jacques Pansiot Organization: ULP LSIIT & Departement d'Informatique User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020811 X-Accept-Language: fr, en-us MIME-Version: 1.0 To: Jari Arkko CC: john.loughney@nokia.com, brian@innovationslab.net, ipv6@ietf.org Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBCABEC.7050301@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > john.loughney@nokia.com wrote: > >> Hi all, >> >> The 2nd paragraph in 4.6 looks like: >> >> If an application is going to support Source-Specific Multicast, it >> "SHOULD support MLDv2 but MAY support MLDv1 and conform to the >> Source-Specific Multicast overview document [RFC3569]; refer to >> Source-Specific Multicast architecture document for details [SSMARCH]. >> >> I think that is sufficient strength to address Jean-Jacques concern, >> as SHOULD is quite strong. > > > Hmm.... I think RFC 3569 says that you can only do SSM with MLDv2, > not with MLDv1. Also, I wouldn't put an informative document like > 3569 after a keyword. > > We need to put Brian's SHOULD..MAY suggestion into the text, but > in a slightly different form. Here is one suggested rewrite: > > 4.6 Multicast Listener Discovery (MLD) > > Nodes that need to join multicast groups SHOULD implement MLDv2 > [MLDv2]. However, if the node has applications which only need > support for Any-Source Multicast [RFC3569], the node MAY implement > MLDv1 [MLDv1] instead. If the node has applications which need > support for Source-Specific Multicast [RFC3569, SSMARCH], the > node MUST support MLDv2 [MLDv2]. > > When MLD is used, the rules in "Source Address Selection for the > Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be > followed. > I agree with Jari, moreover, MLDv2 is not only necessary for SSM but also useful to select sources in an ASM group (using the source filter API : draft-ietf-magma-msf-api-05.txt ). If a host implementing MLDv1 is a member of group G, then all other receivers of the same group (and implementing MLDv2) must use MLDv1 (and therefore cannot express their sources of interest) for this group until this host leaves the group. Jean-Jacques > --Jari > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 07:43:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02068 for ; Thu, 20 Nov 2003 07:43:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo93-0005sm-C4 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:42:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKCgnWg022612 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo92-0005sd-Vd for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 07:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02035 for ; Thu, 20 Nov 2003 07:42:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMo92-0002Am-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:42:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMo91-0002Aj-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:42:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo8I-0005a7-A2; Thu, 20 Nov 2003 07:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo8D-0005Zo-LV for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 07:41:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02008 for ; Thu, 20 Nov 2003 07:41:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMo8C-00029p-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:41:57 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AMo8C-00029m-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:41:56 -0500 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 hAKCfPV09220; Thu, 20 Nov 2003 04:41:25 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAKCjstX025332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Nov 2003 04:45:57 -0800 Message-ID: <3FBCB65B.8000704@innovationslab.net> Date: Thu, 20 Nov 2003 07:40:59 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: john.loughney@nokia.com, ipv6@ietf.org Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements References: <3FBCABEC.7050301@kolumbus.fi> In-Reply-To: <3FBCABEC.7050301@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Jari's proposed text. Brian Jari Arkko wrote: > john.loughney@nokia.com wrote: > >> Hi all, >> >> The 2nd paragraph in 4.6 looks like: >> >> If an application is going to support Source-Specific Multicast, it >> "SHOULD support MLDv2 but MAY support MLDv1 and conform to the >> Source-Specific Multicast overview document [RFC3569]; refer to >> Source-Specific Multicast architecture document for details [SSMARCH]. >> >> I think that is sufficient strength to address Jean-Jacques concern, >> as SHOULD is quite strong. > > > Hmm.... I think RFC 3569 says that you can only do SSM with MLDv2, > not with MLDv1. Also, I wouldn't put an informative document like > 3569 after a keyword. > > We need to put Brian's SHOULD..MAY suggestion into the text, but > in a slightly different form. Here is one suggested rewrite: > > 4.6 Multicast Listener Discovery (MLD) > > Nodes that need to join multicast groups SHOULD implement MLDv2 > [MLDv2]. However, if the node has applications which only need > support for Any-Source Multicast [RFC3569], the node MAY implement > MLDv1 [MLDv1] instead. If the node has applications which need > support for Source-Specific Multicast [RFC3569, SSMARCH], the > node MUST support MLDv2 [MLDv2]. > > When MLD is used, the rules in "Source Address Selection for the > Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be > followed. > > --Jari > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 08:25:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03359 for ; Thu, 20 Nov 2003 08:25:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMoo4-0000mv-Ta for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:25:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKDPC27003017 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMoo4-0000m3-DN for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 08:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03269 for ; Thu, 20 Nov 2003 08:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMoo3-0002l7-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:25:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMoo2-0002l0-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:25:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMomw-0000Lo-Il; Thu, 20 Nov 2003 08:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMngO-0004Dw-U2 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 07:13:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01004 for ; Thu, 20 Nov 2003 07:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMngO-0001hF-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:13:12 -0500 Received: from mailserver.unimi.it ([159.149.10.5]) by ietf-mx with esmtp (Exim 4.12) id 1AMngN-0001ft-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:13:11 -0500 Received: from smtp.unimi.it (smtp.unimi.it [159.149.10.3]) by mailserver.unimi.it (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HON0038FGKKNC@mailserver.unimi.it> for ipv6@ietf.org; Thu, 20 Nov 2003 13:12:21 +0100 (MET) Received: from unimi.it (lori.divtlc.unimi.it [159.149.105.62]) by smtp.unimi.it (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0HON00142GKI2Z@smtp.unimi.it> for ipv6@ietf.org; Thu, 20 Nov 2003 13:12:18 +0100 (MET) Date: Thu, 20 Nov 2003 13:12:19 +0100 From: Claudio Lori Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements To: Jari Arkko Cc: john.loughney@nokia.com, brian@innovationslab.net, ipv6@ietf.org Message-id: <3FBCAFA3.70602@unimi.it> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 References: <3FBCABEC.7050301@kolumbus.fi> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Jari Arkko wrote: > john.loughney@nokia.com wrote: > >> Hi all, >> >> The 2nd paragraph in 4.6 looks like: >> >> If an application is going to support Source-Specific Multicast, it >> "SHOULD support MLDv2 but MAY support MLDv1 and conform to the >> Source-Specific Multicast overview document [RFC3569]; refer to >> Source-Specific Multicast architecture document for details [SSMARCH]. >> >> I think that is sufficient strength to address Jean-Jacques concern, >> as SHOULD is quite strong. > > > Hmm.... I think RFC 3569 says that you can only do SSM with MLDv2, > not with MLDv1. Also, I wouldn't put an informative document like > 3569 after a keyword. > > We need to put Brian's SHOULD..MAY suggestion into the text, but > in a slightly different form. Here is one suggested rewrite: > > 4.6 Multicast Listener Discovery (MLD) > > Nodes that need to join multicast groups SHOULD implement MLDv2 > [MLDv2]. However, if the node has applications which only need > support for Any-Source Multicast [RFC3569], the node MAY implement > MLDv1 [MLDv1] instead. If the node has applications which need > support for Source-Specific Multicast [RFC3569, SSMARCH], the > node MUST support MLDv2 [MLDv2]. > > When MLD is used, the rules in "Source Address Selection for the > Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be > followed. > > --Jari > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- unsubscribe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 08:40:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03672 for ; Thu, 20 Nov 2003 08:40:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMp2Q-0001t0-83 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:40:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKDe2VC007244 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMp2O-0001se-O4 for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 08:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03647 for ; Thu, 20 Nov 2003 08:39:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMp2N-0002wM-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:39:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMp2N-0002wI-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:39:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMp1S-0001eq-Dg; Thu, 20 Nov 2003 08:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMp0n-0001eE-0o for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 08:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03596 for ; Thu, 20 Nov 2003 08:38:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMp0l-0002un-00 for ipv6@ietf.org; Thu, 20 Nov 2003 08:38:19 -0500 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AMp0l-0002uZ-00 for ipv6@ietf.org; Thu, 20 Nov 2003 08:38:19 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id B09E28008; Thu, 20 Nov 2003 14:38:12 +0100 (CET) From: "Jeroen Massar" To: "'Claudio Lori'" Cc: Subject: Mailman unsubscribe FAQ (Was: unsubscribe) Date: Thu, 20 Nov 2003 14:38:15 +0100 Organization: Unfix Message-ID: <00d001c3af6b$8cbf61e0$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.4510 In-Reply-To: <3FBCB78B.5010909@unimi.it> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- (offtopic, but this seems to be a very difficult subject for many people) How difficult is it to unsubscribe from mailman managed mailinglists when the bottom of every message contains (snipped from the message): > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- This URL contains all the information and html forms to unsubscribe. Note also that the headers contain: List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Thus even a message to ipv6-request@ietf.org?subject=unsubscribe should unsubscribe you. This *should* be clear enough for any person that has at least some brains :) If you don't have enough brains, or there are some other issues you can ofcourse contact ipv6-admin@ietf.org which will also take care of your requests swiftly. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP7zDximqKFIzPnwjEQLypACffpPRjvLy5iaz/bQZx+9sP4vN7FwAnjCZ AuT7Dv7FSfBGrItMx2y4xg2s =mVCV -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 08:55:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04073 for ; Thu, 20 Nov 2003 08:55:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpGy-0002wO-Vd for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKDt4wP011294 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpGy-0002w3-0m for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 08:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04043 for ; Thu, 20 Nov 2003 08:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpGw-00036q-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpGv-00036j-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpFx-0002co-QX; Thu, 20 Nov 2003 08:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpFi-0002cT-19 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 08:53:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03999 for ; Thu, 20 Nov 2003 08:53:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpFg-00035T-00 for ipv6@ietf.org; Thu, 20 Nov 2003 08:53:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AMpFg-00035C-00 for ipv6@ietf.org; Thu, 20 Nov 2003 08:53:44 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 20 Nov 2003 05:54:04 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAKDr1DO023618; Thu, 20 Nov 2003 08:53:11 -0500 (EST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED16186; Thu, 20 Nov 2003 08:53:00 -0500 (EST) Message-Id: <4.3.2.7.2.20031120084135.01e93f90@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Nov 2003 08:52:57 -0500 To: john.loughney@nokia.com From: Ralph Droms Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Comments (mostly editorial) in line... - Ralph At 11:12 AM 11/20/2003 +0200, john.loughney@nokia.com wrote: >Hi all, > >Please ignore previous mails on this topic, here is the proposed text: > >thanks, >John > > > > In addition, in the absence of a router, > > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > > > > > > ==> what does "in the absence of a router" mean? maybe this needs to be > > > made slightly more explicit to be unambiguous.. > > > > Suggested text? > >reword: > > For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' flag set (see > section 5.5.3 of RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > >to: > > Nodes that implement DHCP MUST use DHCP upon the receipt of a > Router Advertisement with the 'M' flag set (see section 5.5.3 of > RFC2462). In addition, in the absence of a router, How about replacing "in the absence of a router" with "if the node does not receive any Router Advertisements"? Please ignore my suggestion if I'm leading us down a previously explored rathole. > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this Is the capitalization of "Nodes" consistent with the rest of the doc (seems to be, based on the text snippets included here?)? > context, 'use DHCP' means trying to obtain both address(es) and > other configuration information through DHCP. As was suggested elsewhere, substituting DHCPv6 for DHCP throughout wouldn't hurt (but certainly isn't critical). > > > For those IPv6 Nodes (acting as hosts) that implement DHCP, those > > > nodes MUST use DHCP upon the receipt of a Router Advertisement with > > > the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the > > > absence of a router, hosts that implement DHCP MUST attempt to use > > > DHCP. > > > > > > ==> attempt to use DHCP _for what_ ? Getting stateful information, of > > > course, not the addresses? > > > > Suggested text? > >reword: > > For those IPv6 Nodes (acting as hosts) that implement DHCP, those > nodes MUST use DHCP upon the receipt of a Router Advertisement with > the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the > absence of a router, hosts that implement DHCP MUST attempt to use > DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a > Router Advertisement can be ignored. Furthermore, in the absence of > a router, these types of node are not required to initiate DHCP. s/types of node/such Nodes/ (for clarity and consistency)? >to: > > IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon Is there a reason to differentiate between nodes acting as hosts here, but not in the paragraph describing the behavior in response to the 'M' bit? I'd suggest, in fact, that only hosts want to use DHCPv6 for address assignment, while both hosts and routers want to use DHCPv6 for other configuration information. Again, please ignore my suggestion if the issue has already been explored. > the receipt of a Router Advertisement with the 'O' flag set (see > section 5.5.3 of RFC2462). In addition, in the > absence of a router, hosts that implement DHCP MUST attempt to use My comment above about "in the absence of a router" applies here, too. > DHCP. In this context, 'use DHCP' means trying to obtain only other > configuration information through DHCP, not address(es). > > IPv6 Nodes that do not implement DHCP can ignore the 'O' flag > of a Router Advertisement. Is there a specific reason that a similar sentence does not appear in the text about the 'M' bit? > Furthermore, in the absence of > a router, these types of node are not required to initiate DHCP. s/types of node/such Nodes/ (for clarity and consistency)? >(these are not only editorial issues IMHO, especially the latter one, >if someone is envisioning that in absence of a router, DHCP should try >to get an address as well, from the context of other config >information) I'm afraid I don't understand the parenthetical comment... >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 09:09:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04844 for ; Thu, 20 Nov 2003 09:09:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpUL-0003sB-6R for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:08:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKE8rwN014881 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpUK-0003rw-U9 for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:08:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04805 for ; Thu, 20 Nov 2003 09:08:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpUJ-0003PR-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:08:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpUJ-0003PO-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:08:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpTW-0003ej-Mf; Thu, 20 Nov 2003 09:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpSl-0003PU-P2 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 09:07:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04748 for ; Thu, 20 Nov 2003 09:07:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpSk-0003OK-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:07:14 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpSj-0003Np-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:07:13 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 09:06:38 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042014@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ralph Droms'" , john.loughney@nokia.com Cc: ipv6@ietf.org Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Date: Thu, 20 Nov 2003 09:06:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > Is there a reason to differentiate between nodes acting as > hosts here, but > not in the paragraph describing the behavior in response to > the 'M' bit? => In general, unless previously discussed and rejected for some reason, I'd globally: s/Nodes (acting as hosts)/host It's a bit clumsy to read as it is. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 09:18:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03360 for ; Thu, 20 Nov 2003 08:25:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMoo4-0000mw-Tr for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:25:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKDPCGs003019 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMoo4-0000m2-AD for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 08:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03267 for ; Thu, 20 Nov 2003 08:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMoo3-0002l5-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:25:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMoo2-0002l1-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:25:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMomy-0000M3-27; Thu, 20 Nov 2003 08:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMoCj-000664-99 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 07:46:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02178 for ; Thu, 20 Nov 2003 07:46:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMoCi-0002FT-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:46:36 -0500 Received: from mailserver.unimi.it ([159.149.10.5]) by ietf-mx with esmtp (Exim 4.12) id 1AMoCh-0002DD-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:46:36 -0500 Received: from smtp.unimi.it (smtp.unimi.it [159.149.10.3]) by mailserver.unimi.it (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HON0030DI4TNC@mailserver.unimi.it> for ipv6@ietf.org; Thu, 20 Nov 2003 13:46:06 +0100 (MET) Received: from unimi.it (lori.divtlc.unimi.it [159.149.105.62]) by smtp.unimi.it (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0HON00159I4Q9N@smtp.unimi.it> for ipv6@ietf.org; Thu, 20 Nov 2003 13:46:02 +0100 (MET) Date: Thu, 20 Nov 2003 13:46:03 +0100 From: Claudio Lori Subject: unsubscribe To: Jean-Jacques Pansiot Cc: Jari Arkko , john.loughney@nokia.com, brian@innovationslab.net, ipv6@ietf.org Message-id: <3FBCB78B.5010909@unimi.it> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 References: <3FBCABEC.7050301@kolumbus.fi> <3FBCB468.3060508@crc.u-strasbg.fr> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Jean-Jacques Pansiot wrote: > Jari Arkko wrote: > >> john.loughney@nokia.com wrote: >> >>> Hi all, >>> >>> The 2nd paragraph in 4.6 looks like: >>> >>> If an application is going to support Source-Specific Multicast, >>> it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the >>> Source-Specific Multicast overview document [RFC3569]; refer to >>> Source-Specific Multicast architecture document for details [SSMARCH]. >>> >>> I think that is sufficient strength to address Jean-Jacques concern, >>> as SHOULD is quite strong. >> >> >> >> Hmm.... I think RFC 3569 says that you can only do SSM with MLDv2, >> not with MLDv1. Also, I wouldn't put an informative document like >> 3569 after a keyword. >> >> We need to put Brian's SHOULD..MAY suggestion into the text, but >> in a slightly different form. Here is one suggested rewrite: >> >> 4.6 Multicast Listener Discovery (MLD) >> >> Nodes that need to join multicast groups SHOULD implement MLDv2 >> [MLDv2]. However, if the node has applications which only need >> support for Any-Source Multicast [RFC3569], the node MAY implement >> MLDv1 [MLDv1] instead. If the node has applications which need >> support for Source-Specific Multicast [RFC3569, SSMARCH], the >> node MUST support MLDv2 [MLDv2]. >> >> When MLD is used, the rules in "Source Address Selection for the >> Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be >> followed. >> > > I agree with Jari, > > moreover, MLDv2 is not only necessary for SSM but also useful to > select sources > in an ASM group (using the source filter API : > draft-ietf-magma-msf-api-05.txt > ). If a host implementing MLDv1 is a member of group G, then all > other receivers of the same group (and implementing MLDv2) must use > MLDv1 (and therefore cannot express their sources of interest) for > this group until > this host leaves the group. > > Jean-Jacques > >> --Jari >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 09:18:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05245 for ; Thu, 20 Nov 2003 09:18:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpcx-0004YV-GN for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:17:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEHl5E017505 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:17:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpcx-0004YG-A5 for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:17:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05196 for ; Thu, 20 Nov 2003 09:17:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpcv-0003Yv-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:17:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpcv-0003Ys-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:17:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpcE-0004LW-9V; Thu, 20 Nov 2003 09:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpbP-0004Jp-Kl for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 09:16:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05160 for ; Thu, 20 Nov 2003 09:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpbO-0003Vm-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:16:10 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpbN-0003VB-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:16:09 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEFaAt026870; Thu, 20 Nov 2003 06:15:37 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED17723; Thu, 20 Nov 2003 09:15:35 -0500 (EST) Message-Id: <4.3.2.7.2.20031120090748.01ead000@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Nov 2003 09:15:32 -0500 To: john.loughney@nokia.com, ipv6@ietf.org From: Ralph Droms Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042014@ftmail.lab.flarion. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I strongly suggest the use of "Nodes" (unqualified) in the text about the 'O' bit: IPv6 Nodes that implement DHCP, MUST use DHCP upon the receipt of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). There is no reason a router can't use DHCPv6 for other configuration information. However, there is some question about any discussion of "nodes" and RAs, as there may be text in RFC 2461 (I'm working from memory, here, which in my case is a remarkably unreliable service; I hope someone more familiar with RFC 2461 can confirm or deny) that allows or requires routers to ignore RAs. - Ralph At 09:06 AM 11/20/2003 -0500, Soliman Hesham wrote: > > > > Is there a reason to differentiate between nodes acting as > > hosts here, but > > not in the paragraph describing the behavior in response to > > the 'M' bit? > >=> In general, unless previously discussed and rejected for some >reason, I'd globally: s/Nodes (acting as hosts)/host > >It's a bit clumsy to read as it is. > >Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 09:30:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05927 for ; Thu, 20 Nov 2003 09:30:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpot-0005N3-ME for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:30:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEU7sw020639 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:30:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpot-0005Mo-8n for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:30:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05876 for ; Thu, 20 Nov 2003 09:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpor-0003m1-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:30:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpor-0003ly-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpnp-00058y-AM; Thu, 20 Nov 2003 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpn7-00057c-S7 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 09:28:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05752 for ; Thu, 20 Nov 2003 09:28:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpn6-0003is-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:28:16 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpn5-0003hL-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:28:15 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 09:27:45 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042015@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Ralph Droms'" , john.loughney@nokia.com, ipv6@ietf.org Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Date: Thu, 20 Nov 2003 09:27:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I strongly suggest the use of "Nodes" (unqualified) in the text > about the 'O' bit: => To be clear, I was suggesting substitusting "Nodes (acting as hosts)". I'm not sure if you're replying to my comment or in general. > However, there is some question about any discussion of "nodes" and > RAs, as there may be text in RFC 2461 (I'm working from > memory, here, which > in my case is a remarkably unreliable service; I hope > someone more familiar > with RFC 2461 can confirm or deny) that allows or requires > routers to ignore RAs. => In 6.2.7 : Routers SHOULD inspect valid Router Advertisements sent by other routers and verify that the routers are advertising consistent information on a link. Detected inconsistencies indicate that one or more routers might be misconfigured and SHOULD be logged to system or network management. The minimum set of information to check includes: - Cur Hop Limit values (except for the unspecified value of zero). - Values of the M or O flags. - Reachable Time values (except for the unspecified value of zero). Whether that means routers can also act upon the information they receive is of course a separate issue. But at least it is clear that routers are not required to automatically drop RAs. Hesham > > - Ralph > > At 09:06 AM 11/20/2003 -0500, Soliman Hesham wrote: > > > > > > Is there a reason to differentiate between nodes acting as > > > hosts here, but > > > not in the paragraph describing the behavior in response to > > > the 'M' bit? > > > >=> In general, unless previously discussed and rejected for some > >reason, I'd globally: s/Nodes (acting as hosts)/host > > > >It's a bit clumsy to read as it is. > > > >Hesham > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 09:32:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06063 for ; Thu, 20 Nov 2003 09:32:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpqU-0005kU-RB for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:31:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEVkDN022092 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:31:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpqU-0005kF-Jg for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06010 for ; Thu, 20 Nov 2003 09:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpqS-0003pb-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:31:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpqS-0003pY-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:31:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMppl-0005Ou-L4; Thu, 20 Nov 2003 09:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpoz-0005NE-Td for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 09:30:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05883 for ; Thu, 20 Nov 2003 09:30:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpoy-0003mC-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:30:12 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpox-0003lX-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:30:11 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAKETAp05887; Thu, 20 Nov 2003 16:29:10 +0200 Date: Thu, 20 Nov 2003 16:29:10 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: john.loughney@nokia.com, Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) In-Reply-To: <4.3.2.7.2.20031120090748.01ead000@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 20 Nov 2003, Ralph Droms wrote: > I strongly suggest the use of "Nodes" (unqualified) in the text > about the 'O' bit: > > IPv6 Nodes that implement DHCP, MUST use DHCP upon > the receipt of a Router Advertisement with the 'O' flag set (see > section 5.5.3 of RFC2462). > > There is no reason a router can't use DHCPv6 for other configuration > information. I agree on this point. However, the text you quote is ambiguous, which was the reason for my rewording proposal. If A node gets 'O' -bit advertisement (without M bit), and implements DHCP, should it try to run it in "stateless mode", without trying to get addresses or not? That is, "use DHCP" is not clear because it can refer to getting addresses, other config information or both. Similarly, "implement DHCP" is not clear, because you can implement full or stateless DHCP, which provide different functions. This text needs a bit of revising. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 09:42:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06541 for ; Thu, 20 Nov 2003 09:42:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMq0B-0007iG-57 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:41:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEflXo029642 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:41:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMq0A-0007i1-WA for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:41:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06507 for ; Thu, 20 Nov 2003 09:41:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMq09-00040M-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:41:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMq08-00040I-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:41:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpzR-0007Uf-GH; Thu, 20 Nov 2003 09:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpz5-0007U3-4b for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 09:40:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06470 for ; Thu, 20 Nov 2003 09:40:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpz3-0003zT-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:40:37 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpz2-0003yl-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:40:36 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEe3At013224; Thu, 20 Nov 2003 06:40:04 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED19561; Thu, 20 Nov 2003 09:40:01 -0500 (EST) Message-Id: <4.3.2.7.2.20031120093743.01ed4c58@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Nov 2003 09:39:58 -0500 To: Pekka Savola From: Ralph Droms Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Cc: john.loughney@nokia.com, In-Reply-To: References: <4.3.2.7.2.20031120090748.01ead000@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Pekka - The specific text is ambiguous ... however, in John's message of 11/20, there is a sentence later in the same paragraph: In this context, 'use DHCP' means trying to obtain only other configuration information through DHCP, not address(es). That sentence clarifies the text I quoted. - Ralph At 04:29 PM 11/20/2003 +0200, Pekka Savola wrote: >On Thu, 20 Nov 2003, Ralph Droms wrote: > > I strongly suggest the use of "Nodes" (unqualified) in the text > > about the 'O' bit: > > > > IPv6 Nodes that implement DHCP, MUST use DHCP upon > > the receipt of a Router Advertisement with the 'O' flag set (see > > section 5.5.3 of RFC2462). > > > > There is no reason a router can't use DHCPv6 for other configuration > > information. > >I agree on this point. > >However, the text you quote is ambiguous, which was the reason for my >rewording proposal. If A node gets 'O' -bit advertisement (without M >bit), and implements DHCP, should it try to run it in "stateless >mode", without trying to get addresses or not? > >That is, "use DHCP" is not clear because it can refer to getting >addresses, other config information or both. > >Similarly, "implement DHCP" is not clear, because you can implement >full or stateless DHCP, which provide different functions. > >This text needs a bit of revising. > >-- >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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 11:06:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10910 for ; Thu, 20 Nov 2003 11:06:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrK2-0003yE-8V for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 11:06:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKG6MSN015261 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 11:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrK1-0003y4-Fa for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:06:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10821 for ; Thu, 20 Nov 2003 11:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrJy-0005Cy-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 11:06:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrJy-0005Cv-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 11:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrIl-0003c1-L8; Thu, 20 Nov 2003 11:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrIU-0003bI-Qw for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 11:04:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10741 for ; Thu, 20 Nov 2003 11:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrIS-0005BC-00 for ipv6@ietf.org; Thu, 20 Nov 2003 11:04:44 -0500 Received: from astronomyinspanish.org ([140.252.1.54] helo=noao.edu) by ietf-mx with esmtp (Exim 4.12) id 1AMrIR-0005B2-00 for ipv6@ietf.org; Thu, 20 Nov 2003 11:04:43 -0500 Received: from baja.tuc.noao.edu ([140.252.8.105] verified) by noao.edu (CommuniGate Pro SMTP 4.1.5) with ESMTP id 9603020; Thu, 20 Nov 2003 09:04:41 -0700 Received: (from shroff@localhost) by baja.tuc.noao.edu (8.11.6+Sun/8.11.6) id hAKG6jl07764; Thu, 20 Nov 2003 09:06:45 -0700 (MST) Date: Thu, 20 Nov 2003 09:06:45 -0700 (MST) From: "Chirag H. Shroff" Message-Id: <200311201606.hAKG6jl07764@baja.tuc.noao.edu> To: ipv6@ietf.org Subject: Re: How do I unsubscribe? Have tried lots of possibillities but no success. Please help! Cc: dag@dxtoolbox.com X-Sun-Charset: US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I have tried several times to unsubscribe too. Please remove me from the mail list. Chirag > From ipv6-admin@ietf.org Thu Nov 20 03:14:12 2003 > X-SpamCatcher-Score: 1 [X] > X-Autogenerated: Mirror > X-Mirrored-by: > X-SpamCatcher-Score: 1 [X] > X-Real-To: > From: "Dag Veierod" > To: > Subject: How do I unsubscribe? Have tried lots of possibillities but no success. Please help! > Date: Thu, 20 Nov 2003 09:39:25 +0100 > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 > Importance: Normal > Content-Transfer-Encoding: 7bit > X-BeenThere: ipv6@ietf.org > X-Mailman-Version: 2.0.12 > List-Unsubscribe: , > > List-Id: IP Version 6 Working Group (ipv6) > List-Post: > List-Help: > List-Subscribe: , > > > > > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > john.loughney@nokia.com > Sent: 20. november 2003 09:36 > To: john.loughney@nokia.com; ipv6@ietf.org > Subject: RE: Node Req: Issue31: DHCPv6 text > > Hi All, > > I forgot other text that Pekka suggested, here is all of the text: > > reword: > > For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' flag set (see > section 5.5.3 of RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > to: > > Nodes that implement DHCPv6 MUST use DHCP upon the receipt of a > Router Advertisement with the 'M' flag set (see section 5.5.3 of > RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCPv6 MUST attempt to use DHCPv6. In this > > context, 'use DHCP' means trying to obtain both address(es) and > other configuration information through DHCP. > > and: > > reword: > > For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' flag set (see > section 5.5.3 of RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > > to: > > Nodes that implement DHCP MUST use DHCP upon the receipt of a > Router Advertisement with the 'M' flag set (see section 5.5.3 of > RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this > context, 'use DHCP' means trying to obtain both address(es) and > other configuration information through DHCP. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 11:17:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11438 for ; Thu, 20 Nov 2003 11:17:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrUB-0005do-JO for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 11:16:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGGp69021684 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 11:16:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrUB-0005df-DK for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:16:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11369 for ; Thu, 20 Nov 2003 11:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrUA-0005P3-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 11:16:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrUA-0005Ox-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 11:16:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrTO-0005KD-IO; Thu, 20 Nov 2003 11:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrTI-0005J5-8r for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 11:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11284 for ; Thu, 20 Nov 2003 11:15:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrTH-0005L8-00 for ipv6@ietf.org; Thu, 20 Nov 2003 11:15:55 -0500 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AMrTG-0005L2-00 for ipv6@ietf.org; Thu, 20 Nov 2003 11:15:54 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 55A8B8008; Thu, 20 Nov 2003 17:15:51 +0100 (CET) From: "Jeroen Massar" To: "'Chirag H. Shroff'" , Subject: Mailman unsubscribe FAQ (Was: How do I unsubscribe? Have tried lots of possibillities but no success. Please help!) Date: Thu, 20 Nov 2003 17:15:51 +0100 Organization: Unfix Message-ID: <003901c3af81$91c9f680$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.4510 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200311201606.hAKG6jl07764@baja.tuc.noao.edu> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Chirag H. Shroff wrote: > I have tried several times to unsubscribe too. Please remove me from > the mail list. > > X-Mirrored-by: > > X-SpamCatcher-Score: 1 [X] > > X-Real-To: That is the address with which you are really subscribed to the list. > > From: "Dag Veierod" Same problem, but somewhat different was for this person. These are the links, as in every message's header, per RFC: > > List-Unsubscribe: , > > > > List-Id: IP Version 6 Working Group (ipv6) > > List-Post: > > List-Help: > > List-Subscribe: , > > And also the webinterface as noted in the footer: > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- And otherwise one can also always mail ipv6-admin@ietf.org.... Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP7zotSmqKFIzPnwjEQLYEQCfRfJzHHR5ccwVoTYGuj5D+zBXxcIAn2o0 8O6h1oM2swT5VHp8noZ+6Pkq =6Bk5 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 13:48:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18188 for ; Thu, 20 Nov 2003 13:48:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtqH-0000fv-Gn for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 13:47:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKIlnIs002591 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 13:47:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtqH-0000fi-CU for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 13:47:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18138 for ; Thu, 20 Nov 2003 13:47:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtqF-0000H5-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 13:47:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMtqE-0000H0-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 13:47:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtoc-0000JJ-77; Thu, 20 Nov 2003 13:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtoE-0000E7-3N for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 13:45:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17975; Thu, 20 Nov 2003 13:45:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMto9-0000Ca-00; Thu, 20 Nov 2003 13:45:37 -0500 Received: from firecrest.mail.pas.earthlink.net ([207.217.121.247]) by ietf-mx with esmtp (Exim 4.12) id 1AMto8-0000CX-00; Thu, 20 Nov 2003 13:45:36 -0500 Received: from 235.130.dothill.com ([155.254.130.235] helo=EGRodriguez) by firecrest.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 1AMto7-0007ky-00; Thu, 20 Nov 2003 10:45:35 -0800 From: "Elizabeth Rodriguez" To: Cc: , Subject: Reminder: IMSS Working Group last call on IPv6 over Fibre Channel Draft Ends Monday Nov 24 Date: Thu, 20 Nov 2003 10:44:47 -0800 Message-ID: <000901c3af96$6e4e3440$6d01a8c0@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 X-ELNK-Trace: 298a5331f71a6b7b79fa035ab2d882059ef193a6bfc3dd48b753f2c9bf31778dbac1300a30a7e950350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is a reminder that the FC over IPv6 draft is currently in IMSS = working group last call. The last call period ends on November 24 at 9pm EST. The draft may be found at=20 www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-00.t= xt A link to the draft may also be found at the bottom of the IMSS WG home = page at www.ietf.org/html.charters/imss-charter.html. This page also = includes instructions on subscribing to the mailing list. If anyone has comments against this draft, please post them to the IMSS mailing list. If the comments are only editorial in nature, they may be posted to the mailing list or send directly to the author with copies to = the chair and technical advisors as indicated below. The original WG Last Call announcement follows. Thanks, Elizabeth Rodriguez IMSS Chair Note: The URLs above have been verified. If the URLs above do not work = for you, make sure your mailer has not split the URL over two lines. =20 -----Original Message----- From: imss-admin@ietf.org [mailto:imss-admin@ietf.org] On Behalf Of elizabeth.rodriguez@dothill.com Sent: Sunday, November 02, 2003 8:59 PM To: imss@ietf.org Cc: ipv6@ietf.org; t11_3@t11.org; cds@andiamo.com; black_david@emc.com; Margaret.Wasserman@nokia.com; bwijnen@lucent.com Subject: [imss] IMSS: Working Group last call on IPv6 over Fibre Channel Draft Hello, I would like to announce the IETF IMSS Working Group last call on the = IPv6 over Fibre Channel draft. The draft may be found at http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-chann= el- 00.txt The last call period will end at 9pm EST on Monday, November 24, 2003. =20 Please address any technical comments to the IMSS mailing list at imss@ietf.org.=20 Editorial comments may be made directly to the draft author, Claudio DeSanti, at cds@andiamo.com. Please copy me at elizabeth.rodriguez@dothill.com and our technical coordinators for this draft, David Black (black_david@emc.com) and = Margaret Wasserman (margaret.wasserman@nokia.com). Summary: Draft: IPv6 over Fibre Channel Draft URL: http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-chann= el- 00.txt WGLC ends: Monday, November 24, 2003 at 9pm EST Technical comments to: imss@ietf.org Editorial comments to: Claudio DeSanti (cds@andiamo.org), David Black (black_david@emc.com), Margaret Wasserman (margaret.wasserman@nokia.com) = and Elizabeth Rodriguez (elizabeth.rodriguez@dothill.com) Thank you, Elizabeth Rodriguez IMSS Chair IMSS Charter: http://www.ietf.org/html.charters/imss-charter.html To subscribe to the IMSS mailing list, see https://www1.ietf.org/mailman/listinfo/imss _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 14:52:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20964 for ; Thu, 20 Nov 2003 14:52:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuqj-0004l4-4J for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 14:52:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJqL78018286 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 14:52:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuqj-0004kr-03 for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:52:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20920 for ; Thu, 20 Nov 2003 14:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuqg-0001EJ-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 14:52:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMuqf-0001ED-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 14:52:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMupS-0004TR-7L; Thu, 20 Nov 2003 14:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuou-0004Sb-1C for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 14:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20794 for ; Thu, 20 Nov 2003 14:50:13 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuoq-0001Cd-00 for ipv6@ietf.org; Thu, 20 Nov 2003 14:50:24 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMuop-0001Ca-00 for ipv6@ietf.org; Thu, 20 Nov 2003 14:50:24 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAKJoMA16512 for ; Thu, 20 Nov 2003 21:50:22 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Nov 2003 21:50:21 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 13:50:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Date: Thu, 20 Nov 2003 14:50:19 -0500 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOux1B4G1HE4C0cQz2KBK0zYQ058QAeIsbAAAGiZFAAFdm7cA== To: , X-OriginalArrivalTime: 20 Nov 2003 19:50:20.0395 (UTC) FILETIME=[8777EBB0:01C3AF9F] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > to: >=20 > Nodes that implement DHCP MUST use DHCP upon the receipt of a=20 > Router Advertisement with the 'M' flag set (see section 5.5.3 of=20 > RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this=20 > context, 'use DHCP' means trying to obtain both address(es) and=20 > other configuration information through DHCP. This wording seems clumsy to me. How about: If no Router Advertisements are recieved within (NN seconds?) of joining a link and sending a Router Solicitation, IPv6 hosts that implement DHCPv6 should attempt to use DHCPv6 to obtain both IPv6 address(es) and other configuration information. [Do we need to say what happens if a router advertisement is received later?] Upon receipt of a router advertisement with the 'M' flag set (see section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST = attempt=20 to use DHCPv6 to obtain both IPv6 addess(es) and other configuration information. > to: >=20 > IPv6 Nodes (acting as hosts) that implement DHCP, MUST use=20 > DHCP upon=20 > the receipt of a Router Advertisement with the 'O' flag set (see=20 > section 5.5.3 of RFC2462). In addition, in the > absence of a router, hosts that implement DHCP MUST attempt to use > DHCP. In this context, 'use DHCP' means trying to obtain=20 > only other=20 > configuration information through DHCP, not address(es). >=20 > IPv6 Nodes that do not implement DHCP can ignore the 'O' flag=20 > of a Router Advertisement. Furthermore, in the absence of > a router, these types of node are not required to initiate DHCP. Similarly, how about: "Upon reciept of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST attempt to use DHCPv6 to obtain non-address configuration information, but not IPv6 address(es).=20 IPv6 nodes that do not implement DHCPv6 client functionality should ignore the 'M' and 'O' bits of the router advertisement." The no router case shouldn't be repeated here, as it is covered above. And, yes, I do think that hosts should attempt to use DHCPv6 to get IPv6 addresses in the absence of a router. Also, I=20 think it is silly to say that hosts that don't implement DHCPv6=20 don't need to use it... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 14:54:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21071 for ; Thu, 20 Nov 2003 14:54:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMusF-0005AO-QI for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 14:53:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJrtLS019854 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 14:53:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMusF-0005A9-K4 for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:53:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21025 for ; Thu, 20 Nov 2003 14:53:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMusC-0001GR-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 14:53:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMusC-0001GO-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 14:53:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMurO-0004rK-EM; Thu, 20 Nov 2003 14:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuqe-0004iM-Ad for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 14:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20916 for ; Thu, 20 Nov 2003 14:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuqb-0001EA-00 for ipv6@ietf.org; Thu, 20 Nov 2003 14:52:13 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMuqa-0001DG-00 for ipv6@ietf.org; Thu, 20 Nov 2003 14:52:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKJpe917746; Thu, 20 Nov 2003 11:51:40 -0800 X-mProtect: <200311201951> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd1w8NMc; Thu, 20 Nov 2003 11:51:38 PST Message-Id: <4.3.2.7.2.20031120114106.00b8bd38@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Nov 2003 11:50:29 -0800 To: john.loughney@nokia.com From: Bob Hinden Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Cc: ipv6@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , John, > For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' flag set (see > section 5.5.3 of RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. >to: > Nodes that implement DHCP MUST use DHCP upon the receipt of a > Router Advertisement with the 'M' flag set (see section 5.5.3 of > RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this > context, 'use DHCP' means trying to obtain both address(es) and > other configuration information through DHCP. Please remind me why the "in the absence of a router" text is there. I am having a hard time thinking about a scenario where there would be a DHCP server, but no router. The presences of a DHCP relay agent would also need a router to be useful. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 14:56:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21244 for ; Thu, 20 Nov 2003 14:56:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuu7-0005a4-EX for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 14:55:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJtpW9021446 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 14:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuu7-0005Zp-7a for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:55:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21167 for ; Thu, 20 Nov 2003 14:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuu4-0001Ia-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 14:55:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMuu4-0001IX-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 14:55:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMutK-0005Hk-Jk; Thu, 20 Nov 2003 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMut2-0005Gv-T6 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 14:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21130 for ; Thu, 20 Nov 2003 14:54:30 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMusz-0001HX-00 for ipv6@ietf.org; Thu, 20 Nov 2003 14:54:42 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMusz-0001HU-00 for ipv6@ietf.org; Thu, 20 Nov 2003 14:54:41 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAKJsf619904 for ; Thu, 20 Nov 2003 21:54:41 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 21:54:40 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 11:53:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Date: Thu, 20 Nov 2003 14:53:36 -0500 Message-ID: Thread-Topic: Node Req: Issue31: DHCPv6 text (ignore previous mails) Thread-Index: AcOvcsfbPbgAZZTbToSeR5wAKykavgALQ52Q To: , , , X-OriginalArrivalTime: 20 Nov 2003 19:53:37.0892 (UTC) FILETIME=[FD2F9240:01C3AF9F] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > =3D> In 6.2.7 : >=20 > Routers SHOULD inspect valid Router Advertisements sent by other > routers and verify that the routers are advertising consistent > information on a link. Detected inconsistencies indicate=20 > that one or > more routers might be misconfigured and SHOULD be logged=20 > to system or > network management. The minimum set of information to check > includes: >=20 > - Cur Hop Limit values (except for the unspecified value of zero). >=20 > - Values of the M or O flags. >=20 > - Reachable Time values (except for the unspecified value=20 > of zero). As far as I know, there is no requirement in the specs that routers receive and process other router advertisements. If not, we shouldn't add it here -- this is an informative docuement, not a place to create new specs. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 15:31:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24297 for ; Thu, 20 Nov 2003 15:31:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvSD-0008MZ-GE for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 15:31:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKV5fu032143 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 15:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvSD-0008MM-Bq for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24243 for ; Thu, 20 Nov 2003 15:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvSC-0001pi-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 15:31:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMvSB-0001pZ-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 15:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvRB-00081M-Vj; Thu, 20 Nov 2003 15:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvQT-0007zm-LV for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 15:29:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24102; Thu, 20 Nov 2003 15:29:04 -0500 (EST) Message-Id: <200311202029.PAA24102@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2013-update-02.txt Date: Thu, 20 Nov 2003 15:29:04 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the User Datagram Protocol (UDP) Author(s) : B. Fenner Filename : draft-ietf-ipv6-rfc2013-update-02.txt Pages : 21 Date : 2003-11-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) [4] in an IP version independent manner. It is intended to obsolete RFC 2013 and RFC 2454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2013-update-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2013-update-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-20154407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2013-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2013-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20154407.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 16:06:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26483 for ; Thu, 20 Nov 2003 16:06:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMw0Q-0002kA-ED for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:06:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKL6Qho010546 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:06:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMw0Q-0002k0-7P for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:06:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26447 for ; Thu, 20 Nov 2003 16:06:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMw0O-0002jj-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:06:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMw0B-0002jW-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:06:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvz5-0002WN-DY; Thu, 20 Nov 2003 16:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvyv-0002Vk-0P for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 16:04:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26398; Thu, 20 Nov 2003 16:04:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvyt-0002hu-00; Thu, 20 Nov 2003 16:04:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMvys-0002gi-00; Thu, 20 Nov 2003 16:04:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKL45v24940; Thu, 20 Nov 2003 13:04:05 -0800 X-mProtect: <200311202104> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJAIO1Z; Thu, 20 Nov 2003 13:04:03 PST Message-ID: <3FBD2E06.4060208@iprg.nokia.com> Date: Thu, 20 Nov 2003 13:11:34 -0800 From: Fred 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: Elizabeth Rodriguez CC: imss@ietf.org, t11_3@t11.org, ipv6@ietf.org Subject: Re: Reminder: IMSS Working Group last call on IPv6 over Fibre Channel Draft Ends Monday Nov 24 References: <000901c3af96$6e4e3440$6d01a8c0@EGRodriguez> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ~64KB MTU L2 media, huh? Sounds interesting. Has there been any consideration given to L2 bridging between FiberChannel and other media such as Gbps and 10/100 Ethernet, or are you expecting everything between dissimilar media to go through a router? Thanks - Fred ftemplin@iprg.nokia.com Elizabeth Rodriguez wrote: >This is a reminder that the FC over IPv6 draft is currently in IMSS working >group last call. The last call period ends on November 24 at 9pm EST. > >The draft may be found at >www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-00.txt > >A link to the draft may also be found at the bottom of the IMSS WG home page >at www.ietf.org/html.charters/imss-charter.html. This page also includes >instructions on subscribing to the mailing list. > >If anyone has comments against this draft, please post them to the IMSS >mailing list. If the comments are only editorial in nature, they may be >posted to the mailing list or send directly to the author with copies to the >chair and technical advisors as indicated below. > >The original WG Last Call announcement follows. > >Thanks, >Elizabeth Rodriguez >IMSS Chair > >Note: The URLs above have been verified. If the URLs above do not work for >you, make sure your mailer has not split the URL over two lines. > >-----Original Message----- >From: imss-admin@ietf.org [mailto:imss-admin@ietf.org] On Behalf Of >elizabeth.rodriguez@dothill.com >Sent: Sunday, November 02, 2003 8:59 PM >To: imss@ietf.org >Cc: ipv6@ietf.org; t11_3@t11.org; cds@andiamo.com; black_david@emc.com; >Margaret.Wasserman@nokia.com; bwijnen@lucent.com >Subject: [imss] IMSS: Working Group last call on IPv6 over Fibre Channel >Draft > >Hello, > >I would like to announce the IETF IMSS Working Group last call on the IPv6 >over Fibre Channel draft. >The draft may be found at >http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel- >00.txt >The last call period will end at 9pm EST on Monday, November 24, 2003. > >Please address any technical comments to the IMSS mailing list at >imss@ietf.org. >Editorial comments may be made directly to the draft author, Claudio >DeSanti, at cds@andiamo.com. >Please copy me at elizabeth.rodriguez@dothill.com and our technical >coordinators for this draft, David Black (black_david@emc.com) and Margaret >Wasserman (margaret.wasserman@nokia.com). > >Summary: > >Draft: IPv6 over Fibre Channel >Draft URL: >http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel- >00.txt >WGLC ends: Monday, November 24, 2003 at 9pm EST >Technical comments to: imss@ietf.org >Editorial comments to: Claudio DeSanti (cds@andiamo.org), David Black >(black_david@emc.com), Margaret Wasserman (margaret.wasserman@nokia.com) and >Elizabeth Rodriguez (elizabeth.rodriguez@dothill.com) > >Thank you, > >Elizabeth Rodriguez >IMSS Chair > >IMSS Charter: http://www.ietf.org/html.charters/imss-charter.html >To subscribe to the IMSS mailing list, see >https://www1.ietf.org/mailman/listinfo/imss > >_______________________________________________ >imss mailing list >imss@ietf.org >https://www1.ietf.org/mailman/listinfo/imss > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 16:12:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27002 for ; Thu, 20 Nov 2003 16:12:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMw5g-0003Ty-TL for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:11:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLBq6a013380 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:11:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMw5g-0003Tj-OS for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:11:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26942 for ; Thu, 20 Nov 2003 16:11:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMw5f-0002vY-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:11:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMw5e-0002vU-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:11:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMw4s-0003F0-Oy; Thu, 20 Nov 2003 16:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMw4a-0003Ea-HD for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 16:10:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26802 for ; Thu, 20 Nov 2003 16:10:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMw4Y-0002sM-00 for ipv6@ietf.org; Thu, 20 Nov 2003 16:10:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMw4Y-0002qt-00 for ipv6@ietf.org; Thu, 20 Nov 2003 16:10:42 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKL8nc27914; Thu, 20 Nov 2003 13:08:49 -0800 X-mProtect: <200311202108> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyxoL68; Thu, 20 Nov 2003 13:08:47 PST Message-ID: <3FBD2F22.7010004@iprg.nokia.com> Date: Thu, 20 Nov 2003 13:16:18 -0800 From: Fred 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: Margaret.Wasserman@nokia.com CC: H.Soliman@flarion.com, rdroms@cisco.com, john.loughney@nokia.com, ipv6@ietf.org Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I havn't followed this discussion closely, but in my opinion we have no business legislating anything stronger than a MAY in relation to handling the M & O bits in received Router Advertisements. Sorry if this goes against other opinions, but that's the way I see it. Fred ftemplin@iprg.nokia.com Margaret.Wasserman@nokia.com wrote: >>=> In 6.2.7 : >> >> Routers SHOULD inspect valid Router Advertisements sent by other >> routers and verify that the routers are advertising consistent >> information on a link. Detected inconsistencies indicate >>that one or >> more routers might be misconfigured and SHOULD be logged >>to system or >> network management. The minimum set of information to check >> includes: >> >> - Cur Hop Limit values (except for the unspecified value of zero). >> >> - Values of the M or O flags. >> >> - Reachable Time values (except for the unspecified value >>of zero). >> >> > >As far as I know, there is no requirement in the specs that routers >receive and process other router advertisements. If not, we shouldn't >add it here -- this is an informative docuement, not a place to create >new specs. > >Margaret > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 16:28:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28772 for ; Thu, 20 Nov 2003 16:28:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwLo-0005H8-CR for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:28:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLSWIg020272 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwLo-0005Gt-6h for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:28:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28688 for ; Thu, 20 Nov 2003 16:28:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwLa-0003cf-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:28:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMwLZ-0003cc-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:28:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwKM-00050g-JZ; Thu, 20 Nov 2003 16:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwJa-0004xQ-97 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 16:26:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28379 for ; Thu, 20 Nov 2003 16:26:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwJY-0003WE-00 for ipv6@ietf.org; Thu, 20 Nov 2003 16:26:12 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwJX-0003W5-00 for ipv6@ietf.org; Thu, 20 Nov 2003 16:26:11 -0500 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 VAA25200 for ; Thu, 20 Nov 2003 21:26:10 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA05793 for ; Thu, 20 Nov 2003 21:26:10 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAKLQAC13041 for ipv6@ietf.org; Thu, 20 Nov 2003 21:26:10 GMT Date: Thu, 20 Nov 2003 21:26:10 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Message-ID: <20031120212609.GN12489@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <4.3.2.7.2.20031120114106.00b8bd38@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.20031120114106.00b8bd38@mailhost.iprg.nokia.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, Nov 20, 2003 at 11:50:29AM -0800, Bob Hinden wrote: > > Please remind me why the "in the absence of a router" text is there. I am > having a hard time thinking about a scenario where there would be a DHCP > server, but no router. The presences of a DHCP relay agent would also need > a router to be useful. One assumes that the router would invariably be the relay agent... Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 16:35:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29407 for ; Thu, 20 Nov 2003 16:35:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwRr-0005qA-Iy for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:34:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLYlJF022443 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 16:34:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwRr-0005pu-Dc for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:34:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29363 for ; Thu, 20 Nov 2003 16:34:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwRp-0003r1-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:34:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMwRp-0003qy-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 16:34:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwR8-0005cs-5A; Thu, 20 Nov 2003 16:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwQk-0005cB-QV for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 16:33:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29290 for ; Thu, 20 Nov 2003 16:33:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwQi-0003pu-00 for ipv6@ietf.org; Thu, 20 Nov 2003 16:33:36 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwQi-0003po-00 for ipv6@ietf.org; Thu, 20 Nov 2003 16:33:36 -0500 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 VAA25334 for ; Thu, 20 Nov 2003 21:33:02 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA05842 for ; Thu, 20 Nov 2003 21:33:02 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAKLX2f13085 for ipv6@ietf.org; Thu, 20 Nov 2003 21:33:02 GMT Date: Thu, 20 Nov 2003 21:33:02 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Message-ID: <20031120213302.GO12489@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, Nov 20, 2003 at 02:50:19PM -0500, Margaret.Wasserman@nokia.com wrote: > > Upon receipt of a router advertisement with the 'M' flag set (see > section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST attempt > to use DHCPv6 to obtain both IPv6 addess(es) and other configuration > information. Well, section 5.5.3 says "should invoke" (lower case) not MUST....? [Aside: What was the thinking behind the M bit meaning "address and other info", and the O bit "other info" - would it not have been cleaner for M to mean "address info" and O to mean "other info"? Just curious as to why it was done that way...] Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 18:33:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07849 for ; Thu, 20 Nov 2003 18:33:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyIb-0005om-CP for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 18:33:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKNXL4G022354 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 18:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyIb-0005oT-7S for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 18:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07816 for ; Thu, 20 Nov 2003 18:33:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyIY-0006jm-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 18:33:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMyIX-0006jj-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 18:33:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyHK-0005bw-Ds; Thu, 20 Nov 2003 18:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyFD-0005M3-Cc for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 18:29:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07708; Thu, 20 Nov 2003 18:29:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyFA-0006gK-00; Thu, 20 Nov 2003 18:29:48 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMyF9-0006g1-00; Thu, 20 Nov 2003 18:29:47 -0500 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAKNTFAt015091; Thu, 20 Nov 2003 15:29:15 -0800 (PST) Received: from cds-w2k02.andiamo.com (dhcp-171-71-49-41.cisco.com [171.71.49.41]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT24092; Thu, 20 Nov 2003 15:29:14 -0800 (PST) Message-Id: <4.3.2.7.2.20031120151330.03892778@mira-sjcd-1.cisco.com> X-Sender: cds@andiamo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Nov 2003 15:29:14 -0800 To: Fred Templin From: Claudio DeSanti Subject: Re: [imss] Re: Reminder: IMSS Working Group last call on IPv6 over Fibre Channel Draft Ends Monday Nov 24 Cc: Elizabeth Rodriguez , imss@ietf.org, t11_3@t11.org, ipv6@ietf.org In-Reply-To: <3FBD2E06.4060208@iprg.nokia.com> References: <000901c3af96$6e4e3440$6d01a8c0@EGRodriguez> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Fred, the ~64KB MTU comes from RFC 2625 (IPv4 over Fibre Channel), and one of the goals of the IPv6 over FC specification is to keep unchanged the encapsulation technique between IPv4 and IPv6. I understand that with IPv6 a bridge has no more the option to fragment a too big packet, as in IPv4, but I do not believe this is an issue, because: - router advertisements may announce a proper MTU over a bridged network; - current deployments are almost entirely based on routers instead than on bridges. In any case, if the group believes this to be an issue, then we have the same issue also for RFC 2467 (Transmission of IPv6 Packets over FDDI Networks), where the default MTU is 4352 octets. If it is not a problem there, then it is neither a problem here. Thanks, Claudio. At 01:11 PM 11/20/2003 -0800, Fred Templin wrote: >~64KB MTU L2 media, huh? Sounds interesting. > >Has there been any consideration given to L2 bridging >between FiberChannel and other media such as Gbps >and 10/100 Ethernet, or are you expecting everything >between dissimilar media to go through a router? > >Thanks - Fred >ftemplin@iprg.nokia.com > >Elizabeth Rodriguez wrote: > >>This is a reminder that the FC over IPv6 draft is currently in IMSS working >>group last call. The last call period ends on November 24 at 9pm EST. >> >>The draft may be found at >>www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-00.txt >> >>A link to the draft may also be found at the bottom of the IMSS WG home page >>at www.ietf.org/html.charters/imss-charter.html. This page also includes >>instructions on subscribing to the mailing list. >> >>If anyone has comments against this draft, please post them to the IMSS >>mailing list. If the comments are only editorial in nature, they may be >>posted to the mailing list or send directly to the author with copies to the >>chair and technical advisors as indicated below. >> >>The original WG Last Call announcement follows. >> >>Thanks, >>Elizabeth Rodriguez >>IMSS Chair >> >>Note: The URLs above have been verified. If the URLs above do not work for >>you, make sure your mailer has not split the URL over two lines. >> >>-----Original Message----- >>From: imss-admin@ietf.org [mailto:imss-admin@ietf.org] On Behalf Of >>elizabeth.rodriguez@dothill.com >>Sent: Sunday, November 02, 2003 8:59 PM >>To: imss@ietf.org >>Cc: ipv6@ietf.org; t11_3@t11.org; cds@andiamo.com; black_david@emc.com; >>Margaret.Wasserman@nokia.com; bwijnen@lucent.com >>Subject: [imss] IMSS: Working Group last call on IPv6 over Fibre Channel >>Draft >> >>Hello, >> >>I would like to announce the IETF IMSS Working Group last call on the IPv6 >>over Fibre Channel draft. >>The draft may be found at >>http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel- >>00.txt >>The last call period will end at 9pm EST on Monday, November 24, 2003. >> >>Please address any technical comments to the IMSS mailing list at >>imss@ietf.org. Editorial comments may be made directly to the draft >>author, Claudio >>DeSanti, at cds@andiamo.com. >>Please copy me at elizabeth.rodriguez@dothill.com and our technical >>coordinators for this draft, David Black (black_david@emc.com) and Margaret >>Wasserman (margaret.wasserman@nokia.com). >> >>Summary: >> >>Draft: IPv6 over Fibre Channel >>Draft URL: >>http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel- >>00.txt >>WGLC ends: Monday, November 24, 2003 at 9pm EST >>Technical comments to: imss@ietf.org >>Editorial comments to: Claudio DeSanti (cds@andiamo.org), David Black >>(black_david@emc.com), Margaret Wasserman (margaret.wasserman@nokia.com) and >>Elizabeth Rodriguez (elizabeth.rodriguez@dothill.com) >> >>Thank you, >> >>Elizabeth Rodriguez >>IMSS Chair >> >>IMSS Charter: http://www.ietf.org/html.charters/imss-charter.html >>To subscribe to the IMSS mailing list, see >>https://www1.ietf.org/mailman/listinfo/imss >> >>_______________________________________________ >>imss mailing list >>imss@ietf.org >>https://www1.ietf.org/mailman/listinfo/imss >> >> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> > > > >_______________________________________________ >imss mailing list >imss@ietf.org >https://www1.ietf.org/mailman/listinfo/imss -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 19:40:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11367 for ; Thu, 20 Nov 2003 19:40:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMzLF-0001bs-JU for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 19:40:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL0e9J4006168 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 19:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMzLE-0001b2-I7 for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 19:40:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11332 for ; Thu, 20 Nov 2003 19:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMzLC-0000Jb-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 19:40:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMzLC-0000JS-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 19:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMzK9-0001Iy-TD; Thu, 20 Nov 2003 19:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMzK8-0001Ij-Aw for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 19:39:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11296 for ; Thu, 20 Nov 2003 19:38:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMzK6-0000IW-00 for ipv6@ietf.org; Thu, 20 Nov 2003 19:38:58 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMzK5-0000IS-00 for ipv6@ietf.org; Thu, 20 Nov 2003 19:38:57 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAL0cjLL013890 for ; Thu, 20 Nov 2003 17:38:48 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id hAL0cbrO000630 for ; Thu, 20 Nov 2003 18:38:40 -0600 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.10/8.12.10) with ESMTP id hAL0caoF002708 for ; Fri, 21 Nov 2003 11:38:36 +1100 (EST) Message-ID: <3FBD5E8C.BB5188A7@motorola.com> Date: Fri, 21 Nov 2003 11:38:36 +1100 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 CC: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: <001b01c3ae9e$c2f81590$ec061eac@ttitelecom.com> <3FBBBA9A.2807ED2F@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit EricLKlein wrote: > This is not the first time that I have heard that someone was willing to > skip IPv6 because of the percieved pain and security threat that > standards compliance would entail. But then again these are all people > that take security and network administration very personal and very > seriously, and the idea of having the accounts recievable (or worse > payable) computer with a globaly reachable address scares them to heck. > > To be honest I stated these concerns back in the spring, and I still > haven't seen anything that would work to convince me that this is not > what we as a WG are proposing. If someone converts their existing network > to a globaly unique address range then what is responsible for filtering > all of the critical addresses from sending or recieving packets from the > network over the network Interent router? I see this as being moved from > the protocol level to that of the network technician, who now needs to > explicitly deny individual addresses (or ranges) rather and explicityl > allow the permited ranges. The problem with these people's arguments is that it's not the address range that gives the security, it's the fact that you have an isolated network connected to the global network via only a proxy (NAT) and firewall. You can use any address range you like inside the NAT. However, if you don't use a 'private' range you're running two risks: - masking a portion of the global internet - leaking addresses that look real but are actually invalid rather than obviously invalid ones. The advantage of a local/private address range is that you can create one for whatever local use you need without needing to obtain space through a registration authority. The advantage of 'approximately unique' local addresses (in the style of the Hinden/Haberman draft) is that you get addresses with all the benefits of private address AND they're not likely to conflict if you merge. Any 'security advantage' of local/private addresses is just that if they leak they are LIKELY (no guarantee) to not work 'properly'. *As I understand it*, the TRANSLATION function of the NAT doesn't gain you any real security benefits, except for scrambling your traffic (whether this is a benefit is up for debate). However, the many->one nature of most deployed NATs acts as a stateful firewall. You get almost all the security benefits (without the scrambling) by putting a stateful firewall in place with a very simple rule - if I didn't send something out, don't let anything back. If you really want isolation, add a proxy of your choice. And if your firewall isn't passing traffic, it doesn't matter what address range is on the inside. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 21:25:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14186 for ; Thu, 20 Nov 2003 21:25:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0yv-0007Pq-U2 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 21:25:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL2PD5m028500 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 21:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0yv-0007Pb-Os for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 21:25:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14155 for ; Thu, 20 Nov 2003 21:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0ys-0001g9-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 21:25:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN0ys-0001g6-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 21:25:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0xm-00076X-Gd; Thu, 20 Nov 2003 21:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN0xL-00075z-1d for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 21:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14093 for ; Thu, 20 Nov 2003 21:23:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN0xI-0001es-00 for ipv6@ietf.org; Thu, 20 Nov 2003 21:23:32 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AN0xH-0001ep-00 for ipv6@ietf.org; Thu, 20 Nov 2003 21:23:31 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id ACFE9AFDE1 for ; Thu, 20 Nov 2003 21:23:32 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00635-08; Thu, 20 Nov 2003 21:23:31 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7B9B5AFB5C; Thu, 20 Nov 2003 21:23:31 -0500 (EST) Date: Thu, 20 Nov 2003 21:24:11 -0500 Subject: names for non-global addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Keith Moore To: ipv6@ietf.org From: Keith Moore Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I still prefer GUPI (pronounced "guppy" like the fish) - globally unique provider-independent PUPI (pronounced "puppy" like a young dog) - probably unique provider-independent as having about the right ratio of cuteness to mnemonic power. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 20 22:13:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15360 for ; Thu, 20 Nov 2003 22:13:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN1j9-0002Be-07 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 22:13:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL3CwSF008400 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 22:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN1j8-0002BP-Pp for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 22:12:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15308 for ; Thu, 20 Nov 2003 22:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN1j5-0002Ay-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 22:12:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN1j5-0002Av-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 22:12:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN1iD-0001yg-Lc; Thu, 20 Nov 2003 22:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN1hI-0001xz-Gx for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 22:11:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15277; Thu, 20 Nov 2003 22:10:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN1hF-0002AE-00; Thu, 20 Nov 2003 22:11:01 -0500 Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1AN1hE-0002AB-00; Thu, 20 Nov 2003 22:11:00 -0500 Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id AD45543888B; Thu, 20 Nov 2003 22:10:56 -0500 (EST) Received: by server2.messagingengine.com (Postfix, from userid 99) id ECFE37E937; Thu, 20 Nov 2003 22:10:55 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: "Claudio DeSanti" , "Fred Templin" Date: Fri, 21 Nov 2003 08:40:55 +0530 X-Sasl-Enc: O0Hv+wy+7plF+vdPxAS4xw 1069384255 Cc: "Elizabeth Rodriguez" , imss@ietf.org, t11_3@t11.org, ipv6@ietf.org Subject: Re: [imss] Re: Reminder: IMSS Working Group last call on IPv6 over Fibre Channel Draft Ends Monday Nov 24 References: <000901c3af96$6e4e3440$6d01a8c0@EGRodriguez> <4.3.2.7.2.20031120151330.03892778@mira-sjcd-1.cisco.com> In-Reply-To: <4.3.2.7.2.20031120151330.03892778@mira-sjcd-1.cisco.com> Message-Id: <20031121031055.ECFE37E937@server2.messagingengine.com> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 20 Nov 2003 15:29:14 -0800, "Claudio DeSanti" said: > I understand that with IPv6 a bridge has no more the option to fragment > a too big packet, as in IPv4, but I do not believe this is an issue, > because: > - router advertisements may announce a proper MTU over a bridged > network; ND-proxy draft has the same recommendation for handling MTU within a subnet comprising of multiple L2-technologies. You can find the draft at: http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-01.txt Section 4.1.3.3 covers processing of RA's. CP -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 01:13:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19191 for ; Fri, 21 Nov 2003 01:13:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN4XU-00046Y-Ac for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 01:13:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL6D8C1015772 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 01:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN4XT-00046I-VF for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 01:13:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19149 for ; Fri, 21 Nov 2003 01:12:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN4XQ-0004MO-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 01:13:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN4XQ-0004ML-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 01:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN4WP-0003t1-VB; Fri, 21 Nov 2003 01:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN4WM-0003sf-MZ for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 01:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19111 for ; Fri, 21 Nov 2003 01:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN4WJ-0004LN-00 for ipv6@ietf.org; Fri, 21 Nov 2003 01:11:55 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AN4WI-0004L3-00 for ipv6@ietf.org; Fri, 21 Nov 2003 01:11:55 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HOO00804UIK73@mailout2.samsung.com> for ipv6@ietf.org; Fri, 21 Nov 2003 15:11:08 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HOO003MZUIKXT@mailout2.samsung.com> for ipv6@ietf.org; Fri, 21 Nov 2003 15:11:08 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HOO00F98UIJA6@mmp1.samsung.com> for ipv6@ietf.org; Fri, 21 Nov 2003 15:11:08 +0900 (KST) Date: Fri, 21 Nov 2003 15:11:35 +0900 From: Soohong Daniel Park Subject: Isn't there any link to refer slides To: ipv6@ietf.org Message-id: <001401c3aff6$51867dd0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello Isn't there any link to refer slides ? If available, let me know it. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 03:17:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04578 for ; Fri, 21 Nov 2003 03:17:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6T9-0004Be-OL for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 03:16:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL8GlV3016095 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 03:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6T7-0004BW-LD for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 03:16:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04546 for ; Fri, 21 Nov 2003 03:16:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6T5-0005sA-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:16:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN6T4-0005s7-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:16:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6SR-000423-Ie; Fri, 21 Nov 2003 03:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6SE-00041R-4V for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 03:15:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04532 for ; Fri, 21 Nov 2003 03:15:37 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6SB-0005qB-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:15:47 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AN6SA-0005q7-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:15:47 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAL8Fh614295 for ; Fri, 21 Nov 2003 10:15:43 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Nov 2003 10:15:41 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 10:15:41 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 29: AD REVIEW: IPv6 Node Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 21 Nov 2003 10:15:40 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOvXfsBIu8BfOEYSDGRRFQB+I9hpQAqaWuA To: Cc: , X-OriginalArrivalTime: 21 Nov 2003 08:15:41.0409 (UTC) FILETIME=[A7451D10:01C3B007] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Jari, I agree this text is good. John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 20 November, 2003 13:56 > To: Loughney John (NRC/Helsinki) > Cc: brian@innovationslab.net; ipv6@ietf.org > Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements >=20 >=20 > john.loughney@nokia.com wrote: > > Hi all, > >=20 > > The 2nd paragraph in 4.6 looks like: > >=20 > > If an application is going to support Source-Specific Multicast,=20 > > it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the=20 > > Source-Specific Multicast overview document [RFC3569]; refer to=20 > > Source-Specific Multicast architecture document for=20 > details [SSMARCH]. > >=20 > > I think that is sufficient strength to address Jean-Jacques concern, > > as SHOULD is quite strong. >=20 > Hmm.... I think RFC 3569 says that you can only do SSM with MLDv2, > not with MLDv1. Also, I wouldn't put an informative document like > 3569 after a keyword. >=20 > We need to put Brian's SHOULD..MAY suggestion into the text, but > in a slightly different form. Here is one suggested rewrite: >=20 > 4.6 Multicast Listener Discovery (MLD) >=20 > Nodes that need to join multicast groups SHOULD implement MLDv2 > [MLDv2]. However, if the node has applications which only need > support for Any-Source Multicast [RFC3569], the node MAY implement > MLDv1 [MLDv1] instead. If the node has applications which need > support for Source-Specific Multicast [RFC3569, SSMARCH], the > node MUST support MLDv2 [MLDv2]. >=20 > When MLD is used, the rules in "Source Address Selection for the > Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be > followed. >=20 > --Jari >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 03:25:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04811 for ; Fri, 21 Nov 2003 03:25:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6bZ-0005J8-U2 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 03:25:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL8PT1U020396 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 03:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6bX-0005It-Ut for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 03:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04776 for ; Fri, 21 Nov 2003 03:25:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6bV-0005yp-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:25:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN6bV-0005ym-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:25:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6bB-00059F-Bx; Fri, 21 Nov 2003 03:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6b2-00057V-OB for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 03:24:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04759 for ; Fri, 21 Nov 2003 03:24:44 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6b0-0005yE-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:24:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AN6az-0005y9-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:24:53 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAL8Os628742 for ; Fri, 21 Nov 2003 10:24:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Nov 2003 10:24:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 10:24:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 21 Nov 2003 10:24:53 +0200 Message-ID: Thread-Topic: Node Req: Issue31: DHCPv6 text (ignore previous mails) Thread-Index: AcOvdJ/tzz+78wJrSDiit7U9DG8PLQAlEF+g To: , Cc: X-OriginalArrivalTime: 21 Nov 2003 08:24:53.0653 (UTC) FILETIME=[F06EDC50:01C3B008] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ralph, Expanding your text, would this be acceptable: IPv6 Nodes that implement DHCP, MUST use DHCP to obtain other = configuration=20 information (not including address(es) upon the receipt of a Router=20 Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). John > -----Original Message----- > From: ext Ralph Droms [mailto:rdroms@cisco.com] > Sent: 20 November, 2003 16:40 > To: Pekka Savola > Cc: Loughney John (NRC/Helsinki); ipv6@ietf.org > Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) >=20 >=20 > Pekka - The specific text is ambiguous ... however, in John's > message of 11/20, there is a sentence later in the same paragraph: >=20 > In this context, 'use DHCP' means trying to obtain only other > configuration information through DHCP, not address(es). >=20 > That sentence clarifies the text I quoted. >=20 > - Ralph >=20 > At 04:29 PM 11/20/2003 +0200, Pekka Savola wrote: > >On Thu, 20 Nov 2003, Ralph Droms wrote: > > > I strongly suggest the use of "Nodes" (unqualified) in the text > > > about the 'O' bit: > > > > > > IPv6 Nodes that implement DHCP, MUST use DHCP upon > > > the receipt of a Router Advertisement with the 'O'=20 > flag set (see > > > section 5.5.3 of RFC2462). > > > > > > There is no reason a router can't use DHCPv6 for other=20 > configuration > > > information. > > > >I agree on this point. > > > >However, the text you quote is ambiguous, which was the reason for my > >rewording proposal. If A node gets 'O' -bit advertisement (without M > >bit), and implements DHCP, should it try to run it in "stateless > >mode", without trying to get addresses or not? > > > >That is, "use DHCP" is not clear because it can refer to getting > >addresses, other config information or both. > > > >Similarly, "implement DHCP" is not clear, because you can implement > >full or stateless DHCP, which provide different functions. > > > >This text needs a bit of revising. > > > >-- > >Pekka Savola "You each name yourselves king, yet the > >Netcore Oy kingdom bleeds." > >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 03:35:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05153 for ; Fri, 21 Nov 2003 03:35:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6kg-00065X-Nx for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 03:34:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL8Ys8E023401 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 03:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6kf-00065M-M4 for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 03:34:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05105 for ; Fri, 21 Nov 2003 03:34:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6kd-0006A3-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:34:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN6kc-0006A0-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:34:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6jr-0005mM-FC; Fri, 21 Nov 2003 03:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6jh-0005lh-Qf for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 03:33:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05090 for ; Fri, 21 Nov 2003 03:33:41 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6jf-00069L-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:33:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AN6je-00069I-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:33:50 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAL8XpA15579 for ; Fri, 21 Nov 2003 10:33:51 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 21 Nov 2003 10:33:49 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 10:33:50 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 10:33:50 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Address config (was: Node Req: Issue31: DHCPv6 text) Date: Fri, 21 Nov 2003 10:33:46 +0200 Message-ID: Thread-Topic: Node Req: Issue31: DHCPv6 text (ignore previous mails) Thread-Index: AcOvrTShvTxw99kfTmyM+R058itJnwAXB4hg To: X-OriginalArrivalTime: 21 Nov 2003 08:33:50.0167 (UTC) FILETIME=[30386670:01C3B00A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, Just popping up a level. It seems that for address configuration, we = have 3 options: 1) Manual config 2) Autoconfig 3) DHCPv6 My reading of the specs are that Nodes must support (i.e. - implement) = Manual Config & Autoconfig & may implement DHCPv6.=20 I don't think that the Node Requirements can specify what a Node MUST do = in order to perform address config, but it can say what a node should do when it = gets a Router Advertisement with the M or O bit set. If the WG agrees, I will try to create the appropriate text. If the WG feels that a node's behavior needs to be specified, than I = feel it should be done else where. If text is needed on how to resolve conflicts with = address=20 asignment, I feel that should be done elsewhere (however, I feel that it = is more likely OS or node dependent behavior). thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 05:07:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07916 for ; Fri, 21 Nov 2003 05:07:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8CH-0003hp-DJ for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 05:07:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALA7TdC014239 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 05:07:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8CG-0003hG-8m for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 05:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07894 for ; Fri, 21 Nov 2003 05:07:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8CD-0007Rq-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 05:07:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN8CC-0007Rn-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 05:07:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8Bs-0003Yu-RO; Fri, 21 Nov 2003 05:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8Aw-0003UM-VE for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 05:06:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07854 for ; Fri, 21 Nov 2003 05:05:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8At-0007Qg-00 for ipv6@ietf.org; Fri, 21 Nov 2003 05:06:03 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8As-0007QW-00 for ipv6@ietf.org; Fri, 21 Nov 2003 05:06:03 -0500 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 KAA07860 for ; Fri, 21 Nov 2003 10:06:03 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA13940 for ; Fri, 21 Nov 2003 10:06:02 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hALA62a20743 for ipv6@ietf.org; Fri, 21 Nov 2003 10:06:02 GMT Date: Fri, 21 Nov 2003 10:06:02 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Address config (was: Node Req: Issue31: DHCPv6 text) Message-ID: <20031121100602.GC20028@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, Nov 21, 2003 at 10:33:46AM +0200, john.loughney@nokia.com wrote: > > I don't think that the Node Requirements can specify what a Node MUST do in order > to perform address config, but it can say what a node should do when it gets a > Router Advertisement with the M or O bit set. I think the nodes requirement text should simply not change the wording used in the existing RFCs. So if 2462 says "should" then this text should use "should" as well. Unless we know 100% we will revise the RFC. This document is supposed to be a summary, not changing existing new/conflicting standards. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 05:21:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08303 for ; Fri, 21 Nov 2003 05:21:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8Pn-00056C-4a for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 05:21:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALALRpH019600 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 05:21:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8Pl-000563-Sy for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 05:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08270 for ; Fri, 21 Nov 2003 05:21:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8Pi-0007dk-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 05:21:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN8Ph-0007dg-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 05:21:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8PS-0004x6-32; Fri, 21 Nov 2003 05:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8PL-0004wb-RD for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 05:20:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08260 for ; Fri, 21 Nov 2003 05:20:45 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8PI-0007dQ-00 for ipv6@ietf.org; Fri, 21 Nov 2003 05:20:56 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AN8PH-0007dK-00 for ipv6@ietf.org; Fri, 21 Nov 2003 05:20:55 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hALAKR626076 for ; Fri, 21 Nov 2003 12:20:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Nov 2003 12:20:25 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 12:20:27 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Address config (was: Node Req: Issue31: DHCPv6 text) Date: Fri, 21 Nov 2003 12:20:26 +0200 Message-ID: Thread-Topic: Address config (was: Node Req: Issue31: DHCPv6 text) Thread-Index: AcOwF1mCmKc0UtiARJOQmFyC9NyGmgAAbCOQ To: , X-OriginalArrivalTime: 21 Nov 2003 10:20:27.0293 (UTC) FILETIME=[15345CD0:01C3B019] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Tim, > > I don't think that the Node Requirements can specify what a=20 > Node MUST do in order > > to perform address config, but it can say what a node=20 > should do when it gets a > > Router Advertisement with the M or O bit set. >=20 > I think the nodes requirement text should simply not change the = wording used > in the existing RFCs. So if 2462 says "should" then this text should = use > "should" as well. Unless we know 100% we will revise the RFC. This = document > is supposed to be a summary, not changing existing=20 > new/conflicting standards. Agreed. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 09:05:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13828 for ; Fri, 21 Nov 2003 09:05:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBu2-00006w-MR for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:04:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALE4sNP000426 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:04:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBu2-00006n-Fy for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 09:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13788 for ; Fri, 21 Nov 2003 09:04:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBu1-0002Zl-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:04:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANBu0-0002Zh-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:04:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBtC-0008Fp-Iw; Fri, 21 Nov 2003 09:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBt1-0008FA-8l for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 09:03:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13764 for ; Fri, 21 Nov 2003 09:03:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBsz-0002Z4-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:03:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ANBsz-0002YW-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:03:49 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2003 06:04:01 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hALE3Ew5011456; Fri, 21 Nov 2003 06:03:14 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED98996; Fri, 21 Nov 2003 09:03:13 -0500 (EST) Message-Id: <4.3.2.7.2.20031121085644.01eea658@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Nov 2003 09:03:10 -0500 To: john.loughney@nokia.com From: Ralph Droms Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , (inline) At 10:24 AM 11/21/2003 +0200, john.loughney@nokia.com wrote: >Ralph, > >Expanding your text, would this be acceptable: > > IPv6 Nodes that implement DHCP, MUST use DHCP to obtain other > configuration > information (not including address(es) upon the receipt of a Router > Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). > >John John - would this sentence replace both paragraphs (from your previous e-mail): IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon the receipt of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. In this context, 'use DHCP' means trying to obtain only other configuration information through DHCP, not address(es). IPv6 Nodes that do not implement DHCP can ignore the 'O' flag of a Router Advertisement. Furthermore, in the absence of a router, these types of node are not required to initiate DHCP. I think your new text is OK for the first paragraph but we still need to address the second; perhaps: If an IPv6 Node that implements DHCPv6 does not receive a Router Advertisement, it will initiate DHCPv6 for address assignment (see above). The use of DHCPv6 for address assignment will also provide other available configuration information. IPv6 Nodes that do not implement DHCPv6 can ignore the 'O' flag of a Router Advertisement. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 09:05:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13865 for ; Fri, 21 Nov 2003 09:05:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBuE-0000G4-8a for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:05:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALE56AX000985 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBuD-0000CD-1z for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 09:05:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13795 for ; Fri, 21 Nov 2003 09:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBuA-0002a0-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:05:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANBuA-0002Zx-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBuB-00007V-0t; Fri, 21 Nov 2003 09:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBtU-0008I1-7b for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 09:04:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13774 for ; Fri, 21 Nov 2003 09:04:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBtS-0002ZQ-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:04:18 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBtS-0002Yv-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:04:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hALE3jD29822; Fri, 21 Nov 2003 16:03:45 +0200 Date: Fri, 21 Nov 2003 16:03:45 +0200 (EET) From: Pekka Savola To: Margaret.Wasserman@nokia.com cc: john.loughney@nokia.com, Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 20 Nov 2003 Margaret.Wasserman@nokia.com wrote: > If no Router Advertisements are recieved within (NN seconds?) of > joining a link and sending a Router Solicitation, IPv6 hosts that > implement DHCPv6 should attempt to use DHCPv6 to obtain both > IPv6 address(es) and other configuration information. [Do we > need to say what happens if a router advertisement is received > later?] While getting a better specification to the "no RA/Router" case would be useful, this is probably the wrong place to do it. (In general I agree that my rewording attempts were a bit wrong, but they brought up the point about the need to for more precise wording..) -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 09:07:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13951 for ; Fri, 21 Nov 2003 09:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBwA-0000VL-AY for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:07:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALE760g001931 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBw9-0000Ua-Rf for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 09:07:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13942 for ; Fri, 21 Nov 2003 09:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBw8-0002c2-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:07:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANBw8-0002bz-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBw7-0000QK-OY; Fri, 21 Nov 2003 09:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBvj-0000Oz-2N for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 09:06:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13933 for ; Fri, 21 Nov 2003 09:06:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBvh-0002bo-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:06:37 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBvg-0002bE-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:06:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hALE66M29860 for ; Fri, 21 Nov 2003 16:06:06 +0200 Date: Fri, 21 Nov 2003 16:06:05 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: RFC2461bis issue: clarity of using DHCP? [RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) (fwd)] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, Just bringing this issue up explicitly.. RFC2461bis may have to take a better stance on what using managed address autoconfiguration or getting other configuration means (as discussed in the DHCPv6 thread here). No suggestions at this point, perhaps we'll have to see when we agree about the text for Node Requirements.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Thu, 20 Nov 2003 14:50:19 -0500 From: Margaret.Wasserman@nokia.com To: john.loughney@nokia.com, ipv6@ietf.org Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) > to: > > Nodes that implement DHCP MUST use DHCP upon the receipt of a > Router Advertisement with the 'M' flag set (see section 5.5.3 of > RFC2462). In addition, in the absence of a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this > context, 'use DHCP' means trying to obtain both address(es) and > other configuration information through DHCP. This wording seems clumsy to me. How about: If no Router Advertisements are recieved within (NN seconds?) of joining a link and sending a Router Solicitation, IPv6 hosts that implement DHCPv6 should attempt to use DHCPv6 to obtain both IPv6 address(es) and other configuration information. [Do we need to say what happens if a router advertisement is received later?] Upon receipt of a router advertisement with the 'M' flag set (see section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST attempt to use DHCPv6 to obtain both IPv6 addess(es) and other configuration information. > to: > > IPv6 Nodes (acting as hosts) that implement DHCP, MUST use > DHCP upon > the receipt of a Router Advertisement with the 'O' flag set (see > section 5.5.3 of RFC2462). In addition, in the > absence of a router, hosts that implement DHCP MUST attempt to use > DHCP. In this context, 'use DHCP' means trying to obtain > only other > configuration information through DHCP, not address(es). > > IPv6 Nodes that do not implement DHCP can ignore the 'O' flag > of a Router Advertisement. Furthermore, in the absence of > a router, these types of node are not required to initiate DHCP. Similarly, how about: "Upon reciept of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST attempt to use DHCPv6 to obtain non-address configuration information, but not IPv6 address(es). IPv6 nodes that do not implement DHCPv6 client functionality should ignore the 'M' and 'O' bits of the router advertisement." The no router case shouldn't be repeated here, as it is covered above. And, yes, I do think that hosts should attempt to use DHCPv6 to get IPv6 addresses in the absence of a router. Also, I think it is silly to say that hosts that don't implement DHCPv6 don't need to use it... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 09:25:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14516 for ; Fri, 21 Nov 2003 09:25:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCDo-000209-7O for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:25:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALEPKhu007687 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 09:25:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCDo-0001zP-1j for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 09:25:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14479 for ; Fri, 21 Nov 2003 09:25:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANCDm-0002pz-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:25:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANCDl-0002pw-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 09:25:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCDX-0001r0-3K; Fri, 21 Nov 2003 09:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCCe-0001oA-7x for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 09:24:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14439 for ; Fri, 21 Nov 2003 09:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANCCc-0002pU-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:24:06 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ANCCc-0002pD-00 for ipv6@ietf.org; Fri, 21 Nov 2003 09:24:06 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Nov 2003 09:23:35 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04201A@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , ipv6@ietf.org Subject: RE: RFC2461bis issue: clarity of using DHCP? [RE: Node Req: Issue 31: DHCPv6 text (ignore previous mails) (fwd)] Date: Fri, 21 Nov 2003 09:23:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I think this issue is covered under issue 5: Issue 5: Clarifying the use of the M and O flags (raised by Rolf and others during V6ops meeting in San Francisco) Hesham > Just bringing this issue up explicitly.. > > RFC2461bis may have to take a better stance on what using managed > address autoconfiguration or getting other configuration means (as > discussed in the DHCPv6 thread here). > > No suggestions at this point, perhaps we'll have to see when > we agree > about the text for Node Requirements.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ---------- Forwarded message ---------- > Date: Thu, 20 Nov 2003 14:50:19 -0500 > From: Margaret.Wasserman@nokia.com > To: john.loughney@nokia.com, ipv6@ietf.org > Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) > > > > to: > > > > Nodes that implement DHCP MUST use DHCP upon the receipt of a > > Router Advertisement with the 'M' flag set (see section > 5.5.3 of > > RFC2462). In addition, in the absence of a router, > > IPv6 Nodes that implement DHCP MUST attempt to use > DHCP. In this > > context, 'use DHCP' means trying to obtain both address(es) and > > other configuration information through DHCP. > > This wording seems clumsy to me. How about: > > If no Router Advertisements are recieved within (NN seconds?) of > joining a link and sending a Router Solicitation, IPv6 hosts that > implement DHCPv6 should attempt to use DHCPv6 to obtain both > IPv6 address(es) and other configuration information. [Do we > need to say what happens if a router advertisement is received > later?] > > Upon receipt of a router advertisement with the 'M' flag set (see > section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 > MUST attempt > to use DHCPv6 to obtain both IPv6 addess(es) and other configuration > information. > > > to: > > > > IPv6 Nodes (acting as hosts) that implement DHCP, MUST use > > DHCP upon > > the receipt of a Router Advertisement with the 'O' flag > set (see > > section 5.5.3 of RFC2462). In addition, in the > > absence of a router, hosts that implement DHCP MUST > attempt to use > > DHCP. In this context, 'use DHCP' means trying to obtain > > only other > > configuration information through DHCP, not address(es). > > > > IPv6 Nodes that do not implement DHCP can ignore the 'O' flag > > of a Router Advertisement. Furthermore, in the absence of > > a router, these types of node are not required to initiate DHCP. > > Similarly, how about: > > "Upon reciept of a Router Advertisement with the 'O' flag set (see > section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST > attempt to use DHCPv6 to obtain non-address configuration > information, > but not IPv6 address(es). > > IPv6 nodes that do not implement DHCPv6 client functionality should > ignore the 'M' and 'O' bits of the router advertisement." > > The no router case shouldn't be repeated here, as it is covered > above. And, yes, I do think that hosts should attempt to use > DHCPv6 to get IPv6 addresses in the absence of a router. Also, I > think it is silly to say that hosts that don't implement DHCPv6 > don't need to use it... > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 12:04:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22483 for ; Fri, 21 Nov 2003 12:04:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEhM-0004Y2-6b for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 12:04:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALH40cB017482 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 12:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEhL-0004Xt-TH for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 12:03:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22442 for ; Fri, 21 Nov 2003 12:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEhK-0005Jq-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 12:03:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANEhK-0005Jn-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 12:03:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEes-00047M-2f; Fri, 21 Nov 2003 12:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEe7-0003jS-49 for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 12:00:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22288 for ; Fri, 21 Nov 2003 12:00:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEe5-0005Fd-00 for ipv6@ietf.org; Fri, 21 Nov 2003 12:00:37 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEe5-0005Fa-00 for ipv6@ietf.org; Fri, 21 Nov 2003 12:00:37 -0500 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 RAA19290 for ; Fri, 21 Nov 2003 17:00:34 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA10364 for ; Fri, 21 Nov 2003 17:00:34 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hALH0Ym31176 for ipv6@ietf.org; Fri, 21 Nov 2003 17:00:34 GMT Date: Fri, 21 Nov 2003 17:00:34 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Message-ID: <20031121170034.GR27697@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <4.3.2.7.2.20031121085644.01eea658@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20031121085644.01eea658@flask.cisco.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Fri, Nov 21, 2003 at 09:03:10AM -0500, Ralph Droms wrote: > > IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon > the receipt of a Router Advertisement with the 'O' flag set (see > section 5.5.3 of RFC2462). Section 5.5.3 of RFC2462 states "should", not "MUST". You're changing what the RFC says - is this change going to be made in RFC2462-bis? Could you clarify? > In addition, in the > absence of a router, hosts that implement DHCP MUST attempt to use > DHCP. In this context, 'use DHCP' means trying to obtain only other > configuration information through DHCP, not address(es). In section 5.5.2 of RFC2462 it says "addresses and other configuration information", not just other configuration information. So the same consistency question applies. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 12:26:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23412 for ; Fri, 21 Nov 2003 12:26:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANF2p-00068z-SB for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 12:26:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALHQBn6023616 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 12:26:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANF2p-00068p-MD for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 12:26:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23379 for ; Fri, 21 Nov 2003 12:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANF2o-0005hh-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 12:26:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANF2n-0005he-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 12:26:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANF2g-00063F-Cx; Fri, 21 Nov 2003 12:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANF28-00062a-1D for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 12:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23364 for ; Fri, 21 Nov 2003 12:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANF26-0005hN-00 for ipv6@ietf.org; Fri, 21 Nov 2003 12:25:26 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ANF26-0005gu-00 for ipv6@ietf.org; Fri, 21 Nov 2003 12:25:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 09:25:29 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hALHOrw5008441; Fri, 21 Nov 2003 09:24:53 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEE16955; Fri, 21 Nov 2003 12:24:51 -0500 (EST) Message-Id: <4.3.2.7.2.20031121121026.01edee58@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Nov 2003 12:24:49 -0500 To: Tim Chown From: Ralph Droms Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Cc: ipv6@ietf.org In-Reply-To: <20031121170034.GR27697@login.ecs.soton.ac.uk> References: <4.3.2.7.2.20031121085644.01eea658@flask.cisco.com> <4.3.2.7.2.20031121085644.01eea658@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Looks like we've got dueling revisions... I agree with both your points: this Requirements doc ought to use the same requirements words as the original RFC (I used MUST just editing the original proposed text); and if the node does not receive any RAs, it ought to use DHCPv6 to obtain both addresses and other configuration information. So, let's ask John to repost complete, updated text to reset the discussion... - Ralph At 05:00 PM 11/21/2003 +0000, Tim Chown wrote: >On Fri, Nov 21, 2003 at 09:03:10AM -0500, Ralph Droms wrote: > > > > IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon > > the receipt of a Router Advertisement with the 'O' flag set (see > > section 5.5.3 of RFC2462). > >Section 5.5.3 of RFC2462 states "should", not "MUST". You're changing what >the RFC says - is this change going to be made in RFC2462-bis? Could you >clarify? > > > In addition, in the > > absence of a router, hosts that implement DHCP MUST attempt to use > > DHCP. In this context, 'use DHCP' means trying to obtain only other > > configuration information through DHCP, not address(es). > >In section 5.5.2 of RFC2462 it says "addresses and other configuration >information", not just other configuration information. So the same >consistency question applies. > >Tim > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 13:16:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25113 for ; Fri, 21 Nov 2003 13:16:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFon-0000zj-24 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 13:15:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALIFjWg003822 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 13:15:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFom-0000zZ-SV for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 13:15:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25079 for ; Fri, 21 Nov 2003 13:15:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFok-0006Nb-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 13:15:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANFok-0006NX-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 13:15:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFo8-0000uX-MV; Fri, 21 Nov 2003 13:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFgQ-0000GD-JX for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 13:07:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24906 for ; Fri, 21 Nov 2003 13:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFgO-0006It-00 for ipv6@ietf.org; Fri, 21 Nov 2003 13:07:04 -0500 Received: from burp.tkv.asdf.org ([212.16.99.49] helo=moth.tkv.asdf.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ANFgN-0006IR-00 for ipv6@ietf.org; Fri, 21 Nov 2003 13:07:04 -0500 Received: from moth.tkv.asdf.org (msa@localhost [127.0.0.1]) by moth.tkv.asdf.org (8.12.9/8.12.9/Debian-5) with ESMTP id hALIDrBk003614 for ; Fri, 21 Nov 2003 20:13:54 +0200 Received: (from msa@localhost) by moth.tkv.asdf.org (8.12.9/8.12.9/Debian-5) id hALIDpfu003610; Fri, 21 Nov 2003 20:13:51 +0200 Date: Fri, 21 Nov 2003 20:13:51 +0200 Message-Id: <200311211813.hALIDpfu003610@moth.tkv.asdf.org> From: Markku Savela To: ipv6@ietf.org In-reply-to: <20031121170034.GR27697@login.ecs.soton.ac.uk> (message from Tim Chown on Fri, 21 Nov 2003 17:00:34 +0000) Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) References: <4.3.2.7.2.20031121085644.01eea658@flask.cisco.com> <20031121170034.GR27697@login.ecs.soton.ac.uk> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Just invading this thread for short comment... > IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon > the receipt of a Router Advertisement with the 'O' flag set (see > section 5.5.3 of RFC2462). Why would there be a "MUST"? The O/M bits are just hints what the node could do as an alternate configuration mechanism, in case it doesn't see any RA containing prefix option with A=1. If it sees a prefix option with A=1, it can just autoconfigure and ignore O/M bits. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 13:29:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25722 for ; Fri, 21 Nov 2003 13:29:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANG1o-0002YT-5w for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 13:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALITCt3009822 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 13:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANG1n-0002YL-Sd for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 13:29:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25680 for ; Fri, 21 Nov 2003 13:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANG1l-0006c5-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 13:29:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANG1l-0006c2-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 13:29:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANG1d-0002Sm-G8; Fri, 21 Nov 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANG1P-0002S7-VI for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 13:28:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25655 for ; Fri, 21 Nov 2003 13:28:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANG1N-0006bI-00 for ipv6@ietf.org; Fri, 21 Nov 2003 13:28:45 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx with esmtp (Exim 4.12) id 1ANG1M-0006aS-00 for ipv6@ietf.org; Fri, 21 Nov 2003 13:28:44 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hALISCd6430144; Fri, 21 Nov 2003 13:28:12 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hALISALR046664; Fri, 21 Nov 2003 13:28:10 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hALIRaoA007939; Fri, 21 Nov 2003 13:27:36 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hALIRaBU007934; Fri, 21 Nov 2003 13:27:36 -0500 Message-Id: <200311211827.hALIRaBU007934@rotala.raleigh.ibm.com> To: Bob Hinden cc: john.loughney@nokia.com, ipv6@ietf.org Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) In-Reply-To: Message from bob.hinden@nokia.com of "Thu, 20 Nov 2003 11:50:29 PST." <4.3.2.7.2.20031120114106.00b8bd38@mailhost.iprg.nokia.com> Date: Fri, 21 Nov 2003 13:27:36 -0500 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Bob Hinden writes: > John, > > For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP > > upon the receipt of a Router Advertisement with the 'M' flag set (see > > section 5.5.3 of RFC2462). In addition, in the absence of a router, > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > >to: > > Nodes that implement DHCP MUST use DHCP upon the receipt of a > > Router Advertisement with the 'M' flag set (see section 5.5.3 of > > RFC2462). In addition, in the absence of a router, > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this > > context, 'use DHCP' means trying to obtain both address(es) and > > other configuration information through DHCP. For my tastes, there is too much protocol specification above (use of MUST language). Better to just cite the existing standards. > Please remind me why the "in the absence of a router" text is there. I am > having a hard time thinking about a scenario where there would be a DHCP > server, but no router. The presences of a DHCP relay agent would also need > a router to be useful. Perhaps because folk have forgotten about existing text in 2461 & 2462? :-) From section RFC 2461 6.3.7: > If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no > Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY > seconds after sending the last solicitation, the host concludes that > there are no routers on the link for the purpose of [ADDRCONF]. > However, the host continues to receive and process Router > Advertisements messages in the event that routers appear on the link. RFC 2462, Section 5.5.2 says: > 5.5.2. Absence of Router Advertisements > > If a link has no routers, a host MUST attempt to use stateful > autoconfiguration to obtain addresses and other configuration > information. An implementation MAY provide a way to disable the > invocation of stateful autoconfiguration in this case, but the > default SHOULD be enabled. From the perspective of > autoconfiguration, a link has no routers if no Router Advertisements > are received after having sent a small number of Router Solicitations > as described in [DISCOVERY]. We can debate whether the current text makes sense, but it reflects the thinking at the time... Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 14:22:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27529 for ; Fri, 21 Nov 2003 14:22:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGrK-0005yF-H7 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 14:22:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJMQld022945 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 14:22:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGrK-0005y0-Ce for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 14:22:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27497 for ; Fri, 21 Nov 2003 14:22:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGrH-0007Ja-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 14:22:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANGrH-0007JX-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 14:22:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGqw-0005sT-Rd; Fri, 21 Nov 2003 14:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGqK-0005s4-Us for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 14:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27472 for ; Fri, 21 Nov 2003 14:21:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGqI-0007It-00 for ipv6@ietf.org; Fri, 21 Nov 2003 14:21:22 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANGqH-0007Ij-00 for ipv6@ietf.org; Fri, 21 Nov 2003 14:21:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALJKiH27802; Fri, 21 Nov 2003 11:20:44 -0800 X-mProtect: <200311211920> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdFMYNmv; Fri, 21 Nov 2003 11:20:42 PST Message-Id: <4.3.2.7.2.20031121105420.038be008@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Nov 2003 11:19:30 -0800 To: Thomas Narten From: Bob Hinden Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Cc: Bob Hinden , john.loughney@nokia.com, ipv6@ietf.org In-Reply-To: <200311211827.hALIRaBU007934@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Thomas, At 10:27 AM 11/21/2003, Thomas Narten wrote: >Bob Hinden writes: > > > John, > > > > For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP > > > upon the receipt of a Router Advertisement with the 'M' flag set (see > > > section 5.5.3 of RFC2462). In addition, in the absence of a router, > > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > > >to: > > > Nodes that implement DHCP MUST use DHCP upon the receipt of a > > > Router Advertisement with the 'M' flag set (see section 5.5.3 of > > > RFC2462). In addition, in the absence of a router, > > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this > > > context, 'use DHCP' means trying to obtain both address(es) and > > > other configuration information through DHCP. > >For my tastes, there is too much protocol specification above (use of >MUST language). Better to just cite the existing standards. Yes, I agree. > > Please remind me why the "in the absence of a router" text is there. I am > > having a hard time thinking about a scenario where there would be a DHCP > > server, but no router. The presences of a DHCP relay agent would also > need > > a router to be useful. > >Perhaps because folk have forgotten about existing text in 2461 & >2462? :-) I figured there must be some reason why this text was there. That's why I asked :-) > From section RFC 2461 6.3.7: > > > If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no > > Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY > > seconds after sending the last solicitation, the host concludes that > > there are no routers on the link for the purpose of [ADDRCONF]. > > However, the host continues to receive and process Router > > Advertisements messages in the event that routers appear on the link. > >RFC 2462, Section 5.5.2 says: > > > 5.5.2. Absence of Router Advertisements > > > > If a link has no routers, a host MUST attempt to use stateful > > autoconfiguration to obtain addresses and other configuration > > information. An implementation MAY provide a way to disable the > > invocation of stateful autoconfiguration in this case, but the > > default SHOULD be enabled. From the perspective of > > autoconfiguration, a link has no routers if no Router Advertisements > > are received after having sent a small number of Router Solicitations > > as described in [DISCOVERY]. > >We can debate whether the current text makes sense, but it reflects >the thinking at the time... Agreed. Since I don't think DHCPv6 wasn't very far along at the time this was written, I wonder if we were thinking about other kinds of stateful autoconfiguration that might be useful when there was no router. Must be in the mail archives. However, this doesn't seem like a useful behavior now. I think it would be best to not restate it in node requirements. Also, I think we should revisit this text in the RFC2462bis effort. Changing the MUST to MAY in the 5.5.2 paragraph looks like the right change to me, but that's a different email thread. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 16:52:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05017 for ; Fri, 21 Nov 2003 16:52:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJBt-000702-Ey for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 16:51:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALLpnWB026902 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 16:51:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJBt-0006zp-7f for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 16:51:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04896 for ; Fri, 21 Nov 2003 16:51:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJBp-0001dm-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 16:51:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANJBp-0001dj-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 16:51:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJB8-0006tm-Py; Fri, 21 Nov 2003 16:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJAa-0006sy-Dj for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 16:50:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04793 for ; Fri, 21 Nov 2003 16:50:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJAY-0001be-00 for ipv6@ietf.org; Fri, 21 Nov 2003 16:50:26 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1ANJAX-0001aV-00 for ipv6@ietf.org; Fri, 21 Nov 2003 16:50:25 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Nov 2003 13:49:52 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Nov 2003 13:49:54 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 21 Nov 2003 13:49:35 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Nov 2003 13:49:35 -0800 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.3790.1069); Fri, 21 Nov 2003 13:49:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Date: Fri, 21 Nov 2003 13:50:30 -0800 Message-ID: Thread-Topic: Node Req: Issue31: DHCPv6 text (ignore previous mails) Thread-Index: AcOwZOdaE7oU3r6gQeCgacKhYH86TwAFEMFg From: "Christian Huitema" To: "Bob Hinden" , "Thomas Narten" Cc: , X-OriginalArrivalTime: 21 Nov 2003 21:49:48.0957 (UTC) FILETIME=[62AD6CD0:01C3B079] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Also, I think we should revisit this text in the RFC2462bis > effort. Changing the MUST to MAY in the 5.5.2 paragraph looks like the > right change to me, but that's a different email thread. I would agree with that. In any case, I object to tying a MUST condition to the availability of the code in the implementation. Implementation is a necessary condition, but so is for example user or admin consent, maybe battery state, whatever. The text should not speak about implementation. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 17:44:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09397 for ; Fri, 21 Nov 2003 17:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANK0b-0003bi-AU for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 17:44:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMiDkJ013860 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 17:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANK0b-0003bT-2K for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09374 for ; Fri, 21 Nov 2003 17:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANK0Y-0003Lq-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 17:44:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANK0Y-0003Ln-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 17:44:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANK0P-0003Vf-JY; Fri, 21 Nov 2003 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJzU-0003Uv-PY for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 17:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09326 for ; Fri, 21 Nov 2003 17:42:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJzF-0003Kv-00 for ipv6@ietf.org; Fri, 21 Nov 2003 17:42:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANJzE-0003Ko-00 for ipv6@ietf.org; Fri, 21 Nov 2003 17:42:49 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALMgHW24129 for ; Fri, 21 Nov 2003 14:42:17 -0800 X-mProtect: <200311212242> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSuSimg; Fri, 21 Nov 2003 14:42:16 PST Message-Id: <4.3.2.7.2.20031121143259.00b8be58@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Nov 2003 14:40:49 -0800 To: ipv6@ietf.org From: Bob Hinden & Brian Haberman Subject: IPv6 w.g. Last Call on "MIB for UDP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title : Management Information Base for the User Datagram Protocol (UDP) Author(s) : B. Fenner Filename : draft-ietf-ipv6-rfc2013-update-02.txt Pages : 21 Date : 2003-11-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) [4] in an IP version independent manner. It is intended to obsolete RFC 2013 and RFC 2454. Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 1 December 2003. Bob Hinden / Brian Haberman IPv6 working group chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 20:23:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14962 for ; Fri, 21 Nov 2003 20:23:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMUe-0005dY-9x for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 20:23:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM1NOjw021662 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 20:23:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMUe-0005dJ-4R for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 20:23:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14929 for ; Fri, 21 Nov 2003 20:23:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMUc-0005HK-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 20:23:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANMUb-0005HH-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 20:23:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMUH-0005Xi-NX; Fri, 21 Nov 2003 20:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMUF-0005XT-5L for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 20:22:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14919 for ; Fri, 21 Nov 2003 20:22:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMUC-0005Gu-00 for ipv6@ietf.org; Fri, 21 Nov 2003 20:22:57 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANMUC-0005Gb-00 for ipv6@ietf.org; Fri, 21 Nov 2003 20:22:56 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAM1MOK18436; Fri, 21 Nov 2003 17:22:24 -0800 X-mProtect: <200311220122> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJr2t0r; Fri, 21 Nov 2003 17:22:23 PST Message-ID: <3FBEBC18.7020706@iprg.nokia.com> Date: Fri, 21 Nov 2003 17:30:00 -0800 From: Fred 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: Keith Moore CC: ipv6@ietf.org Subject: Re: names for non-global addresses References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'll take mnemonic power, but could do without the cuteness. How about: IDEA - Independently-Delegated Endpoint Address Fred ftemplin@iprg.nokia.com Keith Moore wrote: > I still prefer > > GUPI (pronounced "guppy" like the fish) - globally unique > provider-independent > PUPI (pronounced "puppy" like a young dog) - probably unique > provider-independent > > as having about the right ratio of cuteness to mnemonic power. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 21 21:01:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15976 for ; Fri, 21 Nov 2003 21:01:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANN5D-0007yz-2P for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 21:01:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM21B0Q030679 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 21:01:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANN5C-0007yk-QI for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 21:01:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15935 for ; Fri, 21 Nov 2003 21:00:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANN5A-0005iE-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 21:01:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANN59-0005iB-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 21:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANN55-0007vA-F5; Fri, 21 Nov 2003 21:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANN49-0007pT-VY for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 21:00:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15907 for ; Fri, 21 Nov 2003 20:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANN47-0005ht-00 for ipv6@ietf.org; Fri, 21 Nov 2003 21:00:03 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1ANN46-0005hq-00 for ipv6@ietf.org; Fri, 21 Nov 2003 21:00:03 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1F1A2AFC45; Fri, 21 Nov 2003 21:00:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11760-11; Fri, 21 Nov 2003 21:00:02 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id D27E7AFC21; Fri, 21 Nov 2003 21:00:01 -0500 (EST) Date: Fri, 21 Nov 2003 21:00:43 -0500 Subject: Re: names for non-global addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Keith Moore , ipv6@ietf.org To: Fred Templin From: Keith Moore In-Reply-To: <3FBEBC18.7020706@iprg.nokia.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I'll take mnemonic power, but could do without the cuteness. IMO, some amount of cuteness is actually useful - it encourages people to use them. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 22 10:37:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14722 for ; Sat, 22 Nov 2003 10:37:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANZoS-0006eL-Fh for ipv6-archive@odin.ietf.org; Sat, 22 Nov 2003 10:36:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMFaijV025560 for ipv6-archive@odin.ietf.org; Sat, 22 Nov 2003 10:36:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANZoS-0006eB-Bd for ipv6-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 10:36:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14698 for ; Sat, 22 Nov 2003 10:36:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANZoP-0006rf-00 for ipv6-web-archive@ietf.org; Sat, 22 Nov 2003 10:36:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANZoP-0006rb-00 for ipv6-web-archive@ietf.org; Sat, 22 Nov 2003 10:36:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANZnm-0006Xz-5r; Sat, 22 Nov 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANZnL-0006XL-UZ for ipv6@optimus.ietf.org; Sat, 22 Nov 2003 10:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14673 for ; Sat, 22 Nov 2003 10:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANZnJ-0006rF-00 for ipv6@ietf.org; Sat, 22 Nov 2003 10:35:33 -0500 Received: from web80506.mail.yahoo.com ([66.218.79.76]) by ietf-mx with smtp (Exim 4.12) id 1ANZnJ-0006r3-00 for ipv6@ietf.org; Sat, 22 Nov 2003 10:35:33 -0500 Message-ID: <20031122153456.35820.qmail@web80506.mail.yahoo.com> Received: from [63.197.18.101] by web80506.mail.yahoo.com via HTTP; Sat, 22 Nov 2003 07:34:56 PST Date: Sat, 22 Nov 2003 07:34:56 -0800 (PST) From: Fred Templin Subject: Re: names for non-global addresses To: Keith Moore Cc: Keith Moore , ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1200717757-1069515296=:35353" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1200717757-1069515296=:35353 Content-Type: text/plain; charset=us-ascii Keith, GUPIs ("guppies") and PUPIs ("puppies") are things that little children like to bring home from their local pet store. IDEAs are things that all Internet users from the most seasoned professional to the rankest novice immediately associate with the pure essence of technology. The unspoken understanding between any two peers would be: "I have an IDEA; you have an IDEA; let's network!" Fred osprey67@yahoo.com Keith Moore wrote: > I'll take mnemonic power, but could do without the cuteness. IMO, some amount of cuteness is actually useful - it encourages people to use them. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-1200717757-1069515296=:35353 Content-Type: text/html; charset=us-ascii
Keith,
 
GUPIs ("guppies") and PUPIs ("puppies") are things that little
children like to bring home from their local pet store.
 
IDEAs are things that all Internet users from the most seasoned
professional to the rankest novice immediately associate with
the pure essence of technology. The unspoken understanding
between any two peers would be:
 
  "I have an IDEA; you have an IDEA; let's network!"
 
Fred
 
 

Keith Moore <moore@cs.utk.edu> wrote:
> I'll take mnemonic power, but could do without the cuteness.

IMO, some amount of cuteness is actually useful - it encourages people
to use them.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-1200717757-1069515296=:35353-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 22 11:04:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15271 for ; Sat, 22 Nov 2003 11:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANaF1-0008Am-Hq for ipv6-archive@odin.ietf.org; Sat, 22 Nov 2003 11:04:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMG4BcK031410 for ipv6-archive@odin.ietf.org; Sat, 22 Nov 2003 11:04:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANaF1-0008AX-9Z for ipv6-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 11:04:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15247 for ; Sat, 22 Nov 2003 11:03:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANaEy-0007A1-00 for ipv6-web-archive@ietf.org; Sat, 22 Nov 2003 11:04:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANaEy-00079y-00 for ipv6-web-archive@ietf.org; Sat, 22 Nov 2003 11:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANaEr-00084a-QS; Sat, 22 Nov 2003 11:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANaEJ-00084G-7Q for ipv6@optimus.ietf.org; Sat, 22 Nov 2003 11:03:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15236 for ; Sat, 22 Nov 2003 11:03:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANaEG-00079o-00 for ipv6@ietf.org; Sat, 22 Nov 2003 11:03:24 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1ANaEG-00079l-00 for ipv6@ietf.org; Sat, 22 Nov 2003 11:03:24 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A6EF5AFC7F; Sat, 22 Nov 2003 11:03:23 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29437-01; Sat, 22 Nov 2003 11:03:22 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4F44EAFC26; Sat, 22 Nov 2003 11:03:22 -0500 (EST) Date: Sat, 22 Nov 2003 11:04:06 -0500 Subject: Re: names for non-global addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Keith Moore , ipv6@ietf.org To: Fred Templin From: Keith Moore In-Reply-To: <20031122153456.35820.qmail@web80506.mail.yahoo.com> Message-Id: <7FBB936A-1D05-11D8-89BF-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > GUPIs ("guppies") and PUPIs ("puppies") are things that little > children like to bring home from their local pet store. and therefore when network experts uses those terms it will nearly always be clear from context whether they mean pets or addresses - unlike ideas, which some people actually do employ in their work :) but it seems silly to drill down too deep into this issue. the important thing is that we pick a name or names and move on. if the authors of the document don't pick something by the next IETF, we should just vote by humming. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 22 14:16:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18833 for ; Sat, 22 Nov 2003 14:16:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANdF9-0000tn-2g for ipv6-archive@odin.ietf.org; Sat, 22 Nov 2003 14:16:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMJGV0d003449 for ipv6-archive@odin.ietf.org; Sat, 22 Nov 2003 14:16:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANdF8-0000tY-Tj for ipv6-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 14:16:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18802 for ; Sat, 22 Nov 2003 14:16:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANdF6-0001DP-00 for ipv6-web-archive@ietf.org; Sat, 22 Nov 2003 14:16:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANdF6-0001D6-00 for ipv6-web-archive@ietf.org; Sat, 22 Nov 2003 14:16:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANdEg-0000pq-U0; Sat, 22 Nov 2003 14:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANdDx-0000p3-1F for ipv6@optimus.ietf.org; Sat, 22 Nov 2003 14:15:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18793 for ; Sat, 22 Nov 2003 14:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANdDu-0001BL-00 for ipv6@ietf.org; Sat, 22 Nov 2003 14:15:14 -0500 Received: from dsl-209-162-215-52.dsl.easystreet.com ([209.162.215.52] helo=southstation.m5p.com) by ietf-mx with esmtp (Exim 4.12) id 1ANdDt-0001Ak-00 for ipv6@ietf.org; Sat, 22 Nov 2003 14:15:13 -0500 Received: from m5p.com (northstation.m5p.com [10.100.0.5]) by southstation.m5p.com (8.12.10/8.12.10) with ESMTP id hAMJEbG0075471 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Nov 2003 11:14:43 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.10/8.12.10/Submit) id hAMJEbI5026016; Sat, 22 Nov 2003 11:14:37 -0800 (PST) Date: Sat, 22 Nov 2003 11:14:37 -0800 (PST) Message-Id: <200311221914.hAMJEbI5026016@m5p.com> From: george+ipng@m5p.com To: ipv6@ietf.org Subject: names for Hinden/Haberman addresses; was Re: IPv6 w.g. Last Call on IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" X-Scanned-By: MIMEDefang 2.35 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , In a message posted on November 10, Bob Hinden expressed his wish that these addresses not become known as Hinden/Haberman addresses. The first alternative that sprang to my mind was Bob/Brian addresses, but perhaps he would find that equally distasteful. It seems to me we need a new word, devoid of previous baggage, to denote these new style addresses. And so I have coined a new word, specifically intended to describe the addresses in this draft: scolliate I would have sworn that this word doesn't exist, but I plugged it into Google, and it found (with the assistance of the Logos Universal Conjugator) that it is an Italian word, meaning "you unglue." After a few moments' reflection, I thought this might be considered appropriate, considering how unglued people have become over site- local addresses. How I actually coined this word is left as an exercise for the reader. Contact me off-list if you need details. Meanwhile, I look forward to the term "scolliate addresses" taking the IP version 6 world by storm. -- George Mitchell (george@m5p.com) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 23 00:02:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00820 for ; Sun, 23 Nov 2003 00:02:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANmOK-0008Nf-37 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 00:02:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAN52aBV032215 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 00:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANmOJ-0008NW-P6 for ipv6-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 00:02:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00779 for ; Sun, 23 Nov 2003 00:02:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANmOH-0006Sp-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 00:02:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANmOH-0006Sm-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 00:02:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANmNm-0008J0-W8; Sun, 23 Nov 2003 00:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANmND-0008I9-5K for ipv6@optimus.ietf.org; Sun, 23 Nov 2003 00:01:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00760 for ; Sun, 23 Nov 2003 00:01:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANmNA-0006QY-00 for ipv6@ietf.org; Sun, 23 Nov 2003 00:01:24 -0500 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1ANmNA-0006NR-00 for ipv6@ietf.org; Sun, 23 Nov 2003 00:01:24 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id AEC40E1 for ; Sun, 23 Nov 2003 00:00:54 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 23 Nov 2003 00:00:54 -0500 Message-Id: <20031123050054.AEC40E1@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 18 | 14.37% | 94252 | john.loughney@nokia.com 7.94% | 10 | 9.80% | 64298 | ftemplin@iprg.nokia.com 7.14% | 9 | 5.57% | 36555 | tjc@ecs.soton.ac.uk 4.76% | 6 | 5.12% | 33616 | pekkas@netcore.fi 4.76% | 6 | 4.94% | 32419 | rdroms@cisco.com 4.76% | 6 | 4.74% | 31061 | brian@innovationslab.net 4.76% | 6 | 4.48% | 29396 | jari.arkko@kolumbus.fi 2.38% | 3 | 6.42% | 42089 | chirayu@chirayu.org 3.97% | 5 | 3.01% | 19747 | ericlklein@softhome.net 3.17% | 4 | 2.72% | 17856 | bob.hinden@nokia.com 2.38% | 3 | 2.23% | 14617 | narten@us.ibm.com 2.38% | 3 | 2.21% | 14469 | h.soliman@flarion.com 2.38% | 3 | 2.10% | 13799 | margaret.wasserman@nokia.com 2.38% | 3 | 2.10% | 13757 | brc@zurich.ibm.com 2.38% | 3 | 1.85% | 12124 | leifj@it.su.se 2.38% | 3 | 1.64% | 10750 | moore@cs.utk.edu 1.59% | 2 | 2.14% | 14040 | sasson_shuki@emc.com 1.59% | 2 | 1.71% | 11200 | jean-jacques.pansiot@crc.u-strasbg.fr 1.59% | 2 | 1.65% | 10817 | claudio.lori@unimi.it 1.59% | 2 | 1.61% | 10529 | internet-drafts@ietf.org 1.59% | 2 | 1.44% | 9454 | jeroen@unfix.org 1.59% | 2 | 1.39% | 9145 | huitema@windows.microsoft.com 1.59% | 2 | 1.18% | 7766 | kohler@icir.org 0.79% | 1 | 1.19% | 7774 | cds@andiamo.com 0.79% | 1 | 1.05% | 6892 | tphelan@sonusnet.com 0.79% | 1 | 0.97% | 6344 | shroff@baja.tuc.noao.edu 0.79% | 1 | 0.94% | 6134 | samita.chakrabarti@eng.sun.com 0.79% | 1 | 0.93% | 6129 | stig.venaas@uninett.no 0.79% | 1 | 0.92% | 6062 | andrew.e.white@motorola.com 0.79% | 1 | 0.88% | 5754 | elizabeth.rodriguez@dothill.com 0.79% | 1 | 0.81% | 5323 | sra+ipng@hactrn.net 0.79% | 1 | 0.79% | 5162 | osprey67@yahoo.com 0.79% | 1 | 0.74% | 4878 | dag@dxtoolbox.com 0.79% | 1 | 0.71% | 4689 | michael.welzl@uibk.ac.at 0.79% | 1 | 0.71% | 4685 | julian.sellers@unisys.com 0.79% | 1 | 0.71% | 4663 | nisse@lysator.liu.se 0.79% | 1 | 0.65% | 4281 | eric@mehr.ws 0.79% | 1 | 0.61% | 4009 | george+ipng@m5p.com 0.79% | 1 | 0.57% | 3717 | satapati@cisco.com 0.79% | 1 | 0.56% | 3673 | mark.andrews@isc.org 0.79% | 1 | 0.55% | 3601 | msa@moth.tkv.asdf.org 0.79% | 1 | 0.53% | 3456 | soohong.park@samsung.com 0.79% | 1 | 0.46% | 3029 | itojun@itojun.org 0.79% | 1 | 0.29% | 1923 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 126 |100.00% | 655934 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 23 04:55:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17644 for ; Sun, 23 Nov 2003 04:55:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANqxq-0006Gc-Tg for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 04:55:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAN9tYCA024091 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 04:55:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANqxq-0006GU-Fw for ipv6-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 04:55:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17626 for ; Sun, 23 Nov 2003 04:55:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANqxn-00017a-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 04:55:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANqxm-00017X-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 04:55:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANqxK-0006Dn-Gt; Sun, 23 Nov 2003 04:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANqww-0006Be-Jt for ipv6@optimus.ietf.org; Sun, 23 Nov 2003 04:54:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17614 for ; Sun, 23 Nov 2003 04:54:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANqwt-00017C-00 for ipv6@ietf.org; Sun, 23 Nov 2003 04:54:35 -0500 Received: from h008.c001.snv.cp.net ([209.228.32.122] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1ANqws-000179-00 for ipv6@ietf.org; Sun, 23 Nov 2003 04:54:34 -0500 Received: (cpmta 14449 invoked from network); 23 Nov 2003 01:54:34 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.122) with SMTP; 23 Nov 2003 01:54:34 -0800 X-Sent: 23 Nov 2003 09:54:34 GMT Message-ID: <009901c3b1a7$f6357860$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <001b01c3ae9e$c2f81590$ec061eac@ttitelecom.com> <3FBBBA9A.2807ED2F@zurich.ibm.com> <3FBD5E8C.BB5188A7@motorola.com> Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Sun, 23 Nov 2003 11:55:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andrew White wrote > The problem with these people's arguments is that it's not the address range > that gives the security, it's the fact that you have an isolated network > connected to the global network via only a proxy (NAT) and firewall. > > You can use any address range you like inside the NAT. However, if you > don't use a 'private' range you're running two risks: > > - masking a portion of the global internet > - leaking addresses that look real but are actually invalid rather than > obviously invalid ones. This is exactly why some of us have been trying to prevent the depriciation of local ("private") address. > > The advantage of a local/private address range is that you can create one > for whatever local use you need without needing to obtain space through a > registration authority. The advantage of 'approximately unique' local > addresses (in the style of the Hinden/Haberman draft) is that you get > addresses with all the benefits of private address AND they're not likely to > conflict if you merge. > This would work, and would be acceptiable to most people if there was a simple rule that worked, and would continue to work as the network grows. My concern is that an 'approximately unique' local address could at some point become less than unique and could cause routing problems when the address is eventually assigned. I mean, how many companies would use this 'approximately unique' local address option and thus "claim" portions of the network, while the registreies are assigning addresses? Eventually there will be legimate asigned users to some of these 'approximately unique' local addresses and this will cause problems later. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 23 14:28:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27029 for ; Sun, 23 Nov 2003 14:28:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANzuQ-00082b-Nh for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 14:28:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANJSc9g030906 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 14:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANzuP-00082P-2I for ipv6-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 14:28:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27001 for ; Sun, 23 Nov 2003 14:28:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANzuM-0006KZ-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 14:28:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANzuL-0006KS-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 14:28:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANzsr-0007wa-KA; Sun, 23 Nov 2003 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANzrv-0007w9-4O for ipv6@optimus.ietf.org; Sun, 23 Nov 2003 14:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26978 for ; Sun, 23 Nov 2003 14:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANzrs-0006Jp-00 for ipv6@ietf.org; Sun, 23 Nov 2003 14:26:00 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1ANzrr-0006Jc-00 for ipv6@ietf.org; Sun, 23 Nov 2003 14:26:00 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Sun, 23 Nov 2003 11:25:20 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 Nov 2003 11:25:27 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 23 Nov 2003 11:25:27 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 23 Nov 2003 11:25:12 -0800 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.3790.1069); Sun, 23 Nov 2003 11:25:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Local addresses and security? (was: SL deprecation draft) Date: Sun, 23 Nov 2003 11:26:03 -0800 Message-ID: Thread-Topic: Local addresses and security? (was: SL deprecation draft) thread-index: AcOxp/44T9LNn0v/SkaGG5BwfHR0SQAT3aAg From: "Christian Huitema" To: "EricLKlein" , X-OriginalArrivalTime: 23 Nov 2003 19:25:24.0328 (UTC) FILETIME=[8AFB7680:01C3B1F7] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > This would work, and would be acceptiable to most people if there was a > simple rule that worked, and would continue to work as the network grows. > My > concern is that an 'approximately unique' local address could at some > point > become less than unique and could cause routing problems when the address > is > eventually assigned. I mean, how many companies would use this > 'approximately unique' local address option and thus "claim" portions of > the > network, while the registreies are assigning addresses? Eventually there > will be legimate asigned users to some of these 'approximately unique' > local > addresses and this will cause problems later. You can get verifiably unique addresses if you go through the registration procedure. So, if you follow the good housekeeping rules, you should never encounter the bug you mention. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 23 16:48:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01004 for ; Sun, 23 Nov 2003 16:48:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO25t-0004TJ-JN for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 16:48:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANLmboI017188 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 16:48:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO25t-0004T9-Cp for ipv6-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 16:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00980 for ; Sun, 23 Nov 2003 16:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO25r-0007iQ-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 16:48:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO25r-0007iN-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 16:48:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO25J-0004Kz-Qb; Sun, 23 Nov 2003 16:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO250-0004JT-JQ for ipv6@optimus.ietf.org; Sun, 23 Nov 2003 16:47:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00954 for ; Sun, 23 Nov 2003 16:47:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO24y-0007i0-00 for ipv6@ietf.org; Sun, 23 Nov 2003 16:47:40 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO24x-0007hx-00 for ipv6@ietf.org; Sun, 23 Nov 2003 16:47:40 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id hANLldE14740; Sun, 23 Nov 2003 13:47:39 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 23 Nov 2003 13:47:38 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2013-update-02.txt In-Reply-To: <200311202029.PAA24102@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 20 Nov 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the IP > Version 6 Working Group Working Group of the IETF. > > Title : Management Information Base for the > User Datagram Protocol (UDP) > Author(s) : B. Fenner > Filename : draft-ietf-ipv6-rfc2013-update-02.txt > Pages : 21 > Date : 2003-11-20 > This memo defines a portion of the Management > Information Base (MIB) for use with network management protocols > in the Internet community. In particular, it describes managed > objects used for implementations of the User Datagram Protocol > (UDP) [4] in an IP version independent manner. > > It is intended to obsolete RFC 2013 and RFC 2454. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-02.txt Without looking at this MIB module in much detail I ran it through a routine smilint check: This command (smilint 0.4.2-pre1, as of Mon Oct 06 12:50:08 2003) has been processed to get the following results: smilint -m -s -l 6 UDP-MIB UDP-MIB:168: [5] {index-exceeds-too-large} warning: index of row `udpEndpointEntry' can exceed OID size limit by 399 subidentifier(s) UDP-MIB:168: [5] {index-element-accessible} warning: index element `udpEndpointInstance' of row `udpEndpointEntry' should be not-accessible in SMIv2 MIB The first warning is dealt with adequately in the udpEndpointEntry DESCRIPTION clause and does not require any discussion. The second warning arises because there is already an accessible non-index column udpEndpointProcess. The rationale given for making the index column read-only was: Changed udpEndpointInstance back to read-only, since there is no longer a mandatory non-auxiliary column in the udpEndpointTable. While this is true since udpEndpointProcess is only conditionally mandatory, it seems to me that there is another way to address this issue without bending the rules. Namely, make udpEndpointProcess unconditionally mandatory but put language in its DESCRIPTION clause that says its value will be zero on systems that have no concept of a process. In addition to the above I say a typo In the DESCRIPTION clause of udpEndpointTable: s/udpEndpointRemoteAdderess/udpEndpointRemoteAddress/ Mike Heard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 23 18:49:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04785 for ; Sun, 23 Nov 2003 18:49:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO3z1-0008VZ-WC for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 18:49:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANNndED032701 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 18:49:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO3z1-0008VM-Oq for ipv6-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 18:49:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04733 for ; Sun, 23 Nov 2003 18:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO3yy-0001LS-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 18:49:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO3yy-0001LP-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 18:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO3yQ-0008Qr-5o; Sun, 23 Nov 2003 18:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO3xr-0008Q0-4t for ipv6@optimus.ietf.org; Sun, 23 Nov 2003 18:48:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04708 for ; Sun, 23 Nov 2003 18:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO3xn-0001KG-00 for ipv6@ietf.org; Sun, 23 Nov 2003 18:48:24 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AO3xn-0001KD-00 for ipv6@ietf.org; Sun, 23 Nov 2003 18:48:23 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hANNmL6b017774 for ; Sun, 23 Nov 2003 16:48:21 -0700 (MST) Received: from motorola.com (mvp-10-238-2-33.corp.mot.com [10.238.2.33]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hANNktcC011152 for ; Sun, 23 Nov 2003 17:46:57 -0600 Message-ID: <3FC14740.8D25A443@motorola.com> Date: Mon, 24 Nov 2003 10:48:16 +1100 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: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > This would work, and would be acceptiable to most people if there was > > a simple rule that worked, and would continue to work as the network > > grows. > > My concern is that an 'approximately unique' local address could at > > some point become less than unique and could cause routing problems > > when the address is eventually assigned. I mean, how many companies > > would use this 'approximately unique' local address option and thus > > "claim" portions of the network, while the registreies are assigning > > addresses? Eventually there will be legimate asigned users to some of > > these 'approximately unique' local addresses and this will cause > > problems later. > > You can get verifiably unique addresses if you go through the > registration procedure. So, if you follow the good housekeeping rules, > you should never encounter the bug you mention. Though I'd also ask: "Claim portions of WHAT network?" I'm talking about *local* addresses, which by definition and design are not valid for use on the global internet (and those nice little filters we want to mandate help discourage people from trying). Sure, you can claim large tracts of local space, for all the good that does you ("I declare that this 60% of this sandbox is now MINE."), but the approximately unique property is primarily designed to make it much eaiser to merge local networks. So you only need to be piecewise unique with people with whom you might want to create a local VPN. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 23 19:07:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05202 for ; Sun, 23 Nov 2003 19:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Fx-0000of-Ul for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 19:07:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO079Hw003094 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 19:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Fw-0000n2-OZ for ipv6-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 19:07:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05180 for ; Sun, 23 Nov 2003 19:06:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4Ft-0001ek-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 19:07:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO4Ft-0001eh-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 19:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Fr-0000k9-AK; Sun, 23 Nov 2003 19:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4F4-0000j8-4f for ipv6@optimus.ietf.org; Sun, 23 Nov 2003 19:06:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05165 for ; Sun, 23 Nov 2003 19:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4F0-0001dv-00 for ipv6@ietf.org; Sun, 23 Nov 2003 19:06:10 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AO4Ez-0001dY-00 for ipv6@ietf.org; Sun, 23 Nov 2003 19:06:09 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 23 Nov 2003 16:05:39 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 Nov 2003 16:05:39 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 23 Nov 2003 16:05:39 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 23 Nov 2003 16:05:51 -0800 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.3790.1069); Sun, 23 Nov 2003 16:05:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Local addresses and security? (was: SL deprecation draft) Date: Sun, 23 Nov 2003 16:06:15 -0800 Message-ID: Thread-Topic: Local addresses and security? (was: SL deprecation draft) thread-index: AcOyHH+OWYL6+/KISSqng155icMd8gAAglHQ From: "Christian Huitema" To: , X-OriginalArrivalTime: 24 Nov 2003 00:05:43.0463 (UTC) FILETIME=[B3F7CB70:01C3B21E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > You can get verifiably unique addresses if you go through the > > registration procedure. So, if you follow the good housekeeping rules, > > you should never encounter the bug you mention. >=20 > Though I'd also ask: "Claim portions of WHAT network?" I'm talking about > *local* addresses, which by definition and design are not valid for use on > the global internet (and those nice little filters we want to mandate help > discourage people from trying). >=20 > Sure, you can claim large tracts of local space, for all the good that > does > you ("I declare that this 60% of this sandbox is now MINE."), but the > approximately unique property is primarily designed to make it much eaiser > to merge local networks. So you only need to be piecewise unique with > people with whom you might want to create a local VPN. Andrew, the draft has provision for both "registered unique local addresses" and "probably unique local addresses". The registered unique addresses are not valid on the Internet, but they definitely will not collide with other addresses. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 23 19:10:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05316 for ; Sun, 23 Nov 2003 19:10:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Io-0001QG-Kl for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 19:10:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO0A64p005462 for ipv6-archive@odin.ietf.org; Sun, 23 Nov 2003 19:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Io-0001Q1-Fb for ipv6-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 19:10:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05290 for ; Sun, 23 Nov 2003 19:09:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4Il-0001iV-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 19:10:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO4Ik-0001iS-00 for ipv6-web-archive@ietf.org; Sun, 23 Nov 2003 19:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Il-0001Li-4t; Sun, 23 Nov 2003 19:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO3hc-0007ru-3l for ipv6@optimus.ietf.org; Sun, 23 Nov 2003 18:31:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04416 for ; Sun, 23 Nov 2003 18:31:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO3hZ-000192-00 for ipv6@ietf.org; Sun, 23 Nov 2003 18:31:37 -0500 Received: from smtp3.stanford.edu ([171.67.16.117]) by ietf-mx with esmtp (Exim 4.12) id 1AO3hY-00018u-00 for ipv6@ietf.org; Sun, 23 Nov 2003 18:31:36 -0500 Received: from CMOTTA (rains-02-14aa.Stanford.EDU [128.12.189.59]) by smtp3.Stanford.EDU (8.12.10/8.12.10) with SMTP id hANNVZPs006571 for ; Sun, 23 Nov 2003 15:31:35 -0800 Message-ID: <02a901c3b219$f106ff40$3bbd0c80@CMOTTA> From: "Carlos Motta" To: Subject: Stanford Research Date: Sun, 23 Nov 2003 15:31:38 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A6_01C3B1D6.E2BC1300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_02A6_01C3B1D6.E2BC1300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sirs/ Madams: I am a LL.M. (Master of Laws) in Law, Science and Technology Program at = Stanford Law School and I am involved in a Directed Research regarding = Infrastructure and Security on the Internet. One of my targets is the = IPv6. My work is comprised by the analysis on what IETF's working group = is doing on this issue and why such technology is important for the = future of the Internet. Also, I have to understand the procedures to set = a new technological standard. In this regard, I would like to know if someone of you could help me on = this. I can visit you if you are near Stanford University. It would not = take more than one hour of your time and I would appreciate very much. Thank you in advance. Carlos Motta 796, Escondido Rd. Rains 14-A Stanford, CA 94305-7562 USA (650) 498.0717 cmotta@stanford.edu www.cbeji.com.br ------=_NextPart_000_02A6_01C3B1D6.E2BC1300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sirs/ Madams:
 
I am a LL.M. (Master of Laws) in Law, = Science and=20 Technology Program at Stanford Law School and I am involved in a = Directed=20 Research regarding Infrastructure and Security on the Internet. One of = my=20 targets is the IPv6. My work is comprised by=20 the analysis on what IETF's working group is doing = on this=20 issue and why such technology is important for the future of the = Internet. Also,=20 I have to understand the procedures to set a new technological=20 standard.
 
In this regard, I would like to know if = someone of=20 you could help me on this. I can visit you if you are near Stanford = University.=20 It would not take more than one hour of your time and I would appreciate = very=20 much.
 
Thank you in advance.
 
Carlos Motta
796, Escondido = Rd.
Rains=20 14-A
Stanford, CA
94305-7562 USA
(650) 498.0717
cmotta@stanford.edu
www.cbeji.com.br
= ------=_NextPart_000_02A6_01C3B1D6.E2BC1300-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 01:37:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14283 for ; Mon, 24 Nov 2003 01:37:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOALi-0000no-FY for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 01:37:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO6bU1b003067 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 01:37:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOALh-0000nG-BY for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 01:37:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14252 for ; Mon, 24 Nov 2003 01:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOALe-0006rH-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 01:37:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOALd-0006rE-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 01:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOALG-0000Zk-V2; Mon, 24 Nov 2003 01:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAKv-0000Ya-C1 for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 01:36:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14234 for ; Mon, 24 Nov 2003 01:36:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAKs-0006qn-00 for ipv6@ietf.org; Mon, 24 Nov 2003 01:36:38 -0500 Received: from h013.c001.snv.cp.net ([209.228.32.127] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AOAKr-0006qf-00 for ipv6@ietf.org; Mon, 24 Nov 2003 01:36:37 -0500 Received: (cpmta 26295 invoked from network); 23 Nov 2003 22:36:32 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 23 Nov 2003 22:36:32 -0800 X-Sent: 24 Nov 2003 06:36:32 GMT Message-ID: <001201c3b255$76922780$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 08:37:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Andrew, the draft has provision for both "registered unique local > addresses" and "probably unique local addresses". The registered unique > addresses are not valid on the Internet, but they definitely will not > collide with other addresses. I am still have 2 concerns with these concepts: 1. People do not want to register their secure internal network nodes (bank central computes etc) so the "registered unique local addreses" may not meet their needs. They do not want to have even theoritically reachable addresses on a Cash machine or other secure node that needs to be connected as part of the private network. 2. For the "approxiamtely" or "probably" unique local addresses I am concerned that these addresses will eventually be assigned as part of the registered addresses and can then be in conflict with "legitimate" nodes. So between the 2, I do not see a solution that will work better than a RFC1918 type of address space. The more I hear about these options the more I want to bring back site local addresses. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 02:33:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28369 for ; Mon, 24 Nov 2003 02:33:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBDj-0005CV-Q4 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 02:33:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO7XJWJ019989 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 02:33:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBDj-0005CG-28 for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 02:33:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28324 for ; Mon, 24 Nov 2003 02:33:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOBDf-0007aw-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 02:33:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOBDe-0007at-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 02:33:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBDU-00056Q-9V; Mon, 24 Nov 2003 02:33:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBCu-00051k-4E for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 02:32:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28284 for ; Mon, 24 Nov 2003 02:32:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOBCe-0007aE-00 for ipv6@ietf.org; Mon, 24 Nov 2003 02:32:12 -0500 Received: from 227.cust7.nsw.dsl.ozemail.com.au ([203.102.234.227] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AOBCc-0007Zj-00 for ipv6@ietf.org; Mon, 24 Nov 2003 02:32:11 -0500 Received: from Dupy2.nosense.org (227.cust7.nsw.dsl.ozemail.com.au [203.102.234.227]) by nosense.org (Postfix) with SMTP id 214773F07B; Mon, 24 Nov 2003 18:02:49 +1030 (CST) Date: Mon, 24 Nov 2003 18:02:48 +1030 From: Mark Smith To: "EricLKlein" Cc: ericlklein@softhome.net, ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) Message-Id: <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <001201c3b255$76922780$ec061eac@ttitelecom.com> References: <001201c3b255$76922780$ec061eac@ttitelecom.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 24 Nov 2003 08:37:39 +0200 "EricLKlein" wrote: > Christian Huitema wrote: > > > Andrew, the draft has provision for both "registered unique local > > addresses" and "probably unique local addresses". The registered unique > > addresses are not valid on the Internet, but they definitely will not > > collide with other addresses. > > I am still have 2 concerns with these concepts: > 1. People do not want to register their secure internal network nodes (bank > central computes etc) so the "registered unique local addreses" may not meet > their needs. They do not want to have even theoritically reachable addresses > on a Cash machine or other secure node that needs to be connected as part of > the private network. > > 2. For the "approxiamtely" or "probably" unique local addresses I am > concerned that these addresses will eventually be assigned as part of the > registered addresses and can then be in conflict with "legitimate" nodes. > Probably not going to happen in the next 200 years or more, and more likely it will never happen. By the time that becomes a possibility, IPv7 or IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 bit trend, 512 bit addresses ... of course, every bit added doubles the size of the address space. I'm sure somebody can provide a more accurate figure, but with all the currently planned IPv6 address space allocations, there is still in the order of 3/4 unallocated (not unassigned), for any purpose. That 3/4 would have to be used up before your concern becomes a possiblity. > So between the 2, I do not see a solution that will work better than a > RFC1918 type of address space. The more I hear about these options the more > I want to bring back site local addresses. > I suggest you have a read or review the following two IETF documents : "RFC 2993 - Architectural Implications of NAT" http://www.faqs.org/rfcs/rfc2993.html Site Locals opens the NAT can of worms in IPv6. NAT is worth avoiding. Review the SL deprecation draft. If nothing else, Section 2 - "Adverse effects of site local addresses" is worth reviewing again to understand why duplicated address spaces cause problems. http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-02.txt The H/H addresses aren't perfect, but they do seem to be the best solution that meets the largest number of functionality goals, without resorting to Provider Independent addressing. PI would be perfect, except that it is likely to cause the default free routers to melt down in the longer term. As in much of life, it is a trade off. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 02:47:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28764 for ; Mon, 24 Nov 2003 02:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBRJ-0006Nf-Dr for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 02:47:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO7lLre024521 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 02:47:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBRI-0006NQ-Ua for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 02:47:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28734 for ; Mon, 24 Nov 2003 02:47:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOBRF-0007lK-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 02:47:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOBRE-0007lH-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 02:47:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBR0-0006HT-JC; Mon, 24 Nov 2003 02:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBQ6-0006AS-Db for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 02:46:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28682 for ; Mon, 24 Nov 2003 02:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOBQ2-0007iX-00 for ipv6@ietf.org; Mon, 24 Nov 2003 02:46:02 -0500 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 1AOBQ1-0007iI-00 for ipv6@ietf.org; Mon, 24 Nov 2003 02:46:01 -0500 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id hAO7jej05764; Mon, 24 Nov 2003 08:45:40 +0100 Message-ID: <3FC1B724.4070307@it.su.se> Date: Mon, 24 Nov 2003 08:45:40 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Mark Smith CC: EricLKlein , ericlklein@softhome.net, ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Probably not going to happen in the next 200 years or more, and more likely it will never happen. By the time that becomes a possibility, IPv7 or IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 bit trend, 512 bit addresses ... of course, every bit added doubles the size of the address space. > Doubtful. The versions you cite have already been co-opted by a well-known troll. But seriously; thank you for your list of references. I have been having deja-vue all over again these last few days :-( MVH leifj -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 03:34:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29827 for ; Mon, 24 Nov 2003 03:34:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCAi-0000pC-NP for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 03:34:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO8YGNw003168 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 03:34:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCAh-0000p1-HG for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 03:34:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29793 for ; Mon, 24 Nov 2003 03:34:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCAf-0000Ta-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 03:34:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOCAe-0000TX-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 03:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCAU-0000jb-Ko; Mon, 24 Nov 2003 03:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOC9d-0000iW-RY for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 03:33:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29731 for ; Mon, 24 Nov 2003 03:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOC9b-0000SP-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:33:07 -0500 Received: from h013.c001.snv.cp.net ([209.228.32.127] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AOC9a-0000SI-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:33:06 -0500 Received: (cpmta 23566 invoked from network); 24 Nov 2003 00:32:37 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 24 Nov 2003 00:32:37 -0800 X-Sent: 24 Nov 2003 08:32:37 GMT Message-ID: <005101c3b265$add42b70$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 10:33:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Mark Smith wrote > > I am still have 2 concerns with these concepts: > > 1. People do not want to register their secure internal network nodes (bank > > central computes etc) so the "registered unique local addreses" may not meet > > their needs. They do not want to have even theoritically reachable addresses > > on a Cash machine or other secure node that needs to be connected as part of > > the private network. > > > > 2. For the "approxiamtely" or "probably" unique local addresses I am > > concerned that these addresses will eventually be assigned as part of the > > registered addresses and can then be in conflict with "legitimate" nodes. > > > Probably not going to happen in the next 200 years or more, and more likely it will never happen. By the time that becomes a possibility, IPv7 or IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 bit trend, 512 bit addresses ... of course, every bit added doubles the size of the address space. > > I'm sure somebody can provide a more accurate figure, but with all the currently planned IPv6 address space allocations, there is still in the order of 3/4 unallocated (not unassigned), for any purpose. That 3/4 would have to be used up before your concern becomes a possiblity. I personally have not tried the algroythm for all possible cases, but I am a firm believer in Murphy's Law, and i am sure that there will be more than 1 company using some block of addresses when you combine registeres, "approximately unique", and just take what I want address spaces. This is not from an academic or programming view but from 10 years in the field connecting LANs into WANs. People want what they know not what works in the lab. > > > So between the 2, I do not see a solution that will work better than a > > RFC1918 type of address space. The more I hear about these options the more > > I want to bring back site local addresses. > > Site Locals opens the NAT can of worms in IPv6. NAT is worth avoiding. > This may be the case, but I keep seeing proposed standards about how to implement NAT in IPv6. So it seems to me that NAT is not dead. For examples see: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-01.txt http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00. txt http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-07.txt http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-07.txt The list of IPv6 plus NAT is over 140 documents long, with many of them being proposed in the last 5 days. The look up list I ran is: http://search.ietf.org/cgi-bin/htsearch?config=htdig&restrict=http%3A%2F%2Fw ww.ietf.org%2Finternet-drafts%2F&exclude=&matchesperpage=50&method=and&forma t=builtin-long&sort=time&words=%2Bnat+%2BIPv6 I will look over the document that you recommend, but please understand that while we in this WG are depreciating site locals, other people seem to be working hard on NAT and other uses for the site locals that already exist in the existing RFC. > As in much of life, it is a trade off. I agree, but we need to make sure that what we trade off still works in the end. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 03:58:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00352 for ; Mon, 24 Nov 2003 03:58:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCY8-0002Pp-E3 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 03:58:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO8wSN1009283 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 03:58:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCY7-0002Pe-Do for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 03:58:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00321 for ; Mon, 24 Nov 2003 03:58:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCY4-0000hk-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 03:58:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOCY4-0000hg-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 03:58:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCXj-0002K9-Pj; Mon, 24 Nov 2003 03:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCXL-0002GR-Df for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 03:57:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00308 for ; Mon, 24 Nov 2003 03:57:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCXI-0000hL-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:57:36 -0500 Received: from h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AOCXI-0000hH-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:57:36 -0500 Received: (cpmta 23421 invoked from network); 24 Nov 2003 00:57:36 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.115) with SMTP; 24 Nov 2003 00:57:36 -0800 X-Sent: 24 Nov 2003 08:57:36 GMT Message-ID: <005d01c3b269$2b0f9ea0$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <20031124083756.GB16883@login.ecs.soton.ac.uk> Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 10:58:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tim Chown wrote > > So they can use addresses from the probabilistically unique range under > the space fd00::/8. There is, in terms of raw usage, no difference between > using fd00::/8 or fec0::/10. External networks would still have to route > the prefixes back to you for you to be reachable, which is just as hard/easy > under either system. > Then why not jsut reuse the FEC8:: through FECB:: addresses that were originally the site locals, and are now going to have to be left unallocated for a while? It seems a little wasteful to allocate another range when we have one that is "effectively lost". > Well, addresses under fd00::/8 and fd00::/8 can be used locally just like > site-local addresses, only they have the nice property of significantly > reduced (probabilisticly unique) or complete removal of (registered unique) > ambiguity, so I don't see where your concern is? > > It is not unlikely that people will be lazy and just use fd00::/48 for sites, > and thus add back in great ambiguity to the probabilisticly unique address > space. First you ask a question, and then answer it. I am concerned that the many network "experts" out there that are trained in a 2 week certification course will take what is taught to them as an example and will make it gospel, and thus use the exact same addresses in multiple networks in close geographic proximity, and thus on the same Carrier edge router. Consider what happens when a carrier implements IPv6 in a city, and suddenly there are 10 companies connected by inexperienced network "experts" (and they have the certificate to prove it) that all follow the exact same course "template". Now this one carrier edge router is connected to 10 incorrectly configured routers all using the exact same "probabilistically unique address". this is where the original need for RFC1918 came from. I still prefer to have this more defined so that the providers can block a range as part of their access lists or filters. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 04:07:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00614 for ; Mon, 24 Nov 2003 04:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCgm-0003HQ-Ha for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 04:07:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO97OFu012604 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 04:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCgj-0003H0-Qq for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 04:07:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00584 for ; Mon, 24 Nov 2003 04:07:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCgh-0000pL-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 04:07:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOCgg-0000pI-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 04:07:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCgR-00035t-97; Mon, 24 Nov 2003 04:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCfQ-00034J-8c for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 04:06:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00568 for ; Mon, 24 Nov 2003 04:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCfN-0000oq-00 for ipv6@ietf.org; Mon, 24 Nov 2003 04:05:57 -0500 Received: from 227.cust7.nsw.dsl.ozemail.com.au ([203.102.234.227] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AOCfL-0000oZ-00 for ipv6@ietf.org; Mon, 24 Nov 2003 04:05:56 -0500 Received: from Dupy2.nosense.org (227.cust7.nsw.dsl.ozemail.com.au [203.102.234.227]) by nosense.org (Postfix) with SMTP id F04D43F07B; Mon, 24 Nov 2003 19:36:38 +1030 (CST) Date: Mon, 24 Nov 2003 19:36:37 +1030 From: Mark Smith To: "EricLKlein" Cc: ericlklein@softhome.net, ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) Message-Id: <20031124193637.24e21974.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <005101c3b265$add42b70$ec061eac@ttitelecom.com> References: <005101c3b265$add42b70$ec061eac@ttitelecom.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 24 Nov 2003 10:33:41 +0200 "EricLKlein" wrote: > > Mark Smith wrote > > > I am still have 2 concerns with these concepts: > > > 1. People do not want to register their secure internal network nodes > (bank > > > central computes etc) so the "registered unique local addreses" may not > meet > > > their needs. They do not want to have even theoritically reachable > addresses > > > on a Cash machine or other secure node that needs to be connected as > part of > > > the private network. > > > > > > 2. For the "approxiamtely" or "probably" unique local addresses I am > > > concerned that these addresses will eventually be assigned as part of > the > > > registered addresses and can then be in conflict with "legitimate" > nodes. > > > > > > Probably not going to happen in the next 200 years or more, and more > likely it will never happen. By the time that becomes a possibility, IPv7 or > IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 bit trend, > 512 bit addresses ... of course, every bit added doubles the size of the > address space. > > > > I'm sure somebody can provide a more accurate figure, but with all the > currently planned IPv6 address space allocations, there is still in the > order of 3/4 unallocated (not unassigned), for any purpose. That 3/4 would > have to be used up before your concern becomes a possiblity. > > I personally have not tried the algroythm for all possible cases, but I am a > firm believer in Murphy's Law, and i am sure that there will be more than 1 > company using some block of addresses when you combine registeres, > "approximately unique", and just take what I want address spaces. Everybody can take the whole IPv6 address space if they want to, and use it how they like. They were free to do that with IPv4. However, if those people choose to connect to the Internet, then, for the benefit of all users of the Internet, including themselves, they need to follow the policies of the Internet, which includes following / complying with the Internet's addressing policies. This is > not from an academic or programming view but from 10 years in the field > connecting LANs into WANs. There are a number of people on this list who have the experience you have, including myself. I'm sure plenty of people on this list are very familar with daily operational issues. A lot of the very long and large SL discussions have occured because people have contributed their diverse experience and knowledge. People want what they know not what works in the > lab. When you are defining something new, like IPv6, nobody knows it at first, as it is being invented. IPv6 may be completely wrong. However, as long as everybody who has a vested interest in making it better than IPv4 has the opportunity to contribute, and they choose to, then hopefully it will be the best solution available. People can't want something they know when it doesn't exist. > > > > > > So between the 2, I do not see a solution that will work better than a > > > RFC1918 type of address space. The more I hear about these options the > more > > > I want to bring back site local addresses. > > > > Site Locals opens the NAT can of worms in IPv6. NAT is worth avoiding. > > > This may be the case, but I keep seeing proposed standards about how to > implement NAT in IPv6. So it seems to me that NAT is not dead. For examples > see: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-01.txt > http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00. > txt > http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-07.txt > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-07.txt > > The list of IPv6 plus NAT is over 140 documents long, with many of them > being proposed in the last 5 days. The look up list I ran is: > http://search.ietf.org/cgi-bin/htsearch?config=htdig&restrict=http%3A%2F%2Fw > ww.ietf.org%2Finternet-drafts%2F&exclude=&matchesperpage=50&method=and&forma > t=builtin-long&sort=time&words=%2Bnat+%2BIPv6 > A key word search on NAT doesn't show that the technology is worthwhile. A number of the drafts you highlight are actually specs on how to restore end-to-end i.e. bypass or work around the problems NAT causes. This one is an example : http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt I'm guessing these ones do as well : http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-07.txt http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00.txt > > I will look over the document that you recommend, but please understand that > while we in this WG are depreciating site locals, other people seem to be > working hard on NAT and other uses for the site locals that already exist in > the existing RFC. > Well, then, they should stop and review, at least if they think NAT is going to be an official part of IPv6. People on this list know the perils of NAT, and most consider the cost of endorsing it in IPv6 to be too high. > > As in much of life, it is a trade off. > > I agree, but we need to make sure that what we trade off still works in the > end. > The only end there is is when the Earth gets burned up by the Sun, and that is a little while away. All solutions to anything are temporary, and only have to suit a current, near or relatively near (e.g. up to 100-200 years) need. As long as IPv6 works in the near or relatively near interrim term, then it is good enough. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 05:18:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02427 for ; Mon, 24 Nov 2003 05:18:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODnl-0007Go-Bq for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 05:18:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOAIfZQ027945 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 05:18:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODni-0007D0-Pv for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 05:18:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02393 for ; Mon, 24 Nov 2003 05:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODnf-0001j8-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 05:18:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AODnf-0001j3-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 05:18:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODn7-00077F-TL; Mon, 24 Nov 2003 05:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODmY-00076S-21 for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 05:17:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02363 for ; Mon, 24 Nov 2003 05:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODmU-0001i1-00 for ipv6@ietf.org; Mon, 24 Nov 2003 05:17:22 -0500 Received: from theory.cs.uni-bonn.de ([131.220.4.211]) by ietf-mx with esmtp (Exim 4.12) id 1AODmT-0001hy-00 for ipv6@ietf.org; Mon, 24 Nov 2003 05:17:22 -0500 Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.12.9/8.12.9) with SMTP id hAOAHHoH004167; Mon, 24 Nov 2003 11:17:17 +0100 (MET) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb1 15Feb2003); Mon, 24 Nov 2003 11:16:51 CET (sender ignatios@newton.cs.uni-bonn.de) Date: Mon, 24 Nov 2003 11:16:51 +0100 From: Ignatios Souvatzis To: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) Message-ID: <20031124101651.GA27565@cs.uni-bonn.de> References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 24, 2003 at 06:02:48PM +1030, Mark Smith wrote: =20 > Probably not going to happen in the next 200 years or more, and more > likely it will never happen. By the time that becomes a possibility, > IPv7 already proposed at least twice: TP/IX (RFC 1475) or CATNIP (RFC 1707)? Regards, -is --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEUAgUBP8HakTCn4om+4LhpAQF4rwf3agNU14o65YrxT7VXo7DQLomk0MDgBuN5 1BiH/NhFpjvFONuCnJJ402OeCgTKcpKQpkA/aaAeW/b+jnHDGanzVKK2fpqZV5A3 Q+21VMms5Py8roVVacM6noReYGOXMe9j9uAvKDjrqauaxqE1mZ3/z81WApMoZ8Z4 TA15OUuyUt5UPW6KtnoIe5eDOh26eVGZXuFG7N6jjpMST5WJmNzbqkxQLUT5BsJD 2r0nErzODsgYxkpal0pcyPyZZ1MahZTiTZfhB6bHuLXjA+AIC/CGX0zsG8X6Fwh+ a+CogtTmTxmXYYwGDPdmMYtACnxVEPVeTiB4nm0tr6MiVAZmJQuW =/Sqw -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 06:12:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03771 for ; Mon, 24 Nov 2003 06:12:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOEde-0001BX-LO for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 06:12:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOBCIUb004549 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 06:12:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOEde-0001BI-As for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 06:12:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03742 for ; Mon, 24 Nov 2003 06:12:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOEda-0002Ju-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 06:12:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOEda-0002Jr-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 06:12:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOEdN-00015d-UB; Mon, 24 Nov 2003 06:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOEdD-000157-5c for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 06:11:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03734 for ; Mon, 24 Nov 2003 06:11:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOEd9-0002JY-00 for ipv6@ietf.org; Mon, 24 Nov 2003 06:11:47 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AOEd8-0002JL-00 for ipv6@ietf.org; Mon, 24 Nov 2003 06:11:46 -0500 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 hAOBBGV15149; Mon, 24 Nov 2003 03:11:16 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAOBG3tX016363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 24 Nov 2003 03:16:06 -0800 Message-ID: <3FC1E741.30408@innovationslab.net> Date: Mon, 24 Nov 2003 06:10:57 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EricLKlein CC: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: <001201c3b255$76922780$ec061eac@ttitelecom.com> In-Reply-To: <001201c3b255$76922780$ec061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, EricLKlein wrote: > 2. For the "approxiamtely" or "probably" unique local addresses I am > concerned that these addresses will eventually be assigned as part of the > registered addresses and can then be in conflict with "legitimate" nodes. I'm curious, have you read draft-ietf-ipv6-unique-local-addr-01.txt? The locally assigned prefixes come out of the FD00::/8 range and the centrally assigned prefixes come out of the FC00::/8 range. Can you explain to me why you think they will collide at some point? Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 06:19:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03996 for ; Mon, 24 Nov 2003 06:19:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOEkZ-0001y0-7C for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 06:19:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOBJRvx007554 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 06:19:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOEkZ-0001xl-1t for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 06:19:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03972 for ; Mon, 24 Nov 2003 06:19:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOEkV-0002Rj-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 06:19:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOEkU-0002Re-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 06:19:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOEkA-0001pB-Rh; Mon, 24 Nov 2003 06:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOBgD-0007Q2-Fc for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 03:02:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29081 for ; Mon, 24 Nov 2003 03:02:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOBg9-00008Z-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:02:41 -0500 Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AOBg9-00008S-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:02:41 -0500 Received: (cpmta 12568 invoked from network); 24 Nov 2003 00:02:36 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.119) with SMTP; 24 Nov 2003 00:02:36 -0800 X-Sent: 24 Nov 2003 08:02:36 GMT Message-ID: <004901c3b261$7c844180$ec061eac@ttitelecom.com> From: "EricLKlein" To: References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 10:03:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Smith wrote > > I am still have 2 concerns with these concepts: > > 1. People do not want to register their secure internal network nodes (bank > > central computes etc) so the "registered unique local addreses" may not meet > > their needs. They do not want to have even theoritically reachable addresses > > on a Cash machine or other secure node that needs to be connected as part of > > the private network. > > > > 2. For the "approxiamtely" or "probably" unique local addresses I am > > concerned that these addresses will eventually be assigned as part of the > > registered addresses and can then be in conflict with "legitimate" nodes. > > > Probably not going to happen in the next 200 years or more, and more likely it will never happen. By the time that becomes a possibility, IPv7 or IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128 bit trend, 512 bit addresses ... of course, every bit added doubles the size of the address space. > > I'm sure somebody can provide a more accurate figure, but with all the currently planned IPv6 address space allocations, there is still in the order of 3/4 unallocated (not unassigned), for any purpose. That 3/4 would have to be used up before your concern becomes a possiblity. I personally have not tried the algroythm for all possible cases, but I am a firm believer in Murphy's Law, and i am sure that there will be more than 1 company using some block of addresses when you combine registeres, "approximately unique", and just take what I want address spaces. This is not from an academic or programming view but from 10 years in the field connecting LANs into WANs. People want what they know not what works in the lab. > > > So between the 2, I do not see a solution that will work better than a > > RFC1918 type of address space. The more I hear about these options the more > > I want to bring back site local addresses. > > Site Locals opens the NAT can of worms in IPv6. NAT is worth avoiding. > This may be the case, but I keep seeing proposed standards about how to implement NAT in IPv6. So it seems to me that NAT is not dead. For examples see: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-01.txt http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00. txt http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-07.txt http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-07.txt The list of IPv6 plus NAT is over 140 documents long, with many of them being proposed in the last 5 days. The look up list I ran is: http://search.ietf.org/cgi-bin/htsearch?config=htdig&restrict=http%3A%2F%2Fw ww.ietf.org%2Finternet-drafts%2F&exclude=&matchesperpage=50&method=and&forma t=builtin-long&sort=time&words=%2Bnat+%2BIPv6 I will look over the document that you recommend, but please understand that while we in this WG are depreciating site locals, other people seem to be working hard on NAT and other uses for the site locals that already exist in the existing RFC. > As in much of life, it is a trade off. I agree, but we need to make sure that what we trade off still works in the end. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 07:03:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05075 for ; Mon, 24 Nov 2003 07:03:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQy-0003xV-30 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 07:03:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOC3GZW015206 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 07:03:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQx-0003x2-LI for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 07:03:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05021 for ; Mon, 24 Nov 2003 07:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFQt-0002uW-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 07:03:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOFQs-0002uR-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 07:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQk-0003m8-Hd; Mon, 24 Nov 2003 07:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQE-0003lS-Eg for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 07:02:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05007 for ; Mon, 24 Nov 2003 07:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFQ9-0002u0-00 for ipv6@ietf.org; Mon, 24 Nov 2003 07:02:25 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1AOFQ9-0002tm-00 for ipv6@ietf.org; Mon, 24 Nov 2003 07:02:25 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAOBrYOB088422; Mon, 24 Nov 2003 12:01:54 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAOAYx33186916; Mon, 24 Nov 2003 11:34:59 +0100 Received: from zurich.ibm.com (dhcp21-96.zurich.ibm.com [9.4.21.96]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA48424; Mon, 24 Nov 2003 11:34:58 +0100 Message-ID: <3FC1C6F8.13F0C4F3@zurich.ibm.com> Date: Mon, 24 Nov 2003 09:53:12 +0100 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: EricLKlein CC: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: <001b01c3ae9e$c2f81590$ec061eac@ttitelecom.com> <3FBBBA9A.2807ED2F@zurich.ibm.com> <3FBD5E8C.BB5188A7@motorola.com> <009901c3b1a7$f6357860$ec061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit EricLKlein wrote: > > Andrew White wrote > > The problem with these people's arguments is that it's not the address > range > > that gives the security, it's the fact that you have an isolated network > > connected to the global network via only a proxy (NAT) and firewall. > > > > You can use any address range you like inside the NAT. However, if you > > don't use a 'private' range you're running two risks: > > > > - masking a portion of the global internet > > - leaking addresses that look real but are actually invalid rather than > > obviously invalid ones. > > This is exactly why some of us have been trying to prevent the depriciation > of local ("private") address. And it is why those of us unwilling to accept the major operational problems of *ambiguous* private addresses are trying to provide an unambiguous replacement. > > > > > The advantage of a local/private address range is that you can create one > > for whatever local use you need without needing to obtain space through a > > registration authority. The advantage of 'approximately unique' local > > addresses (in the style of the Hinden/Haberman draft) is that you get > > addresses with all the benefits of private address AND they're not likely > to > > conflict if you merge. > > > > This would work, and would be acceptiable to most people if there was a > simple rule that worked, and would continue to work as the network grows. My > concern is that an 'approximately unique' local address could at some point > become less than unique and could cause routing problems when the address is > eventually assigned. You don't seem to have read the Hinden/Haberman draft closely. The plan is that there will be a central registry for people with this concern. > I mean, how many companies would use this > 'approximately unique' local address option and thus "claim" portions of the > network, They aren't claiming any such thing. They own their internal networks and this is just a quick way for them to make them useable without the overhead of going to a registry. And I would expect every dentist's office to use this mechanism. > while the registreies are assigning addresses? Eventually there > will be legimate asigned users to some of these 'approximately unique' local > addresses No there won't. The Hinden/Haberman proposal makes this entirely clear. There is no overlap between registry-assigned addresses and locally-asssigned ones. > and this will cause problems later. No it won't, because it isn't true. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 07:03:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05090 for ; Mon, 24 Nov 2003 07:03:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQy-0003xW-Be for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 07:03:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOC3G3W015204 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 07:03:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQx-0003x4-LK for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 07:03:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05024 for ; Mon, 24 Nov 2003 07:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFQt-0002uY-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 07:03:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOFQs-0002uS-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 07:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQm-0003mK-6T; Mon, 24 Nov 2003 07:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFQE-0003lX-NX for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 07:02:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05010 for ; Mon, 24 Nov 2003 07:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFQA-0002u3-00 for ipv6@ietf.org; Mon, 24 Nov 2003 07:02:26 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1AOFQ9-0002tl-00 for ipv6@ietf.org; Mon, 24 Nov 2003 07:02:25 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAOBrfvc081300; Mon, 24 Nov 2003 12:01:47 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAOAYw33186914; Mon, 24 Nov 2003 11:34:58 +0100 Received: from zurich.ibm.com (dhcp21-96.zurich.ibm.com [9.4.21.96]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA68094; Mon, 24 Nov 2003 11:34:57 +0100 Message-ID: <3FC1C557.50733BA8@zurich.ibm.com> Date: Mon, 24 Nov 2003 09:46:15 +0100 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: Pekka Savola CC: ipv6@ietf.org Subject: Re: draft-hain-templin-ipv6-localcomm-03 comments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, I hate NATs, and the delusion that private addresses are a security feature, as much as you do. But the problem here is that Tony (author of the strongest NAT critique issued as an RFC) and Fred are much more in touch with the reality of corporate network deployment than you seem to be. See for example the recent messages from Eric Klein. I hear the same thing all the time from my colleagues in IBM Global Services. The academic argument that private addressing isn't the answer may be correct academically, but it has no relevance whatever to getting IPv6 deployed in the large majority of enterprises that are currently using RFC 1918 under the collective belief that it's a security feature (and protects them from the million dollar costs of renumbering). Now, I would be completely happy for us to throw away the Hain/Templin draft as long as we immediately standardize the Hinden/Haberman solution. But if we want to address (pun intended) the problems of the real world, we cannot ignore the fact that most corporate network managers are profoundly convinced of the need for private addressing. We must overcome our cognitive dissonance and simply deal with that reality. It is the only remaining small hope of avoiding NATv6. Brian Pekka Savola wrote: > > Hi, > > well, the document seems like to completely concentrate on an > addressing-based solution model.. which it probably should not. Anyone > even glancing at the document can be 100% sure of this. > > Or was it only supposed to be agnostic of whether local-use addressing was > needed? There's a difference there.. > > So, I agree 100% with Erik's earlier comments on the "coloring" and the > "background" of the document.. > > (I only read the beginning of the draft, got too big a headache..) > > substantial > ----------- > > 1) the whole section 3.2 Maintaining Confidentiality of the Address Space is > pretty much bogus. Remember, we're talking about using local communications > with *IPv6*. With IPv4, you would be required to record the address > prefixes in the RIR registries etc. -- but these are no longer relevant. > You get one /48, put it in the registry, that's it. No exposing needed. > > Beyond that, all the exposing you'd do is what you choose to do yourself. > If you don't want to give e.g. people the ability to traceroute through the > network to learn the network properties, you can prevent that. > > In summary, this whole section should be removed or seriously reworded. > > 2) I don't see the point of section 3.3 myself: > > Test networks are frequently large, elaborate networks with a mix of > public and private address space. Use of random unallocated space > runs the risk of collision with legitimate addresses on remote > networks if the test network is ever connected to the Internet. > > ==> what kind of test network are you talking about? > why would you ever connect a test to the Internet, except through some DMZ > hosts/routers etc? > > With IPv6, you have enough addresses to play around if you want to connect > something to the net. If you don't, you can just invent something (most TAC > etc. labs probably certaintly do). No magic there... > > Needs rewording to bring up the point better or remove.. > > 3) there is solutionism/assuming the addressing is the answer in many of the > goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8. Intentional? > > 4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the > text), could be removed ? > > 5) section 3.7 is a bit incomprehensible: > > 3.7 Asset Protection in Enterprise Networks > > Enterprise networks that protect private corporate assets (e.g., > printers, faxes, robotics, sensors, etc.) require an addressing > scheme that remains stable even when VPN connections from outside > sites occur. > > ==> how on earth would VPN connections from outside disturb a stable > addressing scheme?!? > > 6) it's no surprise that section 4 on goals presupposes an addressing-based > solution. Is this intentional? In any case, the titles are: > > 4.1 Easy to Acquire > 4.2 Stable > 4.3 Multiple Link Support > 4.4 Prefix Filtering and Hints to Applications > 4.5 Globally Unique > 4.6 Usable in the Absence of a Provider > 4.7 Applicable in Managed/Unmanaged Environments > 4.8 Compatible with Site Naming System > 4.9 Compatible with VPN > 4.10 Multiple Addressing > > one could generalize and reword these to: > > 4.1 Easy to Take to Use > 4.2 Session Stability > 4.3 Multiple Link Support > 4.4 Application Awareness of Policy > 4.5 Locality Between Multiple Sites > 4.6 Usable in the Absence of a Provider > 4.7 Applicable in Managed/Unmanaged Environments > 4.8 Compatible with Site Naming System > 4.9 Compatible with VPN (XXX: ?) > 4.10 Provision for Both Local and Global Communications > > semi-editorial > -------------- > > Abstract > > The IPv6 addressing architecture specifies global and local-use > unicast addressing schemes, but provides no operational guidelines > for their use. > > and: > > 1. Introduction > > The IPv6 addressing architecture [RFC3513] specifies global and > local-use unicast addresses. Global addresses are understood to have > unlimited range and may be used as the source and destination > addresses in packets that originate from any point on the connected > global IPv6 Internet. Local-use addresses are intended for use only > within the range of a single link/site, but their specification does > not address operational considerations for real-world deployment > scenarios. > > ==> the critical local-use addressing part is to be removed before this > becomes relevant, so I don't think it's appropriate to refer to these > documents here. Suggest removing or serious rewording. > > .... > > . As such, > the address prefixes used in each PAN should be globally unique to > avoid collisions and provide a means for verifying ownership to > resolve conflicts. > > ==> this (in 3.5) doesn't seem to be relevant to the local communications, > remove? > > editorial > --------- > > . Of > utmost importance is that the systems on board the ship all function, > > ==> s/Of utmost importance is/It's of utmost importance/ > > -- > 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 IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 08:41:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07749 for ; Mon, 24 Nov 2003 08:41:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxS-0001X9-7n for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:40:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODesXF005887 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:40:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxR-0001Ws-Mk for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:40:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07622 for ; Mon, 24 Nov 2003 08:40:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxQ-0004wp-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:40:52 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOGxP-0004vi-01 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:40:51 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOGux-0002F1-Ip for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:38:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGui-0000xI-6n; Mon, 24 Nov 2003 08:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGuP-0000so-2p for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 08:37:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07503 for ; Mon, 24 Nov 2003 08:37:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGuN-0004se-00 for ipv6@ietf.org; Mon, 24 Nov 2003 08:37:43 -0500 Received: from 227.cust7.nsw.dsl.ozemail.com.au ([203.102.234.227] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AOGuN-0004rl-00 for ipv6@ietf.org; Mon, 24 Nov 2003 08:37:43 -0500 Received: from Dupy2.nosense.org (227.cust7.nsw.dsl.ozemail.com.au [203.102.234.227]) by nosense.org (Postfix) with SMTP id A634E3F07B; Tue, 25 Nov 2003 00:08:25 +1030 (CST) Date: Tue, 25 Nov 2003 00:08:25 +1030 From: Mark Smith To: "EricLKlein" Cc: ericlklein@softhome.net, ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) Message-Id: <20031125000825.3ed2196d.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <008e01c3b28a$22fca700$ec061eac@ttitelecom.com> References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <3FC1E741.30408@innovationslab.net> <008e01c3b28a$22fca700$ec061eac@ttitelecom.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 24 Nov 2003 14:54:41 +0200 "EricLKlein" wrote: > > Can you explain why are we allocating another range for locally assigned > prefixes, rather than reusing the FEC8:; FEC9:: spaces that were used this > way and are now going to stay unallocated? Why tie up a second range? Because code may exist that assumes the probably soon-to-be-former SL functionality. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 08:41:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07767 for ; Mon, 24 Nov 2003 08:41:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxU-0001Xs-KL for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:40:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODeuXN005934 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxU-0001Xd-F6 for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:40:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07650 for ; Mon, 24 Nov 2003 08:40:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxT-0004xS-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:40:55 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOGxS-0004x7-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:40:54 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOGt4-0002EO-29 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:36:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGsm-0000OB-KF; Mon, 24 Nov 2003 08:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGsB-0000Mt-4C for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 08:35:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07426 for ; Mon, 24 Nov 2003 08:35:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGs9-0004pE-00 for ipv6@ietf.org; Mon, 24 Nov 2003 08:35:25 -0500 Received: from 227.cust7.nsw.dsl.ozemail.com.au ([203.102.234.227] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AOGs9-0004nr-00 for ipv6@ietf.org; Mon, 24 Nov 2003 08:35:25 -0500 Received: from Dupy2.nosense.org (227.cust7.nsw.dsl.ozemail.com.au [203.102.234.227]) by nosense.org (Postfix) with SMTP id EE3D53F07B; Tue, 25 Nov 2003 00:06:06 +1030 (CST) Date: Tue, 25 Nov 2003 00:06:06 +1030 From: Mark Smith To: "EricLKlein" Cc: ericlklein@softhome.net, ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) Message-Id: <20031125000606.303630d2.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <00a701c3b28a$fba659c0$ec061eac@ttitelecom.com> References: <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> <004901c3b261$7c844180$ec061eac@ttitelecom.com> <20031124112454.GK17562@login.ecs.soton.ac.uk> <00a701c3b28a$fba659c0$ec061eac@ttitelecom.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 24 Nov 2003 15:00:46 +0200 "EricLKlein" wrote: > Tim Chown wrote: > > > On Mon, Nov 24, 2003 at 10:03:44AM +0200, EricLKlein wrote: > > > > > This may be true, but no one is proposing green cow become an IETF standard. > The list I provided is recently proposed IETF drafts on when and how to use > NAT with IPv6. > I recommend you read some of the drafts you are listing. The "toredo" draft for example. > If there are this many new drafts coming out in November 2003, even with a > WG decision to not do NAT IPv6 then there should be a big red flag that > there is a disconnect between what this WG says and what others are doing. > I would prefer to say it the other way ... if your evidence is actual, it shows the other groups are disconnected with this one. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 08:41:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07812 for ; Mon, 24 Nov 2003 08:41:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxb-0001eC-C0 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODf37h006287 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxa-0001cM-GU for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:41:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07681 for ; Mon, 24 Nov 2003 08:40:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxY-0004y7-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:41:00 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOGxX-0004x7-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:40:59 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOGib-0001qO-92 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:25:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhE-0007RT-HR; Mon, 24 Nov 2003 08:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGFE-0006EY-Sr for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 07:55:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06152 for ; Mon, 24 Nov 2003 07:54:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGFE-0003xZ-00 for ipv6@ietf.org; Mon, 24 Nov 2003 07:55:12 -0500 Received: from h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AOGFD-0003xV-00 for ipv6@ietf.org; Mon, 24 Nov 2003 07:55:11 -0500 Received: (cpmta 12054 invoked from network); 24 Nov 2003 04:55:09 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.115) with SMTP; 24 Nov 2003 04:55:09 -0800 X-Sent: 24 Nov 2003 12:55:09 GMT Message-ID: <008e01c3b28a$22fca700$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <3FC1E741.30408@innovationslab.net> Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 14:54:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian Haberman wrote: > I'm curious, have you read draft-ietf-ipv6-unique-local-addr-01.txt? > The locally assigned prefixes come out of the FD00::/8 range and > the centrally assigned prefixes come out of the FC00::/8 range. Can > you explain to me why you think they will collide at some point? > To be honest, as stated in another e-mail, I have not read the draft-ietf-ipv6-unique-local-addr-01.txt, I am catching up on drafts and will read it soon. Can you explain why are we allocating another range for locally assigned prefixes, rather than reusing the FEC8:; FEC9:: spaces that were used this way and are now going to stay unallocated? Why tie up a second range? Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 08:46:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08037 for ; Mon, 24 Nov 2003 08:46:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOH35-0002Hj-F5 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:46:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODkh0r008777 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 08:46:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOH35-0002HU-8J for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:46:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07987 for ; Mon, 24 Nov 2003 08:46:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOH33-00054Y-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:46:42 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOGxX-0004vi-01 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:40:59 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOGiZ-0001qN-0k for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 08:25:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhH-0007Sw-8K; Mon, 24 Nov 2003 08:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGL6-0006OC-9o for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 08:01:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06382 for ; Mon, 24 Nov 2003 08:01:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGL5-00046T-00 for ipv6@ietf.org; Mon, 24 Nov 2003 08:01:15 -0500 Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AOGL4-00046P-00 for ipv6@ietf.org; Mon, 24 Nov 2003 08:01:14 -0500 Received: (cpmta 267 invoked from network); 24 Nov 2003 05:01:12 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.119) with SMTP; 24 Nov 2003 05:01:12 -0800 X-Sent: 24 Nov 2003 13:01:12 GMT Message-ID: <00a701c3b28a$fba659c0$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> <004901c3b261$7c844180$ec061eac@ttitelecom.com> <20031124112454.GK17562@login.ecs.soton.ac.uk> Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 15:00:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tim Chown wrote: > On Mon, Nov 24, 2003 at 10:03:44AM +0200, EricLKlein wrote: > > > > The list of IPv6 plus NAT is over 140 documents long, with many of them > > being proposed in the last 5 days. The look up list I ran is: > > http://search.ietf.org/cgi-bin/htsearch?config=htdig&restrict=http%3A%2F%2Fw > > ww.ietf.org%2Finternet-drafts%2F&exclude=&matchesperpage=50&method=and&forma > > t=builtin-long&sort=time&words=%2Bnat+%2BIPv6 > > So I google for "green cow" and get a million hits... but there are very > few green cows out there... > > People will use IPv6 with NAT, but then they may as well stick with IPv4+NAT. > This may be true, but no one is proposing green cow become an IETF standard. The list I provided is recently proposed IETF drafts on when and how to use NAT with IPv6. If there are this many new drafts coming out in November 2003, even with a WG decision to not do NAT IPv6 then there should be a big red flag that there is a disconnect between what this WG says and what others are doing. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 09:57:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10290 for ; Mon, 24 Nov 2003 09:57:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI9S-00077v-Sv for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 09:57:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOEvMRO027389 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 09:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI9S-00077f-Mz for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 09:57:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10265 for ; Mon, 24 Nov 2003 09:57:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOI9Q-0006MV-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 09:57:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOI9Q-0006MS-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 09:57:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI98-00072E-3j; Mon, 24 Nov 2003 09:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI8I-00071E-4l for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 09:56:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10248 for ; Mon, 24 Nov 2003 09:55:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOI8G-0006Ls-00 for ipv6@ietf.org; Mon, 24 Nov 2003 09:56:08 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1AOI8C-0006LW-00 for ipv6@ietf.org; Mon, 24 Nov 2003 09:56:07 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAOEpPn0072112; Mon, 24 Nov 2003 14:53:17 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAOEoo33279834; Mon, 24 Nov 2003 15:50:52 +0100 Received: from zurich.ibm.com (dyn-9-159-99-71.bw.ch.ibm.com [9.159.99.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA62998; Mon, 24 Nov 2003 15:50:48 +0100 Message-ID: <3FC21A9D.37F26201@zurich.ibm.com> Date: Mon, 24 Nov 2003 15:50:05 +0100 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: EricLKlein CC: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: <001201c3b255$76922780$ec061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit EricLKlein wrote: > > Christian Huitema wrote: > > > Andrew, the draft has provision for both "registered unique local > > addresses" and "probably unique local addresses". The registered unique > > addresses are not valid on the Internet, but they definitely will not > > collide with other addresses. > > I am still have 2 concerns with these concepts: > 1. People do not want to register their secure internal network nodes (bank > central computes etc) so the "registered unique local addreses" may not meet > their needs. There is no way to get a unique prefix without a central allocator (i.e. a registry, whether it's human or a robot). That's the reason for using the word "escrow" to describe the way the registry retains its information. > They do not want to have even theoritically reachable addresses > on a Cash machine or other secure node that needs to be connected as part of > the private network. The Hinden/Haberman addresses are not theoretically reachable. They are (like RFC 1918 or FEC0::/10) theoretically unreachable. Their new characteristic is unambiguity, which experience with RFC 1918 has shown is very necessary. The usual warning about the difference between theory and practice applies in all these cases, of course. > > 2. For the "approxiamtely" or "probably" unique local addresses I am > concerned that these addresses will eventually be assigned as part of the > registered addresses and can then be in conflict with "legitimate" nodes. No. Please read the draft. This cannot happen. > > So between the 2, I do not see a solution that will work better than a > RFC1918 type of address space. The more I hear about these options the more > I want to bring back site local addresses. The only real differences are that you get unambiguity, which is a MUST from RFC 1918 experience, and you lose the woolly concept of site scope, which we don't know how to use. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 10:54:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13905 for ; Mon, 24 Nov 2003 10:54:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJ2d-0004XT-VT for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 10:54:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOFsNdF017441 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 10:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJ2d-0004XE-F3 for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 10:54:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13857 for ; Mon, 24 Nov 2003 10:54:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJ2b-0007HM-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 10:54:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOJ2a-0007HJ-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 10:54:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJ2H-0004OP-4D; Mon, 24 Nov 2003 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJ1Z-0004Mr-GN for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 10:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13841 for ; Mon, 24 Nov 2003 10:53:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJ1W-0007Gn-00 for ipv6@ietf.org; Mon, 24 Nov 2003 10:53:15 -0500 Received: from h020.c001.snv.cp.net ([209.228.32.134] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AOJ1W-0007Gk-00 for ipv6@ietf.org; Mon, 24 Nov 2003 10:53:14 -0500 Received: (cpmta 7530 invoked from network); 24 Nov 2003 07:53:11 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.134) with SMTP; 24 Nov 2003 07:53:11 -0800 X-Sent: 24 Nov 2003 15:53:11 GMT Message-ID: <00bf01c3b2a3$01e73990$ec061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <20031124180248.06b4993a.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org><004901c3b261$7c844180$ec061eac@ttitelecom.com><20031124112454.GK17562@login.ecs.soton.ac.uk><00a701c3b28a$fba659c0$ec061eac@ttitelecom.com> <20031125000606.303630d2.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> Subject: Re: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 17:52:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Smith wrote > > If there are this many new drafts coming out in November 2003, even with a > > WG decision to not do NAT IPv6 then there should be a big red flag that > > there is a disconnect between what this WG says and what others are doing. > > > > I would prefer to say it the other way ... if your evidence is actual, it shows the other groups are disconnected with this one. I agree, but either way there is a disconnect. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 12:03:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16302 for ; Mon, 24 Nov 2003 12:03:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOK7g-0000zi-4U for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 12:03:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOH3d5u003813 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 12:03:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOK7f-0000zG-0r for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12:03:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16228 for ; Mon, 24 Nov 2003 12:03:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOK7a-0000Qg-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 12:03:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOK7X-0000Qd-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 12:03:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOK5K-0000EV-1G; Mon, 24 Nov 2003 12:01:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOK4A-00005X-FB for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 12:00:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16023 for ; Mon, 24 Nov 2003 11:59:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOK46-0000LI-00 for ipv6@ietf.org; Mon, 24 Nov 2003 11:59:58 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AOK46-0000Kq-00 for ipv6@ietf.org; Mon, 24 Nov 2003 11:59:58 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Nov 2003 08:59:20 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Nov 2003 08:59:26 -0800 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.6713); Mon, 24 Nov 2003 08:59:26 -0800 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.1069); Mon, 24 Nov 2003 08:59:28 -0800 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.3790.1069); Mon, 24 Nov 2003 08:59:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Local addresses and security? (was: SL deprecation draft) Date: Mon, 24 Nov 2003 09:00:02 -0800 Message-ID: Thread-Topic: Local addresses and security? (was: SL deprecation draft) thread-index: AcOyo1AI+ykIXXYuSMmUgijAqwBXcQAB4gug From: "Christian Huitema" To: "EricLKlein" , X-OriginalArrivalTime: 24 Nov 2003 16:59:37.0528 (UTC) FILETIME=[57E57380:01C3B2AC] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > ...prefer to say it the other way ... if your evidence is actual, > it shows the other groups are disconnected with this one. >=20 > I agree, but either way there is a disconnect. Eric, One simple way to cure the disconnect would be to actually read the drafts that you are quoting, starting with the H/H local addresses specification. I am familiar with several of these drafts, and you appear to be way off base: - http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt Deals with signaling, i.e. how to learn the mappings established by a NAT. Fundamentally a "NAT traversal" technology, made necessary to=20 remedy the effect of NAT. Certainly not a NAT advocacy paper. - http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal -00.txt Tries to define an extension of the STUN technology to traverse NAT.=20 Again, NAT remedy rather than NAT advocacy. - http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-01.txt Describes the state of the art in traversal techniques for IPv4 NAT, and recommends ways for these NATs to allow P2P traffic. Never mentions IPv6. - http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-07.txt Definition of a MIB for controlling NAT. Also used by MIDCOM to specify NAT traversal technologies. - http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt Describes how to allocate global IPv6 addresses so hosts behind=20 An IPv4 NAT could behave as if directly connected to the IPv6=20 Internet. - http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt Negotiation of NAT traversal for IPSEC traffic. In fact, a common point of all these drafts is to try to bypass the NAT, to obtain global connectivity despites the NAT, often using side effects of the NAT implementation. Most of that work is driven by application developers who are making their best to make NAT go away. None of these drafts is an advocacy for NAT, quite the contrary in fact. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 12:28:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17495 for ; Mon, 24 Nov 2003 12:28:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKVO-0002JS-M7 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 12:28:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHSAof008884 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 12:28:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKVO-0002JD-GF for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12:28:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17461 for ; Mon, 24 Nov 2003 12:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKVM-0000tE-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 12:28:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKVM-0000tB-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 12:28:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKVG-0002FX-KE; Mon, 24 Nov 2003 12:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKV9-0002F8-P8 for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 12:27:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17450 for ; Mon, 24 Nov 2003 12:27:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKV8-0000sr-00 for ipv6@ietf.org; Mon, 24 Nov 2003 12:27:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AOKV7-0000sW-00 for ipv6@ietf.org; Mon, 24 Nov 2003 12:27:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAOHRFQ13931; Mon, 24 Nov 2003 09:27:15 -0800 X-mProtect: <200311241727> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDHjnyM; Mon, 24 Nov 2003 09:27:13 PST Message-ID: <3FC2411C.1000904@iprg.nokia.com> Date: Mon, 24 Nov 2003 09:34:20 -0800 From: Fred 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: EricLKlein CC: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <3FC1E741.30408@innovationslab.net> <008e01c3b28a$22fca700$ec061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, EricLKlein wrote: >To be honest, as stated in another e-mail, I have not read the >draft-ietf-ipv6-unique-local-addr-01.txt, I am catching up on drafts and >will read it soon. > I'm a bit perplexed that you seem to have time to engage in the e-mail discussions but have not yet found the time to read documents that already address many/most of the points you are raising. It would perhaps serve to get us all on the same page if you could give some of the relevant documents a look. Thanks - Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 12:37:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18199 for ; Mon, 24 Nov 2003 12:37:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKeJ-00037f-AU for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 12:37:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHbNsa011983 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 12:37:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKeH-000374-1W for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12:37:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18098 for ; Mon, 24 Nov 2003 12:37:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKeF-00015Q-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 12:37:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKeF-00015N-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 12:37:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKdy-0002sK-KK; Mon, 24 Nov 2003 12:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKdQ-0002rW-49 for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 12:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17983 for ; Mon, 24 Nov 2003 12:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKdO-000138-00 for ipv6@ietf.org; Mon, 24 Nov 2003 12:36:26 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AOKdN-00011y-00 for ipv6@ietf.org; Mon, 24 Nov 2003 12:36:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAOHZpQ19017; Mon, 24 Nov 2003 09:35:51 -0800 X-mProtect: <200311241735> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNP5bW6; Mon, 24 Nov 2003 09:35:49 PST Message-ID: <3FC2434D.1070808@iprg.nokia.com> Date: Mon, 24 Nov 2003 09:43:41 -0800 From: Fred 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: Fred Templin CC: EricLKlein , ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <3FC1E741.30408@innovationslab.net> <008e01c3b28a$22fca700$ec061eac@ttitelecom.com> <3FC2411C.1000904@ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Whoops! I sent this before seeing the similar note from Christian. Not meaning to belabor the point or otherwise come down too hard on you, Eric. You are certainly not the only one involved in these discussions who could benefit from a read of the documents. Fred ftemplin@iprg.nokia.com Fred Templin wrote: > Eric, > > EricLKlein wrote: > >> To be honest, as stated in another e-mail, I have not read the >> draft-ietf-ipv6-unique-local-addr-01.txt, I am catching up on drafts and >> will read it soon. >> > > I'm a bit perplexed that you seem to have time to engage in > the e-mail discussions but have not yet found the time to read > documents that already address many/most of the points you > are raising. > > It would perhaps serve to get us all on the same page if you > could give some of the relevant documents a look. > > Thanks - Fred > ftemplin@iprg.nokia.com > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 13:31:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20141 for ; Mon, 24 Nov 2003 13:31:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLUp-0006Iu-2F for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 13:31:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOIVdne024231 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 13:31:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLUn-0006Ih-GM for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 13:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20099 for ; Mon, 24 Nov 2003 13:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLUg-0001qA-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 13:31:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOLUg-0001q7-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 13:31:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLUE-0006CV-LN; Mon, 24 Nov 2003 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLTq-00069G-Rr for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 13:30:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20055; Mon, 24 Nov 2003 13:30:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLTo-0001pR-00; Mon, 24 Nov 2003 13:30:36 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AOLTo-0001p3-00; Mon, 24 Nov 2003 13:30:36 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 24 Nov 2003 10:30:05 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Nov 2003 10:30:05 -0800 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); Mon, 24 Nov 2003 10:30:04 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Nov 2003 10:30:07 -0800 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.3790.1069); Mon, 24 Nov 2003 10:30:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: REVISED Last Call: 'Management Information Base for the Internet Protocol (IP)' to Proposed Standard Date: Mon, 24 Nov 2003 10:30:03 -0800 Message-ID: Thread-Topic: REVISED Last Call: 'Management Information Base for the Internet Protocol (IP)' to Proposed Standard thread-index: AcOjCUNp/VSPnLjBT2m0/8XGyrwUmAPoaynQ From: "Dave Thaler" To: Cc: , X-OriginalArrivalTime: 24 Nov 2003 18:30:20.0669 (UTC) FILETIME=[0442DAD0:01C3B2B9] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I just started implementing draft-ietf-ipv6-rfc2011-update-04.txt and have the following comments: 1) > inetIcmpOutMsgs OBJECT-TYPE [...] > "The total number of ICMP messages which the entity received. ^^^^^^^^ Should be "attempted to send", as in RFC 2011. 2) In the case diagram, InMcastPkts & InBcastPkts are shown before=20 InHdrErrors. I believe they need to be shown after it, as the only way=20 to tell if the packet is IP multicast or broadcast is to look in the=20 IP header which you can only do if it's valid. 3) ipMIBCompliance2 has ipSystemStatsGroup in MANDATORY-GROUPS ipSystemStatsGroup includes ipSystemStatsInBcastPkts and=20 ipSystemStatsOutBcastPkts. However, an IPv6-only device has=20 no need for these since there is no broadcast in IPv6. I believe the objects for broadcast should be in an IPv4 conformance group which IPv6-only devices need not implement. 4) > ipSystemStatsInTruncatedPkts OBJECT-TYPE [...] > "The number of input IP datagrams discarded because datagram > frame didn't carry enough data. This is unclear. If the frame didn't carry enough data to hold an IP header, is this counter incremented or ipSystemStatsInHdrErrors, or both? As the case diagram implies, I think this counter should only be incremented if the IP header is valid. 5) Are all three of InForwDatagrams, InNoRoutes, and OutForwDatagrams needed? Per the case diagram, is it always the case that InForwDatagrams =3D InNoRoutes + OutForwDatagrams or it it legal for InDiscards or OutDiscards to be incremented in between InForwDatagrams and OutForwDatagrams? There's currently the note "(2) The discard counters may increment at any time in the processing path." but it isn't clear which processing path. Obviously it should not be legal for InDiscards to be incremented in the send path, or for OutDiscards to be incremented in the receive path. But with the forward path line, it's not clear where the legal "InDiscards" section ends and the legal "OutDiscards" section begins. One simple fix would be to just specify that InDiscards applies anywhere left of the InNoRoutes junction, and OutDiscards applies anywhere right of it. 6) 4.1 > ignored. If you decide to implement it you may wish to use the previous > instrumentation and arrange for the system statistics table to aggregate > the new interface level statistics. This is unclear. If you mean to suggest that one can compute a global value but adding all the per-interface values, then you should point out that this can only be done without causing counter discontinuities if the set of interfaces is static. (That is removing an interface would make the global counter value drop, which is a discontinuity.) 7) the ip6Forwarding object is described as > "The indication of whether this entity is acting as an IPv6 > router in respect to the forwarding of datagrams received > by, but not addressed to, this entity. IPv6 routers forward > datagrams. [...] However, forwarding is actually a per-interface attribute in general. If a device is acting as a router on some interfaces and as a host on others, what value should it report here? In my opinion it should report true here (if this object is kept at all) and there should be=20 a per-interface Forwarding object. 8) ipv6InterfacePhysicalAddress OBJECT-TYPE If this object is needed (as opposed to just using ifPhysAddress) why does the same reason not apply to IPv4 also? 9) ipv6InterfaceReasmMaxSize OBJECT-TYPE =20 SYNTAX Unsigned32 (0..65535) From RFC 2460 sec 5: > A node must be able to accept a fragmented packet that, after > reassembly, is as large as 1500 octets. A node is permitted to > accept fragmented packets that reassemble to more than 1500 octets. So shouldn't the range be (1500..65535)? 10) ipv6InterfaceRetransmitTime OBJECT-TYPE Is there a reason this doesn't apply to IPv4? RFC 1122 says regarding ARP: > [...] The recommended maximum rate is 1 per second per > destination. It would seem that all objects in the ipv{4,6}InterfaceTables=20 should be the same except for ipv6InterfaceIdentifier. =20 Is there a reason they are not merged as was done with the ipSystemStatsTable? 11)=20 > SYNTAX INTEGER { =20 > medium (0), > high (1), > reserved (2), =20 > low (3) =20 > } Can this be changed to: reserved (-2), low (-1), medium (0), high (1) Or just use a signed Integer32 (-2..1), since the object instrumented is a 2-bit signed integer. 12) The ipDefaultRouterTable is indexed as > INDEX {ipDefaultRouterAFType, ipDefaultRouterAddress} The current indexing requires the agent to report only one row when=20 the link zone id is the same for both interfaces (i.e. indicating=20 multiple interfaces are attached to the same physical link) and the same router is reachable on both interfaces. Per RFC 2461: > Router list entries point to entries in the > Neighbor Cache; [...] The inetNetToMediaTable instruments the neighbor cache and contains=20 the ifIndex in the INDEX. As a result, the MIB does not follow the=20 RFC 2461 model. To be consistent, ipDefaultRouterIfIndex must be in the INDEX clause to allow an entry to point to a specific inetNetToMediaEntry. 13) ipv6ScopeZoneIndexSubnetLocal=20 Rename to ipv6ScopeZoneIndex3 for consistency with scoped address architecture changes, and update DESCRIPTION. 14) ipv6RouterAdvertDefaultLifetime=20 > SYNTAX Unsigned32 (0..65535) =20 > UNITS "seconds" =20 > "[...] This value =20 > MUST be either 0 or between ipv6RouterAdvertMaxInterval and > 9000 seconds. [...]" So why does the SYNTAX allow values > 9000? Sounds like it should be (0 | 4..9000). 15) Shouldn't there be 64-bit versions of ipSystemStatsInForwDatagrams Counter32, ipSystemStatsOutForwDatagrams Counter32, ipSystemStatsInDelivers Counter32, ipSystemStatsOutRequests Counter32, ? If InReceives can wrap in an hour, the packets have to go somewhere, and if OutTransmits can wrap in an hour, the packets have to come from somewhere... 16) The case diagram accounts for the case where the IF changes on the receive path, but what about on the send path? The same thing happens in the weak host model. =20 Similarly, on a router, a packet could be forwarded and then be locally destined. Or it could be locally sourced and then forwarded. In these cases, should InForwDatagrams and OutForwDatagrams be incremented? I would say yes, although the case diagram doesn't allow for it. It would be nice to add a note to at least add a note to this effect. =20 Missing references ------------------ > ipv6RouteTable) has been removed from this MIB. The replacements or > updates for this information is in the update to the IP Forwarding Table > MIB. add a reference to that document so the reader can find them > REFERENCE "draft-ietf-ipv6-router-selection-02.txt, section 2.1" The reference is missing from the References section. Typos ----- 3.2.1 > Each of group of objects is required when implementing their respective ^^ delete extra "of" 3.2.3 > discontinuity event which would invalidate the management entities > understanding of the counters has occurred. The system being re- "entities" should be "entity's" 3.2.10 > set of counter to track the number of ICMP messages and errors processed ^^^^^^^ should be "counters" 4.2 > The ipAddressTable is loosely based on the ipv6AddrTable but has changed > considerable with the addition of several new objects and the removal of ^^^^^^^^^^^^ should be "considerably" > REVISION "9411010000Z" Update the pre-2000 revision dates to use 4-digit years > ipSystemStatsInTruncatedPkts OBJECT-TYPE [...] > "The number of input IP datagrams discarded because datagram > frame didn't carry enough data. insert "the" before "datagram" > ipRoutingDiscards OBJECT-TYPE [...] > and a similar, but more thourghly clarified, object has been ^^^^^^^^^ Should be "thoroughly" > ipv6RouterAdvertOtherConfigFlag OBJECT-TYPE =20 > "The true/false value to be placed int the 'other stateful ^^^ should be "in" or "into" -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 13:53:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21179 for ; Mon, 24 Nov 2003 13:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLph-0008N4-0Y for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 13:53:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOIrCKU032177 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 13:53:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLpg-0008Mu-Rw for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 13:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21152 for ; Mon, 24 Nov 2003 13:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLpe-0002Eq-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 13:53:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOLpe-0002En-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 13:53:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLpV-0008Fh-Tc; Mon, 24 Nov 2003 13:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLpA-0008FE-PJ for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 13:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21134 for ; Mon, 24 Nov 2003 13:52:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLp8-0002EQ-00 for ipv6@ietf.org; Mon, 24 Nov 2003 13:52:38 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1AOLp7-0002Dh-00 for ipv6@ietf.org; Mon, 24 Nov 2003 13:52:37 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAOIoI3V128574 for ; Mon, 24 Nov 2003 18:52:05 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAOAYx33087586 for ; Mon, 24 Nov 2003 11:35:00 +0100 Received: from zurich.ibm.com (dhcp21-96.zurich.ibm.com [9.4.21.96]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA58408 for ; Mon, 24 Nov 2003 11:34:59 +0100 Message-ID: <3FC1C83C.1BA81577@zurich.ibm.com> Date: Mon, 24 Nov 2003 09:58:36 +0100 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@ietf.org Subject: Re: names for non-global addresses References: <3FBEBC18.7020706@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Politically, calling them private addresses will work best, even if it offends end-to-end purists such as myself. I don't think cute geek acronyms work for this. We're looking for a suitable chapter heading for a dummies' guide book. "Configuring private addresses for your network." - Brian Fred Templin wrote: > > I'll take mnemonic power, but could do without the cuteness. > How about: > > IDEA - Independently-Delegated Endpoint Address > > Fred > ftemplin@iprg.nokia.com > > Keith Moore wrote: > > > I still prefer > > > > GUPI (pronounced "guppy" like the fish) - globally unique > > provider-independent > > PUPI (pronounced "puppy" like a young dog) - probably unique > > provider-independent > > > > as having about the right ratio of cuteness to mnemonic power. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 14:07:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21883 for ; Mon, 24 Nov 2003 14:07:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOM3E-0000nA-Me for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 14:07:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOJ7CWs003038 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 14:07:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOM3E-0000mv-8x for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 14:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21842 for ; Mon, 24 Nov 2003 14:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOM3B-0002VZ-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 14:07:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOM3B-0002VV-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 14:07:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOM34-0000iT-DL; Mon, 24 Nov 2003 14:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOM2z-0000hn-4O for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 14:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21830 for ; Mon, 24 Nov 2003 14:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOM2w-0002VK-00 for ipv6@ietf.org; Mon, 24 Nov 2003 14:06:54 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AOM2w-0002VH-00 for ipv6@ietf.org; Mon, 24 Nov 2003 14:06:54 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 47AC5AFEBB; Mon, 24 Nov 2003 14:06:54 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25137-06; Mon, 24 Nov 2003 14:06:53 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id EF471AFEB6; Mon, 24 Nov 2003 14:06:52 -0500 (EST) Date: Mon, 24 Nov 2003 14:07:39 -0500 Subject: Re: names for non-global addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Keith Moore , ipv6@ietf.org To: Brian E Carpenter From: Keith Moore In-Reply-To: <3FC1C83C.1BA81577@zurich.ibm.com> Message-Id: <7940F147-1EB1-11D8-89BF-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Politically, calling them private addresses will work best, even > if it offends end-to-end purists such as myself. mumble. is there a way to call them something that sounds politically correct without giving the impression that these addresses only work on the local network? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 15:05:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24935 for ; Mon, 24 Nov 2003 15:05:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMxd-0004ab-9p for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 15:05:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOK5T7Z017635 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 15:05:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMxd-0004aM-3C for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:05:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24800 for ; Mon, 24 Nov 2003 15:05:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMxa-0003Sl-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 15:05:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMxZ-0003Sh-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 15:05:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMwD-0004KC-Pf; Mon, 24 Nov 2003 15:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMvK-0004HB-Ug for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 15:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24497 for ; Mon, 24 Nov 2003 15:02:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMvH-0003Q0-00 for ipv6@ietf.org; Mon, 24 Nov 2003 15:03:03 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AOMvH-0003Px-00 for ipv6@ietf.org; Mon, 24 Nov 2003 15:03:03 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id DD390AFB4C; Mon, 24 Nov 2003 15:03:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01916-02; Mon, 24 Nov 2003 15:03:02 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 80D83AFB12; Mon, 24 Nov 2003 15:03:02 -0500 (EST) Date: Mon, 24 Nov 2003 15:03:49 -0500 Subject: Re: names for non-global addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Keith Moore , ipv6@ietf.org To: Brian E Carpenter From: Keith Moore In-Reply-To: <3FC1C83C.1BA81577@zurich.ibm.com> Message-Id: <51B9F7C2-1EB9-11D8-89BF-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit More on this point - I have two specific concerns about the use of "private addresses" 1. potential confusion with RFC 1918 addresses, including the association of RFC 1918 addresses with "non-routable outside of the local network" and "used with NATs". 2. potential confusion with RFC 3041 "privacy addresses" Unfortunately English doesn't seem to have many antonyms for "public", but as politically-correct but not misleading alternatives to GUPI/PUPI, IDEA, and "private addresses" I suggest that either "nonpublic addresses" or "limited-access addresses" or perhaps just "limited addresses" would be better. > Politically, calling them private addresses will work best, even > if it offends end-to-end purists such as myself. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 15:42:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28530 for ; Mon, 24 Nov 2003 15:42:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONXG-0008PY-Qa for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 15:42:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKgI6K032326 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 15:42:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONXG-0008PJ-KE for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:42:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28485 for ; Mon, 24 Nov 2003 15:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONXF-0004Gf-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 15:42:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONXE-0004G9-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 15:42:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONW2-00083v-8j; Mon, 24 Nov 2003 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONVy-00083N-Sn for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 15:40:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28422 for ; Mon, 24 Nov 2003 15:40:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONVx-0004F7-00 for ipv6@ietf.org; Mon, 24 Nov 2003 15:40:57 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AONVw-0004F4-00 for ipv6@ietf.org; Mon, 24 Nov 2003 15:40:56 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AONVe-000396-00; Mon, 24 Nov 2003 20:40:38 +0000 Date: Mon, 24 Nov 2003 20:40:38 +0000 To: Keith Moore Cc: Brian E Carpenter , ipv6@ietf.org Subject: Re: names for non-global addresses Message-ID: <20031124204038.GB31948@fysh.org> References: <3FC1C83C.1BA81577@zurich.ibm.com> <7940F147-1EB1-11D8-89BF-000393DB5366@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7940F147-1EB1-11D8-89BF-000393DB5366@cs.utk.edu> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Keith Moore wrote: >mumble. is there a way to call them something that sounds politically >correct without giving the impression that these addresses only work on >the local network? "Private" doesn't give me that impression. "Private" suggests to me that they work within a region determined by the owner of the address (which is approximately correct); they do not necessarily work in the public Internet. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 17:02:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05318 for ; Mon, 24 Nov 2003 17:02:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOmB-0005Yy-Tq for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 17:01:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOM1lIN021380 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 17:01:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOmB-0005Yi-Lh for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 17:01:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05217 for ; Mon, 24 Nov 2003 17:01:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOm9-0006ae-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 17:01:45 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOOh8-0006Ci-01 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 16:56:35 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOOYZ-0008V5-Mo for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 16:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOWw-0003uj-1F; Mon, 24 Nov 2003 16:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOWB-0003rz-44 for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 16:45:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03205 for ; Mon, 24 Nov 2003 16:44:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOW8-0005nG-00 for ipv6@ietf.org; Mon, 24 Nov 2003 16:45:12 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOW7-0005kl-00 for ipv6@ietf.org; Mon, 24 Nov 2003 16:45:12 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAOLiCa01541; Mon, 24 Nov 2003 23:44:12 +0200 Date: Mon, 24 Nov 2003 23:44:12 +0200 (EET) From: Pekka Savola To: Tony Hain cc: "'Brian E Carpenter'" , Subject: RE: draft-hain-templin-ipv6-localcomm-03 comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, 24 Nov 2003, Tony Hain wrote: > Brian E Carpenter wrote: > > ... > > Now, I would be completely happy for us to throw away the Hain/Templin > > draft as long as we immediately standardize the Hinden/Haberman solution. > > But if we want to address (pun intended) the problems of the real world, > > we cannot ignore the fact that most corporate network managers are > > profoundly convinced of the need for private addressing. > > In many cases I would agree with Brian, but in this specific one we have an > example of lost discussion from many years ago about why network managers > 'need' a private space, and FEC0 was allocated for it. We need to document > why Hinden/Haberman is needed to solve today's problems, so we don't end up > arguing about it 5 years from now. If you know the result in advance, why bother to write a requirements/goals document? Wouldn't it just make more sense to just write a document describing why private addressing is a good idea (and similarly, say why it is a bad idea) ? The current document, with its broad title, "Goals for Local Communications within Sites", gives an impression that the document would be looking neutrally to the real requirements, not presuppose the solutions. Even a bare glance at the document shows that there doesn't even seem to be an attempt to describe the requirements in terms which are not related to addressing -based solutions. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 18:44:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11471 for ; Mon, 24 Nov 2003 18:44:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQNZ-0003Xx-S1 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 18:44:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAONiTR1013627 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 18:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQNZ-0003Xf-M1 for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 18:44:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11435 for ; Mon, 24 Nov 2003 18:44:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQNW-0000nZ-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 18:44:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOQNW-0000nV-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 18:44:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQN8-0003Rr-0d; Mon, 24 Nov 2003 18:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQMd-0003RS-Tz for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 18:43:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11402 for ; Mon, 24 Nov 2003 18:43:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQMa-0000nC-00 for ipv6@ietf.org; Mon, 24 Nov 2003 18:43:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AOQMa-0000ms-00 for ipv6@ietf.org; Mon, 24 Nov 2003 18:43:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAONgsv05035; Mon, 24 Nov 2003 15:42:54 -0800 X-mProtect: <200311242342> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0v4FRe; Mon, 24 Nov 2003 15:42:53 PST Message-ID: <3FC29956.30900@iprg.nokia.com> Date: Mon, 24 Nov 2003 15:50:46 -0800 From: Fred 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: Keith Moore CC: Brian E Carpenter , ipv6@ietf.org Subject: Re: names for non-global addresses References: <51B9F7C2-1EB9-11D8-89BF-000393DB5366@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, Keith Moore wrote: > More on this point - I have two specific concerns about the use of > "private addresses" > > 1. potential confusion with RFC 1918 addresses, including the > association of RFC 1918 addresses with "non-routable outside of the > local network" and "used with NATs". > 2. potential confusion with RFC 3041 "privacy addresses" > > Unfortunately English doesn't seem to have many antonyms for "public", > but as politically-correct but not misleading alternatives to > GUPI/PUPI, IDEA, and "private addresses" I suggest that either > "nonpublic addresses" or "limited-access addresses" or perhaps just > "limited addresses" would be better. You are coming dangerously close to completing the full-circle and bringing us back to the term "limited range" which was en vogue for some time. Frankly, I see this as an endless rathole that we could spin on forever; Brian's suggestion gives us a clean way to avoid it. Fred ftemplin@iprg.nokia.com >> Politically, calling them private addresses will work best, even >> if it offends end-to-end purists such as myself. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 19:17:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13046 for ; Mon, 24 Nov 2003 19:17:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQtB-00063y-Ei for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 19:17:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP0H9Ll023300 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 19:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQtB-00063j-4R for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 19:17:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12981 for ; Mon, 24 Nov 2003 19:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQt9-0001WO-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:17:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOQt9-0001WL-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQt4-0005vE-Jl; Mon, 24 Nov 2003 19:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQsJ-0005uD-ID for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 19:16:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12947 for ; Mon, 24 Nov 2003 19:15:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQsH-0001Sn-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:16:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AOQsH-0001ST-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:16:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAP0FPS21473; Mon, 24 Nov 2003 16:15:25 -0800 X-mProtect: <200311250015> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3CCrMG; Mon, 24 Nov 2003 16:15:23 PST Message-ID: <3FC2A0F4.5000706@iprg.nokia.com> Date: Mon, 24 Nov 2003 16:23:16 -0800 From: Fred 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: Keith Moore CC: brc@zurich.ibm.com, ipv6@ietf.org Subject: Re: names for non-global addresses References: <51B9F7C2-1EB9-11D8-89BF-000393DB5366@cs.utk.edu> <3FC29956.30900@iprg.nokia.com> <20031124185933.7be21459.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hmm - so it seems that you *are* willing to go full circle and spin in the rathole? Have fun, but please don't try to take the wg with you; we have already spent way too much time there. Fred ftemplin@iprg.nokia.com Keith Moore wrote: >>You are coming dangerously close to completing the full-circle and >>bringing us back to the term "limited range" which was en vogue for >>some time. >> >> > >well, to me "limited range" seems less dangerous than "private addresses", >but others might disagree. > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 19:46:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14040 for ; Mon, 24 Nov 2003 19:46:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORLm-00088u-36 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 19:46:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP0kgOR031294 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 19:46:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORLl-00088f-A0 for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 19:46:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13977 for ; Mon, 24 Nov 2003 19:46:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORLj-0001wC-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:46:39 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AORKc-0001u3-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:45:30 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AORBi-0005E5-2R for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:36:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORBT-0006z2-3H; Mon, 24 Nov 2003 19:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORBJ-0006yT-Oi for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 19:35:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13636 for ; Mon, 24 Nov 2003 19:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORBI-0001ni-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:35:52 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AORBH-0001nP-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:35:51 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAP0ZJA28456; Mon, 24 Nov 2003 16:35:19 -0800 X-mProtect: <200311250035> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdhmjKAc; Mon, 24 Nov 2003 16:35:18 PST Message-Id: <4.3.2.7.2.20031124162718.0368bf00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Nov 2003 16:33:55 -0800 To: Brian E Carpenter From: Bob Hinden Subject: Re: names for non-global addresses Cc: ipv6@ietf.org In-Reply-To: <3FC1C83C.1BA81577@zurich.ibm.com> References: <3FBEBC18.7020706@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , At 12:58 AM 11/24/2003, Brian E Carpenter wrote: >Politically, calling them private addresses will work best, even >if it offends end-to-end purists such as myself. > >I don't think cute geek acronyms work for this. We're looking for >a suitable chapter heading for a dummies' guide book. > > "Configuring private addresses for your network." This could be: Private IPv6 Unicast Addresses (PUA) or perhaps: Globally Unique Private IPv6 Unicast Addresses (GUPA) Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Nov 24 19:47:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14055 for ; Mon, 24 Nov 2003 19:47:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORLo-00089H-6x for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 19:46:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP0ki4c031317 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 19:46:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORLo-000892-1g for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 19:46:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13984 for ; Mon, 24 Nov 2003 19:46:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORLm-0001yM-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:46:42 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AORKb-0001u3-01 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:45:29 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AORCj-0005EG-L0 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORCR-0007LB-Lv; Mon, 24 Nov 2003 19:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORCO-0007Kj-M8 for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 19:37:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13696 for ; Mon, 24 Nov 2003 19:36:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORCM-0001p4-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:36:58 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AORCM-0001ox-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:36:58 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4DF44AFD52; Mon, 24 Nov 2003 19:36:59 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07699-15; Mon, 24 Nov 2003 19:36:58 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3C126AFB2E; Mon, 24 Nov 2003 19:36:58 -0500 (EST) Date: Mon, 24 Nov 2003 19:28:40 -0500 From: Keith Moore To: Fred Templin Cc: moore@cs.utk.edu, brc@zurich.ibm.com, ipv6@ietf.org Subject: Re: names for non-global addresses Message-Id: <20031124192840.01d37764.moore@cs.utk.edu> In-Reply-To: <3FC2A0F4.5000706@iprg.nokia.com> References: <51B9F7C2-1EB9-11D8-89BF-000393DB5366@cs.utk.edu> <3FC29956.30900@iprg.nokia.com> <20031124185933.7be21459.moore@cs.utk.edu> <3FC2A0F4.5000706@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, maybe I wasn't paying much attention when that particular rathole was being discussed, so I don't realize how painful it was. Anyway, I've put in well more than my two cents' worth on this topic. Keith > Hmm - so it seems that you *are* willing to go full circle > and spin in the rathole? Have fun, but please don't try to > take the wg with you; we have already spent way too > much time there. > > >>You are coming dangerously close to completing the full-circle and > >>bringing us back to the term "limited range" which was en vogue for > >>some time. > > > >well, to me "limited range" seems less dangerous than "private > >addresses", but others might disagree. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 07:28:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15130 for ; Tue, 25 Nov 2003 07:28:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcIv-0005TB-5s for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 07:28:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPCSTuJ021019 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 07:28:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcIv-0005Sw-13 for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 07:28:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15096 for ; Tue, 25 Nov 2003 07:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcIu-0003Wj-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 07:28:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOcIu-0003Wg-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 07:28:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcIU-0005Na-Gm; Tue, 25 Nov 2003 07:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcIS-0005ND-Ih for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 07:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15088 for ; Tue, 25 Nov 2003 07:27:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcIR-0003W5-00 for ipv6@ietf.org; Tue, 25 Nov 2003 07:27:59 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcIR-0003VM-00 for ipv6@ietf.org; Tue, 25 Nov 2003 07:27:59 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAPCRQa15297 for ; Tue, 25 Nov 2003 14:27:27 +0200 Date: Tue, 25 Nov 2003 14:27:26 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: ICMPv6 ND option for more specific routes [Re: draft-ietf-ipv6-router-selection-02.txt issues list] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id hAPCRQa15297 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Just hoping to avoid the similar mess as we're having with MIPv6 and=20 MLDv2, would it be possible to pre-assign a Neighbor Discovery Option=20 code for more specific routes extension in: http://www.iana.org/assignments/icmpv6-parameters .. this shouldn't cause a problem, as there are no IANA considerations=20 for applying these in RFC2461, and I guess they're allocated in a=20 basically FCFS basis. Various =EDmplementations are using various values, at least some of=20 them "9" -- which is already being used for something else. Would it make thse to try to pre-assign a value at this point so folks=20 could start building interoperable implementations already? :-) (Assuming that the spec is going to be finished soon.. :-) On Mon, 3 Nov 2003, Dave Thaler wrote: > I've gone through the threads that Rich Draves sent me to extract=20 > the issues raised with draft-ietf-ipv6-router-selection-02.txt. >=20 > There were a number of relatively minor editorial suggestions to=20 > which Rich had responded with an okay. These I am already=20 > incorporating into the document. >=20 > Besides those, there were 10 issues raised which are now at=20 > http://www.icir.org/dthaler/RouterSelectionIssues.htm >=20 > I should have a proposed update available prior to IETF. >=20 > -Dave >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --=20 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 08:02:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16281 for ; Tue, 25 Nov 2003 08:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcpa-00077s-7g for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 08:02:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPD2EZo027392 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 08:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcpa-00077j-26 for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 08:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16224 for ; Tue, 25 Nov 2003 08:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcpZ-0004Nk-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 08:02:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOcpY-0004Nh-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 08:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcpO-000722-AT; Tue, 25 Nov 2003 08:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcoT-0006zU-KL for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 08:01:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16191 for ; Tue, 25 Nov 2003 08:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcoS-0004LB-00 for ipv6@ietf.org; Tue, 25 Nov 2003 08:01:04 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AOcoS-0004Ko-00 for ipv6@ietf.org; Tue, 25 Nov 2003 08:01:04 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAPD0TDM020607 for ; Tue, 25 Nov 2003 08:00:30 -0500 (EST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-225.cisco.com [10.82.224.225]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEF88122; Tue, 25 Nov 2003 08:00:29 -0500 (EST) Message-Id: <4.3.2.7.2.20031125075153.01efbe80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Nov 2003 08:00:26 -0500 To: ipv6@ietf.org From: Ralph Droms Subject: RFC2461bis issue: IANA considerations In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Pekka's request for assignment of a new option code number for a Neighbor Discovery option prompted me to take a quick look at RFC2461, which doesn't have an IANA Considerations section. I suggest that IANA Considerations be added to RFC2461bis, with rules about assigning new option codes. The rules for new option codes in DHCPv6, from the IANA Considerations section of RFC 3315, seem appropriate for ND options as well: New DHCP option codes are tentatively assigned after the specification for the associated option, published as an Internet Draft, has received expert review by a designated expert [11]. The final assignment of DHCP option codes is through Standards Action, as defined in RFC 2434 [11]. [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 08:57:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17624 for ; Tue, 25 Nov 2003 08:57:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdh6-000156-FG for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 08:57:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPDvWEC004157 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 08:57:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdh4-00014y-WA for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 08:57:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17580 for ; Tue, 25 Nov 2003 08:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdh3-0005Kr-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 08:57:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOdh3-0005Ko-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 08:57:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdgd-0000zJ-6I; Tue, 25 Nov 2003 08:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdgC-0000z0-Ml for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 08:56:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17567 for ; Tue, 25 Nov 2003 08:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdgB-0005KJ-00 for ipv6@ietf.org; Tue, 25 Nov 2003 08:56:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AOdgA-0005K9-00 for ipv6@ietf.org; Tue, 25 Nov 2003 08:56:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAPDu2213322; Tue, 25 Nov 2003 05:56:02 -0800 X-mProtect: <200311251356> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzdwO4F; Tue, 25 Nov 2003 05:56:01 PST Message-ID: <3FC3614F.8080100@iprg.nokia.com> Date: Tue, 25 Nov 2003 06:03:59 -0800 From: Fred 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: ipv6@ietf.org, v6ops@ops.ietf.org Subject: "ROUTERS" vs. "routers" References: <3FC2B319.9080707@iprg.nokia.com> <20031125020315.7A6958B@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread took on an interesting twist that I felt warranted a new subject heading. RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS"). "ROUTERS" typically advertise autoconfig parameters and prefixes from their attached networks. Hosts use them to reach off-link nodes via default or more-specific routes. But, a new breed of routers (i.e., "routers") is emerging from paradigms such as Mobile Ad-hoc Networks. "routers" typically advertise host routes only (aka, "addresses" or "locators") and no prefix or autoconfig parameters at all. I talked about this dichotomy several years ago in my writings in the MANET wg and in some of the contract work I did at SRI International. The dichotomy is also discussed in documents such as the "global6" work by Charles Perkins and his colleagues. But, the notion of "routers" has really been around for decades and is quite well known in some circles. In the MANET paradigm, "routers" often have only a single network interface which may be used for multi-hop forwarding within a flat addressing space (i.e., using host routes and redirects to steer the multi-hop forwarding decisions) while "ROUTERS" are used to reach other off-link networks. But, the same paradigm can be applied to the emerging global IPv6 Internet. In particular, I believe we will soon see an emerging paradigm for IPv6 in which most (if not all) nodes will be "routers" and a smaller subset of the nodes will be "ROUTERS". A node can qualify as a "router" IFF it has the proper credentials so that other nodes can guard against redirection attacks. The NOID approach specifies a method by which "routers" may attain the proper credentials (it also supports site-multihoming as an added attraction): http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt "routers" will also need a means for distributing host routes w/o including the normal information traditional "ROUTERS" advertise. The "Default Router Preferences, More-Specific Routers and Load Sharing" approach specifies the necessary mechanisms: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt So, what is missing? It would be desireable for a node sending an RFC 2461 Router Solicitation to be able to specify whether "ROUTER" or "router" information (or both) was being solicited. This function can be accommodated by either providing a codepoint (i.e., 1-2 bits) in the existing Router Solicitation message or a new IPv6 Neighbor Discovery message type (call it a "Type II Router Solicitaiton" for lack of a better name.) Perhaps this isn't even needed; I would be happy to let others comment. So, where does the "all nodes are routers" model lead us? To an IPv6 Internet with end-to-end security, site multihoming, multi-hop forwarding capability, and a restoration of the end-to-end principles. I think we need to get on board with this, folks... Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 09:06:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17946 for ; Tue, 25 Nov 2003 09:06:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdpQ-0001ez-Fc for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 09:06:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPE68Kg006375 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 09:06:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdpQ-0001ek-A2 for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09:06:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17907 for ; Tue, 25 Nov 2003 09:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdpO-0005RJ-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 09:06:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOdpO-0005RG-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 09:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdpK-0001b6-J0; Tue, 25 Nov 2003 09:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdoe-0001a9-NW for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 09:05:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17885 for ; Tue, 25 Nov 2003 09:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdod-0005Qs-00 for ipv6@ietf.org; Tue, 25 Nov 2003 09:05:19 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AOdoc-0005Qg-00 for ipv6@ietf.org; Tue, 25 Nov 2003 09:05:18 -0500 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 hAPE4lV25460; Tue, 25 Nov 2003 06:04:47 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAPE9dtX021357 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Nov 2003 06:09:42 -0800 Message-ID: <3FC36156.8000003@innovationslab.net> Date: Tue, 25 Nov 2003 09:04:06 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: ICMPv6 ND option for more specific routes [Re: draft-ietf-ipv6-router-selection-02.txt issues list] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by uillean.fuaim.com id hAPE4lV25460 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, There are two ways we could do this. One would be for the doc authors to request a value from IANA. The other would be to push draft-narten-iana-experimental-allocations-05.txt through the process and utilize it for early testing/experimentation. Regards, Brian Pekka Savola wrote: > Hi, >=20 > Just hoping to avoid the similar mess as we're having with MIPv6 and=20 > MLDv2, would it be possible to pre-assign a Neighbor Discovery Option=20 > code for more specific routes extension in: > http://www.iana.org/assignments/icmpv6-parameters >=20 > .. this shouldn't cause a problem, as there are no IANA considerations=20 > for applying these in RFC2461, and I guess they're allocated in a=20 > basically FCFS basis. >=20 > Various =EDmplementations are using various values, at least some of=20 > them "9" -- which is already being used for something else. >=20 > Would it make thse to try to pre-assign a value at this point so folks=20 > could start building interoperable implementations already? :-) >=20 > (Assuming that the spec is going to be finished soon.. :-) >=20 > On Mon, 3 Nov 2003, Dave Thaler wrote: >=20 >>I've gone through the threads that Rich Draves sent me to extract=20 >>the issues raised with draft-ietf-ipv6-router-selection-02.txt. >> >>There were a number of relatively minor editorial suggestions to=20 >>which Rich had responded with an okay. These I am already=20 >>incorporating into the document. >> >>Besides those, there were 10 issues raised which are now at=20 >>http://www.icir.org/dthaler/RouterSelectionIssues.htm >> >>I should have a proposed update available prior to IETF. >> >>-Dave >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 09:14:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18233 for ; Tue, 25 Nov 2003 09:14:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdxL-0002fh-Je for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 09:14:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPEEJt2010263 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 09:14:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdxL-0002fS-9p for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09:14:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18193 for ; Tue, 25 Nov 2003 09:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdxJ-0005Ws-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 09:14:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOdxJ-0005Wp-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 09:14:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdx3-0002Wc-Qf; Tue, 25 Nov 2003 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdwR-0002Sm-02 for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 09:13:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18149 for ; Tue, 25 Nov 2003 09:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdwP-0005WA-00 for ipv6@ietf.org; Tue, 25 Nov 2003 09:13:21 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdwO-0005VP-00 for ipv6@ietf.org; Tue, 25 Nov 2003 09:13:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAPECPj17068; Tue, 25 Nov 2003 16:12:25 +0200 Date: Tue, 25 Nov 2003 16:12:25 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: ipv6@ietf.org Subject: Re: RFC2461bis issue: IANA considerations In-Reply-To: <4.3.2.7.2.20031125075153.01efbe80@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 25 Nov 2003, Ralph Droms wrote: > New DHCP option codes are tentatively assigned after the > specification for the associated option, published as an Internet > Draft, has received expert review by a designated expert [11]. The > final assignment of DHCP option codes is through Standards Action, as > defined in RFC 2434 [11]. What does "tentatively assigned" mean? What if the document doesn't get produced in the end, because even though a designated expert is OK with it, it is not useful in general? I don't assume it would be possible to "reclaim" such tentatively assigned numbers, at least easily. But not sure if someone has thought this through? IMHO, the proposal would place too high trust in just one expert saying whether this seems OK or not. The bar needs to be higher, e.g. IESG's decision, or maybe adopting the document as WG item, or something like that. (FWIW, draft-narten-ipv6-iana-considerations-00.txt proposes "IESG Approval" or "Standards Action".) -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 09:30:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18788 for ; Tue, 25 Nov 2003 09:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeCo-0003gr-Gq for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 09:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPEUIXR014179 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 09:30:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeCo-0003gc-A4 for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09:30:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18741 for ; Tue, 25 Nov 2003 09:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeCm-0005mA-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 09:30:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOeCm-0005m6-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 09:30:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeCZ-0003al-7z; Tue, 25 Nov 2003 09:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeBl-0003ZJ-4m for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 09:29:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18711 for ; Tue, 25 Nov 2003 09:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeBj-0005l9-00 for ipv6@ietf.org; Tue, 25 Nov 2003 09:29:11 -0500 Received: from smistad.uninett.no ([158.38.62.77]) by ietf-mx with esmtp (Exim 4.12) id 1AOeBi-0005l4-00 for ipv6@ietf.org; Tue, 25 Nov 2003 09:29:11 -0500 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 182E220F32; Tue, 25 Nov 2003 15:28:39 +0100 (CET) Date: Tue, 25 Nov 2003 15:28:39 +0100 (CET) Message-Id: <20031125.152839.01257123.he@uninett.no> To: ftemplin@iprg.nokia.com Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" From: Havard Eidnes In-Reply-To: <3FC3614F.8080100@iprg.nokia.com> References: <3FC2B319.9080707@iprg.nokia.com> <20031125020315.7A6958B@coconut.itojun.org> <3FC3614F.8080100@iprg.nokia.com> X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hm, I hope I'm not the only one who find the choice of wording to be unfortunate. From=20the 10km-high perspective, there should be other and more fundamental distinguishing marks than the prefix length of advertisments or more general protocol behaviour to draw the line between what has traditionally been named "hosts" and "routers". I'll therefore give some pushback on introducing a subtle for-ipv6-only distinction between "ROUTERS" and "routers". Regards, - H=E5vard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 10:08:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20940 for ; Tue, 25 Nov 2003 10:08:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOenn-0006fR-QQ for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 10:08:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPF8VqU025623 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 10:08:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOenn-0006fC-Eh for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:08:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20824 for ; Tue, 25 Nov 2003 10:08:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOenk-0006NF-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 10:08:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOenk-0006NB-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 10:08:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOenK-0006Vs-Pt; Tue, 25 Nov 2003 10:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOemL-0006I4-T5 for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 10:07:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20655 for ; Tue, 25 Nov 2003 10:06:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOemJ-0006Lg-00 for ipv6@ietf.org; Tue, 25 Nov 2003 10:06:59 -0500 Received: from web80510.mail.yahoo.com ([66.218.79.80]) by ietf-mx with smtp (Exim 4.12) id 1AOemI-0006Kt-00 for ipv6@ietf.org; Tue, 25 Nov 2003 10:06:58 -0500 Message-ID: <20031125150550.46577.qmail@web80510.mail.yahoo.com> Received: from [63.197.18.101] by web80510.mail.yahoo.com via HTTP; Tue, 25 Nov 2003 07:05:50 PST Date: Tue, 25 Nov 2003 07:05:50 -0800 (PST) From: Fred Templin Subject: Re: "ROUTERS" vs. "routers" To: ipv6@ietf.org, v6ops@ops.ietf.org Cc: ftemplin@iprg.nokia.com, osprey67@yahoo.com In-Reply-To: <3FC3614F.8080100@iprg.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-886304300-1069772750=:45636" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-886304300-1069772750=:45636 Content-Type: text/plain; charset=us-ascii Whoops! I got just a tad bit overboard in my message and need to add some balance. There will still be *plenty* of simple hosts in the new paradigm that neither need nor want to be considered as "routers" or "ROUTERS". They will include things like my home printer, my home security system, my car's speedomeer, etc. These will be good candidates for an IPv6 local addressing scheme of some sort. Fred Templin osprey67@yahoo.com ftemplin@iprg.nokia.com Fred Templin wrote: The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread took on an interesting twist that I felt warranted a new subject heading. RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS"). "ROUTERS" typically advertise autoconfig parameters and prefixes from their attached networks. Hosts use them to reach off-link nodes via default or more-specific routes. But, a new breed of routers (i.e., "routers") is emerging from paradigms such as Mobile Ad-hoc Networks. "routers" typically advertise host routes only (aka, "addresses" or "locators") and no prefix or autoconfig parameters at all. I talked about this dichotomy several years ago in my writings in the MANET wg and in some of the contract work I did at SRI International. The dichotomy is also discussed in documents such as the "global6" work by Charles Perkins and his colleagues. But, the notion of "routers" has really been around for decades and is quite well known in some circles. In the MANET paradigm, "routers" often have only a single network interface which may be used for multi-hop forwarding within a flat addressing space (i.e., using host routes and redirects to steer the multi-hop forwarding decisions) while "ROUTERS" are used to reach other off-link networks. But, the same paradigm can be applied to the emerging global IPv6 Internet. In particular, I believe we will soon see an emerging paradigm for IPv6 in which most (if not all) nodes will be "routers" and a smaller subset of the nodes will be "ROUTERS". A node can qualify as a "router" IFF it has the proper credentials so that other nodes can guard against redirection attacks. The NOID approach specifies a method by which "routers" may attain the proper credentials (it also supports site-multihoming as an added attraction): http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt "routers" will also need a means for distributing host routes w/o including the normal information traditional "ROUTERS" advertise. The "Default Router Preferences, More-Specific Routers and Load Sharing" approach specifies the necessary mechanisms: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt So, what is missing? It would be desireable for a node sending an RFC 2461 Router Solicitation to be able to specify whether "ROUTER" or "router" information (or both) was being solicited. This function can be accommodated by either providing a codepoint (i.e., 1-2 bits) in the existing Router Solicitation message or a new IPv6 Neighbor Discovery message type (call it a "Type II Router Solicitaiton" for lack of a better name.) Perhaps this isn't even needed; I would be happy to let others comment. So, where does the "all nodes are routers" model lead us? To an IPv6 Internet with end-to-end security, site multihoming, multi-hop forwarding capability, and a restoration of the end-to-end principles. I think we need to get on board with this, folks... Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-886304300-1069772750=:45636 Content-Type: text/html; charset=us-ascii
Whoops! I got just a tad bit overboard in my message and need to
add some balance. There will still be *plenty* of simple hosts in the
new paradigm that neither need nor want to be considered as "routers"
or "ROUTERS". They will include things like my home printer, my
home security system, my car's speedomeer, etc. These will be
good candidates for an IPv6 local addressing scheme of some sort.
 
Fred Templin
 

Fred Templin <ftemplin@iprg.nokia.com> wrote:
The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread
took on an interesting twist that I felt warranted a new subject heading.

RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS").
"ROUTERS" typically advertise autoconfig parameters and prefixes from
their attached networks. Hosts use them to reach off-link nodes via default
or more-specific routes. But, a new breed of routers (i.e., "routers") is
emerging from paradigms such as Mobile Ad-hoc Networks. "routers"
typically advertise host routes only (aka, "addresses" or "locators") and
no prefix or autoconfig parameters at all.

I talked about this dichotomy several years ago in my writings
in the MANET wg and in some of the contract work I did at SRI
International. The dichotomy is also discussed in documents such
as the "global6" work by Charles! Perkins and his colleagues. But,
the notion of "routers" has really been around for decades and is
quite well known in some circles.

In the MANET paradigm, "routers" often have only a single network
interface which may be used for multi-hop forwarding within a flat
addressing space (i.e., using host routes and redirects to steer the
multi-hop forwarding decisions) while "ROUTERS" are used to reach
other off-link networks. But, the same paradigm can be applied to the
emerging global IPv6 Internet.

In particular, I believe we will soon see an emerging paradigm for
IPv6 in which most (if not all) nodes will be "routers" and a smaller
subset of the nodes will be "ROUTERS". A node can qualify as a
"router" IFF it has the proper credentials so that other nodes can
guard against redirection attacks. The NOID approach specifies
a method by which "routers" may attain the proper credentials
(it also supports site-multihoming as an added attraction):

http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt

"routers" will also need a means for distributing host routes w/o
including the normal information traditional "ROUTERS" advertise.
The "Default Router Preferences, More-Specific Routers and Load
Sharing" approach specifies the necessary mechanisms:


http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt

So, what is missing? It would be desireable for a node sending
an RFC 2461 Router Solicitation to be able to specify whether
"ROUTER" or "router" information (or both) was being solicited.
This function can be accommodated by either providing a codepoint
(i.e., 1-2 bits) in the existing Router Solicitation message or a new
IPv6 Neighbor Discovery message type (call it a "Type II Router
Solicitaiton" for lack of a better name.) Perhaps this isn't even
needed; I would be happy to let others comment.

So, whe! re does the "all nodes are routers" model lead us? To an
IPv6 Internet with end-to-end security, site multihoming, multi-hop
forwarding capability, and a restoration of the end-to-end principles.

I think we need to get on board with this, folks...

Fred
ftemplin@iprg.nokia.com






--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-886304300-1069772750=:45636-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 10:24:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22400 for ; Tue, 25 Nov 2003 10:24:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf2x-0008Ok-3X for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 10:24:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFOBBk032281 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 10:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf2w-0008Oa-GV for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:24:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22356 for ; Tue, 25 Nov 2003 10:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf2u-0006li-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 10:24:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf2t-0006lf-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 10:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf2n-0008G7-8r; Tue, 25 Nov 2003 10:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf29-0008Eh-43 for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 10:23:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22325 for ; Tue, 25 Nov 2003 10:23:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf26-0006k9-00 for ipv6@ietf.org; Tue, 25 Nov 2003 10:23:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOf26-0006jE-00 for ipv6@ietf.org; Tue, 25 Nov 2003 10:23:18 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 16:20:08 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAPFMXUV005295; Tue, 25 Nov 2003 16:22:34 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 15:22:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: "ROUTERS" vs. "routers" Date: Tue, 25 Nov 2003 15:22:43 -0000 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzYMqq/McgpH1dQmy1+QKMxpDFnwAAz07A From: "Pascal Thubert (pthubert)" To: "Havard Eidnes" , Cc: , X-OriginalArrivalTime: 25 Nov 2003 15:22:45.0382 (UTC) FILETIME=[FA001A60:01C3B367] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Havard I believe it's worth opening the Pandora's box. I agree with Fred that = things and usages have changed. On top of the MANET based examples that Fred proposed, I have in mind an = other 'Half and half' case. That's the concept on "Network in node" = which is a basically a host with a network attached to it or inside it. = Examples: - A traffic dispatcher - A PC with multiple Network addressable entities such as storage media - A PC with multiple users or applications, each one with a addressable = with different IP address from an "inner" network - A mobile router (still shows as a Host on the roaming interface) = acting as a bridge when at home - A ND proxy that is not exposed as a router, eg a Home Network behind a = Home Gateway. I'm not sure if in Fred's term I'm introducing "HOST" vs "host", but it = appears that the old paradigm of routers vs hosts seems limited for some = applications that IPv6 enables. Pascal > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of = Havard Eidnes > Sent: mardi 25 novembre 2003 15:29 > To: ftemplin@iprg.nokia.com > Cc: ipv6@ietf.org; v6ops@ops.ietf.org > Subject: Re: "ROUTERS" vs. "routers" >=20 > Hm, >=20 > I hope I'm not the only one who find the choice of wording to be > unfortunate. >=20 > From the 10km-high perspective, there should be other and more > fundamental distinguishing marks than the prefix length of > advertisments or more general protocol behaviour to draw the line > between what has traditionally been named "hosts" and "routers". >=20 > I'll therefore give some pushback on introducing a subtle > for-ipv6-only distinction between "ROUTERS" and "routers". >=20 > Regards, >=20 > - H=E5vard >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 10:45:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23990 for ; Tue, 25 Nov 2003 10:45:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfNI-0002lS-IH for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 10:45:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFjCLV010620 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 10:45:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfNI-0002lD-CA for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:45:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23895 for ; Tue, 25 Nov 2003 10:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfNG-0007Fo-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 10:45:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfNF-0007Fk-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 10:45:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfN8-0002dY-W4; Tue, 25 Nov 2003 10:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfMB-0002NJ-E8 for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 10:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23799 for ; Tue, 25 Nov 2003 10:43:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfM8-0007Da-00 for ipv6@ietf.org; Tue, 25 Nov 2003 10:44:00 -0500 Received: from smistad.uninett.no ([158.38.62.77]) by ietf-mx with esmtp (Exim 4.12) id 1AOfM7-0007Bl-00 for ipv6@ietf.org; Tue, 25 Nov 2003 10:44:00 -0500 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id B0B5220F32; Tue, 25 Nov 2003 16:43:28 +0100 (CET) Date: Tue, 25 Nov 2003 16:43:28 +0100 (CET) Message-Id: <20031125.164328.95799586.he@uninett.no> To: pthubert@cisco.com Cc: ftemplin@iprg.nokia.com, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hm, maybe I was unclear -- let me try to clarify. The distinction between routers and hosts and the criteria to separate between them is one which I perceive as having been well established in Internet technology for a Long Time. I think we should think twice before obfuscating this distinction, or try to sneak in something which is claimed to be somewhere between them. I'm therefore reacting negatively to the attempt at abusing the "router" term by introducing new and subtle meaning with a distinction between "ROUTER" and "router". Choose a different word if you insist on pursuing this, please! I've heard in other discussions the distinction between hosts implementing a "strong" versus a "weak" model, typically used as a distinguishing additional criteria when hosts are attached to multiple networks and/or have multiple addresses. However, my local RFC repository does not have any mention of that term. I wonder if this direction is something which could be pursued. Regards, - H=E5vard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 11:03:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24662 for ; Tue, 25 Nov 2003 11:03:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfel-0003eC-2o for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 11:03:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPG3Fsg014021 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 11:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfek-0003e1-Kq for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 11:03:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24641 for ; Tue, 25 Nov 2003 11:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfei-0007kC-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 11:03:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfeh-0007k9-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 11:03:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfeX-0003YU-Ll; Tue, 25 Nov 2003 11:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfdq-0003Xh-Oa for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 11:02:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24609 for ; Tue, 25 Nov 2003 11:02:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfdo-0007iw-00 for ipv6@ietf.org; Tue, 25 Nov 2003 11:02:16 -0500 Received: from web80513.mail.yahoo.com ([66.218.79.83]) by ietf-mx with smtp (Exim 4.12) id 1AOfdn-0007iL-00 for ipv6@ietf.org; Tue, 25 Nov 2003 11:02:15 -0500 Message-ID: <20031125160144.60580.qmail@web80513.mail.yahoo.com> Received: from [63.197.18.101] by web80513.mail.yahoo.com via HTTP; Tue, 25 Nov 2003 08:01:44 PST Date: Tue, 25 Nov 2003 08:01:44 -0800 (PST) From: Fred Templin Subject: Re: "ROUTERS" vs. "routers" To: Havard Eidnes , pthubert@cisco.com Cc: ftemplin@iprg.nokia.com, ipv6@ietf.org, v6ops@ops.ietf.org In-Reply-To: <20031125.164328.95799586.he@uninett.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-197517590-1069776104=:60318" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-197517590-1069776104=:60318 Content-Type: text/plain; charset=us-ascii The goal of my message is to get a message out; not to push new terminology. See RFC 1122 for a discussion of the "strong" vs "weak" ES models. Thanks - Fred osprey67@yahoo.com ftemplin@iprg.nokia.com Havard Eidnes wrote: I've heard in other discussions the distinction between hosts implementing a "strong" versus a "weak" model, typically used as a distinguishing additional criteria when hosts are attached to multiple networks and/or have multiple addresses. However, my local RFC repository does not have any mention of that term. I wonder if this direction is something which could be pursued. --0-197517590-1069776104=:60318 Content-Type: text/html; charset=us-ascii
The goal of my message is to get a message out; not to
push new terminology. See RFC 1122 for a discussion
of the "strong" vs "weak" ES models.
 
Thanks - Fred
 
Havard Eidnes <he@uninett.no> wrote:

I've heard in other discussions the distinction between hosts
implementing a "strong" versus a "weak" model, typically used as a
distinguishing additional criteria when hosts are attached to multiple
networks and/or have multiple addresses. However, my local RFC
repository does not have any mention of that term. I wonder if this
direction is something which could be pursued.

--0-197517590-1069776104=:60318-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 13:30:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00871 for ; Tue, 25 Nov 2003 13:30:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhxG-0005zC-Rm for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 13:30:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPIUUbv023010 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 13:30:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhxG-0005z3-MT for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 13:30:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00799 for ; Tue, 25 Nov 2003 13:30:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOhxE-0002ST-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 13:30:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOhxE-0002SQ-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 13:30:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhwp-0005tN-Nm; Tue, 25 Nov 2003 13:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOhwa-0005se-AW for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 13:29:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00759 for ; Tue, 25 Nov 2003 13:29:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOhwY-0002S2-00 for ipv6@ietf.org; Tue, 25 Nov 2003 13:29:46 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AOhwX-0002Rp-00 for ipv6@ietf.org; Tue, 25 Nov 2003 13:29:45 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 10:29:18 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 10:29:15 -0800 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); Tue, 25 Nov 2003 10:29:31 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 10:29:12 -0800 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.3790.1069); Tue, 25 Nov 2003 10:29:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "ROUTERS" vs. "routers" Date: Tue, 25 Nov 2003 10:29:49 -0800 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzazPJCDZlhkKaSeCEmivAXw8UMgAFmrhw From: "Christian Huitema" To: "Havard Eidnes" , Cc: , , X-OriginalArrivalTime: 25 Nov 2003 18:29:11.0938 (UTC) FILETIME=[05B51620:01C3B382] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > The distinction between routers and hosts and the criteria to separate > between them is one which I perceive as having been well established > in Internet technology for a Long Time. Well, how do you qualify a PC running a software component like Microsoft's "Internet Connection Sharing"? It appears as a host to the ISP, and acts as a router for the local network. That software has been available since at least 1998.=20 But never mind PC. How do you qualify a home NAT that appears as a host to the ISP, get an IPv4 address using DHCP, and then appears as a router to the local network? There are millions of these. So what exactly is "well established"? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 14:02:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02303 for ; Tue, 25 Nov 2003 14:02:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiRW-0008CM-JZ for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 14:01:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJ1kJF031508 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 14:01:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiRW-0008C7-D9 for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02256 for ; Tue, 25 Nov 2003 14:01:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiRT-00031M-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 14:01:44 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOiN0-0002tP-01 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 13:57:06 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOiDY-0004t9-Rf for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 13:47:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiDG-000750-C6; Tue, 25 Nov 2003 13:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiCR-00074D-3L for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 13:46:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01466 for ; Tue, 25 Nov 2003 13:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiCO-0002hc-00 for ipv6@ietf.org; Tue, 25 Nov 2003 13:46:08 -0500 Received: from smistad.uninett.no ([158.38.62.77]) by ietf-mx with esmtp (Exim 4.12) id 1AOiCO-0002hE-00 for ipv6@ietf.org; Tue, 25 Nov 2003 13:46:08 -0500 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 643A220F32; Tue, 25 Nov 2003 19:45:37 +0100 (CET) Date: Tue, 25 Nov 2003 19:45:36 +0100 (CET) Message-Id: <20031125.194536.114541470.he@uninett.no> To: huitema@windows.microsoft.com Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I'm sure you'll excuse my naivete, but at least to my mind, a box performing packet forwarding service between different interfaces (be they logical or physical) to carry traffic where it itself is not an endpoint, makes a box fall into the general category of "a router". How it gets it's address(es), or whether it additionally performs NAT or NAT-PT functions shouldn't make a huge difference with respect to whether it is characterized as a "host" or a "router". Regards, - H=E5vard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 14:02:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02333 for ; Tue, 25 Nov 2003 14:02:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiRZ-0008D7-8J for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 14:01:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJ1nQO031555 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 14:01:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiRZ-0008Cs-3E for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:01:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02270 for ; Tue, 25 Nov 2003 14:01:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiRW-00032t-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 14:01:46 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOiN0-0002tP-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 13:57:06 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOiEL-0004td-MZ for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 13:48:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiEE-0007PU-9C; Tue, 25 Nov 2003 13:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiDq-0007OZ-EB for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 13:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01499 for ; Tue, 25 Nov 2003 13:47:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiDo-0002kN-00 for ipv6@ietf.org; Tue, 25 Nov 2003 13:47:36 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AOiDn-0002kE-00 for ipv6@ietf.org; Tue, 25 Nov 2003 13:47:35 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AOiDg-00062P-00; Tue, 25 Nov 2003 18:47:28 +0000 Date: Tue, 25 Nov 2003 18:47:28 +0000 To: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Message-ID: <20031125184728.GA23008@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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Christian Huitema wrote: >But never mind PC. How do you qualify a home NAT that appears as a host >to the ISP, get an IPv4 address using DHCP, and then appears as a router >to the local network? The NAT divides the network into two areas, the difference between them being that certain things look different when seen from points of view in the two areas. One of the things that differs is whether the NAT box appears to be a router or a non-routing host. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 14:03:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02439 for ; Tue, 25 Nov 2003 14:03:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiSy-0008KL-Aw for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 14:03:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJ3GB7032003 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 14:03:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiSy-0008K6-4m for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:03:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02386 for ; Tue, 25 Nov 2003 14:03:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiSv-00035k-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 14:03:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOiSv-00035h-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 14:03:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiSj-0008Fw-NE; Tue, 25 Nov 2003 14:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiSN-0008FE-Hk for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 14:02:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02363 for ; Tue, 25 Nov 2003 14:02:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiSL-00034q-00 for ipv6@ietf.org; Tue, 25 Nov 2003 14:02:37 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AOiSK-00034I-00 for ipv6@ietf.org; Tue, 25 Nov 2003 14:02:36 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 11:02:00 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 11:02:05 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 11:02:05 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 11:02:03 -0800 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.3790.1069); Tue, 25 Nov 2003 11:02:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "ROUTERS" vs. "routers" Date: Tue, 25 Nov 2003 11:02:40 -0800 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzhFkcsUAuLZ6DS4i4FlI6gw3ckwAAcxOQ From: "Christian Huitema" To: "Havard Eidnes" Cc: , X-OriginalArrivalTime: 25 Nov 2003 19:02:05.0848 (UTC) FILETIME=[9E3FD980:01C3B386] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I'm sure you'll excuse my naivete, but at least to my mind, a box > performing packet forwarding service between different interfaces (be > they logical or physical) to carry traffic where it itself is not an > endpoint, makes a box fall into the general category of "a router". Sure. That is the definition. "If it forwards packets, it is a router." The problem occurs when one tries to legislate what boxes can and cannot do on the basis of some categorization. Operational constraints derive from operational environments. Different environment have different constraints. We should not legislate constraints into the protocol specification. -- Christian Huitema=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 17:15:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13936 for ; Tue, 25 Nov 2003 17:15:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlTA-0005Sg-Eq for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 17:15:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMFeFd020985 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 17:15:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlTA-0005SO-85 for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 17:15:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13849 for ; Tue, 25 Nov 2003 17:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlT7-0000Mr-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 17:15:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOlT7-0000Mn-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 17:15:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlSa-0005IA-WE; Tue, 25 Nov 2003 17:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlSL-0005H1-9I for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 17:14:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13796 for ; Tue, 25 Nov 2003 17:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlSI-0000Kl-00 for ipv6@ietf.org; Tue, 25 Nov 2003 17:14:46 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AOlSI-0000Kh-00 for ipv6@ietf.org; Tue, 25 Nov 2003 17:14:46 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id BEF468B; Wed, 26 Nov 2003 07:14:41 +0900 (JST) To: huitema@windows.microsoft.com Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: RE: "ROUTERS" vs. "routers" In-Reply-To: Your message of "Tue, 25 Nov 2003 10:29:49 -0800" References: X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031125221441.BEF468B@coconut.itojun.org> Date: Wed, 26 Nov 2003 07:14:41 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , not sure on which mailing list we should continue this discussion. > > The distinction between routers and hosts and the criteria to separate > > between them is one which I perceive as having been well established > > in Internet technology for a Long Time. > > Well, how do you qualify a PC running a software component like > Microsoft's "Internet Connection Sharing"? It appears as a host to the > ISP, and acts as a router for the local network. That software has been > available since at least 1998. i guess you are using "host" to mean "being able to make TCP connection" here. "host" in IPv6 spec refers to forwarding functionality, so XP with Internet Code Sharing would be a "router" under IPv6 terminology. it is not unusual for a router (device that foward packet) be able to make outgoing TCP connection. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 17:58:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15593 for ; Tue, 25 Nov 2003 17:58:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOm80-0000NS-6F for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 17:57:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMvqeO001449 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 17:57:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOm80-0000NH-0H for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 17:57:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15573 for ; Tue, 25 Nov 2003 17:57:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOm7x-0001Oe-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 17:57:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOm7w-0001Nr-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 17:57:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOm7B-00008e-Fu; Tue, 25 Nov 2003 17:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlx1-00081p-Ak for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 17:46:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15042 for ; Tue, 25 Nov 2003 17:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlwy-00016G-00 for ipv6@ietf.org; Tue, 25 Nov 2003 17:46:28 -0500 Received: from lowellg.ne.client2.attbi.com ([66.30.200.37] helo=be-well.no-ip.com) by ietf-mx with esmtp (Exim 4.12) id 1AOlwy-00016C-00 for ipv6@ietf.org; Tue, 25 Nov 2003 17:46:28 -0500 Received: by be-well.no-ip.com (Postfix, from userid 1147) id ECDD96D; Tue, 25 Nov 2003 17:46:27 -0500 (EST) Resent-To: ipv6@ietf.org Resent-From: Lowell Gilbert Resent-Date: 25 Nov 2003 17:46:27 -0500 X-From-Line: nobody Tue Nov 25 17:36:53 2003 To: ipng@sunroof.eng.sun.com Subject: Re: "ROUTERS" vs. "routers" References: <20031125184728.GA23008@fysh.org> From: Lowell Gilbert Date: 25 Nov 2003 17:36:52 -0500 In-Reply-To: <20031125184728.GA23008@fysh.org> Message-ID: <44oev0qdmj.fsf@be-well.ilk.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 11 Resent-Message-Id: <20031125224627.ECDD96D@be-well.no-ip.com> Resent-Date: Tue, 25 Nov 2003 17:46:28 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Zefram writes: > The NAT divides the network into two areas, the difference between them > being that certain things look different when seen from points of view > in the two areas. One of the things that differs is whether the NAT > box appears to be a router or a non-routing host. That's a really good way of looking at it, and allows for an "as-if" rule *requiring* that the NAT "look like" a router on the appropriate network and *not* "look like" a router on the other... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 18:09:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16587 for ; Tue, 25 Nov 2003 18:09:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmIu-000173-4z for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 18:09:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPN983q004271 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 18:09:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmIt-00016o-Tl for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 18:09:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16514 for ; Tue, 25 Nov 2003 18:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOmIr-0001gz-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 18:09:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOmIq-0001gw-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 18:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmIn-000135-5g; Tue, 25 Nov 2003 18:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmHq-0000z9-MD for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 18:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16401 for ; Tue, 25 Nov 2003 18:07:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOmHn-0001fZ-00 for ipv6@ietf.org; Tue, 25 Nov 2003 18:07:59 -0500 Received: from mx2sophos.cqu.edu.au ([138.77.5.126]) by ietf-mx with esmtp (Exim 4.12) id 1AOmHn-0001fV-00 for ipv6@ietf.org; Tue, 25 Nov 2003 18:07:59 -0500 Received: from proton.staff.ad.cqu.edu.au ([138.77.34.41] helo=ROKEMAIL.staff.ad.cqu.edu.au) by mx2sophos.cqu.edu.au with esmtp (Exim 4.22) id 1AOmHi-0005mz-5U; Wed, 26 Nov 2003 09:07:54 +1000 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" Content-Transfer-Encoding: quoted-printable Subject: RE: "ROUTERS" vs. "routers" Date: Wed, 26 Nov 2003 09:03:18 +1000 Message-ID: Thread-Topic: "ROUTERS" vs. "routers" Thread-Index: AcOzayQ2fJJeIPhvQPmbwYygA1zSrgAPBgyw From: "Amoakoh Gyasi-Agyei" To: "Havard Eidnes" , Cc: , , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Havard; I may have to accept that I do share your feelings as I think there's = more than enough confusion with the terminologies used in the IT&T = industry at the moment. There are many possible letter combinations in = the English alphabet alone, so why can't we please use terminologies = freed of ambiguities? I already perceive a confusion with the usage of = the words "router", "switch" and "hub", etc. by some authors. Cheers, AGA -----Original Message----- From: Havard Eidnes [mailto:he@uninett.no]=20 Sent: Wednesday, 26 November 2003 1:43 AM To: pthubert@cisco.com Cc: ftemplin@iprg.nokia.com; ipv6@ietf.org; v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Hm, maybe I was unclear -- let me try to clarify. The distinction between routers and hosts and the criteria to separate = between them is one which I perceive as having been well established in = Internet technology for a Long Time. I think we should think twice = before obfuscating this distinction, or try to sneak in something which = is claimed to be somewhere between them. I'm therefore reacting negatively to the attempt at abusing the "router" = term by introducing new and subtle meaning with a distinction between = "ROUTER" and "router". Choose a different word if you insist on = pursuing this, please! I've heard in other discussions the distinction between hosts = implementing a "strong" versus a "weak" model, typically used as a = distinguishing additional criteria when hosts are attached to multiple = networks and/or have multiple addresses. However, my local RFC = repository does not have any mention of that term. I wonder if this = direction is something which could be pursued. Regards, - H=E5vard -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 21:52:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22650 for ; Tue, 25 Nov 2003 21:52:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOpnG-0002p4-IK for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 21:52:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ2qgmp010850 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 21:52:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOpnG-0002ov-8p for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 21:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22626 for ; Tue, 25 Nov 2003 21:52:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOpnD-0005Jk-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 21:52:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOpnC-0005Jh-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 21:52:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOpmc-0002jL-MR; Tue, 25 Nov 2003 21:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOpmM-0002iw-FX for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 21:51:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22609 for ; Tue, 25 Nov 2003 21:51:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOpmJ-0005JG-00 for ipv6@ietf.org; Tue, 25 Nov 2003 21:51:43 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1AOpmI-0005JB-00 for ipv6@ietf.org; Tue, 25 Nov 2003 21:51:42 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id 2C3CD1C00CDF for ; Tue, 25 Nov 2003 21:51:36 -0500 (EST) Received: from india.hp.com (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id IAA00389 for ; Wed, 26 Nov 2003 08:20:17 +0530 (IST) Message-ID: <3FC41529.4030005@india.hp.com> Date: Wed, 26 Nov 2003 08:21:21 +0530 From: Vijayabhaskar A K User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: [Fwd: I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] Content-Type: multipart/mixed; boundary="------------090702060808090306030208" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------090702060808090306030208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The related drafts are: http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mcast-reconf-00.txt http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt Please go through these three drafts and let me know your comments Vijay -- __________________________________________________________ Vijayabhaskar A K Phone : +91-80-2053085 Hewlett Packard Mobile: +91-9845241382 29 Cunningham Road Telnet: 847-3085 Bangalore 52 Email : vijayak@india.hp.com Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. __________________________________________________________ --------------090702060808090306030208 Content-Type: message/rfc822; name="I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt" Received: from fakir.india.hp.com (root@fakir.india.hp.com [15.10.40.3]) by iconsrv5.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id CAA08700; Wed, 26 Nov 2003 02:37:33 +0530 (IST) Received: from palrel12.hp.com (palrel12.hp.com [15.81.176.20]) by fakir.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id CAA03773; Wed, 26 Nov 2003 02:53:16 +0530 (IST) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by palrel12.hp.com (Postfix) with ESMTP id BBBFD1C0056F; Tue, 25 Nov 2003 13:08:43 -0800 (PST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AOjlZ-0007jy-DR for ietf-announce-list@asgard.ietf.org; Tue, 25 Nov 2003 15:26:33 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AOjkw-0007ge-8K for all-ietf@asgard.ietf.org; Tue, 25 Nov 2003 15:25:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07610 for ; Tue, 25 Nov 2003 15:25:40 -0500 (EST) Message-Id: <200311252025.PAA07610@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt Date: Tue, 25 Nov 2003 15:25:40 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ND Support to trigger the nodes refresh the other configuration Author(s) : a. Vijayabhaskar Filename : draft-vijay-ipv6-icmp-refresh-otherconf-00.txt Pages : 7 Date : 2003-11-25 Neighbor Discovery for IPv6 [RFC2461] provides a way by which the nodes can determine whether to use administered protocol for address autoconfiguration and other non-address information through M and O bits in the Router Advertisements. Though RAs can notify nodes of a change in the address prefixes, currently there is no way the nodes can learn that there is a change in the non-address configuration parameters. This will make the nodes unable to learn about new or changed configuration parameters like DNS server addresses. This specification extends the Neighbor Discovery protocol [RFC2461] to notify the nodes that the other information obtained through an administered protocol has been changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-ipv6-icmp-refresh-otherconf-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-vijay-ipv6-icmp-refresh-otherconf-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-vijay-ipv6-icmp-refresh-otherconf-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-11-25151852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vijay-ipv6-icmp-refresh-otherconf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-vijay-ipv6-icmp-refresh-otherconf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-25151852.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------090702060808090306030208-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 25 22:13:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23366 for ; Tue, 25 Nov 2003 22:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOq78-0004W2-Hy for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 22:13:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ3DELG017352 for ipv6-archive@odin.ietf.org; Tue, 25 Nov 2003 22:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOq78-0004Vn-Bl for ipv6-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 22:13:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23319 for ; Tue, 25 Nov 2003 22:12:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOq75-0005bU-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 22:13:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOq74-0005bR-00 for ipv6-web-archive@ietf.org; Tue, 25 Nov 2003 22:13:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOq6v-0004RW-R3; Tue, 25 Nov 2003 22:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOq6g-0004RC-Gm for ipv6@optimus.ietf.org; Tue, 25 Nov 2003 22:12:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23315 for ; Tue, 25 Nov 2003 22:12:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOq6d-0005b8-00 for ipv6@ietf.org; Tue, 25 Nov 2003 22:12:43 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=killjoy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AOq6c-0005b2-00 for ipv6@ietf.org; Tue, 25 Nov 2003 22:12:42 -0500 Received: by killjoy.zoic.org (Postfix, from userid 1000) id 07CECCB1FE0; Wed, 26 Nov 2003 14:12:13 +1100 (EST) Date: Wed, 26 Nov 2003 14:12:12 +1100 From: "Nick 'Sharkey' Moore" To: Fred Templin Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Message-ID: <20031126031212.GA4317@zoic.org> References: <3FC2B319.9080707@iprg.nokia.com> <20031125020315.7A6958B@coconut.itojun.org> <3FC3614F.8080100@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC3614F.8080100@iprg.nokia.com> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On 2003-11-25, Fred Templin wrote: > > RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS"). > "ROUTERS" typically advertise autoconfig parameters and prefixes from > their attached networks. Hosts use them to reach off-link nodes via default > or more-specific routes. But, a new breed of routers (i.e., "routers") is > emerging from paradigms such as Mobile Ad-hoc Networks. "routers" > typically advertise host routes only (aka, "addresses" or "locators") and > no prefix or autoconfig parameters at all. > [...] > In the MANET paradigm, "routers" often have only a single network > interface which may be used for multi-hop forwarding [...] Firstly, I don't think differentiating 'router' and 'ROUTER' is a good idea. I for one would find it hard to follow in conversation :-) I think the usual definition of Router is a good one -- a Router is a node which forwards packets. It seems to me that the confusion is not in the definition of Router, but in the definitions of 'Interface', 'Link' and 'Network', which don't generally take wireless into account. -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 00:45:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26236 for ; Wed, 26 Nov 2003 00:45:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOsUa-0001Q4-Hn for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 00:45:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ5jacS005457 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 00:45:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOsUa-0001Pw-94 for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 00:45:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26207 for ; Wed, 26 Nov 2003 00:45:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOsUX-00072a-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 00:45:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOsUX-00072X-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 00:45:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOsU1-0001Jo-Sd; Wed, 26 Nov 2003 00:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOsTm-0001JG-AC for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 00:44:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26170 for ; Wed, 26 Nov 2003 00:44:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOsTj-00071c-00 for ipv6@ietf.org; Wed, 26 Nov 2003 00:44:43 -0500 Received: from 227.cust7.nsw.dsl.ozemail.com.au ([203.102.234.227] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AOsTi-00071G-00 for ipv6@ietf.org; Wed, 26 Nov 2003 00:44:43 -0500 Received: from Dupy2.nosense.org (227.cust7.nsw.dsl.ozemail.com.au [203.102.234.227]) by nosense.org (Postfix) with SMTP id 307DB3F07B; Wed, 26 Nov 2003 16:15:25 +1030 (CST) Date: Wed, 26 Nov 2003 16:15:24 +1030 From: Mark Smith To: "Pascal Thubert (pthubert)" Cc: he@uninett.no, ftemplin@iprg.nokia.com, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: "ROUTERS" vs. "routers" Message-Id: <20031126161524.2402f1b3.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: References: Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 25 Nov 2003 15:22:43 -0000 "Pascal Thubert (pthubert)" wrote: > - A PC with multiple Network addressable entities such as storage media I had the maybe not so strange idea a while back of having all components within a PC have an IPv6 address, or at least represented within the OS by an IPv6 eg keyboard, mouse, HDD etc. I'm not necessarily suggesting that inter-device communication occurs over TCP or UDP though. Just IPv6 addresses for management, and possibly other uses that I haven't thought of. You could then do tricks such as if the user complains that their HDD has stopped working, you could ping it over the network. Or have SNMP agents issue traps when eg. the keyboard stops working. I don't know whether this model would make the PC a router, or just that the PC's interface to the network acts as a proxy for all the device's "internal" IPv6 addresses, performing things such as DAD on their behalf. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 01:25:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27273 for ; Wed, 26 Nov 2003 01:25:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOt6v-0003Go-3n for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 01:25:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ6PD8B012564 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 01:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOt6u-0003GZ-W4 for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 01:25:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27244 for ; Wed, 26 Nov 2003 01:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOt6s-0007a8-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 01:25:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOt6r-0007a5-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 01:25:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOt6l-0003Cv-Q8; Wed, 26 Nov 2003 01:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOt67-0003CM-9F for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 01:24:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27236 for ; Wed, 26 Nov 2003 01:24:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOt64-0007Zu-00 for ipv6@ietf.org; Wed, 26 Nov 2003 01:24:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOt63-0007ZY-00 for ipv6@ietf.org; Wed, 26 Nov 2003 01:24:19 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQ6NoM00907; Wed, 26 Nov 2003 08:23:50 +0200 Date: Wed, 26 Nov 2003 08:23:50 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org cc: v6ops@ops.ietf.org Subject: Stop "ROUTERS" vs "routers" discussion in v6ops [RE: "ROUTERS" vs. "routers"] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id hAQ6NoM00907 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi everybody, Now that we've opened the particular can of worms, it's time to close=20 it again. Let's not get into a too heated debate on what we call=20 IPv6 routers; we have more pressing matters to discuss. Please don't continue the discussion of "ROUTERS" vs "routers" on=20 v6ops mailing list. It doesn't seem to be relevant here, at least=20 anymore. Thanks, Pekka writing as v6ops co-chair On Wed, 26 Nov 2003, Amoakoh Gyasi-Agyei wrote: > Dear Havard; >=20 > I may have to accept that I do share your feelings as I think > there's more than enough confusion with the terminologies used in > the IT&T industry at the moment. There are many possible letter > combinations in the English alphabet alone, so why can't we please > use terminologies freed of ambiguities? I already perceive a > confusion with the usage of the words "router", "switch" and "hub", > etc. by some authors. >=20 > Cheers, > AGA >=20 > -----Original Message----- > From: Havard Eidnes [mailto:he@uninett.no]=20 > Sent: Wednesday, 26 November 2003 1:43 AM > To: pthubert@cisco.com > Cc: ftemplin@iprg.nokia.com; ipv6@ietf.org; v6ops@ops.ietf.org > Subject: Re: "ROUTERS" vs. "routers" >=20 >=20 > Hm, >=20 > maybe I was unclear -- let me try to clarify. >=20 > The distinction between routers and hosts and the criteria to separate = between them is one which I perceive as having been well established in I= nternet technology for a Long Time. I think we should think twice before= obfuscating this distinction, or try to sneak in something which is clai= med to be somewhere between them. >=20 > I'm therefore reacting negatively to the attempt at abusing the "router= " term by introducing new and subtle meaning with a distinction between "= ROUTER" and "router". Choose a different word if you insist on pursuing = this, please! >=20 > I've heard in other discussions the distinction between hosts implement= ing a "strong" versus a "weak" model, typically used as a distinguishing = additional criteria when hosts are attached to multiple networks and/or h= ave multiple addresses. However, my local RFC repository does not have a= ny mention of that term. I wonder if this direction is something which c= ould be pursued. >=20 > Regards, >=20 > - H=E5vard >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --=20 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 05:28:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01228 for ; Wed, 26 Nov 2003 05:28:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwtg-0000tx-Mj for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 05:27:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQARmlj003464 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 05:27:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwtg-0000tn-HJ for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 05:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01194 for ; Wed, 26 Nov 2003 05:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOwtd-0003AV-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 05:27:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOwtc-0003AS-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 05:27:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwsw-0000pw-Go; Wed, 26 Nov 2003 05:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOwsu-0000pY-P9 for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 05:27:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01176 for ; Wed, 26 Nov 2003 05:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOwsr-00039o-00 for ipv6@ietf.org; Wed, 26 Nov 2003 05:26:57 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOwsq-00039Y-00 for ipv6@ietf.org; Wed, 26 Nov 2003 05:26:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQAQ9t06169; Wed, 26 Nov 2003 12:26:09 +0200 Date: Wed, 26 Nov 2003 12:26:08 +0200 (EET) From: Pekka Savola To: "Nick 'Sharkey' Moore" cc: Fred Templin , Subject: Re: "ROUTERS" vs. "routers" In-Reply-To: <20031126031212.GA4317@zoic.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , (Tai out v6ops list..) On Wed, 26 Nov 2003, Nick 'Sharkey' Moore wrote: > On 2003-11-25, Fred Templin wrote: > > > > RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS"). > > "ROUTERS" typically advertise autoconfig parameters and prefixes from > > their attached networks. Hosts use them to reach off-link nodes via default > > or more-specific routes. But, a new breed of routers (i.e., "routers") is > > emerging from paradigms such as Mobile Ad-hoc Networks. "routers" > > typically advertise host routes only (aka, "addresses" or "locators") and > > no prefix or autoconfig parameters at all. > > [...] > > In the MANET paradigm, "routers" often have only a single network > > interface which may be used for multi-hop forwarding [...] > > Firstly, I don't think differentiating 'router' and 'ROUTER' is > a good idea. I for one would find it hard to follow in conversation :-) > > I think the usual definition of Router is a good one -- a Router > is a node which forwards packets. > > It seems to me that the confusion is not in the definition of > Router, but in the definitions of 'Interface', 'Link' and 'Network', > which don't generally take wireless into account. I agree with this view, it's no use trying to overload two different meanings for a router depending on capitalization. I don't think it matters at all whether a router has just one interface or many, or what it advertises or not, or whether it pretends to be a host on one interface, or originates UDP/TCP packets, or whatever. It's still a router. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 07:34:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04510 for ; Wed, 26 Nov 2003 07:34:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOysG-000756-Mb for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 07:34:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQCYSVB027214 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 07:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOysG-00074r-Gw for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 07:34:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04410 for ; Wed, 26 Nov 2003 07:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOysF-0004iS-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 07:34:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOysF-0004iP-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 07:34:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOyrq-0006wl-7u; Wed, 26 Nov 2003 07:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOyqw-0006iR-Rg for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 07:33:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04356 for ; Wed, 26 Nov 2003 07:32:54 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOyqw-0004gu-00 for ipv6@ietf.org; Wed, 26 Nov 2003 07:33:06 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AOyqv-0004ga-00 for ipv6@ietf.org; Wed, 26 Nov 2003 07:33:05 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 12:32:33 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 12:32:32 +0000 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Fwd: I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] Date: Wed, 26 Nov 2003 12:32:07 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7003EFEB40@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [Fwd: I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] Thread-Index: AcOzyGvKbUoxZsp4RrCb9s8tWh6MbAAUMzvw To: Cc: X-OriginalArrivalTime: 26 Nov 2003 12:32:32.0794 (UTC) FILETIME=[5D3C97A0:01C3B419] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Vijay, > -----Original Message----- > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]=20 > Sent: 26 November 2003 02:51 > To: ipv6@ietf.org > Subject: [Fwd: I-D=20 > ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] >=20 > The related drafts are: >=20 > http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mca > st-reconf-00.txt As I already stated on the dhc WG list, I don't believe that extensions to ND are the way to go here. This is a host configuration problem, and DHCPv6 extensions are in the works that solve it. Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 08:07:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05609 for ; Wed, 26 Nov 2003 08:07:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzNv-0000VG-PN for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 08:07:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQD7BhQ001928 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 08:07:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzNv-0000V1-3S for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 08:07:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05578 for ; Wed, 26 Nov 2003 08:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOzNt-0005DR-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 08:07:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOzNt-0005DO-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 08:07:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzNl-0000Qd-Op; Wed, 26 Nov 2003 08:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzN4-0000Ow-PI for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 08:06:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05550 for ; Wed, 26 Nov 2003 08:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOzN3-0005CH-00 for ipv6@ietf.org; Wed, 26 Nov 2003 08:06:17 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AOzN3-0005C4-00 for ipv6@ietf.org; Wed, 26 Nov 2003 08:06:17 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hAQD5v81020837; Wed, 26 Nov 2003 06:05:58 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hAQD65l8023655; Wed, 26 Nov 2003 07:06:07 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 551EB2EC95; Wed, 26 Nov 2003 14:06:06 +0100 (CET) Message-ID: <3FC4A53E.4060104@nal.motlabs.com> Date: Wed, 26 Nov 2003 14:06:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin Cc: Keith Moore , ipv6@ietf.org Subject: Re: names for non-global addresses References: <3FBEBC18.7020706@iprg.nokia.com> In-Reply-To: <3FBEBC18.7020706@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fred Templin wrote: > I'll take mnemonic power, but could do without the cuteness. How > about: > > IDEA - Independently-Delegated Endpoint Address IDEA is the name of a block cypher too, 128bit keylength, so don't talk to CGA people about IDEA addresses because there might be confusions :-) Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 10:06:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09838 for ; Wed, 26 Nov 2003 10:06:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1En-0000HD-Fy for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 10:05:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQF5rEp001057 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 10:05:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1Em-0000Gy-Rc for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 10:05:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09726 for ; Wed, 26 Nov 2003 10:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1Ek-0006o4-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 10:05:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP1Ek-0006o1-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 10:05:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1Dz-0000Bq-Gz; Wed, 26 Nov 2003 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtRW-0004ZU-28 for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 01:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27728 for ; Wed, 26 Nov 2003 01:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOtRS-000018-00 for ipv6@ietf.org; Wed, 26 Nov 2003 01:46:26 -0500 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wanderer.hardakers.net ident=[VkWegQfr56MVI/zvm/6nVLXaYviV2yPv]) by ietf-mx with esmtp (Exim 4.12) id 1AOtRS-000014-00 for ipv6@ietf.org; Wed, 26 Nov 2003 01:46:26 -0500 Received: by wanderer.hardakers.net (Postfix, from userid 274) id EEB4A574A9; Tue, 25 Nov 2003 22:46:07 -0800 (PST) To: ipv6@ietf.org Subject: comments on rfc2011 update From: Wes Hardaker Organization: Sparta User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) Date: Tue, 25 Nov 2003 22:46:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Unfortunately, I have just learned that I'd really need this update. I'll say this is unfortunate because the cutoff date for comment is tomorrow, and I haven't had a chance to read the document. However, a really really really quick scan produced a couple of comments. 1) The description field for the ipAddressEntry object is simply ridiculously short: "inet addr entry" 2) Was there every discussion about making this table writable? One of the most longstanding needs within MIBs has been the ability to assign addresses to interfaces. I will have to go back and search the mail archives to find out if this was ever discussed, but it would be pretty simple, I would think, to make this table writable. This is the obvious place to make support for settable addresses, so I'm curious as to why it wasn't done... -- Wes Hardaker Sparta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 12:46:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19100 for ; Wed, 26 Nov 2003 12:46:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3jn-0004Ad-MZ for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 12:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHk33L016025 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 12:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3jn-0004AM-Ci for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 12:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19056 for ; Wed, 26 Nov 2003 12:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3jl-0001r7-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 12:46:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP3jk-0001r4-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 12:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3iq-0003xO-EG; Wed, 26 Nov 2003 12:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3id-0003w8-7S for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 12:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19009 for ; Wed, 26 Nov 2003 12:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3ib-0001qW-00 for ipv6@ietf.org; Wed, 26 Nov 2003 12:44:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AP3ia-0001qA-00 for ipv6@ietf.org; Wed, 26 Nov 2003 12:44:49 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Nov 2003 09:46:03 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAQHiEjq013697; Wed, 26 Nov 2003 09:44:15 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.206]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEG90809; Wed, 26 Nov 2003 12:44:13 -0500 (EST) Message-Id: <4.3.2.7.2.20031125124734.01e1ad10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Nov 2003 13:43:17 -0500 To: Pekka Savola From: Ralph Droms Subject: Re: RFC2461bis issue: IANA considerations Cc: ipv6@ietf.org In-Reply-To: References: <4.3.2.7.2.20031125075153.01efbe80@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Comments in line... At 04:12 PM 11/25/2003 +0200, Pekka Savola wrote: >On Tue, 25 Nov 2003, Ralph Droms wrote: > > New DHCP option codes are tentatively assigned after the > > specification for the associated option, published as an Internet > > Draft, has received expert review by a designated expert [11]. The > > final assignment of DHCP option codes is through Standards Action, as > > defined in RFC 2434 [11]. > >What does "tentatively assigned" mean? What if the document doesn't >get produced in the end, because even though a designated expert is OK >with it, it is not useful in general? "Tentatively assigned" means it can be returned to the list of available option codes if no RFC is published. >I don't assume it would be possible to "reclaim" such tentatively >assigned numbers, at least easily. But not sure if someone has >thought this through? Reclaiming the numbers was difficult in DHCPv4, because the assignment at the time of a request to IANA, based solely on the existence of an Internet Draft, was considered permanent. The rules in DHCPv6 make clear that the assignment is tentative until the RFC is published, and the assignment may be revoked in the future. >IMHO, the proposal would place too high trust in just one expert >saying whether this seems OK or not. The bar needs to be higher, e.g. >IESG's decision, or maybe adopting the document as WG item, or >something like that. We tried to balance the delay in going through the entire IESG against the possibility that there is no WG to consider the assignment. Thus, we used the "designated expert" rule. We also used our experience with DHCPv4, where the rule is (now) to assign option codes at the time of Standards action. >(FWIW, draft-narten-ipv6-iana-considerations-00.txt proposes "IESG >Approval" or "Standards Action".) Oops, I missed draft-narten-ipv6-iana-considerations-00.txt. I assume IESG approval covers preliminary assignment prior to Standards action? That text sounds fine to me... - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 14:06:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21950 for ; Wed, 26 Nov 2003 14:06:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4ze-0000qr-TU for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 14:06:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQJ6U0O003272 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 14:06:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4ze-0000qh-Ox for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 14:06:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21928 for ; Wed, 26 Nov 2003 14:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4zc-0002vZ-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 14:06:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP4zc-0002vW-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 14:06:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4zB-0000l2-N8; Wed, 26 Nov 2003 14:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4yp-0000kb-E9 for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 14:05:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21904 for ; Wed, 26 Nov 2003 14:05:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4yl-0002ux-00 for ipv6@ietf.org; Wed, 26 Nov 2003 14:05:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AP4yk-0002uc-00 for ipv6@ietf.org; Wed, 26 Nov 2003 14:05:35 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAQJ4o808617; Wed, 26 Nov 2003 11:04:50 -0800 X-mProtect: <200311261904> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3XyKwc; Wed, 26 Nov 2003 11:04:49 PST Message-ID: <3FC4FB34.7050909@iprg.nokia.com> Date: Wed, 26 Nov 2003 11:12:52 -0800 From: Fred 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: Pekka Savola CC: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: routers - (was: Re: "ROUTERS" vs. "routers") References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As I said in my last message, my goal was to get a message out and not push new terminology. I agree with Pekka that it doesn't matter at all whether a router has just one interface or hundreds; it is still a router. (In fact, this is nearly the exact response I received when I asked a related question during an IPv6 session at IETF 58.) Hosts with embedded gateway functions, as described in RFC 1122, section 3.3.4.2 under: "Weak ES Model" also qaulify as routers, and it doesn't matter at all what different routers advertise - they are all still just *routers*. However, the message that must not be lost in the terminology shuffle is that it very much *does* matter that nodes be able to selectively solicit at least two different classes of information from routers: 1) Classical prefix/autoconfig information as specified in RFC 2461 2) Route Information Options as specified in: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt The two ways I see to do this are to either specify a new IPv6 ND option (call it a "Type II Router Solicitation" for lack of a better name) or to add bits to the existing IPv6 Router Soliciation message (e.g., in the "Reserved" field) that indicate the type of information being solicited. What does the wg feel is the best way to move forward with this? Thanks - Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >I agree with this view, it's no use trying to overload two different >meanings for a router depending on capitalization. > >I don't think it matters at all whether a router has just one >interface or many, or what it advertises or not, or whether it >pretends to be a host on one interface, or originates UDP/TCP packets, >or whatever. It's still a router. > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 14:49:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24199 for ; Wed, 26 Nov 2003 14:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ey-0004X3-T7 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 14:49:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQJnC5R017415 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 14:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5ey-0004Wo-OC for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 14:49:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24164 for ; Wed, 26 Nov 2003 14:48:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5ev-0003jc-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 14:49:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP5ev-0003jZ-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 14:49:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5en-0004R5-VQ; Wed, 26 Nov 2003 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5dx-0004Qf-7k for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 14:48:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24152 for ; Wed, 26 Nov 2003 14:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5du-0003jN-00 for ipv6@ietf.org; Wed, 26 Nov 2003 14:48:06 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5dt-0003is-00 for ipv6@ietf.org; Wed, 26 Nov 2003 14:48:05 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQJl5I17214; Wed, 26 Nov 2003 21:47:05 +0200 Date: Wed, 26 Nov 2003 21:47:05 +0200 (EET) From: Pekka Savola To: Fred Templin cc: "Nick 'Sharkey' Moore" , Subject: Re: routers - (was: Re: "ROUTERS" vs. "routers") In-Reply-To: <3FC4FB34.7050909@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 26 Nov 2003, Fred Templin wrote: > However, the message that must not be lost in the terminology shuffle > is that it very much *does* matter that nodes be able to selectively > solicit at least two different classes of information from routers: > > 1) Classical prefix/autoconfig information as specified in RFC 2461 > 2) Route Information Options as specified in: > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt > > The two ways I see to do this are to either specify a new IPv6 ND > option (call it a "Type II Router Solicitation" for lack of a better > name) or to add bits to the existing IPv6 Router Soliciation message > (e.g., in the "Reserved" field) that indicate the type of > information being solicited. I do not see the issue you describe. You can solicit exactly this kind of information from any node you wish, right? Naturally, the hosts won't answer; some routers might not either (e.g., if they aren't configured to advertise such information) -- but that's not really relevant -- anyone can elect to be silent if they wish! Are you suggesting that all routers be somehow "forced" to return this kind of information (when asked explicitly in some defined manner) whether they advertise it or not? That probably would not fly. Or are you suggesting that routers should be able to advertise (or tell, when asked explicitly) about the information they know about prefixes/autoconfig/routes, without the hosts implying they would act as a default router as well? Not sure I'd see a point for something like that.. If you meant something else, I didn't understand .. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 15:07:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24982 for ; Wed, 26 Nov 2003 15:07:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5wf-0005Em-FN for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 15:07:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQK7Tii020126 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 15:07:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5wf-0005EX-60 for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 15:07:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24905 for ; Wed, 26 Nov 2003 15:07:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5wc-0003tZ-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 15:07:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP5wb-0003tW-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 15:07:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5wD-00054U-M6; Wed, 26 Nov 2003 15:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP5vm-00053f-CA for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 15:06:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24809 for ; Wed, 26 Nov 2003 15:06:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5vj-0003t0-00 for ipv6@ietf.org; Wed, 26 Nov 2003 15:06:31 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AP5vh-0003sj-00 for ipv6@ietf.org; Wed, 26 Nov 2003 15:06:30 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAQK5iT02632; Wed, 26 Nov 2003 12:05:44 -0800 X-mProtect: <200311262005> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdROv78o; Wed, 26 Nov 2003 12:05:43 PST Message-ID: <3FC5097B.6090304@iprg.nokia.com> Date: Wed, 26 Nov 2003 12:13:47 -0800 From: Fred 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: Pekka Savola CC: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: routers - (was: Re: "ROUTERS" vs. "routers") References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, I meant only what I said - nodes should be able to selectively solicit at least two different classes of information from routers. (Perhaps there will be even more classes of information in the future; I don't know). Some routers might advertise only prefix/autoconfig information, so they might not respond to the "Type II Router Solicitation" I alluded to below. Other routers might advertise only route information, so they might not respond to an ordinary IPv6 Router Solicitation. Still other routers might advertise both classes of information, so they might happily respond to either type of solicitation. I'm not necessarily trying to write the MAY/SHOULD/MUSTs here; I'm simply identifying the need and soliciting input from the wg; thanks for providing yours. Fred ftempling@iprg.nokia.com Pekka Savola wrote: >On Wed, 26 Nov 2003, Fred Templin wrote: > > >>However, the message that must not be lost in the terminology shuffle >>is that it very much *does* matter that nodes be able to selectively >>solicit at least two different classes of information from routers: >> >> 1) Classical prefix/autoconfig information as specified in RFC 2461 >> 2) Route Information Options as specified in: >> >>http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt >> >>The two ways I see to do this are to either specify a new IPv6 ND >>option (call it a "Type II Router Solicitation" for lack of a better >>name) or to add bits to the existing IPv6 Router Soliciation message >>(e.g., in the "Reserved" field) that indicate the type of >>information being solicited. >> >> > >I do not see the issue you describe. You can solicit exactly this >kind of information from any node you wish, right? > >Naturally, the hosts won't answer; some routers might not either >(e.g., if they aren't configured to advertise such information) -- but >that's not really relevant -- anyone can elect to be silent if they >wish! > >Are you suggesting that all routers be somehow "forced" to return this >kind of information (when asked explicitly in some defined manner) >whether they advertise it or not? > >That probably would not fly. > >Or are you suggesting that routers should be able to advertise (or >tell, when asked explicitly) about the information they know about >prefixes/autoconfig/routes, without the hosts implying they would act >as a default router as well? Not sure I'd see a point for something >like that.. > >If you meant something else, I didn't understand .. > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 15:15:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25999 for ; Wed, 26 Nov 2003 15:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP641-00060v-QK for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 15:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQKF583023111 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 15:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP641-00060g-I7 for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 15:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25913 for ; Wed, 26 Nov 2003 15:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP640-00043q-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 15:15:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP63z-00043n-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 15:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP63y-0005ub-8p; Wed, 26 Nov 2003 15:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP63b-0005tr-JM for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 15:14:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25857 for ; Wed, 26 Nov 2003 15:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP63a-000431-00 for ipv6@ietf.org; Wed, 26 Nov 2003 15:14:38 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP63Z-00041v-00 for ipv6@ietf.org; Wed, 26 Nov 2003 15:14:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAQKDx417753; Wed, 26 Nov 2003 22:13:59 +0200 Date: Wed, 26 Nov 2003 22:13:59 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: ipv6@ietf.org Subject: Re: ICMPv6 ND option for more specific routes [Re: draft-ietf-ipv6-router-selection-02.txt issues list] In-Reply-To: <3FC36156.8000003@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 25 Nov 2003, Brian Haberman wrote: > There are two ways we could do this. One would be for the > doc authors to request a value from IANA. The other would be to > push draft-narten-iana-experimental-allocations-05.txt through > the process and utilize it for early testing/experimentation. I'd recommend the former; or failing that, WG chairs or the shepherding AD could do it, or solicit 'IESG Approval' for the number allocation. At this point, IMHO it's too late for the experimental allocations, but they will prove to be useful in the future. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 15:22:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26567 for ; Wed, 26 Nov 2003 15:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP6Aq-0006rX-ID for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 15:22:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQKM88p026373 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 15:22:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP6Aq-0006rI-Cy for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 15:22:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26533 for ; Wed, 26 Nov 2003 15:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP6Ap-0004EL-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 15:22:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP6Ao-0004EI-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 15:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP6Aj-0006lK-HH; Wed, 26 Nov 2003 15:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP69n-0006kS-Po for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 15:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26513 for ; Wed, 26 Nov 2003 15:20:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP69m-0004Dn-00 for ipv6@ietf.org; Wed, 26 Nov 2003 15:21:02 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx with esmtp (Exim 4.12) id 1AP69l-0004D4-00 for ipv6@ietf.org; Wed, 26 Nov 2003 15:21:02 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hAQKKUd6428056 for ; Wed, 26 Nov 2003 15:20:30 -0500 Received: from d01ml099.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAQKKTIV066220 for ; Wed, 26 Nov 2003 15:20:29 -0500 Subject: Nicholas Carbone/Poughkeepsie/IBM is out of the office. From: Nicholas Carbone To: ipv6@ietf.org Message-ID: Date: Wed, 26 Nov 2003 15:20:28 -0500 X-MIMETrack: Serialize by Router on D01ML099/01/M/IBM(Release 6.0.2CF2 IGS_HF9|October 28, 2003) at 11/26/2003 15:20:29 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , I will be out of the office starting November 26, 2003 and will not return until December 1, 2003. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 17:44:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01270 for ; Wed, 26 Nov 2003 17:44:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP8Oe-0007vS-Up for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 17:44:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQMiWcu030465 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 17:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP8Oe-0007vI-Q7 for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 17:44:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01225 for ; Wed, 26 Nov 2003 17:44:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP8Oc-00060G-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 17:44:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP8Ob-00060C-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 17:44:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP8OA-0007ph-BY; Wed, 26 Nov 2003 17:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP8NK-0007oj-Ac for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 17:43:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01180 for ; Wed, 26 Nov 2003 17:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP8NH-0005zI-00 for ipv6@ietf.org; Wed, 26 Nov 2003 17:43:07 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AP8NH-0005yk-00 for ipv6@ietf.org; Wed, 26 Nov 2003 17:43:07 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAQMgMN31936; Wed, 26 Nov 2003 14:42:22 -0800 X-mProtect: <200311262242> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfmo7Ht; Wed, 26 Nov 2003 14:42:21 PST Message-ID: <3FC52E31.8050008@iprg.nokia.com> Date: Wed, 26 Nov 2003 14:50:25 -0800 From: Fred 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: ipv6@ietf.org CC: crawdad@fnal.gov, ftemplin@iprg.nokia.com Subject: Re: routers - (was: Re: "ROUTERS" vs. "routers") References: <3FC4FB34.7050909@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fred Templin wrote: > The two ways I see to do this are to either specify a new IPv6 ND option > (call it a "Type II Router Solicitation" for lack of a better name) or > to add > bits to the existing IPv6 Router Soliciation message (e.g., in the > "Reserved" > field) that indicate the type of information being solicited. To respond to my own post, it just occurred to me there may be a least one other possibility (and probably countless others) to get the needed message types. Maybe we could hijack an unused ICMPv6 Type code from the IANA registries? A quick look at the 'icmpv6-parameters' registry shows: 138 Router Renumbering [Crawford] 139 ICMP Node Information Query [Crawford] 140 ICMP Node Information Response [Crawford] I see that the Router Renumbering option is used by RFC 2894, but does anyone know if the other options are used anywhere? If not, the "Node Information Query" would be a perfect fit for the "Type II Router Solicitation" I've been asking about, and the "Node Information Response" could be used to carry the Route Information Options needed by: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt instead of hacking the IPv6 Router Advertisment message format. Sounds like a win-win, doesn't it? Matt, can you comment as to the availability of the Type codes? Thanks - Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 19:40:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06567 for ; Wed, 26 Nov 2003 19:40:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APACp-0007Nw-Bx for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 19:40:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR0eR1t028382 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 19:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APACp-0007Nh-6w for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 19:40:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06540 for ; Wed, 26 Nov 2003 19:40:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APACn-0007kB-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 19:40:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APACn-0007k8-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 19:40:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APACS-0007Hw-1Z; Wed, 26 Nov 2003 19:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APACA-0007H8-Op for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 19:39:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06527 for ; Wed, 26 Nov 2003 19:39:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAC8-0007ji-00 for ipv6@ietf.org; Wed, 26 Nov 2003 19:39:45 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1APAC8-0007jd-00 for ipv6@ietf.org; Wed, 26 Nov 2003 19:39:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAR0dEO07082; Wed, 26 Nov 2003 16:39:14 -0800 X-mProtect: <200311270039> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd00dZeK; Wed, 26 Nov 2003 16:39:12 PST Message-ID: <3FC54995.1070703@iprg.nokia.com> Date: Wed, 26 Nov 2003 16:47:17 -0800 From: Fred 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: ipv6@ietf.org CC: Fred Templin , crawdad@fnal.gov Subject: Re: routers - (was: Re: "ROUTERS" vs. "routers") References: <3FC4FB34.7050909@iprg.nokia.com> <3FC52E31.8050008@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Responding one final time to my own post, I think we should forget this business about hijacking and just use Matt's document instead: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-10.txt It looks mature, well fleshed out, and has some nice features like references to interoperable implementations. I also wrote a document of my own that references Matt's work and posted it to the I-D registrar. You can find a copy in the interim at: http://www.geocities.com/osprey67/isnoid-01.txt Thanks - Fred ftemplin@iprg.nokia.com Fred Templin wrote: > > > Fred Templin wrote: > >> The two ways I see to do this are to either specify a new IPv6 ND option >> (call it a "Type II Router Solicitation" for lack of a better name) >> or to add >> bits to the existing IPv6 Router Soliciation message (e.g., in the >> "Reserved" >> field) that indicate the type of information being solicited. > > > > To respond to my own post, it just occurred to me there may be > a least one other possibility (and probably countless others) to > get the needed message types. Maybe we could hijack an unused > ICMPv6 Type code from the IANA registries? > > A quick look at the 'icmpv6-parameters' registry shows: > > 138 Router Renumbering [Crawford] > 139 ICMP Node Information Query [Crawford] > 140 ICMP Node Information Response [Crawford] > > I see that the Router Renumbering option is used by RFC 2894, > but does anyone know if the other options are used anywhere? > > If not, the "Node Information Query" would be a perfect fit > for the "Type II Router Solicitation" I've been asking about, > and the "Node Information Response" could be used to carry > the Route Information Options needed by: > > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt > > > instead of hacking the IPv6 Router Advertisment message format. > Sounds like a win-win, doesn't it? > > Matt, can you comment as to the availability of the Type codes? > > Thanks - Fred > ftemplin@iprg.nokia.com > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 19:58:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07239 for ; Wed, 26 Nov 2003 19:58:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAU5-00009h-Oh for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 19:58:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR0wHu6000591 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 19:58:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAU5-00009S-Hf for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 19:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07188 for ; Wed, 26 Nov 2003 19:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAU3-0000E0-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 19:58:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APAU3-0000Dx-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 19:58:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APATq-0008Qk-V7; Wed, 26 Nov 2003 19:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APATa-0008Pf-E2 for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 19:57:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07163 for ; Wed, 26 Nov 2003 19:57:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APATY-0000D1-00 for ipv6@ietf.org; Wed, 26 Nov 2003 19:57:44 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1APATX-0000CY-00 for ipv6@ietf.org; Wed, 26 Nov 2003 19:57:44 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HOZ00401JZC0Z@mailout2.samsung.com> for ipv6@ietf.org; Thu, 27 Nov 2003 09:57:13 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HOZ00AJ7JZC9Q@mailout2.samsung.com> for ipv6@ietf.org; Thu, 27 Nov 2003 09:57:12 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HOZ007D4JZCE8@mmp2.samsung.com> for ipv6@ietf.org; Thu, 27 Nov 2003 09:57:12 +0900 (KST) Date: Thu, 27 Nov 2003 09:57:42 +0900 From: Soohong Daniel Park Subject: RE: [Fwd: I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] In-reply-to: <3FC41529.4030005@india.hp.com> To: "'Vijayabhaskar A K'" , ipv6@ietf.org Cc: "'Soohong Daniel Park'" Message-id: <004901c3b481$761c8fb0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT um... for this operation, all nodes MUST be a DHCPv6 client when obtaining required information. At this case, current DHCPv6 operation * Reconfigure procedure * can be used for that without any new defined option... Am I missing something ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > Behalf Of Vijayabhaskar A K > Sent: Wednesday, November 26, 2003 11:51 AM > To: ipv6@ietf.org > Subject: [Fwd: I-D > ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] > > > The related drafts are: > > http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mca > st-reconf-00.txt > http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless- > dhcpv6-renumbering-00.txt > > Please go through these three drafts and let me know your comments > > Vijay > > > -- > __________________________________________________________ > Vijayabhaskar A K Phone : +91-80-2053085 > Hewlett Packard Mobile: +91-9845241382 > 29 Cunningham Road Telnet: 847-3085 > Bangalore 52 Email : vijayak@india.hp.com > > Until you have the courage to lose sight of the shore, > you will not know the terror of being forever lost at sea. > __________________________________________________________ > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 26 20:08:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07683 for ; Wed, 26 Nov 2003 20:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAdh-0001Ur-F6 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 20:08:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR18D95005743 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 20:08:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAdh-0001US-2F for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 20:08:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07645 for ; Wed, 26 Nov 2003 20:07:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAdf-0000P7-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 20:08:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APAde-0000P4-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 20:08:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAdW-0001JS-SW; Wed, 26 Nov 2003 20:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAck-00018w-6J for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 20:07:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07604 for ; Wed, 26 Nov 2003 20:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAch-0000OC-00 for ipv6@ietf.org; Wed, 26 Nov 2003 20:07:11 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1APAcb-0000NV-00 for ipv6@ietf.org; Wed, 26 Nov 2003 20:07:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAR16YC17276; Wed, 26 Nov 2003 17:06:34 -0800 X-mProtect: <200311270106> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd52mc8Y; Wed, 26 Nov 2003 17:06:32 PST Message-ID: <3FC54FFD.50001@iprg.nokia.com> Date: Wed, 26 Nov 2003 17:14:37 -0800 From: Fred 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: Matt Crawford CC: ipv6@ietf.org Subject: Re: routers - (was: Re: "ROUTERS" vs. "routers") References: <3FC4FB34.7050909@iprg.nokia.com> <3FC52E31.8050008@iprg.nokia.com> <10CD5932-2074-11D8-8D67-000A95A0BF96@fnal.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Matt, I'm going to give things a rest for awhile now and let the dust settle. Have a Happy Thanksgiving to those who celebrate it. Fred ftemplin@iprg.nokia.com Matt Crawford wrote: > On Nov 26, 2003, at 4:50 PM, Fred Templin wrote: > >> 139 ICMP Node Information Query [Crawford] >> 140 ICMP Node Information Response [Crawford] >> >> I see that the Router Renumbering option is used by RFC 2894, >> but does anyone know if the other options are used anywhere? >> [...] >> Matt, can you comment as to the availability of the Type codes? > > > There are multiple implementations of node informations queries (and > responses, of course). > > You could define new query types that might do what you want; I can't > comment on the fit of your application to this mechanism without doing > a lot of background reading. > > Matt Crawford > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 27 00:27:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13051 for ; Thu, 27 Nov 2003 00:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APEgU-00037H-RY for ipv6-archive@odin.ietf.org; Thu, 27 Nov 2003 00:27:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR5RMr0011973 for ipv6-archive@odin.ietf.org; Thu, 27 Nov 2003 00:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APEgU-000372-JK for ipv6-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 00:27:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13019 for ; Thu, 27 Nov 2003 00:27:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APEgS-0002yU-00 for ipv6-web-archive@ietf.org; Thu, 27 Nov 2003 00:27:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APEgR-0002yR-00 for ipv6-web-archive@ietf.org; Thu, 27 Nov 2003 00:27:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APEg9-00031P-DF; Thu, 27 Nov 2003 00:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APEfJ-00030A-FA for ipv6@optimus.ietf.org; Thu, 27 Nov 2003 00:26:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13005 for ; Thu, 27 Nov 2003 00:25:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APEfG-0002xz-00 for ipv6@ietf.org; Thu, 27 Nov 2003 00:26:06 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1APEfG-0002xk-00 for ipv6@ietf.org; Thu, 27 Nov 2003 00:26:06 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAR5PYUP025807; Wed, 26 Nov 2003 21:25:35 -0800 (PST) Received: from lillen (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAR5PWQ07037; Thu, 27 Nov 2003 06:25:32 +0100 (MET) Date: Wed, 26 Nov 2003 21:23:59 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: routers - (was: Re: "ROUTERS" vs. "routers") To: Fred Templin Cc: Pekka Savola , "Nick 'Sharkey' Moore" , ipv6@ietf.org In-Reply-To: "Your message with ID" <3FC4FB34.7050909@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Hosts with embedded gateway > functions, as described in RFC 1122, section 3.3.4.2 under: "Weak ES > Model" also qaulify as routers, and it doesn't matter at all what > different routers advertise - they are all still just *routers*. That wouldn't be consistent with the definition of router in RFC 2460; a node which forwards packets not explicitly addressed to itself. A host in the weak ES model would still only handle packets destined to the addresses assigned to that host; hence it isn't a router per the RFC 2460 definition. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Nov 27 04:46:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01900 for ; Thu, 27 Nov 2003 04:46:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIjI-0000jR-Qh for ipv6-archive@odin.ietf.org; Thu, 27 Nov 2003 04:46:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR9kWa9002810 for ipv6-archive@odin.ietf.org; Thu, 27 Nov 2003 04:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIjG-0000jE-6S for ipv6-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 04:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01862 for ; Thu, 27 Nov 2003 04:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIjD-0005pA-00 for ipv6-web-archive@ietf.org; Thu, 27 Nov 2003 04:46:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APIjC-0005p7-00 for ipv6-web-archive@ietf.org; Thu, 27 Nov 2003 04:46:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIir-0000dV-32; Thu, 27 Nov 2003 04:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIhz-0000ca-Is for ipv6@optimus.ietf.org; Thu, 27 Nov 2003 04:45:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01851 for ; Thu, 27 Nov 2003 04:44:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIhw-0005oq-00 for ipv6@ietf.org; Thu, 27 Nov 2003 04:45:08 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIhv-0005on-00 for ipv6@ietf.org; Thu, 27 Nov 2003 04:45:07 -0500 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 JAA07481 for ; Thu, 27 Nov 2003 09:45:08 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA09046 for ; Thu, 27 Nov 2003 09:45:07 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAR9j7r19086 for ipv6@ietf.org; Thu, 27 Nov 2003 09:45:07 GMT Date: Thu, 27 Nov 2003 09:45:07 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: [Fwd: I-D ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] Message-ID: <20031127094507.GB18128@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <3FC41529.4030005@india.hp.com> <004901c3b481$761c8fb0$b7cbdba8@daniel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004901c3b481$761c8fb0$b7cbdba8@daniel> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Daniel, Maybe you didn't read my problem statement draft that Vijay cited below? I don't think you can use the Reconfigure message when the client is only using stateless DHCPv6 because the server is then not handling IP leases and thus has no list of client IPs to send the unicast Reconfigure message to. That's the whole assumption of the problem statement and the resulting proposals by Vijay (ND option on link + multicast message from server to relays) and Stig (lifetime option) to solve that. Stig's option is simpler but does not address all cases. Tim On Thu, Nov 27, 2003 at 09:57:42AM +0900, Soohong Daniel Park wrote: > um... for this operation, all nodes MUST be a DHCPv6 client > when obtaining required information. At this case, current DHCPv6 > operation * Reconfigure procedure * can be used for that without > any new defined option... > > Am I missing something ? > > > > > Regards > > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics > > > -----Original Message----- > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On > > Behalf Of Vijayabhaskar A K > > Sent: Wednesday, November 26, 2003 11:51 AM > > To: ipv6@ietf.org > > Subject: [Fwd: I-D > > ACTION:draft-vijay-ipv6-icmp-refresh-otherconf-00.txt] > > > > > > The related drafts are: > > > > http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mca > > st-reconf-00.txt > > http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless- > > dhcpv6-renumbering-00.txt > > > > Please go through these three drafts and let me know your comments > > > > Vijay > > > > > > -- > > __________________________________________________________ > > Vijayabhaskar A K Phone : +91-80-2053085 > > Hewlett Packard Mobile: +91-9845241382 > > 29 Cunningham Road Telnet: 847-3085 > > Bangalore 52 Email : vijayak@india.hp.com > > > > Until you have the courage to lose sight of the shore, > > you will not know the terror of being forever lost at sea. > > __________________________________________________________ > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 28 07:34:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25622 for ; Fri, 28 Nov 2003 07:34:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhop-0003ry-Nw for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 07:33:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASCXtwd014875 for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 07:33:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhop-0003rq-H6 for ipv6-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 07:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25595 for ; Fri, 28 Nov 2003 07:33:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APhoo-0001NT-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 07:33:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APhoo-0001NF-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 07:33:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhmz-0003jJ-1x; Fri, 28 Nov 2003 07:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APhm8-0003j0-Ds for ipv6@optimus.ietf.org; Fri, 28 Nov 2003 07:31:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25515 for ; Fri, 28 Nov 2003 07:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APhm7-0001J4-00 for ipv6@ietf.org; Fri, 28 Nov 2003 07:31:07 -0500 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1APhm6-0001Ip-00 for ipv6@ietf.org; Fri, 28 Nov 2003 07:31:06 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri , 28 Nov 2003 18:05:51 +0530 Received: from suvendum (suvendum.future.futsoft.com [10.6.4.104]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id hASCTh319478 for ; Fri, 28 Nov 2003 17:59:43 +0530 Reply-To: From: "Suvendu M" To: Subject: Sending Fragmented packets Date: Fri, 28 Nov 2003 18:01:16 +0530 Message-ID: <001101c3b5ab$8610f840$6804060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a query. After fragmentation can the fragmented IPv6 packets take different routes to reach the destination?? If Yes, how is PMTU Discovery happen in that case??? Does the Source Node perform PMTU Discovery for all probable routes to reach a Destination Node?? regards and thanks in advance Suvendu. *************************************************************************** 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 28 07:55:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26140 for ; Fri, 28 Nov 2003 07:55:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APi96-0005A1-9O for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 07:54:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASCsq76019836 for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 07:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APi96-00059r-2r for ipv6-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 07:54:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26087 for ; Fri, 28 Nov 2003 07:54:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APi95-0001d1-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 07:54:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APi94-0001cy-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 07:54:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APi8H-0004vL-RN; Fri, 28 Nov 2003 07:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APi86-0004v5-Jn for ipv6@optimus.ietf.org; Fri, 28 Nov 2003 07:53:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26057 for ; Fri, 28 Nov 2003 07:53:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APi82-0001c1-00 for ipv6@ietf.org; Fri, 28 Nov 2003 07:53:46 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1APi82-0001by-00 for ipv6@ietf.org; Fri, 28 Nov 2003 07:53:46 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 90FFC6A901; Fri, 28 Nov 2003 14:53:44 +0200 (EET) Message-ID: <3FC7444D.70809@kolumbus.fi> Date: Fri, 28 Nov 2003 14:49:17 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: suvendum@future.futsoft.com Cc: ipv6@ietf.org Subject: Re: Sending Fragmented packets References: <001101c3b5ab$8610f840$6804060a@future.futsoft.com> In-Reply-To: <001101c3b5ab$8610f840$6804060a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Suvendu M wrote: > Hi, > I have a query. After fragmentation can the fragmented IPv6 packets > take different routes to reach the destination?? If Yes, how is PMTU > Discovery happen in that case??? Does the Source Node perform PMTU Discovery > for all probable routes to reach a Destination Node?? PMTU discovery is not specific to the route that is used; normally you would not even know what different routes are in use. But PMTU discovery works essentially by decreasing the MTU until you no longer get ICMP Packet Too Big messages. So if you were indeed using multiple routes and one of them had a small MTU, you would get ICMP errors from that path, until the MTU would be small enough for the packets to get through. More info in RFC 1981. Hope this helps, --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 28 08:00:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26267 for ; Fri, 28 Nov 2003 08:00:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APiDl-0005W7-CN for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 07:59:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASCxfax021201 for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 07:59:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APiDl-0005Vs-8P for ipv6-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 07:59:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26221 for ; Fri, 28 Nov 2003 07:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APiDk-0001gS-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 07:59:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APiDj-0001gP-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 07:59:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APiD9-0005Hl-45; Fri, 28 Nov 2003 07:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APiD0-0005HM-Mx for ipv6@optimus.ietf.org; Fri, 28 Nov 2003 07:58:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26204 for ; Fri, 28 Nov 2003 07:58:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APiCz-0001ft-00 for ipv6@ietf.org; Fri, 28 Nov 2003 07:58:53 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1APiCy-0001fO-00 for ipv6@ietf.org; Fri, 28 Nov 2003 07:58:53 -0500 Received: from keshavaak (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HP20052JBYPXO@mta0.huawei.com> for ipv6@ietf.org; Fri, 28 Nov 2003 20:56:51 +0800 (CST) Date: Fri, 28 Nov 2003 18:30:19 +0530 From: Keshava Subject: Re: Sending Fragmented packets To: suvendum@future.futsoft.com, ipv6@ietf.org Cc: keshavaak@huawei.com Reply-to: Keshava Message-id: <000801c3b5af$9474c250$1604120a@keshavaak> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <001101c3b5ab$8610f840$6804060a@future.futsoft.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, Path MTU calculated is the least value of all avilable paths to the destination. regards, keshava ----- Original Message ----- From: "Suvendu M" To: Sent: Friday, November 28, 2003 6:01 PM Subject: Sending Fragmented packets > Hi, > I have a query. After fragmentation can the fragmented IPv6 packets > take different routes to reach the destination?? If Yes, how is PMTU > Discovery happen in that case??? Does the Source Node perform PMTU Discovery > for all probable routes to reach a Destination Node?? > > regards and thanks in advance > Suvendu. > > > > *************************************************************************** > 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 IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Nov 28 09:35:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28899 for ; Fri, 28 Nov 2003 09:35:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APji1-0000BA-Dx for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 09:35:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASEZ1th000681 for ipv6-archive@odin.ietf.org; Fri, 28 Nov 2003 09:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APji1-0000Au-7P for ipv6-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 09:35:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28864 for ; Fri, 28 Nov 2003 09:34:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APjhz-00032S-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 09:34:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APjhz-00032P-00 for ipv6-web-archive@ietf.org; Fri, 28 Nov 2003 09:34:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APjh4-0008QB-8n; Fri, 28 Nov 2003 09:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APjgu-0008Pt-Tm for ipv6@optimus.ietf.org; Fri, 28 Nov 2003 09:33:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28839 for ; Fri, 28 Nov 2003 09:33:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APjgt-00031g-00 for ipv6@ietf.org; Fri, 28 Nov 2003 09:33:51 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1APjgs-00031P-00 for ipv6@ietf.org; Fri, 28 Nov 2003 09:33:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hASEWxI24283; Fri, 28 Nov 2003 16:32:59 +0200 Date: Fri, 28 Nov 2003 16:32:59 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: ipv6@ietf.org Subject: Re: RFC2461bis issue: IANA considerations In-Reply-To: <4.3.2.7.2.20031125124734.01e1ad10@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, 25 Nov 2003, Ralph Droms wrote: > >(FWIW, draft-narten-ipv6-iana-considerations-00.txt proposes "IESG > >Approval" or "Standards Action".) > > Oops, I missed draft-narten-ipv6-iana-considerations-00.txt. I assume > IESG approval covers preliminary assignment prior to Standards action? > That text sounds fine to me... Yes, IESG approval should be possible at any stage of the draft lifetime. But note that the particular draft in question is still just a personal submission, and has not moved anywhere in the publication process yet. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Nov 29 05:46:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12955 for ; Sat, 29 Nov 2003 05:46:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ2cX-0003Pg-S6 for ipv6-archive@odin.ietf.org; Sat, 29 Nov 2003 05:46:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATAkbsE013117 for ipv6-archive@odin.ietf.org; Sat, 29 Nov 2003 05:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ2cX-0003PU-L2 for ipv6-web-archive@optimus.ietf.org; Sat, 29 Nov 2003 05:46:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12903 for ; Sat, 29 Nov 2003 05:46:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ2cU-0003Uv-00 for ipv6-web-archive@ietf.org; Sat, 29 Nov 2003 05:46:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQ2cT-0003Us-00 for ipv6-web-archive@ietf.org; Sat, 29 Nov 2003 05:46:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ2b1-0003C3-QE; Sat, 29 Nov 2003 05:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ2aJ-0003BK-Lv for ipv6@optimus.ietf.org; Sat, 29 Nov 2003 05:44:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12864 for ; Sat, 29 Nov 2003 05:44:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ2aG-0003TT-00 for IPv6@ietf.org; Sat, 29 Nov 2003 05:44:16 -0500 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1AQ2aE-0003TG-00 for IPv6@ietf.org; Sat, 29 Nov 2003 05:44:15 -0500 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hATAd6pc026243 for ; Sat, 29 Nov 2003 18:39:07 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Sat Nov 29 18:46:44 2003 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Sat, 29 Nov 2003 18:46:44 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B666.145C1E3F" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: a question on IPv6CP Date: Sat, 29 Nov 2003 18:46:44 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EC7C@bellnet-mail3.sbell.com.cn> Thread-Topic: a question on IPv6CP Thread-Index: AcO2ZhRU6ysWtMujQBG/6Bayh00KYQ== From: "CTO WEI Renxiang" To: X-OriginalArrivalTime: 29 Nov 2003 10:46:44.0336 (UTC) FILETIME=[14800700:01C3B666] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B666.145C1E3F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJUHY2Q1AgbmVnb3RpYXRlcyB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXIgb24gYm90aCBl bmRzIG9mIGxpbmsgdG8gZW5zdXJlIHRoZSB1bmlxdWUNCm9mIGFkZHJlc3MuIFRoZSBBZGRyZXNz IENvbmZpZ3VyYXRpb24gbWVjaGFuaXNtKGVpdGhlciBzdGF0ZWxlc3Mgb3Igc3RhdGVmdWwpIGlz IHN0aWxsDQpuZWVkZWQuIA0KTm93IHRoYXQgQWRkcmVzcyBDb25maWd1cmF0aW9uIG1lY2hhbmlz bSBpbmNsdWRlcyBkdXBsaWNhdGUgYWRkcmVzcw0KZGV0ZWN0aW9uLCB3aHkgSVB2NkNQIG5lZWQg dG8gbmVnb3RpYXRlIGludGVyZmFjZSBpZGVudGlmaWVyPw0KIA0KUmVnYXJkcywNCllhbiBSZW54 aWFuZw0KDQo= ------_=_NextPart_001_01C3B666.145C1E3F Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj48SFRNTD48SEVBRD48TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PC9IRUFEPjxCT0RZPjxESVY+SGksPEJSPklQdjZD UCBuZWdvdGlhdGVzIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllciBvbiAKYm90aCBlbmRzIG9mIGxp bmsgdG8gZW5zdXJlIHRoZSB1bmlxdWU8QlI+b2YgYWRkcmVzcy4gVGhlIEFkZHJlc3MgQ29uZmln dXJhdGlvbiAKbWVjaGFuaXNtKGVpdGhlciBzdGF0ZWxlc3Mgb3Igc3RhdGVmdWwpIGlzIHN0aWxs PEJSPm5lZWRlZC4mbmJzcDs8QlI+Tm93IHRoYXQgCkFkZHJlc3MgQ29uZmlndXJhdGlvbiBtZWNo YW5pc20gaW5jbHVkZXMgZHVwbGljYXRlIGFkZHJlc3M8QlI+ZGV0ZWN0aW9uLCB3aHkgCklQdjZD UCBuZWVkIHRvIG5lZ290aWF0ZSBpbnRlcmZhY2UgaWRlbnRpZmllcj88L0RJVj4KPERJVj4mbmJz cDs8L0RJVj4KPERJVj5SZWdhcmRzLDxCUj5ZYW4gUmVueGlhbmc8QlI+PC9ESVY+PC9CT0RZPjwv SFRNTD4= ------_=_NextPart_001_01C3B666.145C1E3F-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 30 00:01:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08324 for ; Sun, 30 Nov 2003 00:01:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQJiI-0000Dq-E0 for ipv6-archive@odin.ietf.org; Sun, 30 Nov 2003 00:01:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAU51gVZ000853 for ipv6-archive@odin.ietf.org; Sun, 30 Nov 2003 00:01:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQJiI-0000Df-8y for ipv6-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 00:01:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08292 for ; Sun, 30 Nov 2003 00:01:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQJiG-0000GT-00 for ipv6-web-archive@ietf.org; Sun, 30 Nov 2003 00:01:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQJiF-0000GP-00 for ipv6-web-archive@ietf.org; Sun, 30 Nov 2003 00:01:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQJhf-0008UF-Sa; Sun, 30 Nov 2003 00:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQJhc-0008Ss-H8 for ipv6@optimus.ietf.org; Sun, 30 Nov 2003 00:01:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08266 for ; Sun, 30 Nov 2003 00:00:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQJha-0000DC-00 for ipv6@ietf.org; Sun, 30 Nov 2003 00:00:58 -0500 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1AQJhZ-0000Cn-00 for ipv6@ietf.org; Sun, 30 Nov 2003 00:00:57 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 1E564507 for ; Sun, 30 Nov 2003 00:00:28 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 30 Nov 2003 00:00:28 -0500 Message-Id: <20031130050028.1E564507@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.63% | 10 | 11.53% | 46724 | ftemplin@iprg.nokia.com 9.30% | 8 | 8.45% | 34232 | pekkas@netcore.fi 8.14% | 7 | 7.77% | 31490 | ericlklein@softhome.net 6.98% | 6 | 7.53% | 30511 | ipv6@c753173126e0bc8b057a22829880cf26.nosense.org 5.81% | 5 | 5.88% | 23832 | huitema@windows.microsoft.com 4.65% | 4 | 6.23% | 25225 | brc@zurich.ibm.com 5.81% | 5 | 4.53% | 18344 | moore@cs.utk.edu 3.49% | 3 | 3.75% | 15182 | tjc@ecs.soton.ac.uk 2.33% | 2 | 3.85% | 15590 | osprey67@yahoo.com 3.49% | 3 | 2.59% | 10473 | he@uninett.no 2.33% | 2 | 2.25% | 9101 | rdroms@cisco.com 2.33% | 2 | 2.23% | 9032 | brian@innovationslab.net 1.16% | 1 | 3.04% | 12315 | dthaler@windows.microsoft.com 2.33% | 2 | 1.60% | 6465 | zefram@fysh.org 1.16% | 1 | 2.27% | 9189 | vijayak@india.hp.com 1.16% | 1 | 1.59% | 6456 | eric@mehr.ws 1.16% | 1 | 1.40% | 5661 | sra+ipng@hactrn.net 1.16% | 1 | 1.36% | 5525 | cmotta@stanford.edu 1.16% | 1 | 1.29% | 5224 | pthubert@cisco.com 1.16% | 1 | 1.28% | 5191 | heard@pobox.com 1.16% | 1 | 1.21% | 4906 | a.gyasi-agyei@cqu.edu.au 1.16% | 1 | 1.20% | 4859 | soohong.park@samsung.com 1.16% | 1 | 1.16% | 4705 | keshavaak@huawei.com 1.16% | 1 | 1.13% | 4589 | andrew.e.white@motorola.com 1.16% | 1 | 1.13% | 4588 | renxiang.wei@alcatel-sbell.com.cn 1.16% | 1 | 1.05% | 4262 | suvendum@future.futsoft.com 1.16% | 1 | 1.05% | 4239 | ignatios@theory.cs.uni-bonn.de 1.16% | 1 | 0.98% | 3978 | sharkey@zoic.org 1.16% | 1 | 0.95% | 3861 | crawdad@fnal.gov 1.16% | 1 | 0.93% | 3750 | leifj@it.su.se 1.16% | 1 | 0.93% | 3748 | matthew.ford@bt.com 1.16% | 1 | 0.92% | 3713 | itojun@itojun.org 1.16% | 1 | 0.91% | 3667 | alh-ietf@tndh.net 1.16% | 1 | 0.89% | 3625 | petrescu@nal.motlabs.com 1.16% | 1 | 0.88% | 3575 | jari.arkko@kolumbus.fi 1.16% | 1 | 0.88% | 3571 | erik.nordmark@sun.com 1.16% | 1 | 0.88% | 3561 | hardaker@tislabs.com 1.16% | 1 | 0.87% | 3541 | ipv6-local@be-well.no-ip.com 1.16% | 1 | 0.87% | 3539 | bob.hinden@nokia.com 1.16% | 1 | 0.76% | 3065 | pizza@us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 86 |100.00% | 405104 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 30 05:36:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27584 for ; Sun, 30 Nov 2003 05:36:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQOwV-0002BF-SJ for ipv6-archive@odin.ietf.org; Sun, 30 Nov 2003 05:36:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUAahie008382 for ipv6-archive@odin.ietf.org; Sun, 30 Nov 2003 05:36:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQOwV-0002B7-AT for ipv6-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 05:36:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27560 for ; Sun, 30 Nov 2003 05:36:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQOwR-0003fE-00 for ipv6-web-archive@ietf.org; Sun, 30 Nov 2003 05:36:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQOwR-0003fB-00 for ipv6-web-archive@ietf.org; Sun, 30 Nov 2003 05:36:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQOvr-00025a-Cg; Sun, 30 Nov 2003 05:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQOv4-00024x-4Z for ipv6@optimus.ietf.org; Sun, 30 Nov 2003 05:35:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27543 for ; Sun, 30 Nov 2003 05:34:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQOv0-0003ek-00 for ipv6@ietf.org; Sun, 30 Nov 2003 05:35:10 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AQOuz-0003eh-00 for ipv6@ietf.org; Sun, 30 Nov 2003 05:35:10 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:75c4:bfef:790:735c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D6CE615210; Sun, 30 Nov 2003 19:35:08 +0900 (JST) Date: Sun, 30 Nov 2003 19:35:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Nicholas Carbone Cc: ipv6@ietf.org Subject: Re: comment on RFC3542 In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , (Sorry for the long delay in responding) >>>>> On Thu, 13 Nov 2003 21:00:21 -0500, >>>>> Nicholas Carbone said: > I am working on the implementation of the APIs that build routing headers > and options headers from RFC3542. Is there a particular reason that > non-standard type uint_t is used for the align argument to > inet6_opt_append()? No, it should be a bug. Actually, "uint_t" introduced from the very beginning of the document, and we simply have not noticed the bug... The "Summary of New Definitions" section of draft-ietf-ipngwg-2292bis-01.txt says int inet6_opt_append(void *, size_t, int, uint8_t, size_t, uint_8, void **); so, I guess the original intention was "uint8_t". And, in fact, the current implementation of the KAME project uses uint8_t for the align parameter. I don't know how to correct this one, though. Obviously, we cannot revise the document again just due to this problem. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Nov 30 08:59:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01343 for ; Sun, 30 Nov 2003 08:59:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQS6w-0006G6-0l for ipv6-archive@odin.ietf.org; Sun, 30 Nov 2003 08:59:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAUDxfVr024049 for ipv6-archive@odin.ietf.org; Sun, 30 Nov 2003 08:59:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQS6u-0006Fo-1P for ipv6-web-archive@optimus.ietf.org; Sun, 30 Nov 2003 08:59:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01307 for ; Sun, 30 Nov 2003 08:59:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQS6s-0005aS-00 for ipv6-web-archive@ietf.org; Sun, 30 Nov 2003 08:59:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQS6s-0005aP-00 for ipv6-web-archive@ietf.org; Sun, 30 Nov 2003 08:59:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQS6H-0006A2-Qh; Sun, 30 Nov 2003 08:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQS6E-00069n-Kj for ipv6@optimus.ietf.org; Sun, 30 Nov 2003 08:58:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01295 for ; Sun, 30 Nov 2003 08:58:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQS6D-0005a4-00 for ipv6@ietf.org; Sun, 30 Nov 2003 08:58:57 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQS6C-0005Zs-00 for ipv6@ietf.org; Sun, 30 Nov 2003 08:58:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAUDwHl01281; Sun, 30 Nov 2003 15:58:17 +0200 Date: Sun, 30 Nov 2003 15:58:17 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Nicholas Carbone , Subject: Re: comment on RFC3542 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Sun, 30 Nov 2003, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > And, in fact, the current implementation of the KAME project uses > uint8_t for the align parameter. > > I don't know how to correct this one, though. Obviously, we cannot > revise the document again just due to this problem. Well, one could at least report it to: http://www.rfc-editor.org/cgi-bin/errata.pl (link form the main page) .. but most folks probably don't check that when reading the specs.. -- 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 IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------