From ipv6-bounces@ietf.org Mon Jan 02 12:23:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTPA-0000yd-Ou; Mon, 02 Jan 2006 12:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTP8-0000yY-2V for ipv6@megatron.ietf.org; Mon, 02 Jan 2006 12:23:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22685 for ; Mon, 2 Jan 2006 12:22:16 -0500 (EST) Received: from mail19d.dulles19-verio.com ([204.202.242.120] helo=mail19d.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtTUC-0007E9-53 for ipv6@ietf.org; Mon, 02 Jan 2006 12:28:47 -0500 Received: from mx07.stngva01.us.mxservers.net (204.202.242.99) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 1-0374172571 for ; Mon, 2 Jan 2006 12:22:52 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx07.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id a6169b34.6576.189.mx07.stngva01.us.mxservers.net; Mon, 02 Jan 2006 12:22:50 -0500 (EST) From: "John Spence" To: Date: Mon, 2 Jan 2006 09:22:53 -0800 Message-ID: <003201c60fc1$2b748880$3f00800a@native6.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-index: AcYPwSf/x66ggX38S0q0An2zSCxLOw== X-Spam: [F=0.0100000000; heur=0.500(300); stat=0.010; spamtraq-heur=0.500(2006010101)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: Are privacy extensions, RFC 3041, defined for non global-scope addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I re-read the document, and it certainly focuses on the privacy needs of global-scope addresses. I did not find a place where it said it was not defined for ULA or link-local scope addresses. Is that the intent - not defined for non global-scope addresses? Or I am reading that into it? Thanks. ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com ---------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 03 14:26:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrnR-0002eo-5A; Tue, 03 Jan 2006 14:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrnO-0002ej-Q2 for ipv6@megatron.ietf.org; Tue, 03 Jan 2006 14:26:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15859 for ; Tue, 3 Jan 2006 14:24:55 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etrsh-0008Bk-RP for ipv6@ietf.org; Tue, 03 Jan 2006 14:31:42 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Jan 2006 14:25:52 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jan 2006 14:25:52 -0500 Message-ID: Thread-Topic: Fwd: Request To Advance: Thread-Index: AcX/u+Y4oVbvNq4GTQKnmuXZChTKUAQ3aSXg From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 03 Jan 2006 19:25:52.0820 (UTC) FILETIME=[82DDFF40:01C6109B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sorry for the late response I was out of the office. > > =3D> This can be added to the text at the beginning of 7.2.,=20 > which discusses this issues.=20 >=20 > Hmm, so the behavior corresponding to the following entry=20 > (shown again > just to be accurate) is not currently described in the draft: =3D> Not in the main text, which is why I suggested above that we can = add it to section 7.2. >=20 > INCOMPLETE NA, Solicited=3Dany, Send ICMP error =20 > unchanged > Override=3Dany, No (if router) or > Link-layer address log error (if host) >=20 > then...we should discuss whether this behavior makes sense in the > first place. Perhaps you added this entry based on a previous > discussion, but I don't remember such consensus. So it=20 > would be great > if you can provide a pointer to the discussion. >=20 > In any case, I personally don't think this behavior makes sense. It > at least violates a SHOULD requirement of Section 7.2.4 of =3D> I think you meant 7.2.5. > draft-ietf-ipv6-2461bis-05.txt: >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happens. If the > link layer has addresses and no Target Link-Layer address=20 > option is > included, the receiving node SHOULD silently discard the received > ^^^^^^^^^^^^^^^^^^^^^^^ > advertisement. [...] >=20 =3D> Understood. It would violate this part, but I wouldn't say that it = doesn't make sense to indicate that something is wrong to upper layers. I = actually think the text in 7.2.5 is too restrictive. It's useful to inform upper = layers of communication failures.=20 > Since the state is INCOMPLETE, this node should be doing link-layer > address resolution by sending multicast NSs. In this case, the > responder MUST include the target link-layer address option per > Section 7.2.4: >=20 > If the > solicitation's IP Destination Address is a multicast address, the > Target Link-Layer option MUST be included in the advertisement. >=20 > So, the event of receiving an NS with no link-layer address in this > state indicates the responder shows a non-compliant behavior. =20 =3D> Yes, it is a non-compliant behaviour. My point is that it's useful = to inform whomever is trying to communicate that something is wrong. ICMP is a good way of = doing that. I > believe it makes more sense to discard the bogus packets silently as > described in the body of the draft (Section 7.2.4) rather than taking > a specific action like sending an ICMPv6 error message. =3D> I don't think that's a good way to handle it, but the current text = inherited from=20 2461 agrees with you. I don't think it breaks backward compatibility to = mention this=20 in the appendix as an optional behaviour (sending the ICMP error). Are = you ok with having this as an optional behaviour in the appendix? others? Thoughts?=20 Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 03 23:14:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu02Y-0000Un-JY; Tue, 03 Jan 2006 23:14:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu02X-0000Ui-4V for ipv6@megatron.ietf.org; Tue, 03 Jan 2006 23:14:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01721 for ; Tue, 3 Jan 2006 23:13:07 -0500 (EST) From: timbeck04@verizon.net Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu07v-0005nX-Qg for ipv6@ietf.org; Tue, 03 Jan 2006 23:19:57 -0500 Received: from vms089.mailsrvcs.net ([192.168.1.2]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0ISJ00IQGVRUYEU3@vms046.mailsrvcs.net> for ipv6@ietf.org; Tue, 03 Jan 2006 22:14:18 -0600 (CST) Date: Tue, 03 Jan 2006 22:14:18 -0600 (CST) To: jspence@native6.com Message-id: <28948162.1136348058667.JavaMail.root@vms089.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: (no subject) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi John, please see my comments in-line: -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of John Spence Sent: Monday, January 02, 2006 12:23 PM To: ipv6@ietf.org Subject: Are privacy extensions, RFC 3041,defined for non global-scope addresses? I re-read the document, and it certainly focuses on the privacy needs of global-scope addresses. I did not find a place where it said it was not defined for ULA or link-local scope addresses. -> AFAICS, RFC 3041 deals only with global-scope addresses. The stated goals (2-4) explicitly refer to global-scope addresses. Is that the intent - not defined for non global-scope addresses? Or I am reading that into it? -> I think it's reasonable to conclude the mechanism defined in RFC 3041 is not defined for non global-scope addressses. ULAs to my knowledge didn't exist at the time 3041 was written (RFC 3041 in January 2001, RFC 4193 not until October 2005). Even though there is an extant draft meant to update 3041 [draft-ietf-ipv6-privacy-addrs-v2-04.txt], it has yet to become an RFC itself. -> If by some stretch RFC 3041 was meant for link-local scope addresses, it seems that would be suboptimal. At least as often as the temp link-local unicast address changed, the node would have to (un)subscribe to the corresponding solicited-node multicast group(s). That could lead to reduced performance. I'd also wonder about the affect temporary link-local addresses would have on a router's neighbor cache, and/or any connectivity dependent upon the accuracy of cache entries... How might this affect ND itself (not a leading question BTW)? Thanks. -> Best regards, Tim Enos 1Sam16:7 ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.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 ipv6-bounces@ietf.org Wed Jan 04 03:18:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu3qz-0005av-Ex; Wed, 04 Jan 2006 03:18:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu3qv-0005YE-91 for ipv6@megatron.ietf.org; Wed, 04 Jan 2006 03:18:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25252 for ; Wed, 4 Jan 2006 03:17:21 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu3wM-0005RB-MG for ipv6@ietf.org; Wed, 04 Jan 2006 03:24:15 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 4 Jan 2006 00:18:26 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 00:18:25 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 00:18:25 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 00:18:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jan 2006 00:19:43 -0800 Message-ID: Thread-Topic: (no subject) thread-index: AcYQ5czp/BTAcsJdSuicMux47hjqHgAIXeuQ From: "Christian Huitema" To: , X-OriginalArrivalTime: 04 Jan 2006 08:18:25.0350 (UTC) FILETIME=[6F20C660:01C61107] X-Spam-Score: 1.1 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: (no subject) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hosts are not supposed to make any distinction between ULA and global scope addresses. Hosts autoconfigure ULA addresses if the RA advertises and ULA prefix. Thus, hosts that are programmed to generate RFC 3041 addresses for global scope addresses will do the same for ULA. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > timbeck04@verizon.net > Sent: Tuesday, January 03, 2006 8:14 PM > To: jspence@native6.com > Cc: ipv6@ietf.org > Subject: (no subject) >=20 > Hi John, please see my comments in-line: >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > John > Spence > Sent: Monday, January 02, 2006 12:23 PM > To: ipv6@ietf.org > Subject: Are privacy extensions, RFC 3041,defined for non global-scope > addresses? >=20 >=20 > I re-read the document, and it certainly focuses on the privacy > needs of global-scope addresses. I did not find a place where it > said it was not defined for ULA or link-local scope addresses. >=20 > -> AFAICS, RFC 3041 deals only with global-scope addresses. The stated > goals (2-4) explicitly refer to global-scope addresses. >=20 > Is that the intent - not defined for non global-scope addresses? > Or I am reading that into it? >=20 > -> I think it's reasonable to conclude the mechanism defined in RFC 3041 > is not defined for non global-scope addressses. ULAs to my knowledge > didn't exist at the time 3041 was written (RFC 3041 in January 2001, RFC > 4193 not until October 2005). Even though there is an extant draft meant > to update 3041 [draft-ietf-ipv6-privacy-addrs-v2-04.txt], it has yet to > become an RFC itself. >=20 > -> If by some stretch RFC 3041 was meant for link-local scope addresses, > it seems that would be suboptimal. At least as often as the temp link- > local unicast address changed, the node would have to (un)subscribe to the > corresponding solicited-node multicast group(s). That could lead to > reduced performance. I'd also wonder about the affect temporary link-local > addresses would have on a router's neighbor cache, and/or any connectivity > dependent upon the accuracy of cache entries... How might this affect ND > itself (not a leading question BTW)? >=20 > Thanks. >=20 > -> Best regards, >=20 > Tim Enos > 1Sam16:7 >=20 > ---------------------------------------------------- > John Spence, CCSI, CCNA, CISSP > Native6, Inc. > IPv6 Training and Consulting > jspence@native6.com > ---------------------------------------------------- >=20 >=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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 04 15:23:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFA7-0001l3-HP; Wed, 04 Jan 2006 15:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFA5-0001kv-D9 for ipv6@megatron.ietf.org; Wed, 04 Jan 2006 15:23:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20852 for ; Wed, 4 Jan 2006 15:21:53 -0500 (EST) From: timbeck04@verizon.net Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFFd-0007Mc-8f for ipv6@ietf.org; Wed, 04 Jan 2006 15:28:53 -0500 Received: from vms169.mailsrvcs.net ([192.168.1.2]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0ISL00HW14MJXV92@vms044.mailsrvcs.net> for ipv6@ietf.org; Wed, 04 Jan 2006 14:23:07 -0600 (CST) Date: Wed, 04 Jan 2006 14:23:07 -0600 (CST) To: huitema@windows.microsoft.com Message-id: <13992961.1136406187828.JavaMail.root@vms169.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: (no subject) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Accidentally left original subject: out of original reply; sorry about that. Comments in-line: -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Wednesday, January 04, 2006 3:20 AM To: timbeck04@verizon.net; jspence@native6.com Cc: ipv6@ietf.org Subject: RE: (no subject) Hosts are not supposed to make any distinction between ULA and global scope addresses. -> "not supposed to" seems a bit strong. Section 4.5 of RFC 4193 says "Application and other higher level protocols CAN (capitalization mine) treat Local IPv6 addresses in the same manner as other types of global unicast addresses." Again, in section 1 "-In practice, applications MAY (capitalization mine) treat these addresses like global scoped addresses." Also, "In some cases, it is better for nodes and applications to treat them differently from global unicast addresses." Hosts autoconfigure ULA addresses if the RA advertises and ULA prefix. -> 'if' being the operative word (they could also be assigned via DHCPv6 or manually). Thus, hosts that are programmed to generate RFC 3041 addresses for global scope addresses will do the same for ULA. -> I just read draft-ietf-ipv6-privacy-addrs-v2-04.txt***, and see that it includes references to ULAs. It also refers to the ULA spec as informative, which was at the time also a draft. If the draft*** becomes an RFC (which I expect it will), thus obsoleting RFC 3041, it is then it would be appropriate to say hosts "will do the same for ULA". At present (RFC 3041, not RFC 4193) it does not mention ULAs. It's only appropriate to cite drafts as "works in progress". Best Regards, Tim Enos 1Sam16:7 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > timbeck04@verizon.net > Sent: Tuesday, January 03, 2006 8:14 PM > To: jspence@native6.com > Cc: ipv6@ietf.org > Subject: (no subject) > > Hi John, please see my comments in-line: > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > John > Spence > Sent: Monday, January 02, 2006 12:23 PM > To: ipv6@ietf.org > Subject: Are privacy extensions, RFC 3041,defined for non global-scope > addresses? > > > I re-read the document, and it certainly focuses on the privacy > needs of global-scope addresses. I did not find a place where it > said it was not defined for ULA or link-local scope addresses. > > -> AFAICS, RFC 3041 deals only with global-scope addresses. The stated > goals (2-4) explicitly refer to global-scope addresses. > > Is that the intent - not defined for non global-scope addresses? > Or I am reading that into it? > > -> I think it's reasonable to conclude the mechanism defined in RFC 3041 > is not defined for non global-scope addressses. ULAs to my knowledge > didn't exist at the time 3041 was written (RFC 3041 in January 2001, RFC > 4193 not until October 2005). Even though there is an extant draft meant > to update 3041 [draft-ietf-ipv6-privacy-addrs-v2-04.txt], it has yet to > become an RFC itself. > > -> If by some stretch RFC 3041 was meant for link-local scope addresses, > it seems that would be suboptimal. At least as often as the temp link- > local unicast address changed, the node would have to (un)subscribe to the > corresponding solicited-node multicast group(s). That could lead to > reduced performance. I'd also wonder about the affect temporary link-local > addresses would have on a router's neighbor cache, and/or any connectivity > dependent upon the accuracy of cache entries... How might this affect ND > itself (not a leading question BTW)? > > Thanks. > > -> Best regards, > > Tim Enos > 1Sam16:7 > > ---------------------------------------------------- > John Spence, CCSI, CCNA, CISSP > Native6, Inc. > IPv6 Training and Consulting > jspence@native6.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 ipv6-bounces@ietf.org Wed Jan 04 15:50:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFaP-00028G-Ux; Wed, 04 Jan 2006 15:50:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFa9-0001tS-Q7; Wed, 04 Jan 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24144; Wed, 4 Jan 2006 15:48:49 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFfg-0008LM-Jt; Wed, 04 Jan 2006 15:55:49 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EuFa5-00080B-Ak; Wed, 04 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Information Queries Author(s) : M. Crawford, B. Haberman Filename : draft-ietf-ipngwg-icmp-name-lookups-13.txt Pages : 15 Date : 2006-1-4 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-13.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: <2006-1-4111513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-4111513.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Wed Jan 04 16:08:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFsN-0002dt-7H; Wed, 04 Jan 2006 16:08:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFsL-0002dH-76 for ipv6@megatron.ietf.org; Wed, 04 Jan 2006 16:08:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00959 for ; Wed, 4 Jan 2006 16:07:38 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFxs-0002Fk-1B for ipv6@ietf.org; Wed, 04 Jan 2006 16:14:37 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.11021181; Wed, 04 Jan 2006 16:07:58 -0500 Mime-Version: 1.0 (Apple Message framework v623) To: IPv6 WG Message-Id: From: Brian Haberman Date: Wed, 4 Jan 2006 16:08:01 -0500 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Bob Hinden Subject: Fwd: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0631193272==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0631193272== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--812108369; protocol="application/pkcs7-signature" --Apple-Mail-2--812108369 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit All, I have integrated most of the changes I proposed to the ICMP Names draft. After my previous note on the subject, I had a lot of input on the tunnel endpoint text and determined that there was not consensus to add it to the document. As this draft is now in the repository, Bob will start a WG Last Call so that we can begin moving it forward. Thanks to everyone who has provided input, reviews, and comments. Regards, Brian Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: January 4, 2006 15:50:01 EST > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Version 6 Working Group Working > Group of the IETF. > > Title : IPv6 Node Information Queries > Author(s) : M. Crawford, B. Haberman > Filename : draft-ietf-ipngwg-icmp-name-lookups-13.txt > Pages : 15 > Date : 2006-1-4 > > This document describes a protocol for asking an IPv6 node to supply > certain network information, such as its hostname or fully-qualified > domain name. IPv6 implementation experience has shown that direct > queries for a hostname are useful, and a direct query mechanism for > other information has been found useful in serverless environments > and for debugging. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name- > lookups-13.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipngwg-icmp-name-lookups-13.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-13.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-1-4111513.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-2--812108369 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMTA0MjEwODAxWjAjBgkqhkiG9w0B CQQxFgQUGkvL6zmoFd6qejQn79A43XH3XasweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAT7ZYWYM/xk/nNcFpBZ7mVMYuinFLfExXYtMxZPccXcJXbUQy2d9vBltUCSQ0iuFC9QLa fUOJnxd8PO/dkGK+DqklEaC04PbNchRRKu3zHhh1mBMYYjgJhYR0IAohKl+tSDh4GEhRD10xvJC9 3HS9M7A6f0gi+4DSF1Xv++rxKc7kfHxnCTNMj31RnCrA3357qCthpiGJUd0lp0zCh41oEwZiyGjq vwuLBXcmC7Xe+3z/mCeHkZid6/wS3dLHhkfq0votDCauBp/VhqaiwKAuHq/SKEY0cYdJ862BLZ+g GuKurAG4armpSJ1noRsYELyqV18cweb9NMvsergUQFMK0wAAAAAAAA== --Apple-Mail-2--812108369-- --===============0631193272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0631193272==-- From ipv6-bounces@ietf.org Wed Jan 04 16:21:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFuh-0004AB-Af; Wed, 04 Jan 2006 16:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFue-000498-5R for ipv6@megatron.ietf.org; Wed, 04 Jan 2006 16:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01814 for ; Wed, 4 Jan 2006 16:10:01 -0500 (EST) Received: from mail19d.dulles19-verio.com ([204.202.242.120] helo=mail19d.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuG03-0002Vy-GI for ipv6@ietf.org; Wed, 04 Jan 2006 16:16:57 -0500 Received: from mx06.stngva01.us.mxservers.net (204.202.242.35) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 1-0720209046 for ; Wed, 4 Jan 2006 16:10:48 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx06.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 6d93cb34.15239.226.mx06.stngva01.us.mxservers.net; Wed, 04 Jan 2006 16:10:46 -0500 (EST) From: "John Spence" Cc: Date: Wed, 4 Jan 2006 13:10:48 -0800 Message-ID: <001101c61173$569f0090$0400a8c0@native6.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYRbXlA6jAzL6J6Sq2ZauEX1agyCwAA29xQ In-Reply-To: <13992961.1136406187828.JavaMail.root@vms169.mailsrvcs.net> X-Spam: [F=0.0043103448; heur=0.500(-4700); stat=0.010; spamtraq-heur=0.300(2006010405)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] To: ipv6@ietf.org X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 1.1 (+) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit Subject: RE: Are privacy extensions, RFC 3041, defined for non global-scope addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Good thread. That was quick research into the Privacy draft Tim! It sounds like we are all pretty much in agreement that: *) generating private link-local addresses is a bad idea, and neither the RFC or new Draft say to do it *) generating private ULA's does make sense, just like private global's makes sense (if desired by local administrators) *) I see in the Draft where it says local administrators should be able to disable privacy extensions by prefix, so privacy addresses could be generated for, say, global but not ULA-scope addresses, or as local administrators deem appropriate. I like choices. Thanks. John Spence ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com (wk) 206-682-0275 www.native6.com ---------------------------------------------------- >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of timbeck04@verizon.net >Sent: Wednesday, January 04, 2006 12:23 PM >To: huitema@windows.microsoft.com >Cc: ipv6@ietf.org >Subject: (no subject) > >Accidentally left original subject: out of original reply; >sorry about that. Comments in-line: > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of Christian Huitema >Sent: Wednesday, January 04, 2006 3:20 AM >To: timbeck04@verizon.net; jspence@native6.com >Cc: ipv6@ietf.org >Subject: RE: (no subject) > >Hosts are not supposed to make any distinction between ULA and >global scope addresses. > >-> "not supposed to" seems a bit strong. Section 4.5 of RFC >4193 says "Application and other higher level protocols CAN >(capitalization mine) treat Local IPv6 addresses in the same >manner as other types of global unicast addresses." Again, in >section 1 "-In practice, applications MAY (capitalization >mine) treat these addresses like global scoped addresses." >Also, "In some cases, it is better for nodes and applications >to treat them differently from global unicast addresses. >Hosts autoconfigure ULA addresses if the RA advertises and ULA prefix. > >-> 'if' being the operative word (they could also be assigned >via DHCPv6 or manually). > >Thus, hosts that are programmed to generate RFC 3041 addresses >for global scope addresses will do the same for ULA. > >-> I just read draft-ietf-ipv6-privacy-addrs-v2-04.txt***, and >see that it includes references to ULAs. It also refers to the >ULA spec as informative, which was at the time also a draft. >If the draft*** becomes an RFC (which I expect it will), thus >obsoleting RFC 3041, it is then it would be appropriate to say >hosts "will do the same for ULA". At present (RFC 3041, not >RFC 4193) it does not mention ULAs. It's only appropriate to >cite drafts as "works in progress". > >Best Regards, > >Tim Enos >1Sam16:7 > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >Of >> timbeck04@verizon.net >> Sent: Tuesday, January 03, 2006 8:14 PM >> To: jspence@native6.com >> Cc: ipv6@ietf.org >> Subject: (no subject) >> >> Hi John, please see my comments in-line: >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >Of >> John >> Spence >> Sent: Monday, January 02, 2006 12:23 PM >> To: ipv6@ietf.org >> Subject: Are privacy extensions, RFC 3041,defined for non >global-scope >> addresses? >> >> >> I re-read the document, and it certainly focuses on the >privacy needs >> of global-scope addresses. I did not find a place where it said it >> was not defined for ULA or link-local scope addresses. >> >> -> AFAICS, RFC 3041 deals only with global-scope addresses. >The stated >> goals (2-4) explicitly refer to global-scope addresses. >> >> Is that the intent - not defined for non global-scope addresses? >> Or I am reading that into it? >> >> -> I think it's reasonable to conclude the mechanism defined in RFC >3041 >> is not defined for non global-scope addressses. ULAs to my knowledge >> didn't exist at the time 3041 was written (RFC 3041 in January 2001, >RFC >> 4193 not until October 2005). Even though there is an extant draft >meant >> to update 3041 [draft-ietf-ipv6-privacy-addrs-v2-04.txt], it has yet >to >> become an RFC itself. >> >> -> If by some stretch RFC 3041 was meant for link-local scope >addresses, >> it seems that would be suboptimal. At least as often as the >temp link- >> local unicast address changed, the node would have to >(un)subscribe to >the >> corresponding solicited-node multicast group(s). That could lead to >> reduced performance. I'd also wonder about the affect temporary >link-local >> addresses would have on a router's neighbor cache, and/or any >connectivity >> dependent upon the accuracy of cache entries... How might this affect >ND >> itself (not a leading question BTW)? >> >> Thanks. >> >> -> Best regards, >> >> Tim Enos >> 1Sam16:7 >> >> ---------------------------------------------------- >> John Spence, CCSI, CCNA, CISSP >> Native6, Inc. >> IPv6 Training and Consulting >> jspence@native6.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 >> ----------------------------------------------------------------- --- > >---------------------------------------------------------------- ---- >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 ipv6-bounces@ietf.org Wed Jan 04 16:53:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGZG-0001go-CX; Wed, 04 Jan 2006 16:53:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGZE-0001gX-3K for ipv6@megatron.ietf.org; Wed, 04 Jan 2006 16:53:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08492 for ; Wed, 4 Jan 2006 16:51:57 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuGem-0004YO-6Y for ipv6@ietf.org; Wed, 04 Jan 2006 16:58:56 -0500 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 4 Jan 2006 21:52:54 +0000 (GMT) Date: Wed, 4 Jan 2006 21:52:50 +0000 From: David Malone To: Brian Haberman Message-ID: <20060104215250.GA25212@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Bob Hinden , IPv6 WG Subject: Re: Fwd: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Jan 04, 2006 at 04:08:01PM -0500, Brian Haberman wrote: > I have integrated most of the changes I proposed to the ICMP Names > draft. After my previous note on the subject, I had a lot of input on > the tunnel endpoint text and determined that there was not consensus to add > it to the document. Some text seems to have been added to the draft that I don't remember being discussed here. The diff is: node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es) but if so, - the default configuration MUST be not to discard them. + the default configuration SHOULD be not to discard them. An + exception is made in the previous rule in the case of the All-Routers + (FF02::2) and All-Nodes (FF02::1) multicast addresses. The default + configuration for responding to NI Queries to these multicast + addresses MUST be to discard them. All-nodes is one of the most useful addresses to send a node information query to. If you are trying to find a newly configured bit of kit you've just plugged in you'll query the all nodes address and see if it responds with a recognisable name. Requiring that nodes do not respond by default makes this far less useful. Also, using the all-nodes address would be the solution if you need to use NI queries on a network that has a mix of machines using the old draft and the new draft. I sort of articulated this in this message: http://www1.ietf.org/mail-archive/web/ipv6/current/msg05925.html without this, I don't see an obvious way to manage such a network without sending messages to two multicast addresses, which weakens the argument for changing the multicast range. (In fact, in the last around of discussions, several people suggested ditching the hashed name lookups and just keeping the unicast and regular multicast lookups, so this seems a very strange change to make.) David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 04 23:49:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuN4N-0004WB-Ih; Wed, 04 Jan 2006 23:49:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuN4J-0004Vm-KU for ipv6@megatron.ietf.org; Wed, 04 Jan 2006 23:49:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19716 for ; Wed, 4 Jan 2006 23:48:28 -0500 (EST) Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuN9u-0001Tr-U8 for ipv6@ietf.org; Wed, 04 Jan 2006 23:55:32 -0500 Received: from S018431 ([71.245.237.243]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0ISL00J1VS2SZXN0@vms044.mailsrvcs.net> for ipv6@ietf.org; Wed, 04 Jan 2006 22:49:41 -0600 (CST) Date: Wed, 04 Jan 2006 23:49:39 -0500 From: "timothy enos" In-reply-to: <13992961.1136406187828.JavaMail.root@vms169.mailsrvcs.net> To: "'Christian Huitema'" Message-id: <002901c611b3$70346d20$6400a8c0@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.9 (+) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Are privacy extensions, RFC 3041,defined for non global-scope addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Accidentally left original subject: out of original reply; sorry about that. Comments in-line: -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Wednesday, January 04, 2006 3:20 AM To: timbeck04@verizon.net; jspence@native6.com Cc: ipv6@ietf.org Subject: RE: (no subject) Hosts are not supposed to make any distinction between ULA and global scope addresses. -> "not supposed to" seems a bit strong. Section 4.5 of RFC 4193 says "Application and other higher level protocols CAN (capitalization mine) treat Local IPv6 addresses in the same manner as other types of global unicast addresses." Again, in section 1 "-In practice, applications MAY (capitalization mine) treat these addresses like global scoped addresses." Also, "In some cases, it is better for nodes and applications to treat them differently from global unicast addresses." Hosts autoconfigure ULA addresses if the RA advertises and ULA prefix. -> 'if' being the operative word (they could also be assigned via DHCPv6 or manually). Thus, hosts that are programmed to generate RFC 3041 addresses for global scope addresses will do the same for ULA. -> I just read draft-ietf-ipv6-privacy-addrs-v2-04.txt, and see that it includes references to ULAs. It also refers to the ULA spec as informative, which was at the time also a draft. If draft-ietf-ipv6-privacy-addrs-v2-04.txt becomes an RFC (which I expect it will), thus making obsolete RFC 3041, it is then it would be appropriate to say hosts "will do the same for ULA". At present (RFC 3041, not RFC 4193) it does not mention ULAs. It's only appropriate to cite drafts as "works in progress". ->Best Regards, ->Tim Enos 1Sam16:7 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > timbeck04@verizon.net > Sent: Tuesday, January 03, 2006 8:14 PM > To: jspence@native6.com > Cc: ipv6@ietf.org > Subject: (no subject) > > Hi John, please see my comments in-line: > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > John > Spence > Sent: Monday, January 02, 2006 12:23 PM > To: ipv6@ietf.org > Subject: Are privacy extensions, RFC 3041,defined for non global-scope > addresses? > > > I re-read the document, and it certainly focuses on the privacy > needs of global-scope addresses. I did not find a place where it > said it was not defined for ULA or link-local scope addresses. > > -> AFAICS, RFC 3041 deals only with global-scope addresses. The stated > goals (2-4) explicitly refer to global-scope addresses. > > Is that the intent - not defined for non global-scope addresses? > Or I am reading that into it? > > -> I think it's reasonable to conclude the mechanism defined in RFC 3041 > is not defined for non global-scope addressses. ULAs to my knowledge > didn't exist at the time 3041 was written (RFC 3041 in January 2001, RFC > 4193 not until October 2005). Even though there is an extant draft meant > to update 3041 [draft-ietf-ipv6-privacy-addrs-v2-04.txt], it has yet to > become an RFC itself. > > -> If by some stretch RFC 3041 was meant for link-local scope addresses, > it seems that would be suboptimal. At least as often as the temp link- > local unicast address changed, the node would have to (un)subscribe to the > corresponding solicited-node multicast group(s). That could lead to > reduced performance. I'd also wonder about the affect temporary link-local > addresses would have on a router's neighbor cache, and/or any connectivity > dependent upon the accuracy of cache entries... How might this affect ND > itself (not a leading question BTW)? > > Thanks. > > -> Best regards, > > Tim Enos > 1Sam16:7 > > ---------------------------------------------------- > John Spence, CCSI, CCNA, CISSP > Native6, Inc. > IPv6 Training and Consulting > jspence@native6.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 ipv6-bounces@ietf.org Thu Jan 05 03:22:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQO6-0007q8-Ha; Thu, 05 Jan 2006 03:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQO3-0007q3-Jj for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 03:22:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10034 for ; Thu, 5 Jan 2006 03:21:03 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuQTf-000072-Hu for ipv6@ietf.org; Thu, 05 Jan 2006 03:28:10 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:3583:efad:e5f9:3384]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C07E115265; Thu, 5 Jan 2006 17:21:52 +0900 (JST) Date: Thu, 05 Jan 2006 17:21:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IPv6 WG Subject: Re: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Tue, 3 Jan 2006 14:25:52 -0500, >>>>> "Soliman, Hesham" said: > Sorry for the late response I was out of the office. >> > => This can be added to the text at the beginning of 7.2., >> which discusses this issues. >> >> Hmm, so the behavior corresponding to the following entry >> (shown again >> just to be accurate) is not currently described in the draft: > => Not in the main text, which is why I suggested above that we can add it > to section 7.2. I see. As I said in the previous message (see also below), we should first make a consensus about whether this is to be added. Then, if the result is positive, we should explicitly add the corresponding text to 7.2 (in general, the appendix should be a summary of the main text, IMO). (snip) >> I >> believe it makes more sense to discard the bogus packets silently as >> described in the body of the draft (Section 7.2.4) rather than taking >> a specific action like sending an ICMPv6 error message. > => I don't think that's a good way to handle it, but the current text inherited from > 2461 agrees with you. I don't think it breaks backward compatibility to mention this > in the appendix as an optional behaviour (sending the ICMP error). Are you ok with > having this as an optional behaviour in the appendix? others? I don't have a strong opinion on either way (whether or not including this feature). As you said, it may help in some cases (e.g., an end host may be able to give up connecting to a non-compliant remote host faster). But since this may require a change to the existing implementation, I'd like to see an explicit consensus about the additional behavior (i.e., 'no objection' would not suffice). 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 ipv6-bounces@ietf.org Thu Jan 05 06:09:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuSzo-0005U7-MG; Thu, 05 Jan 2006 06:09:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuSzm-0005Sn-RA for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 06:09:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27182 for ; Thu, 5 Jan 2006 06:08:11 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuT5R-0005WZ-RA for ipv6@ietf.org; Thu, 05 Jan 2006 06:15:19 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Jan 2006 06:09:10 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2006 06:09:10 -0500 Message-ID: Thread-Topic: Fwd: Request To Advance: Thread-Index: AcYR0RUkOLgB2XEeQBeCV7ptm3vlBAAFv+bw From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 05 Jan 2006 11:09:10.0443 (UTC) FILETIME=[7417A7B0:01C611E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > =3D> Not in the main text, which is why I suggested above=20 > that we can add it > > to section 7.2. >=20 > I see. As I said in the previous message (see also below), we should > first make a consensus about whether this is to be added. Then, if > the result is positive, we should explicitly add the corresponding > text to 7.2 (in general, the appendix should be a summary of the main > text, IMO). =3D> Agreed. >=20 > (snip) >=20 > >> I > >> believe it makes more sense to discard the bogus packets=20 > silently as > >> described in the body of the draft (Section 7.2.4) rather=20 > than taking > >> a specific action like sending an ICMPv6 error message. >=20 > > =3D> I don't think that's a good way to handle it, but the=20 > current text inherited from=20 > > 2461 agrees with you. I don't think it breaks backward=20 > compatibility to mention this=20 > > in the appendix as an optional behaviour (sending the ICMP=20 > error). Are you ok with > > having this as an optional behaviour in the appendix? others? >=20 > I don't have a strong opinion on either way (whether or not including > this feature). As you said, it may help in some cases (e.g., an end > host may be able to give up connecting to a non-compliant remote host > faster). But since this may require a change to the existing > implementation, I'd like to see an explicit consensus about the > additional behavior (i.e., 'no objection' would not suffice). =3D> That's fine. I'll send a separate email to ask if people agree with = adding=20 the ICMP part as an optional feature.=20 Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 05 08:41:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuVMZ-0000qR-02; Thu, 05 Jan 2006 08:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuVMW-0000oN-5I for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 08:41:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14978 for ; Thu, 5 Jan 2006 08:39:46 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuVSA-0002XI-I0 for ipv6@ietf.org; Thu, 05 Jan 2006 08:46:55 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.11088808; Thu, 05 Jan 2006 08:40:20 -0500 In-Reply-To: <20060104215250.GA25212@walton.maths.tcd.ie> References: <20060104215250.GA25212@walton.maths.tcd.ie> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <0a57add5ffb69b534504bd3e91de2acd@innovationslab.net> From: Brian Haberman Date: Thu, 5 Jan 2006 08:40:23 -0500 To: David Malone X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: IPv6 WG , Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245269696==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1245269696== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--752565855; protocol="application/pkcs7-signature" --Apple-Mail-1--752565855 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi David, On Jan 4, 2006, at 16:52, David Malone wrote: > On Wed, Jan 04, 2006 at 04:08:01PM -0500, Brian Haberman wrote: >> I have integrated most of the changes I proposed to the ICMP >> Names >> draft. After my previous note on the subject, I had a lot of input on >> the tunnel endpoint text and determined that there was not consensus >> to add >> it to the document. > > Some text seems to have been added to the draft that I don't remember > being discussed here. The diff is: > > node MAY be configured to discard NI Queries > to > multicast addresses other than its NI Group Address(es) but if so, > - the default configuration MUST be not to discard them. > + the default configuration SHOULD be not to discard them. An > + exception is made in the previous rule in the case of the > All-Routers > + (FF02::2) and All-Nodes (FF02::1) multicast addresses. The default > + configuration for responding to NI Queries to these multicast > + addresses MUST be to discard them. > > All-nodes is one of the most useful addresses to send a node > information query to. If you are trying to find a newly configured > bit of kit you've just plugged in you'll query the all nodes address > and see if it responds with a recognisable name. Requiring that > nodes do not respond by default makes this far less useful. This change was made to address DoS concerns raised with having the default behavior to respond to queries to the All-Nodes address. Some people have argued that allowing nodes to respond in this case simplifies an attacker's ability to map out a victim network. > > Also, using the all-nodes address would be the solution if you need > to use NI queries on a network that has a mix of machines using the > old draft and the new draft. I sort of articulated this in this > message: > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05925.html > > without this, I don't see an obvious way to manage such a network > without sending messages to two multicast addresses, which weakens > the argument for changing the multicast range. The change in multicast addresses was introduced to conform to RFC 3307. > > (In fact, in the last around of discussions, several people suggested > ditching the hashed name lookups and just keeping the unicast and > regular multicast lookups, so this seems a very strange change to > make.) The primary goal of this work is to document what has already been implemented. Making the change to the multicast address was discussed with people who have already implemented the protocol to ensure it would not be a big impact. Eliminating hashed name lookups would make this protocol a new protocol (in my opinion at least). Do others have concerns with the document as it is? Regards, Brian --Apple-Mail-1--752565855 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMTA1MTM0MDI0WjAjBgkqhkiG9w0B CQQxFgQUhcQ4fgFdUtydnb7B8NFBIwpYp+gweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAQj5yMzoysNR/4uR0lzAilR58bVwAF9JZ3zohKbSQTXZhdswvuC/LpW9MnLRnqyDL8MOe voT0WP5O4HQapC+KuhPvqBZoT/E6T+AsutmwiDxBhHsWUG+H8PXWjYHaK0eCEHFEP5C7OxXftuP1 uxjzZ9Fh2Kx1Y82u81CE+FWKUtJBIwpUIpo3+aREZMCCbpJw7GNBlN4DwIx23TDIcDfCJGPk1DhE 3xTP4jfBJteQqJP3FDT+XilhAD8CpajtDAJA936hKwJvx6BlcLhRiqxVkCCytccT0dDwQFfaQhBe Y28BOO8hzd5RenKsRecVCQ1lkmW1LU665UHBF6CZhScXsgAAAAAAAA== --Apple-Mail-1--752565855-- --===============1245269696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1245269696==-- From ipv6-bounces@ietf.org Thu Jan 05 10:39:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXD8-0004A7-Gl; Thu, 05 Jan 2006 10:39:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXD4-00048R-0X for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 10:39:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27872 for ; Thu, 5 Jan 2006 10:38:09 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuXIk-0006bD-Uj for ipv6@ietf.org; Thu, 05 Jan 2006 10:45:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id k05Fcv109883; Thu, 5 Jan 2006 17:38:57 +0200 Date: Thu, 5 Jan 2006 17:38:57 +0200 (EET) From: Pekka Savola To: Brian Haberman In-Reply-To: <0a57add5ffb69b534504bd3e91de2acd@innovationslab.net> Message-ID: References: <20060104215250.GA25212@walton.maths.tcd.ie> <0a57add5ffb69b534504bd3e91de2acd@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: David Malone , Bob Hinden , IPv6 WG Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 5 Jan 2006, Brian Haberman wrote: >> Some text seems to have been added to the draft that I don't remember >> being discussed here. The diff is: >> >> node MAY be configured to discard NI Queries to >> multicast addresses other than its NI Group Address(es) but if so, >> - the default configuration MUST be not to discard them. >> + the default configuration SHOULD be not to discard them. An >> + exception is made in the previous rule in the case of the All-Routers >> + (FF02::2) and All-Nodes (FF02::1) multicast addresses. The default >> + configuration for responding to NI Queries to these multicast >> + addresses MUST be to discard them. >> >> All-nodes is one of the most useful addresses to send a node >> information query to. If you are trying to find a newly configured >> bit of kit you've just plugged in you'll query the all nodes address >> and see if it responds with a recognisable name. Requiring that >> nodes do not respond by default makes this far less useful. > > This change was made to address DoS concerns raised with having > the default behavior to respond to queries to the All-Nodes address. > Some people have argued that allowing nodes to respond in this > case simplifies an attacker's ability to map out a victim network. ... > Do others have concerns with the document as it is? Yes. I completely agree with David on this. A NIQ to the link-local all-hosts or all-routers group is a very useful feature (maybe even the most useful for ICMP NIQ), and I don't think it's good to forbid that. It doesn't even really give much security. If you have access to the link, you can pretty much observe which nodes are on the link anyway using dozens of mechanisms such as: - pinging all-routers/all-hosts mcast address and then sending individual NIQ's - looking at the ND packets that fly by - etc. -- 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 ipv6-bounces@ietf.org Thu Jan 05 10:43:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXH0-00069H-Gj; Thu, 05 Jan 2006 10:43:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXGy-000696-6S for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 10:43:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28326 for ; Thu, 5 Jan 2006 10:42:11 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuXMd-0006lH-8Y for ipv6@ietf.org; Thu, 05 Jan 2006 10:49:22 -0500 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 5 Jan 2006 15:43:18 +0000 (GMT) Date: Thu, 5 Jan 2006 15:43:14 +0000 From: David Malone To: Brian Haberman Message-ID: <20060105154314.GA34993@walton.maths.tcd.ie> References: <20060104215250.GA25212@walton.maths.tcd.ie> <0a57add5ffb69b534504bd3e91de2acd@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a57add5ffb69b534504bd3e91de2acd@innovationslab.net> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: David Malone , IPv6 WG , Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Jan 05, 2006 at 08:40:23AM -0500, Brian Haberman wrote: > This change was made to address DoS concerns raised with having > the default behavior to respond to queries to the All-Nodes address. Echo requests already have this problem. I have a feeling that it makes no sense to drop queries to ff02::1 unless you also do the same for all other ICMP types that require a response. > Some people have argued that allowing nodes to respond in this > case simplifies an attacker's ability to map out a victim network. Currently to get a list of names I issue NI queries by using: ping6 -w ff02::1 I get the answer in 1+N packets. After this change to the draft I do this: ping6 ff02::1 > responders for $addr in `cat responders`; do; ping6 -w $addr ; done Now I have the same list of names, I've just had to use 1+3N packets That won't deter any attacker, but makes the life harder for the person who actually wants to use NI queries for some legitimate reason. Maybe all this has been covered in a discussion somewhere already? I did spend a while searching for such a discussion, but didn't turn up anything useful. > The change in multicast addresses was introduced to conform to RFC > 3307. Yes - though I thought part of Ron's motivation for the change was to avoid sending NI queries to hosts that didn't want them. Regardless, I'm OK with changing the multicast address range as long as it is still possible to query ff02::1. > The primary goal of this work is to document what has already been > implemented. Making the change to the multicast address was discussed > with people who have already implemented the protocol to ensure it > would not be a big impact. Eliminating hashed name lookups would > make this protocol a new protocol (in my opinion at least). Changing the multicast range or eliminating hashed name lookups would be easy implementation changes I guess. I'm just trying to consider the usability of the protocol, which doesn't have much to do with how hard it is to implement. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 05 18:05:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueAX-0004nU-Hd; Thu, 05 Jan 2006 18:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueAU-0004nK-Uz for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 18:05:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06861 for ; Thu, 5 Jan 2006 18:03:59 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EueGF-0002RZ-QG for ipv6@ietf.org; Thu, 05 Jan 2006 18:11:13 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 5 Jan 2006 15:05:03 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 15:05:02 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 15:05:02 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 15:05:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2006 15:04:54 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC11514D9E3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt thread-index: AcXSNJTcdGSVKnWqTaqSRW+EeTCC/AAIdsGgD/zKtqA= From: "Dave Thaler" To: X-OriginalArrivalTime: 05 Jan 2006 23:05:01.0911 (UTC) FILETIME=[75298E70:01C6124C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The draft in the RFC-editors queue now references obsoleted (as of last month) RFCs. Specifically: RFC2401 is now obsoleted by RFC4301 RFC2402 is now obsoleted by RFC4302 RFC2404 is now obsoleted by RFC4305 RFC2406 is now obsoleted by RFC4303, RFC4305 RFC2407,2408,2409 are now obsoleted by RFC4306 Also two statements in section 8 are now obsolete as a result: "RFC-2401 is being updated by the IPsec Working Group." "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." Can these be updated? -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 05 18:34:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euecm-0006nA-PC; Thu, 05 Jan 2006 18:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euecl-0006n5-8x for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 18:34:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10914 for ; Thu, 5 Jan 2006 18:33:11 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EueiW-0003YH-EZ for ipv6@ietf.org; Thu, 05 Jan 2006 18:40:25 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k05NU37Z001258 for ; Fri, 6 Jan 2006 01:30:07 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 01:34:20 +0200 Received: from [172.19.69.52] ([172.19.69.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 Jan 2006 01:34:20 +0200 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IPv6 WG From: Bob Hinden Date: Thu, 5 Jan 2006 15:34:27 -0800 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 23:34:20.0659 (UTC) FILETIME=[8D753430:01C61250] X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This starts a two week IPv6 working group last call on publishing Title : IPv6 Node Information Queries Author(s) : M. Crawford, B. Haberman Filename : draft-ietf-ipngwg-icmp-name-lookups-13.txt Pages : 15 Date : 2006-1-4 as an Experimental RFC. Please send substantive comments to the IPv6 mailing list. Editorial comments can be sent to the authors. Also, note the current discussion on the IPv6 mailing list started by David Malone. This last call will end on January 19, 2005. Regards, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 05 18:36:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eueea-0007OS-H9; Thu, 05 Jan 2006 18:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueeX-0007KS-0k for ipv6@megatron.ietf.org; Thu, 05 Jan 2006 18:36:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11072 for ; Thu, 5 Jan 2006 18:35:01 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuekI-0003bm-Cd for ipv6@ietf.org; Thu, 05 Jan 2006 18:42:15 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k05NaAuw031410; Fri, 6 Jan 2006 01:36:12 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 01:36:11 +0200 Received: from [172.19.69.52] ([172.19.69.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 Jan 2006 01:36:10 +0200 In-Reply-To: References: <20060104215250.GA25212@walton.maths.tcd.ie> <0a57add5ffb69b534504bd3e91de2acd@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Thu, 5 Jan 2006 15:36:16 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 23:36:10.0935 (UTC) FILETIME=[CF2FFC70:01C61250] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: David Malone , Brian Haberman , IPv6 WG Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >> This change was made to address DoS concerns raised with having >> the default behavior to respond to queries to the All-Nodes address. >> Some people have argued that allowing nodes to respond in this >> case simplifies an attacker's ability to map out a victim network. > ... >> Do others have concerns with the document as it is? > > Yes. I completely agree with David on this. A NIQ to the link- > local all-hosts or all-routers group is a very useful feature > (maybe even the most useful for ICMP NIQ), and I don't think it's > good to forbid that. I agree as well. This is one of the main uses for NIQ. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 06 03:24:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EumtN-0002Ij-Ld; Fri, 06 Jan 2006 03:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EumtL-0002GK-8x for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 03:24:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14675 for ; Fri, 6 Jan 2006 03:22:50 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EumzA-0001mr-Ug for ipv6@ietf.org; Fri, 06 Jan 2006 03:30:10 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B7A05898D0; Fri, 6 Jan 2006 10:23:38 +0200 (EET) Message-ID: <43BE2928.3090706@kolumbus.fi> Date: Fri, 06 Jan 2006 10:24:08 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler References: <2E33960095B58E40A4D3345AB9F65EC11514D9E3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC11514D9E3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, ipv6@ietf.org Subject: Re: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org They should be updated. By the way I noticed recently that the RFC Editor does not necessarily do "obsoleted by" updates to references automatically. This stuff needs to be done by the authors in AUTH48. And in this particular case we have even text changes, as you point out. By the way, there are also substantive changes in the new IPsec documents. For instance, AH support is no longer a MUST. I think this should be reflected in the node requirements document too, as that currently says "AH [RFC-2402] MUST be supported.". There's probably an impact in the algorithms and key management sections, too... --Jari Dave Thaler wrote: >The draft in the RFC-editors queue now references obsoleted (as of last >month) RFCs. Specifically: > RFC2401 is now obsoleted by RFC4301 > RFC2402 is now obsoleted by RFC4302 > RFC2404 is now obsoleted by RFC4305 > RFC2406 is now obsoleted by RFC4303, RFC4305 > RFC2407,2408,2409 are now obsoleted by RFC4306 > >Also two statements in section 8 are now obsolete as a result: > "RFC-2401 is being updated by the IPsec Working Group." > "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." > >Can these be updated? > >-Dave > >-------------------------------------------------------------------- >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 ipv6-bounces@ietf.org Fri Jan 06 05:29:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euoqv-000354-UQ; Fri, 06 Jan 2006 05:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euoqs-000322-Qa for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 05:29:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21393 for ; Fri, 6 Jan 2006 05:28:25 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euowj-0005A2-PD for ipv6@ietf.org; Fri, 06 Jan 2006 05:35:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id k06ATFh29801; Fri, 6 Jan 2006 12:29:15 +0200 Date: Fri, 6 Jan 2006 12:29:15 +0200 (EET) From: Pekka Savola To: Jari Arkko In-Reply-To: <43BE2928.3090706@kolumbus.fi> Message-ID: References: <2E33960095B58E40A4D3345AB9F65EC11514D9E3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <43BE2928.3090706@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: john.loughney@nokia.com, ipv6@ietf.org, Dave Thaler Subject: Re: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 6 Jan 2006, Jari Arkko wrote: > By the way, there are also substantive changes in the > new IPsec documents. For instance, AH support is no > longer a MUST. I think this should be reflected in the > node requirements document too, as that currently > says "AH [RFC-2402] MUST be supported.". > > There's probably an impact in the algorithms and key > management sections, too... Do we need or want to change these at this point? Obsoleting is just, well.. obsoleting. The implementations conforming to the old specs aren't going away any time soon. I guess the proper resolution depends on whether we want the document focus on: 1) what we think the node requirements are now (or were a year ago) 2) what we think the node requirements should be in a couple of years (as nobody is fulfilling them at present) 3) what we think the node requirements would be in an "ideal world" (where only specifications exist, not implementations) FWIW, I have a document in a slightly similar situation (but still different as it's not a requirements doc) but not so far in the process (draft-ietf-v6ops-ipsec-tunnels-01.txt). It covers both IKEv1 and IKEv2, and both old and new IPsec architectures. Even though the old ones are now obsolete, I'm not going to remove the support and text on the obsolete ones. -- 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 ipv6-bounces@ietf.org Fri Jan 06 07:45:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuqyJ-00006Q-I9; Fri, 06 Jan 2006 07:45:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuqyG-00005X-T6 for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 07:45:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28833 for ; Fri, 6 Jan 2006 07:44:12 -0500 (EST) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eur49-0000K1-3j for ipv6@ietf.org; Fri, 06 Jan 2006 07:51:34 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 6 Jan 2006 12:45:26 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Fri, 6 Jan 2006 12:43:38 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jan 2006 06:43:33 -0600 Message-ID: <041052AD735329479241C23E0813EB7E9768BF@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: IPv6 WG Last Call: Thread-Index: AcYSUb/0iss3fqBzQ6O8sudBjEgjXAAbHvAg From: "Pashby, Ronald W CTR NSWCDD-B35" To: X-OriginalArrivalTime: 06 Jan 2006 12:43:34.0971 (UTC) FILETIME=[CED3C8B0:01C612BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Subject: FW: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I was confused when I read the draft about the change to the multicast = address. I reread the draft and realized where the confusion arrises in = the second paragraph of section 5 it states: "Append the first 32 bits of that 128-bit hash to the prefix = FF02:0:0:0:0:2:FF::/104."=20 Should this read:=20 "Append the first 24 bits of that 128-bit hash to the prefix = FF02:0:0:0:0:2:FF::/104." -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of Bob Hinden Sent: Thursday, January 05, 2006 18:34 To: IPv6 WG Subject: IPv6 WG Last Call: This starts a two week IPv6 working group last call on publishing Title : IPv6 Node Information Queries Author(s) : M. Crawford, B. Haberman Filename : draft-ietf-ipngwg-icmp-name-lookups-13.txt Pages : 15 Date : 2006-1-4 as an Experimental RFC. Please send substantive comments to the IPv6 =20 mailing list. Editorial comments can be sent to the authors. Also, =20 note the current discussion on the IPv6 mailing list started by David =20 Malone. This last call will end on January 19, 2005. Regards, 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 06 08:21:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EurX2-0005Uj-PP; Fri, 06 Jan 2006 08:21:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EurX0-0005Ub-AE for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 08:21:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01175 for ; Fri, 6 Jan 2006 08:20:06 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eurcp-0001UO-U6 for ipv6@ietf.org; Fri, 06 Jan 2006 08:27:28 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k06DKZWT170194 for ; Fri, 6 Jan 2006 13:20:42 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k06DKR1n037458 for ; Fri, 6 Jan 2006 14:20:27 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k06DKQ3F026407 for ; Fri, 6 Jan 2006 14:20:26 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k06DKQkX026389; Fri, 6 Jan 2006 14:20:26 +0100 Received: from zurich.ibm.com (sig-9-145-249-81.de.ibm.com [9.145.249.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA83072; Fri, 6 Jan 2006 14:20:25 +0100 Message-ID: <43BE6E94.6050201@zurich.ibm.com> Date: Fri, 06 Jan 2006 14:20:20 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Jari Arkko References: <2E33960095B58E40A4D3345AB9F65EC11514D9E3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <43BE2928.3090706@kolumbus.fi> In-Reply-To: <43BE2928.3090706@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, ipv6@ietf.org, Dave Thaler Subject: Re: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org IMHO, the reference updates should be done during AUTH48 without further discussion, but making AH optional seems like a substantive change. Personally, I would support that change, i.e. s/MUST/MAY/. Brian (speaking only for myself) Jari Arkko wrote: > They should be updated. By the way I noticed recently > that the RFC Editor does not necessarily do "obsoleted by" > updates to references automatically. This stuff needs to > be done by the authors in AUTH48. And in this particular > case we have even text changes, as you point out. > > By the way, there are also substantive changes in the > new IPsec documents. For instance, AH support is no > longer a MUST. I think this should be reflected in the > node requirements document too, as that currently > says "AH [RFC-2402] MUST be supported.". > > There's probably an impact in the algorithms and key > management sections, too... > > --Jari > > Dave Thaler wrote: > >> The draft in the RFC-editors queue now references obsoleted (as of last >> month) RFCs. Specifically: >> RFC2401 is now obsoleted by RFC4301 >> RFC2402 is now obsoleted by RFC4302 >> RFC2404 is now obsoleted by RFC4305 >> RFC2406 is now obsoleted by RFC4303, RFC4305 >> RFC2407,2408,2409 are now obsoleted by RFC4306 >> >> Also two statements in section 8 are now obsolete as a result: >> "RFC-2401 is being updated by the IPsec Working Group." >> "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." >> >> Can these be updated? >> >> -Dave >> >> -------------------------------------------------------------------- >> 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 ipv6-bounces@ietf.org Fri Jan 06 10:30:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutYL-0005Wb-9n; Fri, 06 Jan 2006 10:30:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutYJ-0005WW-Qt for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 10:30:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08210 for ; Fri, 6 Jan 2006 10:29:34 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuteE-00053c-ME for ipv6@ietf.org; Fri, 06 Jan 2006 10:36:58 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Jan 2006 10:30:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Fri, 6 Jan 2006 10:30:37 -0500 Message-ID: Thread-Topic: Fwd: Request To Advance: Thread-Index: AcYR0RUkOLgB2XEeQBeCV7ptm3vlBAAFv+bwADs+rjA= From: "Soliman, Hesham" To: "IPv6 WG" X-OriginalArrivalTime: 06 Jan 2006 15:30:37.0188 (UTC) FILETIME=[2488BC40:01C612D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Subject: Sending ICMP error upon receiving an NA without SLLAO in 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, This is a mini concensus call on the discussion I had with Jinmei below. The basic issue left is whether we should allow a node to send an ICMP error due to the reception of an NA without the SLLAO. The reason for sending the ICMP error is to inform upper layers that the communication has failed. The current spec says that such message SHOULD be silently discarded (see section 7.2 and section 7.2.5 in http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-05.txt). However, it would be useful to inform upper layers of such failures. ICMP is the natural choice for transmitting the error message. Implementing this feature would be optional and should not have problems with backward compatibility. I don't know if this would be considered a substantive change to the current spec. IMHO it can easily pass as a clarification. Please express your opinion on whether we could add this clarification to the spec or keep it as is. Hesham > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On > Behalf Of Soliman, Hesham > Sent: Thursday, January 05, 2006 6:09 AM > To: JINMEI Tatuya / ???? > Cc: IPv6 WG > Subject: RE: Fwd: Request To Advance: > > > > > > > > => Not in the main text, which is why I suggested above > > that we can add it > > > to section 7.2. > > > > I see. As I said in the previous message (see also > below), we should > > first make a consensus about whether this is to be added. > Then, if > > the result is positive, we should explicitly add the corresponding > > text to 7.2 (in general, the appendix should be a summary > of the main > > text, IMO). > > => Agreed. > > > > > (snip) > > > > >> I > > >> believe it makes more sense to discard the bogus packets > > silently as > > >> described in the body of the draft (Section 7.2.4) rather > > than taking > > >> a specific action like sending an ICMPv6 error message. > > > > > => I don't think that's a good way to handle it, but the > > current text inherited from > > > 2461 agrees with you. I don't think it breaks backward > > compatibility to mention this > > > in the appendix as an optional behaviour (sending the ICMP > > error). Are you ok with > > > having this as an optional behaviour in the appendix? others? > > > > I don't have a strong opinion on either way (whether or > not including > > this feature). As you said, it may help in some cases > (e.g., an end > > host may be able to give up connecting to a non-compliant > remote host > > faster). But since this may require a change to the existing > > implementation, I'd like to see an explicit consensus about the > > additional behavior (i.e., 'no objection' would not suffice). > > => That's fine. I'll send a separate email to ask if people > agree with adding > the ICMP part as an optional feature. > > Hesham > > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > =========================================================== > This email may contain confidential and privileged material > for the sole use > of the intended recipient. Any review or distribution by > others is strictly > prohibited. If you are not the intended recipient please > contact the sender > and delete all copies. > =========================================================== > > > -------------------------------------------------------------------- > 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 ipv6-bounces@ietf.org Fri Jan 06 10:57:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutyP-0007Te-KL; Fri, 06 Jan 2006 10:57:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EutyM-0007Sp-Tc for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 10:57:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10196 for ; Fri, 6 Jan 2006 10:56:29 -0500 (EST) Received: from zcars04f.nortel.com ([47.129.242.57] helo=zcars04f.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euu4G-0005xm-BN for ipv6@ietf.org; Fri, 06 Jan 2006 11:03:53 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k06FvPK04131 for ; Fri, 6 Jan 2006 10:57:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jan 2006 10:56:54 -0500 Message-ID: Thread-Topic: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt Thread-Index: AcYS2dB/wLlRAy/ORp+0doDxCTaNWA== From: "Dwight Jamieson" To: X-Spam-Score: 0.9 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0944885158==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0944885158== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C612D9.D0DC28EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C612D9.D0DC28EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was some discussion at the Paris IPv6 WG meeting about allocating /56 to small end sites. There was a suggestion that the IAB comment regarding this policy.=20 I am a member of the ATIS IPv6 task force http://www.atis.org/and We will be making recommendations to ATIS members on various things such as allocation policy.=20 I haven't seen anything from ARIN or the IETF on this issue since August.=20 Cheers, Dwight ------_=_NextPart_001_01C612D9.D0DC28EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question regarding = draft-narten-ipv6-3177bis-48boundary-00.txt

There was some discussion at the Paris = IPv6 WG meeting about allocating /56 to small end sites. There was a = suggestion that the IAB comment regarding this policy.

I am a member of the ATIS IPv6 task = force http://www.atis.org/and   We will be making recommendations to ATIS = members on various things such as allocation policy.

I haven't seen anything from ARIN or = the IETF on this issue since August.

Cheers,
Dwight

------_=_NextPart_001_01C612D9.D0DC28EC-- --===============0944885158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0944885158==-- From ipv6-bounces@ietf.org Fri Jan 06 13:05:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvxU-0002rp-IP; Fri, 06 Jan 2006 13:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvxS-0002rk-78 for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 13:04:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18882 for ; Fri, 6 Jan 2006 13:03:42 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euw3O-0001Rw-36 for ipv6@ietf.org; Fri, 06 Jan 2006 13:11:06 -0500 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001541722.msg for ; Fri, 06 Jan 2006 19:06:36 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 06 Jan 2006 19:04:32 +0100 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" Message-ID: Thread-Topic: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt Thread-Index: AcYS2dB/wLlRAy/ORp+0doDxCTaNWAAEdRog In-Reply-To: Mime-version: 1.0 X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00, HTML_FONTCOLOR_BLUE, HTML_MESSAGE,TO_ADDRESS_EQ_REAL autolearn=no version=2.64 X-Spam-Processed: consulintel.es, Fri, 06 Jan 2006 19:06:41 +0100 X-MDAV-Processed: consulintel.es, Fri, 06 Jan 2006 19:06:45 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: Re: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0343739229==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >Este mensaje tiene formato MIME. Al no reconocer su lector de correo este formato, puede que todo o parte del mensaje resulte ilegible. --===============0343739229== Content-type: multipart/alternative; boundary="B_3219419075_1359837" >Este mensaje tiene formato MIME. Al no reconocer su lector de correo este formato, puede que todo o parte del mensaje resulte ilegible. --B_3219419075_1359837 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I think there has not been any agreement to proceed with that in any RIR at the time being, but I=B9m not 100% sure. My personal opinion is also that we should not do that change. I think is more possible to agree on the HD-ratio change, and in fact the policy proposed at APNIC (suggesting the HD-ratio change+/56) was rejected and suggested to split in two proposals. My recommendation to ISPs is still to allocate /48 to every customer. This also helps to simplify management, so at the end is a benefit for them. Big allocations are being done to big ISPs also following this rule (a new /19 has been allocated a week ago in Europe). Regards, Jordi De: Dwight Jamieson Responder a: Fecha: Fri, 6 Jan 2006 10:56:54 -0500 Para: Conversaci=F3n: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt Asunto: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt There was some discussion at the Paris IPv6 WG meeting about allocating /56 to small end sites. There was a suggestion that the IAB comment regarding this policy.=20 I am a member of the ATIS IPv6 task force http://www.atis.org/and We will be making recommendations to ATIS members on various things such as allocation policy. I haven't seen anything from ARIN or the IETF on this issue since August. Cheers,=20 Dwight=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. --B_3219419075_1359837 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt I think there has not been any agreement to proceed with that in any RIR at the time being, but I’m not 100% sure.

My personal opinion is also that we should not do that change. I think is more possible to agree on the HD-ratio change, and in fact the policy proposed at APNIC (suggesting the HD-ratio change+/56) was rejected and suggested to split in two proposals.

My recommendation to ISPs is still to allocate /48 to every customer. This also helps to simplify management, so at the end is a benefit for them. Big allocations are being done to big ISPs also following this rule (a new /19 has been allocated a week ago in Europe).

Regards,
Jordi




De: Dwight Jamieson <djamies@nortel.com>
Responder a: <ipv6-bounces@ietf.org>
Fecha: Fri, 6 Jan 2006 10:56:54 -0500
Para: <ipv6@ietf.org>
Conversación: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt
Asunto: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt



There was some discussion at the Paris IPv6 WG meeting about allocating /56 to small end sites. There was a suggestion that the IAB comment regarding this policy.

I am a member of the ATIS IPv6 task force http://www.atis.org/and <http://www.atis.org/and>   We will be making recommendations to ATIS members on various things such as allocation policy.

I haven't seen anything from ARIN or the IETF on this issue since August.

Cheers,
Dwight

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

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

--B_3219419075_1359837-- --===============0343739229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0343739229==-- From ipv6-bounces@ietf.org Fri Jan 06 16:30:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuzAh-0000Nl-9Z; Fri, 06 Jan 2006 16:30:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuzAf-0000Ng-Rv for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 16:30:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13287 for ; Fri, 6 Jan 2006 16:29:29 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuzGZ-0002WA-EB for ipv6@ietf.org; Fri, 06 Jan 2006 16:36:56 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 6 Jan 2006 13:30:35 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:30:34 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:30:34 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:30:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jan 2006 13:30:30 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC11514E166@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcXSNJTcdGSVKnWqTaqSRW+EeTCC/AAIdsGgD/zKtqAAL7EawA== From: "Dave Thaler" To: X-OriginalArrivalTime: 06 Jan 2006 21:30:34.0304 (UTC) FILETIME=[6D6B1C00:01C61308] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Here's another one: RFC2893 is now obsoleted by RFC4213 Section 6.l.1 says: "RFC 2893 is currently being updated." > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Thursday, January 05, 2006 3:05 PM > To: john.loughney@nokia.com > Cc: ipv6@ietf.org > Subject: draft-ietf-ipv6-node-requirements-11.txt >=20 > The draft in the RFC-editors queue now references obsoleted (as of last > month) RFCs. Specifically: > RFC2401 is now obsoleted by RFC4301 > RFC2402 is now obsoleted by RFC4302 > RFC2404 is now obsoleted by RFC4305 > RFC2406 is now obsoleted by RFC4303, RFC4305 > RFC2407,2408,2409 are now obsoleted by RFC4306 >=20 > Also two statements in section 8 are now obsolete as a result: > "RFC-2401 is being updated by the IPsec Working Group." > "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." >=20 > Can these be updated? >=20 > -Dave >=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 ipv6-bounces@ietf.org Sat Jan 07 02:49:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev8pj-0005sm-6Q; Sat, 07 Jan 2006 02:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev8ph-0005sh-0I for ipv6@megatron.ietf.org; Sat, 07 Jan 2006 02:49:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22265 for ; Sat, 7 Jan 2006 02:48:32 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev8vj-00033K-Ay for ipv6@ietf.org; Sat, 07 Jan 2006 02:56:04 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k077njAD005094; Sat, 7 Jan 2006 09:49:45 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jan 2006 09:49:45 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jan 2006 09:49:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Jan 2006 09:49:44 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869A74@esebe100.NOE.Nokia.com> Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcXSNJTcdGSVKnWqTaqSRW+EeTCC/AAIdsGgD/zKtqAAL7EawAAVnguA To: X-OriginalArrivalTime: 07 Jan 2006 07:49:45.0545 (UTC) FILETIME=[ED489B90:01C6135E] X-Spam-Score: 0.4 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I'll take a look at all of this on Monday and work text up. I'll send the text to the WG, and if there is agreement, I can make the=20 updates during AUTH48. John=20 >-----Original Message----- >From: ext Dave Thaler [mailto:dthaler@windows.microsoft.com]=20 >Sent: 06 January, 2006 23:31 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: ipv6@ietf.org >Subject: RE: draft-ietf-ipv6-node-requirements-11.txt > >Here's another one: >RFC2893 is now obsoleted by RFC4213 > >Section 6.l.1 says: >"RFC 2893 is currently being updated." > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >Of >> Dave Thaler >> Sent: Thursday, January 05, 2006 3:05 PM >> To: john.loughney@nokia.com >> Cc: ipv6@ietf.org >> Subject: draft-ietf-ipv6-node-requirements-11.txt >>=20 >> The draft in the RFC-editors queue now references obsoleted (as of >last >> month) RFCs. Specifically: >> RFC2401 is now obsoleted by RFC4301 >> RFC2402 is now obsoleted by RFC4302 >> RFC2404 is now obsoleted by RFC4305 >> RFC2406 is now obsoleted by RFC4303, RFC4305 >> RFC2407,2408,2409 are now obsoleted by RFC4306 >>=20 >> Also two statements in section 8 are now obsolete as a result: >> "RFC-2401 is being updated by the IPsec Working Group." >> "RFC-2406 and RFC 2402 are being updated by the IPsec Working >Group." >>=20 >> Can these be updated? >>=20 >> -Dave >>=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 ipv6-bounces@ietf.org Sun Jan 08 00:00:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvSfR-0001cY-OW; Sun, 08 Jan 2006 00:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvSfP-0001cM-FQ for ipv6@megatron.ietf.org; Sun, 08 Jan 2006 00:00:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28571 for ; Sat, 7 Jan 2006 23:59:12 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvSlb-0001Er-CR for ipv6@ietf.org; Sun, 08 Jan 2006 00:06:57 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 056EAA50 for ; Sun, 8 Jan 2006 00:00:10 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 08 Jan 2006 00:00:10 -0500 Message-Id: <20060108050011.056EAA50@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.00% | 3 | 11.74% | 20880 | timbeck04@verizon.net 10.00% | 3 | 10.98% | 19528 | h.soliman@flarion.com 6.67% | 2 | 11.57% | 20576 | brian@innovationslab.net 6.67% | 2 | 7.71% | 13710 | jspence@native6.com 6.67% | 2 | 5.47% | 9733 | pekkas@netcore.fi 6.67% | 2 | 5.13% | 9127 | dthaler@windows.microsoft.com 6.67% | 2 | 4.52% | 8039 | bob.hinden@nokia.com 3.33% | 1 | 5.61% | 9969 | jordi.palet@consulintel.es 3.33% | 1 | 3.79% | 6739 | huitema@windows.microsoft.com 3.33% | 1 | 3.59% | 6386 | internet-drafts@ietf.org 3.33% | 1 | 3.43% | 6098 | brc@zurich.ibm.com 3.33% | 1 | 3.20% | 5695 | djamies@nortel.com 3.33% | 1 | 2.93% | 5220 | dwmalone@maths.tcd.ie 3.33% | 1 | 2.87% | 5111 | john.loughney@nokia.com 3.33% | 1 | 2.84% | 5058 | jinmei@isl.rdc.toshiba.co.jp 3.33% | 1 | 2.81% | 4989 | dwmalone=v6lists@maths.tcd.ie 3.33% | 1 | 2.75% | 4896 | ronald.pashby.ctr@navy.mil 3.33% | 1 | 2.56% | 4555 | jari.arkko@kolumbus.fi 3.33% | 1 | 2.40% | 4265 | mailer-daemon@ktf.com 3.33% | 1 | 2.15% | 3821 | mailman-owner@ietf.org 3.33% | 1 | 1.95% | 3461 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 30 |100.00% | 177856 | 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 ipv6-bounces@ietf.org Sun Jan 08 22:39:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evnso-00016n-CI; Sun, 08 Jan 2006 22:39:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evnsj-00016c-6X for ipv6@megatron.ietf.org; Sun, 08 Jan 2006 22:39:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10396 for ; Sun, 8 Jan 2006 22:38:22 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evnz7-0005xZ-Rl for ipv6@ietf.org; Sun, 08 Jan 2006 22:46:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2006 19:39:16 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcYSxDLZ0btyQAz6TpGEIP66SRAFrgCCkVIQ From: "Vishwas Manral" To: "Brian E Carpenter" , "Jari Arkko" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: john.loughney@nokia.com, ipv6@ietf.org, Dave Thaler Subject: RE: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Brian/ Jari, I see a few more inconsistencies regarding the same RFC:=20 Since ESP encryption and authentication are both optional, support for the NULL encryption algorithm [RFC-2410] and the NULL authentication algorithm [RFC-2406] MUST be provided to maintain consistency with the way these services are negotiated. >From RFC4301 - confidentiality-only (MAY be supported) - integrity only (MUST be supported) - confidentiality and integrity (MUST be supported) I think only encryption is now optional in RFC4301. We do not necessarily need to allow NULL authentication either. Actually this is still a problem with RFC4305 and it was not updated because the issue was found late in the RFC process. Thanks, Vishwas -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, January 06, 2006 6:50 PM To: Jari Arkko Cc: john.loughney@nokia.com; ipv6@ietf.org; Dave Thaler Subject: Re: draft-ietf-ipv6-node-requirements-11.txt IMHO, the reference updates should be done during AUTH48 without further discussion, but making AH optional seems like a substantive change. Personally, I would support that change, i.e. s/MUST/MAY/. Brian (speaking only for myself) Jari Arkko wrote: > They should be updated. By the way I noticed recently > that the RFC Editor does not necessarily do "obsoleted by" > updates to references automatically. This stuff needs to > be done by the authors in AUTH48. And in this particular > case we have even text changes, as you point out. >=20 > By the way, there are also substantive changes in the > new IPsec documents. For instance, AH support is no > longer a MUST. I think this should be reflected in the > node requirements document too, as that currently > says "AH [RFC-2402] MUST be supported.". >=20 > There's probably an impact in the algorithms and key > management sections, too... >=20 > --Jari >=20 > Dave Thaler wrote: >=20 >> The draft in the RFC-editors queue now references obsoleted (as of last >> month) RFCs. Specifically: >> RFC2401 is now obsoleted by RFC4301 >> RFC2402 is now obsoleted by RFC4302 >> RFC2404 is now obsoleted by RFC4305 >> RFC2406 is now obsoleted by RFC4303, RFC4305 >> RFC2407,2408,2409 are now obsoleted by RFC4306 >> >> Also two statements in section 8 are now obsolete as a result: >> "RFC-2401 is being updated by the IPsec Working Group." >> "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." >> >> Can these be updated? >> >> -Dave >> >>=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 09 03:18:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvsEj-0001Ck-Ov; Mon, 09 Jan 2006 03:18:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvsEf-0001CN-Mi for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 03:18:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25234 for ; Mon, 9 Jan 2006 03:17:19 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvsL6-0004XB-Vu for ipv6@ietf.org; Mon, 09 Jan 2006 03:25:18 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k098IVHi023139; Mon, 9 Jan 2006 10:18:33 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 10:18:28 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 10:18:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 10:18:27 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869A7D@esebe100.NOE.Nokia.com> Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcYSxDLZ0btyQAz6TpGEIP66SRAFrgCCkVIQAAmsy1A= To: , , X-OriginalArrivalTime: 09 Jan 2006 08:18:28.0302 (UTC) FILETIME=[44F3F6E0:01C614F5] X-Spam-Score: 0.4 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, dthaler@windows.microsoft.com Subject: RE: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Vishwas, >I see a few more inconsistencies regarding the same RFC:=20 > > Since ESP encryption and authentication are both optional, support > for the NULL encryption algorithm [RFC-2410] and the NULL > authentication algorithm [RFC-2406] MUST be provided to maintain > consistency with the way these services are negotiated. > > >From RFC4301 > - confidentiality-only (MAY be supported) > - integrity only (MUST be supported) > - confidentiality and integrity (MUST be supported) > >I think only encryption is now optional in RFC4301. We do not=20 >necessarily need to allow NULL authentication either. Actually=20 >this is still a problem with RFC4305 and it was not updated=20 >because the issue was found late in the RFC process. What was the issue found late with RFC4305? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 09 04:06:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvszG-0000gw-2X; Mon, 09 Jan 2006 04:06:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvszC-0000gl-N5 for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 04:06:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28130 for ; Mon, 9 Jan 2006 04:05:24 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evt5e-0005vv-0S for ipv6@ietf.org; Mon, 09 Jan 2006 04:13:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 01:06:25 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcYSxDLZ0btyQAz6TpGEIP66SRAFrgCCkVIQAAmsy1AAAcS6YA== From: "Vishwas Manral" To: , , X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, dthaler@windows.microsoft.com Subject: RE: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi John, I am referring to the thread and subsequent mails to: http://130.230.52.14/list-archive/ipsec/msg05573.html That said regarding algorithms supported, should we just refer to the RFC's or should we state each of them explicitly. What if the status of algorithm's change (due to some vulnerability found)? Thanks, Vishwas -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Monday, January 09, 2006 1:48 PM To: Vishwas Manral; brc@zurich.ibm.com; jari.arkko@kolumbus.fi Cc: ipv6@ietf.org; dthaler@windows.microsoft.com Subject: RE: draft-ietf-ipv6-node-requirements-11.txt Vishwas, >I see a few more inconsistencies regarding the same RFC:=20 > > Since ESP encryption and authentication are both optional, support > for the NULL encryption algorithm [RFC-2410] and the NULL > authentication algorithm [RFC-2406] MUST be provided to maintain > consistency with the way these services are negotiated. > > >From RFC4301 > - confidentiality-only (MAY be supported) > - integrity only (MUST be supported) > - confidentiality and integrity (MUST be supported) > >I think only encryption is now optional in RFC4301. We do not=20 >necessarily need to allow NULL authentication either. Actually=20 >this is still a problem with RFC4305 and it was not updated=20 >because the issue was found late in the RFC process. What was the issue found late with RFC4305? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 09 07:55:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvwYM-0000eb-LJ; Mon, 09 Jan 2006 07:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvwYK-0000eS-Do for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 07:55:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11897 for ; Mon, 9 Jan 2006 07:53:52 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evwen-0003hA-Rt for ipv6@ietf.org; Mon, 09 Jan 2006 08:01:55 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k09Coe4j004637 for ; Mon, 9 Jan 2006 14:50:40 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 14:54:55 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 14:54:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 14:54:54 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869A8B@esebe100.NOE.Nokia.com> Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcXSNJTcdGSVKnWqTaqSRW+EeTCC/AAIdsGgD/zKtqAAtExIkA== To: X-OriginalArrivalTime: 09 Jan 2006 12:54:55.0645 (UTC) FILETIME=[E3C7A4D0:01C6151B] X-Spam-Score: 0.4 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, I propose to update the Node Requirements to handle these: RFC2401 is now obsoleted by RFC4301 RFC2402 is now obsoleted by RFC4302 RFC2404 is now obsoleted by RFC4305 RFC2406 is now obsoleted by RFC4303, RFC4305 RFC2407,2408,2409 are now obsoleted by RFC4306 Changes are: "AH [RFC-4202] MAY be supported." These texts would be removed: "RFC-2401 is being updated by the IPsec Working Group." "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." The plan would be to update these during AUTH48, assuming the WG agrees with changes. =3D=3D=3D=3D=3D=3D=3D=3D OLD: 8.1 Basic Architecture Security Architecture for the Internet Protocol [RFC-2401] MUST be supported. RFC-2401 is being updated by the IPsec Working Group. NEW: 8.1 Basic Architecture Security Architecture for the Internet Protocol [RFC-4301] MUST be supported.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OLD: 8.2 Security Protocols ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. RFC-2406 and RFC 2402 are being updated by the IPsec Working Group. NEW 8.2 Security Protocols ESP [RFC-4306] MUST be supported. AH [RFC-4302] MAY be supported. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I need to double-check sections 8.3 & 8.4, there are a few changes for these. I will send suggested changes. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 09 11:01:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzSe-0004sv-54; Mon, 09 Jan 2006 11:01:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzSZ-0004s3-5i; Mon, 09 Jan 2006 11:01:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25569; Mon, 9 Jan 2006 11:00:08 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzZ6-0001Cp-0R; Mon, 09 Jan 2006 11:08:12 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EvzSO-0000kf-SI; Mon, 09 Jan 2006 11:01:16 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 09 Jan 2006 11:01:16 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'Optimistic Duplicate Address Detection for IPv6' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'Optimistic Duplicate Address Detection for IPv6 ' as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-07.txt - Technical Summary Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case and to remain interoperable with unmodified hosts and routers. - Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. - Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 09 13:42:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1yD-00006s-PF; Mon, 09 Jan 2006 13:42:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1yB-00006U-MX for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 13:42:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11202 for ; Mon, 9 Jan 2006 13:40:55 -0500 (EST) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew24j-0007ew-Em for ipv6@ietf.org; Mon, 09 Jan 2006 13:49:01 -0500 Received: (qmail 1666 invoked by uid 417); 9 Jan 2006 18:42:07 -0000 Received: from tango-.softhome.net (HELO softhome.net) (172.16.2.14) by shunt-smtp-com-out-com-0 with SMTP; 9 Jan 2006 18:42:07 -0000 Received: from mehr ([132.70.219.75]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 09 Jan 2006 11:42:05 -0700 Message-ID: <004001c6154c$1fd3a660$0401a8c0@mtc.ki.se> From: "Eric Klein" To: ipv6@ietf.org Date: Mon, 9 Jan 2006 20:40:06 +0200 MIME-Version: 1.0 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: Analiyzing the IPv6 list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0146435872==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0146435872== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C6155C.E016C140" This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C6155C.E016C140 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I know that this is a little off topic. As part of my thesis I am trying = to analyze who is taking part in making the IPv6 standard. I have collected some data about the 11 years that the list has been = active, and have found that (not surprisingly) 65% of the messages to = this list come from e-mail addresses ending in .com, .net or .org. Needless to say this makes it hard to identify which country the sender = is sending from (i.e where they are based). So, if your address ends in .com, .net, or .org could you please send me = (no need to send it to the whole list) two things: Which country where you are based: How long you have been based in that country: =20 I realize that this will not reduce the unknown countries to zero, but = this way I can make more accurate conclusions about who is represented = by this mailing list. Thanks, Eric Klein, MSc Ps. If you have an e-mail address that ends in a country TLD that does = not represent where you are actually located, could you also please send = an update. ------=_NextPart_000_003D_01C6155C.E016C140 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
I know that this is a little off topic. = As part of=20 my thesis I am trying to analyze who is taking part in making the IPv6=20 standard.
 
I have collected some data about the 11 = years that=20 the list has been active, and have found that (not surprisingly) 65% of = the=20 messages to this list come from e-mail addresses ending in .com, .net or = .org.
 
Needless to say this makes it hard to = identify=20 which country the sender is sending from (i.e where they are=20 based).
 
So, if your address ends in .com, .net, = or .org=20 could you please send me (no need to send it to the whole list) two=20 things:
 
Which country where you are = based:
How long you have been based in that = country: =20
 
I realize that this will not reduce the = unknown=20 countries to zero, but this way I can make more accurate conclusions = about who=20 is represented by this mailing list.
 
Thanks,
Eric Klein, MSc
 
Ps. If you have an e-mail address that = ends in a=20 country TLD that does not represent where you are actually located, = could you=20 also please send an update.
------=_NextPart_000_003D_01C6155C.E016C140-- --===============0146435872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0146435872==-- From ipv6-bounces@ietf.org Mon Jan 09 17:00:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew53l-0000jx-Hi; Mon, 09 Jan 2006 17:00:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew53j-0000ja-RY for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 17:00:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02136 for ; Mon, 9 Jan 2006 16:58:51 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew5AG-0007XJ-IL for ipv6@ietf.org; Mon, 09 Jan 2006 17:06:58 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k09Lxo9f021445 for ; Mon, 9 Jan 2006 16:59:50 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k09Lxoku093902 for ; Mon, 9 Jan 2006 16:59:50 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k09Lxn5i003442 for ; Mon, 9 Jan 2006 16:59:49 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-212-120.mts.ibm.com [9.65.212.120]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k09Lxnod003373; Mon, 9 Jan 2006 16:59:49 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k09Lxk0e014309; Mon, 9 Jan 2006 16:59:47 -0500 Message-Id: <200601092159.k09Lxk0e014309@cichlid.raleigh.ibm.com> To: "Soliman, Hesham" In-Reply-To: Message from "Soliman, Hesham" of "Fri, 06 Jan 2006 10:30:37 EST." Date: Mon, 09 Jan 2006 16:59:46 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IPv6 WG Subject: Re: Sending ICMP error upon receiving an NA without SLLAO in 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > The basic issue left is whether we should allow a node to send an ICMP error > due to the reception of an NA without the SLLAO. The reason for sending the > ICMP error is to inform upper layers that the communication has > failed. It took me a while to figure out what you are proposing. To summarize: in the case where where a node receives an NA without an SLLAO, but it is expecting an SLLAO (so it can complete the Neighbor Cache Entry), such a received NA is "an error". In the case where a regular data packet is queued pending completion of the NCE, you'd like to be able to send back an ICMP error indicating "dest unreachable". Right? This seems like a fairly minor optimization and one that deals with a a potential "implementation error" (since I understand this situation would normally only arise of the sender of the NA incorrectly left off the SLLAO). If this is the case, IMO, it's not worth modifying the spec to allow this. Indeed, I'd have to think a bit to convince myself that it couldn't lead to potential cases where an ICMP error would be (incorrectly) sent when simply ignoring the faulty NA is actually the more correct response (i.e., if proxies are present and more than one NA is generated). Is this a situation that has come up in actual testing/usage? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 09 18:15:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6F4-00083p-O2; Mon, 09 Jan 2006 18:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6F2-00083a-VD for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 18:15:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06887 for ; Mon, 9 Jan 2006 18:14:37 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6La-0001Gg-Vc for ipv6@ietf.org; Mon, 09 Jan 2006 18:22:45 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k09NBKsj006132; Tue, 10 Jan 2006 01:11:23 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 01:15:46 +0200 Received: from [10.100.0.33] ([10.241.59.170]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Jan 2006 01:15:46 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> Content-Transfer-Encoding: quoted-printable From: Bob Hinden Date: Mon, 9 Jan 2006 09:51:48 -0800 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 09 Jan 2006 23:15:46.0369 (UTC) FILETIME=[9EF10B10:01C61572] X-Spam-Score: 2.0 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jinmei, Sorry for not responding sooner. On Dec 9, 2005, at 9:53 AM, ext JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94= =E5=93=89 wrote: > I believe this was discussed and clarified before, but I could not > find any pointer, so let me ask here... > > It's regarding the "magic number" of 0xFFFE used in the modified > EUI-64 format for the interface identifier of an IPv6 address. > > According to draft-ietf-ipv6-addr-arch-v4-04.txt (or already-published > RFCs), we insert 0xFFFE in the middle of the interface identifier in > order to convert an 48-bit MAC address to the modified EUI-64 format: > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit =20= > MAC > (between the company_id and vendor supplied id). > (in APPENDIX A) > > However, according to [EUI64], we use 0xFFFF (not 0xFFFE) "to create > an EUI-64 identifier from a 48bit MAC identifier" for network devices > (i.e., MAC-48): > > To support encapsulation of EUI-48 and MAC-48 values within small > subsets of the EUI-64 values, the first four digits of the > manufacturer's extension identifier shall not be FFFF16 or > FFFE16. Thus, the 64-bit values of the following form are > never-assigned EUI-64 values: > > ccccccFFFEeeeeee(16) (an EUI-48 extension) > > ccccccFFFFeeeeee(16) (a MAC-48 extension) <=3D=3D=3D=3D = this one > (from http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) > > My question is whether there was any special reason why the IPv6 > addr-arch document specified 0xFFFE. > > I googled and found a web page saying this is "an error": > > Confusingly IPv6 -- one of the most prominent standards that uses > EUI-64 -- applies these rules inconsistenly. Due to an error in the > appendix to the specification of IPv6 addressing, it is currently > standard practice in IPv6 to extend MAC-48 addresses (such as =20 > IEEE 802 > MAC address) to EUI-64 using 'FF-FE' rather than 'FF-FF'; it remains > to be seen how this inconsistency will be resolved in the future. > (http://www.kingj.com/articles/MAC_address) > > Is this true, or was there any particular reason for the "confusing" > choice? I suspect that at the time we thought that an EUI-48 was equivalent =20 to MAC-48. Actually until you sent your email I wasn't aware of the =20 issue. Are there any networks that use EUI-48? I don't think that in practice this causes any problem since we use =20 them to create "modified-EUI-64" based interface identifiers and the =20 main technical requirement for IID is that they are unique on the list. The draft is currently AUTH48 so it might be possible to change the =20 text from MAC-48 to EUI-48, but I would be concerned that this change =20= would cause confusion. I don't think this has caused any confusion =20 for people writing IPv6 over specifications. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jan 09 21:57:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9hQ-0003Xp-CE; Mon, 09 Jan 2006 21:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9hN-0003Xh-Ay for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 21:57:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25090 for ; Mon, 9 Jan 2006 21:56:06 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew9nz-0000Xw-GY for ipv6@ietf.org; Mon, 09 Jan 2006 22:04:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jan 2006 18:57:05 -0800 Message-ID: Thread-Topic: [Ipsec] Discrepency RFC4301 and RFC4305 Thread-Index: AcYVNUfFI1kYkBDGTPOpsMK1/Gq8GgAW9NEg From: "Vishwas Manral" To: X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Cc: ipv6@ietf.org Subject: FW: [Ipsec] Discrepency RFC4301 and RFC4305 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1546701573==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1546701573== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61591.89FA4F27" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61591.89FA4F27 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi John, =20 I am attaching a new thread regarding the NULL auth algorithm on the IPsec mailing list. =20 This should probably clarify what I had said in the thread "draft-ietf-ipv6-node-requirements-11.txt". =20 Thanks, Vishwas ________________________________ From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, January 09, 2006 9:16 PM To: Vishwas Manral Cc: IPsec; russ housley Subject: Re: [Ipsec] Discrepency RFC4301 and RFC4305 =20 At 8:04 PM -0800 1/8/06, Vishwas Manral wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=3D"----_=3D_NextPart_001_01C614D1.CA0C5D20" Hi, =20 I had brought out the issue more then a year back that: =20 RFC4301 states - confidentiality-only (MAY be supported) - integrity only (MUST be supported) - confidentiality and integrity (MUST be supported) =20 However RFC4305 states that NULL authentication support is a MUST. =20 I had brought out the issue with the draft which became RFC4305. Stephen Kent had supported the change and stated "since we changed the requirements for encryption-only support in this round of document revisions, I think a SHOULD here is correct." http://130.230.52.14/list-archive/ipsec/msg05576.html =20 =20 however Donald Eastlake had stated @@@ I think draft-ietf-ipsec-esp-v3-09 should be changed. http://130.230.52.14/list-archive/ipsec/msg05578.html =20 =20 The issue never got resolved and we now have this discrepancy in the RFC's. Should I send an errata for RFC4305 regarding the same? =20 Thanks, Vishwas =20 Whoops. Sorry that this one fell through the cracks in the intervening year after you noted the discrepancy. =20 I still think a SHOULD is appropriate for ESP, given the changes in the architecture document. Since this is a significant change (from a MUST to a SHOULD), it cannot be an errata, as Paul noted. I'll ask Russ how he would like to handle this. =20 Steve =20 ------_=_NextPart_001_01C61591.89FA4F27 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Ipsec] Discrepency RFC4301 and RFC4305

Hi = John,

 

I am attaching a new thread = regarding the NULL auth algorithm on the IPsec mailing list.

 

This should probably clarify what I = had said in the thread = “draft-ietf-ipv6-node-requirements-11.txt”.=

 

Thanks,

=

Vishwas

=

From: = Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, January 09, = 2006 9:16 PM
To: Vishwas Manral
Cc: IPsec; russ housley
Subject: Re: [Ipsec] = Discrepency RFC4301 and RFC4305

 

At 8:04 PM -0800 1/8/06, Vishwas Manral = wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
  = boundary=3D"----_=3D_NextPart_001_01C614D1.CA0C5D20"

Hi,

 

I had brought out the issue more then a year back = that:

 

RFC4301 states

            - confidentiality-only (MAY be supported)

            - integrity only (MUST be supported)

            - confidentiality and integrity (MUST be = supported)

 

However RFC4305 states that NULL authentication = support is a MUST.

 

I had brought out the issue with the draft which = became RFC4305. Stephen Kent had supported the change and = stated

"since we changed the requirements for encryption-only = support in this round of document revisions, I think a SHOULD here is = correct."

http://130.230.52.14/list-ar= chive/ipsec/msg05576.html

 

however Donald Eastlake had = stated

@@@ I think draft-ietf-ipsec-esp-v3-09 should = be changed.

http://130.230.52.14/list-ar= chive/ipsec/msg05578.html

 

The issue never got resolved and we now have this discrepancy in the RFC's. Should I send an errata for RFC4305 regarding = the same?

 

Thanks,

Vishwas

 

Whoops.  Sorry that this one fell through the cracks in the intervening year after you noted the = discrepancy.

 

I still think a SHOULD is appropriate for ESP, given the changes = in the architecture document. Since this is a significant change (from a MUST = to a SHOULD), it cannot be an errata, as Paul noted. I'll ask Russ how he = would like to handle this.

 

Steve

 

------_=_NextPart_001_01C61591.89FA4F27-- --===============1546701573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1546701573==-- From ipv6-bounces@ietf.org Mon Jan 09 22:22:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwA5e-00014i-Cc; Mon, 09 Jan 2006 22:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwA5Z-000146-Mw for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 22:22:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26549 for ; Mon, 9 Jan 2006 22:21:07 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwAC9-0001BE-LF for ipv6@ietf.org; Mon, 09 Jan 2006 22:29:16 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Jan 2006 22:22:03 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 22:22:03 -0500 Message-ID: Thread-Topic: Sending ICMP error upon receiving an NA without SLLAO in 2461bis Thread-Index: AcYVaASBABMO6yo5QJekaycqgOgvTAALMCIA From: "Soliman, Hesham" To: "Thomas Narten" X-OriginalArrivalTime: 10 Jan 2006 03:22:03.0421 (UTC) FILETIME=[06C03CD0:01C61595] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: Sending ICMP error upon receiving an NA without SLLAO in 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > > The basic issue left is whether we should allow a node to=20 > send an ICMP error > > due to the reception of an NA without the SLLAO. The=20 > reason for sending the=20 > > ICMP error is to inform upper layers that the communication has > > failed. >=20 > It took me a while to figure out what you are proposing. To=20 > summarize: > in the case where where a node receives an NA without an=20 > SLLAO, but it > is expecting an SLLAO (so it can complete the Neighbor Cache Entry), > such a received NA is "an error". In the case where a regular data > packet is queued pending completion of the NCE, you'd like to be able > to send back an ICMP error indicating "dest unreachable". Right? =3D> Yes.=20 >=20 > This seems like a fairly minor optimization and one that deals with a > a potential "implementation error" (since I understand this situation > would normally only arise of the sender of the NA=20 > incorrectly left off > the SLLAO). If this is the case, IMO, it's not worth modifying the > spec to allow this. Indeed, I'd have to think a bit to=20 > convince myself > that it couldn't lead to potential cases where an ICMP error would be > (incorrectly) sent when simply ignoring the faulty NA is actually the > more correct response (i.e., if proxies are present and more than one > NA is generated). >=20 > Is this a situation that has come up in actual testing/usage? =3D> Christian Vogt raised this issue so perhaps he (or someone else)=20 can answer this question. Personally, I've never encountered this case. Hesham >=20 > Thomas >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 10 02:48:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEEo-00089q-T4; Tue, 10 Jan 2006 02:48:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEEn-00087O-36 for ipv6@megatron.ietf.org; Tue, 10 Jan 2006 02:48:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12127 for ; Tue, 10 Jan 2006 02:46:52 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwELQ-0008DG-Um for ipv6@ietf.org; Tue, 10 Jan 2006 02:55:06 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:85a9:4360:c5a:7f6d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CD03715274; Tue, 10 Jan 2006 16:47:57 +0900 (JST) Date: Tue, 10 Jan 2006 16:47:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> References: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ipv6@ietf.org Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 9 Jan 2006 09:51:48 -0800, >>>>> Bob Hinden said: > Sorry for not responding sooner. No problem, thanks for the response. > I suspect that at the time we thought that an EUI-48 was equivalent > to MAC-48. Actually until you sent your email I wasn't aware of the > issue. Are there any networks that use EUI-48? Not that I know of. > I don't think that in practice this causes any problem since we use > them to create "modified-EUI-64" based interface identifiers and the > main technical requirement for IID is that they are unique on the list. I agree. > The draft is currently AUTH48 so it might be possible to change the > text from MAC-48 to EUI-48, but I would be concerned that this change > would cause confusion. I don't think this has caused any confusion > for people writing IPv6 over specifications. As I proposed in a follow-up message on this thread (http://www1.ietf.org/mail-archive/web/ipv6/current/msg06052.html), I'd add a note that just clarifies the mismatch. I've attached a proposal of changes to APPENDIX A below (marked by ">>"). We may need to consult the IESG for making this change, but I believe this is minor enough to incorporate at this stage and will help future readers much. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp ======================================================================== APPENDIX A: Creating Modified EUI-64 format Interface Identifiers (...snip...) Links or Nodes with IEEE 802 48 bit MAC's [EUI64] defines a method to create a IEEE EUI-64 identifier from an IEEE 48bit MAC identifier. This is to insert two octets, with >> hexadecimal values of 0xFF and 0xFE (see the note below), in the middle of the 48 bit MAC (between the company_id and vendor supplied id). For example the 48 bit IEEE MAC with global scope: (...snip...) selected extension identifier. The interface identifier would be of the form: |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+ When IEEE 802 48bit MAC addresses are available (on an interface or a node), an implementation may use them to create interface identifiers due to their availability and uniqueness properties. >> Note: technically, the two-octet values to be inserted should be >> 0xFF and 0xFF for a 48-bit MAC identifier according to [EUI64]. >> The values shown in this document were incorrectly chosen by an >> accident due to confusion about the difference between EUI-48 >> identifiers (for which 0xFF and 0xFE are used) and 48-bit MAC >> identifiers (MAC-48). In practice, however, this error does not >> matter. The essential requirement for an interface identifier is >> to be unique within the link, and it is unlikely that an EUI-48 >> identifier, which is assigned to a non-network device, needs to be >> extended to be an IPv6 interface identifier. Since implementations >> with interface identifiers based on the EUI-48 identifier have >> already been deployed, it should be less confusing to continue >> using the "incorrect" octets. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 10 03:02:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwET1-0002s7-45; Tue, 10 Jan 2006 03:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwESz-0002s2-7Q for ipv6@megatron.ietf.org; Tue, 10 Jan 2006 03:02:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12838 for ; Tue, 10 Jan 2006 03:01:32 -0500 (EST) Received: from customer-domains.icp-qv1-irony7.iinet.net.au ([203.59.1.128]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwEZd-000082-9c for ipv6@ietf.org; Tue, 10 Jan 2006 03:09:46 -0500 Received: from 203-173-52-90.dyn.iinet.net.au (HELO ubu.nosense.org) ([203.173.52.90]) by customer-domains.icp-qv1-irony7.iinet.net.au with ESMTP; 10 Jan 2006 16:02:24 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 1E8AA2F627 for ; Tue, 10 Jan 2006 18:32:23 +1030 (CST) Date: Tue, 10 Jan 2006 18:32:22 +1030 From: Mark Smith To: ipv6@ietf.org Message-Id: <20060110183222.745587ab.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <004001c6154c$1fd3a660$0401a8c0@mtc.ki.se> References: <004001c6154c$1fd3a660$0401a8c0@mtc.ki.se> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: Re: Analiyzing the IPv6 list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Eric, I'm from Adelaide, Australia, where IETF47 was held back in 2000. I've been in Australia all my life, 34 years, 2 in Sydney (2000 - 2002), the rest in Adelaide. HTH, Mark. On Mon, 9 Jan 2006 20:40:06 +0200 "Eric Klein" wrote: > I know that this is a little off topic. As part of my thesis I am trying to analyze who is taking part in making the IPv6 standard. > > I have collected some data about the 11 years that the list has been active, and have found that (not surprisingly) 65% of the messages to this list come from e-mail addresses ending in .com, .net or .org. > > Needless to say this makes it hard to identify which country the sender is sending from (i.e where they are based). > > So, if your address ends in .com, .net, or .org could you please send me (no need to send it to the whole list) two things: > > Which country where you are based: > How long you have been based in that country: > > I realize that this will not reduce the unknown countries to zero, but this way I can make more accurate conclusions about who is represented by this mailing list. > > Thanks, > Eric Klein, MSc > > Ps. If you have an e-mail address that ends in a country TLD that does not represent where you are actually located, could you also please send an update. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 10 03:08:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEY6-00046g-UN; Tue, 10 Jan 2006 03:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEY4-00043D-Mc for ipv6@megatron.ietf.org; Tue, 10 Jan 2006 03:08:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13043 for ; Tue, 10 Jan 2006 03:06:48 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwEee-0000Ec-Jw for ipv6@ietf.org; Tue, 10 Jan 2006 03:15:02 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D42CD4CC2C; Tue, 10 Jan 2006 09:07:41 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30339-10; Tue, 10 Jan 2006 09:07:40 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5EFBE4CD20; Tue, 10 Jan 2006 09:07:39 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id A34365B024B; Tue, 10 Jan 2006 09:07:37 +0100 (CET) Date: Tue, 10 Jan 2006 09:07:37 +0100 From: Juergen Schoenwaelder To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20060110080737.GA12312@boskop.local> Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , Bob Hinden , ipv6@ietf.org References: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Jan 10, 2006 at 04:47:57PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > As I proposed in a follow-up message on this thread > (http://www1.ietf.org/mail-archive/web/ipv6/current/msg06052.html), > I'd add a note that just clarifies the mismatch. I've attached a > proposal of changes to APPENDIX A below (marked by ">>"). I support the addition of this clarification. /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 ipv6-bounces@ietf.org Tue Jan 10 03:08:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEYd-0004OM-Gi; Tue, 10 Jan 2006 03:08:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEYX-0004Lg-OL for ipv6@megatron.ietf.org; Tue, 10 Jan 2006 03:08:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13088 for ; Tue, 10 Jan 2006 03:07:17 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwEfC-0000Hu-U1 for ipv6@ietf.org; Tue, 10 Jan 2006 03:15:31 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:85a9:4360:c5a:7f6d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B936215276; Tue, 10 Jan 2006 17:08:35 +0900 (JST) Date: Tue, 10 Jan 2006 17:08:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200601092159.k09Lxk0e014309@cichlid.raleigh.ibm.com> References: <200601092159.k09Lxk0e014309@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Soliman, Hesham" , IPv6 WG Subject: Re: Sending ICMP error upon receiving an NA without SLLAO in 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 09 Jan 2006 16:59:46 -0500, >>>>> Thomas Narten said: >> The basic issue left is whether we should allow a node to send an ICMP error >> due to the reception of an NA without the SLLAO. The reason for sending the >> ICMP error is to inform upper layers that the communication has >> failed. > It took me a while to figure out what you are proposing. To summarize: > in the case where where a node receives an NA without an SLLAO, but it > is expecting an SLLAO (so it can complete the Neighbor Cache Entry), > such a received NA is "an error". In the case where a regular data > packet is queued pending completion of the NCE, you'd like to be able > to send back an ICMP error indicating "dest unreachable". Right? > This seems like a fairly minor optimization and one that deals with a > a potential "implementation error" (since I understand this situation > would normally only arise of the sender of the NA incorrectly left off > the SLLAO). If this is the case, IMO, it's not worth modifying the > spec to allow this. I agree. This is actually the same as my impression when I first noticed the change: http://www1.ietf.org/mail-archive/web/ipv6/current/msg06040.html > Indeed, I'd have to think a bit to convince myself > that it couldn't lead to potential cases where an ICMP error would be > (incorrectly) sent when simply ignoring the faulty NA is actually the > more correct response (i.e., if proxies are present and more than one > NA is generated). Good point. I also agree with you on this. > Is this a situation that has come up in actual testing/usage? I guess Hesham meant an old discussion (about a year ago) regarding an optimistic DAD node. But as far as I can see, even an optimistic node does not send the NA in question here. 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 ipv6-bounces@ietf.org Tue Jan 10 03:11:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEb7-0004uh-Mi; Tue, 10 Jan 2006 03:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEb6-0004uX-Mr for ipv6@megatron.ietf.org; Tue, 10 Jan 2006 03:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13338 for ; Tue, 10 Jan 2006 03:09:56 -0500 (EST) Received: from ihug-mail.icp-qv1-irony4.iinet.net.au ([203.59.1.198] helo=mail-ihug.icp-qv1-irony4.iinet.net.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwEhk-0000My-HF for ipv6@ietf.org; Tue, 10 Jan 2006 03:18:10 -0500 Received: from 203-173-52-90.dyn.iinet.net.au (HELO ubu.nosense.org) ([203.173.52.90]) by mail-ihug.icp-qv1-irony4.iinet.net.au with ESMTP; 10 Jan 2006 16:11:03 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 42E122F627 for ; Tue, 10 Jan 2006 18:41:02 +1030 (CST) Date: Tue, 10 Jan 2006 18:41:02 +1030 From: Mark Smith To: ipv6@ietf.org Message-Id: <20060110184102.47efc705.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20060110183222.745587ab.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <004001c6154c$1fd3a660$0401a8c0@mtc.ki.se> <20060110183222.745587ab.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: Re: Analiyzing the IPv6 list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Appologies to the list. Being using the Internet since 1992, still can't email properly. On Tue, 10 Jan 2006 18:32:22 +1030 Mark Smith wrote: > Hi Eric, > > I'm from Adelaide, Australia, where IETF47 was held back in 2000. > > I've been in Australia all my life, 34 years, 2 in Sydney (2000 - 2002), the rest in > Adelaide. > > HTH, > Mark. > > > > On Mon, 9 Jan 2006 20:40:06 +0200 > "Eric Klein" wrote: > > > I know that this is a little off topic. As part of my thesis I am trying to analyze who is taking part in making the IPv6 standard. > > > > I have collected some data about the 11 years that the list has been active, and have found that (not surprisingly) 65% of the messages to this list come from e-mail addresses ending in .com, .net or .org. > > > > Needless to say this makes it hard to identify which country the sender is sending from (i.e where they are based). > > > > So, if your address ends in .com, .net, or .org could you please send me (no need to send it to the whole list) two things: > > > > Which country where you are based: > > How long you have been based in that country: > > > > I realize that this will not reduce the unknown countries to zero, but this way I can make more accurate conclusions about who is represented by this mailing list. > > > > Thanks, > > Eric Klein, MSc > > > > Ps. If you have an e-mail address that ends in a country TLD that does not represent where you are actually located, could you also please send an update. > > -------------------------------------------------------------------- > 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 ipv6-bounces@ietf.org Tue Jan 10 05:40:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGve-0006Hc-BQ; Tue, 10 Jan 2006 05:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew95v-0000X5-Ci for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 21:18:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22632 for ; Mon, 9 Jan 2006 21:17:23 -0500 (EST) Received: from web35907.mail.mud.yahoo.com ([66.163.179.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew9CV-0007rY-H1 for ipv6@ietf.org; Mon, 09 Jan 2006 21:25:33 -0500 Received: (qmail 40894 invoked by uid 60001); 10 Jan 2006 02:18:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RSo8jBGE2j829OxZv7WJdwl7Sx6aGb+HcgXumhL6w91YHgU2sZoD6TzKoarHx41nqyYLQguAoJJhMD36rvimA1txmidhx5gwBWdUHLhqbGErPo/ri7+iqDPtwTZH2WDhKP2Uojlf+9RA92JJBLrDnu7G07R6fYCZ4lcln+h8v2U= ; Message-ID: <20060110021831.40892.qmail@web35907.mail.mud.yahoo.com> Received: from [66.31.86.8] by web35907.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 18:18:31 PST Date: Mon, 9 Jan 2006 18:18:31 -0800 (PST) From: Derek Smalls To: ipv6@ietf.org In-Reply-To: <43C2DF76.6030504@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 1.4 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA22632 X-Mailman-Approved-At: Tue, 10 Jan 2006 05:40:36 -0500 Subject: Re: Sending ICMP error upon receiving an NA without SLLAO in 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org According to RFC 2492 SLLAO option should not be used in an ATM PVC environment, yet the NA may be transmitted as a part of DAD which is still required. Thus with this proposal we can have an ICMP error generated in a scenario where no error condition has occurred.=20 --- Thomas Narten wrote: > > The basic issue left is whether we should allow a > node to send an ICMP error > > due to the reception of an NA without the SLLAO. > The reason for sending the=20 > > ICMP error is to inform upper layers that the > communication has > > failed. >=20 > It took me a while to figure out what you are > proposing. To summarize: > in the case where where a node receives an NA > without an SLLAO, but it > is expecting an SLLAO (so it can complete the > Neighbor Cache Entry), > such a received NA is "an error". In the case where > a regular data > packet is queued pending completion of the NCE, > you'd like to be able > to send back an ICMP error indicating "dest > unreachable". Right? >=20 > This seems like a fairly minor optimization and one > that deals with a > a potential "implementation error" (since I > understand this situation > would normally only arise of the sender of the NA > incorrectly left off > the SLLAO). If this is the case, IMO, it's not > worth modifying the > spec to allow this. Indeed, I'd have to think a bit > to convince myself > that it couldn't lead to potential cases where an > ICMP error would be > (incorrectly) sent when simply ignoring the faulty > NA is actually the > more correct response (i.e., if proxies are present > and more than one > NA is generated). >=20 > Is this a situation that has come up in actual > testing/usage? >=20 > Thomas >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 >=20 =09 __________________________________________=20 Yahoo! DSL =96 Something to write home about.=20 Just $16.99/mo. or less.=20 dsl.yahoo.com=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jan 10 10:12:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLAJ-0004NG-Jq; Tue, 10 Jan 2006 10:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLAH-0004N8-1O for ipv6@megatron.ietf.org; Tue, 10 Jan 2006 10:12:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09205 for ; Tue, 10 Jan 2006 10:10:42 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwLGy-0004AZ-SY for ipv6@ietf.org; Tue, 10 Jan 2006 10:18:58 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0AFBiYG005670; Tue, 10 Jan 2006 17:11:44 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0AFBhvW005667; Tue, 10 Jan 2006 17:11:44 +0200 Date: Tue, 10 Jan 2006 17:11:43 +0200 (EET) From: Pekka Savola To: Eric Klein In-Reply-To: <004001c6154c$1fd3a660$0401a8c0@mtc.ki.se> Message-ID: References: <004001c6154c$1fd3a660$0401a8c0@mtc.ki.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: Analiyzing the IPv6 list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, 9 Jan 2006, Eric Klein wrote: > Needless to say this makes it hard to identify which country the > sender is sending from (i.e where they are based). > > So, if your address ends in .com, .net, or .org could you please > send me (no need to send it to the whole list) two things: > > Which country where you are based: > How long you have been based in that country: Uhh, I'd go over the research methology again if I were you; mining information out of whois should be your friend... -- 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 ipv6-bounces@ietf.org Thu Jan 12 16:58:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExASa-0006d3-47; Thu, 12 Jan 2006 16:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExASY-0006cy-T0 for ipv6@megatron.ietf.org; Thu, 12 Jan 2006 16:58:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29355 for ; Thu, 12 Jan 2006 16:56:56 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExAZj-0005V1-Do for ipv6@ietf.org; Thu, 12 Jan 2006 17:05:44 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.11957534; Thu, 12 Jan 2006 16:57:37 -0500 Mime-Version: 1.0 (Apple Message framework v623) To: IPv6 WG Message-Id: <9398777ac9b0a71ba35dd87b70076a48@innovationslab.net> From: Brian Haberman Date: Thu, 12 Jan 2006 16:57:36 -0500 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Bob Hinden Subject: IPv6 over PPP Implementation Reports X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0967110152==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0967110152== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--117932843; protocol="application/pkcs7-signature" --Apple-Mail-3--117932843 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit IPv6 WG, We have an issue with the current set of implementation reports for RFC 2472 (IPv6 over PPP). The chairs received two implementation reports for advancing the standard to Draft. Unfortunately, the two reported implementations were not tested against each other. The IESG requires that the implementation reports show interoperability between each other. The following are links to the current reports http://www.ietf.org/IESG/Implementations/RFC2472-Impl-Report-KAME.txt http://www.ietf.org/IESG/Implementations/RFC2472-Impl-Report-Alaxala.txt What we need are either updated reports that demonstrate interoperability between these implementations or implementation reports from those listed in these reports. The chairs would appreciate any input implementors can provide on this! Thanks, Brian --Apple-Mail-3--117932843 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMTEyMjE1NzM3WjAjBgkqhkiG9w0B CQQxFgQUCiVWtBZZbY6tuwlYDIBOpzxz9LUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEARhN5R/mgct7YNDuD0vJm5Gmqr+0UMBk/heWvuKxntrJ28cOW/AEHpMCCIvrPd9p8vOQh mtNjUJX+ZA6G6fPsPlQ0KuRrXV94FAipQ1fQRJewUkNZz+Emm3DqHewmGCGPT84JJkTVjSUVExPK JYYqfAb1YcFZlUaDLpLO+A7xnvZq+yeflt7MPS5kwCyV9XjOzsp35YmxM6oaPTpCHrZNXmsZj0Nf zt9DicUfqrgv/Mlk6aZBJpji6/XEeTKcmZPUKLJSSfa8iHazTB4zCZBHLsWCS7AiKmdMm+f83MeT 6cNBXkO4+OzkRyKerPi0brkOnI0vZ7UoKSgBuxQdIef4zQAAAAAAAA== --Apple-Mail-3--117932843-- --===============0967110152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0967110152==-- From ipv6-bounces@ietf.org Sun Jan 15 11:43:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAy9-0002rt-N4; Sun, 15 Jan 2006 11:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAwI-0001Fp-1l for ipv6@megatron.ietf.org; Sun, 15 Jan 2006 11:41:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14896 for ; Sun, 15 Jan 2006 10:41:16 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey07w-00037P-65 for ipv6@ietf.org; Sun, 15 Jan 2006 00:08:29 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id B280DA56 for ; Sun, 15 Jan 2006 00:00:15 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 15 Jan 2006 00:00:15 -0500 Message-Id: <20060115050015.B280DA56@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.00% | 3 | 24.30% | 28987 | vishwas@sinett.com 10.00% | 2 | 9.99% | 11913 | jinmei@isl.rdc.toshiba.co.jp 10.00% | 2 | 8.28% | 9874 | ipng@69706e6720323030352d30312d31340a.nosense.org 10.00% | 2 | 7.61% | 9083 | john.loughney@nokia.com 5.00% | 1 | 6.61% | 7881 | brian@innovationslab.net 5.00% | 1 | 6.03% | 7197 | ericlklein@softhome.net 5.00% | 1 | 5.38% | 6421 | bob.hinden@nokia.com 5.00% | 1 | 4.59% | 5476 | dsmalls321@yahoo.com 5.00% | 1 | 4.51% | 5385 | h.soliman@flarion.com 5.00% | 1 | 4.43% | 5285 | mailer-daemon@ktf.com 5.00% | 1 | 4.27% | 5088 | narten@us.ibm.com 5.00% | 1 | 3.76% | 4487 | sra+ipng@hactrn.net 5.00% | 1 | 3.63% | 4330 | j.schoenwaelder@iu-bremen.de 5.00% | 1 | 3.42% | 4084 | iesg-secretary@ietf.org 5.00% | 1 | 3.19% | 3803 | pekkas@netcore.fi --------+------+--------+----------+------------------------ 100.00% | 20 |100.00% | 119294 | 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 ipv6-bounces@ietf.org Mon Jan 16 13:57:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZXq-00064v-D8; Mon, 16 Jan 2006 13:57:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZXo-00062B-0g for ipv6@megatron.ietf.org; Mon, 16 Jan 2006 13:57:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06497 for ; Mon, 16 Jan 2006 13:56:07 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyZfm-0005rk-Ne for ipv6@ietf.org; Mon, 16 Jan 2006 14:05:47 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Jan 2006 13:57:08 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Mon, 16 Jan 2006 13:57:11 -0500 Message-ID: Thread-Topic: Fwd: Request To Advance: Thread-Index: AcYR0RUkOLgB2XEeQBeCV7ptm3vlBAAFv+bwADs+rjAB/lBZIA== From: "Soliman, Hesham" To: "Soliman, Hesham" , "IPv6 WG" X-OriginalArrivalTime: 16 Jan 2006 18:57:08.0609 (UTC) FILETIME=[A6870710:01C61ACE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: Subject: RE: Sending ICMP error upon receiving an NA without SLLAO in 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Folks, There were only two new emails on this subject. Given the overwhelming lack of interest in this issue and that both responders felt that it was ok to keep things as is (without adding ICMP errors), this issue is now closed and the suggestion in my email below is rejected. Therefore, the draft will be updated and the reference to ICMP errors in the state machine will be removed. Thanks, Hesham > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On > Behalf Of Soliman, Hesham > Sent: Friday, January 06, 2006 10:31 AM > To: IPv6 WG > Subject: Sending ICMP error upon receiving an NA without > SLLAO in 2461bis > > > Hi all, > > This is a mini concensus call on the discussion I had with > Jinmei below. > > The basic issue left is whether we should allow a node to > send an ICMP error > due to the reception of an NA without the SLLAO. The reason > for sending the > ICMP error is to inform upper layers that the communication > has failed. > > The current spec says that such message SHOULD be silently discarded > (see section 7.2 and section 7.2.5 in > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-05.txt). > > However, it would be useful to inform upper layers of such > failures. ICMP is the > natural choice for transmitting the error message. > > Implementing this feature would be optional and should not > have problems with backward > compatibility. I don't know if this would be considered a > substantive change to the current > spec. IMHO it can easily pass as a clarification. > > Please express your opinion on whether we could add this > clarification to the spec or > keep it as is. > > Hesham > > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On > > Behalf Of Soliman, Hesham > > Sent: Thursday, January 05, 2006 6:09 AM > > To: JINMEI Tatuya / ???? > > Cc: IPv6 WG > > Subject: RE: Fwd: Request To Advance: > > > > > > > > > > > > > > => Not in the main text, which is why I suggested above > > > that we can add it > > > > to section 7.2. > > > > > > I see. As I said in the previous message (see also > > below), we should > > > first make a consensus about whether this is to be added. > > Then, if > > > the result is positive, we should explicitly add the > corresponding > > > text to 7.2 (in general, the appendix should be a summary > > of the main > > > text, IMO). > > > > => Agreed. > > > > > > > > (snip) > > > > > > >> I > > > >> believe it makes more sense to discard the bogus packets > > > silently as > > > >> described in the body of the draft (Section 7.2.4) rather > > > than taking > > > >> a specific action like sending an ICMPv6 error message. > > > > > > > => I don't think that's a good way to handle it, but the > > > current text inherited from > > > > 2461 agrees with you. I don't think it breaks backward > > > compatibility to mention this > > > > in the appendix as an optional behaviour (sending the ICMP > > > error). Are you ok with > > > > having this as an optional behaviour in the appendix? others? > > > > > > I don't have a strong opinion on either way (whether or > > not including > > > this feature). As you said, it may help in some cases > > (e.g., an end > > > host may be able to give up connecting to a non-compliant > > remote host > > > faster). But since this may require a change to the existing > > > implementation, I'd like to see an explicit consensus about the > > > additional behavior (i.e., 'no objection' would not suffice). > > > > => That's fine. I'll send a separate email to ask if people > > agree with adding > > the ICMP part as an optional feature. > > > > Hesham > > > > > > > > JINMEI, Tatuya > > > Communication > Platform Lab. > > > Corporate R&D Center, > > > Toshiba Corp. > > > > jinmei@isl.rdc.toshiba.co.jp > > > > > > > =========================================================== > > This email may contain confidential and privileged material > > for the sole use > > of the intended recipient. Any review or distribution by > > others is strictly > > prohibited. If you are not the intended recipient please > > contact the sender > > and delete all copies. > > =========================================================== > > > > > > > -------------------------------------------------------------------- > > 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 ipv6-bounces@ietf.org Tue Jan 17 01:21:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EykDe-0005lT-E7; Tue, 17 Jan 2006 01:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EykDb-0005kL-Mc for ipv6@megatron.ietf.org; Tue, 17 Jan 2006 01:21:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19670 for ; Tue, 17 Jan 2006 01:19:58 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EykLc-0008DX-U6 for ipv6@ietf.org; Tue, 17 Jan 2006 01:29:44 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Jan 2006 22:21:10 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 22:21:09 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 22:21:09 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 22:21:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C61B2E.340AF2F3" Date: Mon, 16 Jan 2006 22:21:04 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC115359609@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcXSNJTcdGSVKnWqTaqSRW+EeTCC/AAIdsGgD/zKtqAAtExIkAGEzJbQ From: "Dave Thaler" To: X-OriginalArrivalTime: 17 Jan 2006 06:21:09.0309 (UTC) FILETIME=[34B0DED0:01C61B2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-node-requirements-11.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61B2E.340AF2F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, what do you propose to do about RFC2893? (email attached) I am fine with the changes proposed below for the other items. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > john.loughney@nokia.com > Sent: Monday, January 09, 2006 4:55 AM > To: ipv6@ietf.org > Subject: RE: draft-ietf-ipv6-node-requirements-11.txt >=20 > Hi all, >=20 > I propose to update the Node Requirements to handle these: >=20 > RFC2401 is now obsoleted by RFC4301 > RFC2402 is now obsoleted by RFC4302 > RFC2404 is now obsoleted by RFC4305 > RFC2406 is now obsoleted by RFC4303, RFC4305 > RFC2407,2408,2409 are now obsoleted by RFC4306 >=20 > Changes are: >=20 > "AH [RFC-4202] MAY be supported." >=20 > These texts would be removed: > "RFC-2401 is being updated by the IPsec Working Group." > "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." >=20 > The plan would be to update these during AUTH48, assuming the WG agrees > with > changes. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > OLD: > 8.1 Basic Architecture >=20 > Security Architecture for the Internet Protocol [RFC-2401] MUST be > supported. RFC-2401 is being updated by the IPsec Working Group. >=20 > NEW: >=20 > 8.1 Basic Architecture >=20 > Security Architecture for the Internet Protocol [RFC-4301] MUST be > supported. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > OLD: > 8.2 Security Protocols >=20 > ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. > RFC-2406 and RFC 2402 are being updated by the IPsec Working Group. >=20 > NEW > 8.2 Security Protocols >=20 > ESP [RFC-4306] MUST be supported. AH [RFC-4302] MAY be supported. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I need to double-check sections 8.3 & 8.4, there are a few changes for > these. I will > send suggested changes. >=20 > John >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ------_=_NextPart_001_01C61B2E.340AF2F3 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by win-msg-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:34:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:34:45 -0800 Received: from igs-hub-01.northamerica.corp.microsoft.com ([157.57.217.10]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:34:45 -0800 Received: from IGS-IMC-01.northamerica.corp.microsoft.com ([157.57.195.41]) by igs-hub-01.northamerica.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:34:44 -0800 Received: from megatron.ietf.org ([132.151.6.71]) by IGS-IMC-01.northamerica.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 6 Jan 2006 13:34:40 -0800 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuzAh-0000Nl-DR; Fri, 06 Jan 2006 16:30:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuzAf-0000Ng-Rv for ipv6@megatron.ietf.org; Fri, 06 Jan 2006 16:30:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13287 for ; Fri, 6 Jan 2006 16:29:29 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuzGZ-0002WA-EB for ipv6@ietf.org; Fri, 06 Jan 2006 16:36:56 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 6 Jan 2006 13:30:35 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:30:34 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:30:34 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 13:30:34 -0800 Content-class: urn:content-classes:message Subject: RE: draft-ietf-ipv6-node-requirements-11.txt Date: Fri, 6 Jan 2006 13:30:30 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC11514E166@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcXSNJTcdGSVKnWqTaqSRW+EeTCC/AAIdsGgD/zKtqAAL7EawA== List-Help: List-Subscribe: , List-Unsubscribe: , From: "Dave Thaler" Sender: To: Cc: Content-Transfer-Encoding: quoted-printable Here's another one: RFC2893 is now obsoleted by RFC4213 Section 6.l.1 says: "RFC 2893 is currently being updated." > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Thursday, January 05, 2006 3:05 PM > To: john.loughney@nokia.com > Cc: ipv6@ietf.org > Subject: draft-ietf-ipv6-node-requirements-11.txt >=20 > The draft in the RFC-editors queue now references obsoleted (as of last > month) RFCs. Specifically: > RFC2401 is now obsoleted by RFC4301 > RFC2402 is now obsoleted by RFC4302 > RFC2404 is now obsoleted by RFC4305 > RFC2406 is now obsoleted by RFC4303, RFC4305 > RFC2407,2408,2409 are now obsoleted by RFC4306 >=20 > Also two statements in section 8 are now obsolete as a result: > "RFC-2401 is being updated by the IPsec Working Group." > "RFC-2406 and RFC 2402 are being updated by the IPsec Working Group." >=20 > Can these be updated? >=20 > -Dave >=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 -------------------------------------------------------------------- ------_=_NextPart_001_01C61B2E.340AF2F3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C61B2E.340AF2F3-- From ipv6-bounces@ietf.org Wed Jan 18 12:55:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHX2-0004h0-0P; Wed, 18 Jan 2006 12:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHX0-0004gv-Ct for ipv6@megatron.ietf.org; Wed, 18 Jan 2006 12:55:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08787 for ; Wed, 18 Jan 2006 12:54:12 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzHfM-0003UH-FD for ipv6@ietf.org; Wed, 18 Jan 2006 13:04:17 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0IHrGVj016704 for ; Wed, 18 Jan 2006 19:53:19 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 19:54:52 +0200 Received: from [209.157.142.164] ([10.241.59.15]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Jan 2006 19:54:51 +0200 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060110080737.GA12312@boskop.local> References: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> <20060110080737.GA12312@boskop.local> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 18 Jan 2006 09:54:51 -0800 To: IPv6 WG X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 18 Jan 2006 17:54:51.0829 (UTC) FILETIME=[480F2650:01C61C58] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, Here is the text I propose to send to the RFC-Editor to resolve the issue. Take a look and let me know it is is OK. Thanks, Bob > Appendix A: Creating Modified EUI-64 Format Interface Identifiers > ......... > Links or Nodes with IEEE 802 48-bit MACs > > [EUI64] defines a method to create an IEEE EUI-64 identifier > from an > IEEE 48-bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48-bit > MAC s/0xFE,/0xFE (see the Note at the end of appendix),/ > (between the company_id and vendor-supplied id). An example is the > 48-bit IEEE MAC with Global scope: > > |0 1|1 3|3 4| > |0 5|6 1|2 7| > +----------------+----------------+----------------+ > |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| > +----------------+----------------+----------------+ > > where "c" is the bits of the assigned company_id, "0" is the > value of > the universal/local bit to indicate Global scope, "g" is > individual/group bit, and "m" is the bits of the manufacturer- > selected extension identifier. The interface identifier would > be of > the form: > > |0 1|1 3|3 4| > 4 6| > |0 5|6 1|2 7| > 8 3| > +----------------+----------------+---------------- > +----------------+ > |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm| > mmmmmmmmmmmmmmmm| > +----------------+----------------+---------------- > +----------------+ > > When IEEE 802 48-bit MAC addresses are available (on an > interface or > a node), an implementation may use them to create interface > identifiers due to their availability and uniqueness properties. ..... Add: Add to the end of the appendix: Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be inserted to create an IEEE EUI-64 identifier from an IEEE MAC-48 identifier. The 0xFF and 0xFE values are used when starting with an IEEE EUI-48 identifier. The incorrect value was used in earlier versions of the specification due to an misunderstanding about the differences between IEEE MAC-48 and EUI-48 identifiers. This document purposely continues the use of 0xFF and 0xFE because it meets the requirements for IPv6 interface identifiers, specifically that they must be unique on the link, and that it doesn't cause any problems in practice. If in the future, a new link type is invented that uses IEEE EUI-48 and MAC-48 identifiers on the same link, the 0xFF and 0xFF values could be used to convert the EUI-48 identifiers for use as IPv6 interface identifiers to avoid any potential for duplicate interface identifiers. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 18 23:41:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzRbj-00021p-S5; Wed, 18 Jan 2006 23:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzRbh-00021k-2E for ipv6@megatron.ietf.org; Wed, 18 Jan 2006 23:41:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17347 for ; Wed, 18 Jan 2006 23:39:41 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzRk8-0007NU-TX for ipv6@ietf.org; Wed, 18 Jan 2006 23:49:54 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:598b:68a0:e50:98ce]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 113AF1525D; Thu, 19 Jan 2006 13:40:46 +0900 (JST) Date: Thu, 19 Jan 2006 13:40:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: References: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> <20060110080737.GA12312@boskop.local> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IPv6 WG Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 18 Jan 2006 09:54:51 -0800, >>>>> Bob Hinden said: > Here is the text I propose to send to the RFC-Editor to resolve the > issue. Take a look and let me know it is is OK. I personally support this text with one very minor nit: > Add: > Add to the end of the appendix: > Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be > inserted to create an IEEE EUI-64 identifier from an IEEE MAC-48 > identifier. The 0xFF and 0xFE values are used when starting with an > IEEE EUI-48 identifier. The incorrect value was used in earlier > versions of the specification due to an misunderstanding about the s/an misunderstanding/a misunderstanding/ > differences between IEEE MAC-48 and EUI-48 identifiers. > This document purposely continues the use of 0xFF and 0xFE > because it meets > the requirements for IPv6 interface identifiers, specifically that > they must be unique on the link, and that it doesn't cause any > problems in practice. If in the future, a new link type is invented > that uses IEEE EUI-48 and MAC-48 identifiers on the same link, the > 0xFF and 0xFF values could be used to convert the EUI-48 identifiers > for use as IPv6 interface identifiers to avoid any potential for > duplicate interface identifiers. I said 'personally' because it may be controversial to mention the possibility of the future use of 0xFFFF at this stage (i.e., it may be beyond the level of 'clarification'). But if the IESG accepts the description (or the RFC editor agrees this is minor enough), I'm happy with that. 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 ipv6-bounces@ietf.org Thu Jan 19 09:07:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzaRj-0006qW-JS; Thu, 19 Jan 2006 09:07:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzaRh-0006qR-MQ for ipv6@megatron.ietf.org; Thu, 19 Jan 2006 09:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25453 for ; Thu, 19 Jan 2006 09:05:58 -0500 (EST) Received: from handynerds.com ([207.234.208.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzaaA-0000ST-7h for ipv6@ietf.org; Thu, 19 Jan 2006 09:16:15 -0500 Received: from apache by HandyNerds.com with local (Exim 4.41) id 1EzaRb-0004vG-ND for ipv6@ietf.org; Thu, 19 Jan 2006 09:07:19 -0500 Received: from motive.ravenwing.com ([66.100.85.194]) (SquirrelMail authenticated user bthorson); by www.handynerds.com with HTTP; Thu, 19 Jan 2006 09:07:19 -0500 (EST) Message-ID: <57183.66.100.85.194.1137679639.squirrel@66.100.85.194> Date: Thu, 19 Jan 2006 09:07:19 -0500 (EST) From: "Brett Thorson" To: ipv6@ietf.org User-Agent: SquirrelMail/1.4.3a-0.f1.1 X-Mailer: SquirrelMail/1.4.3a-0.f1.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 8bit Subject: Congratulations Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@handynerds.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The co-inventor of the IPv6 protocol awarded Nokia Fellow http://www.noticias.info/asp/aspComunicados.asp?nid=137854&src=0 --Brett -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 19 09:19:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezacu-00049F-Bd; Thu, 19 Jan 2006 09:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezacr-000493-CI for ipv6@megatron.ietf.org; Thu, 19 Jan 2006 09:18:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26241 for ; Thu, 19 Jan 2006 09:17:30 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzalO-0000oC-8g for ipv6@ietf.org; Thu, 19 Jan 2006 09:27:47 -0500 Received: from [10.0.0.138] by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001570964.msg for ; Thu, 19 Jan 2006 15:20:50 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 19 Jan 2006 15:18:29 +0100 From: JORDI PALET MARTINEZ To: Bob Hinden , "ipv6@ietf.org" Message-ID: Thread-Topic: The co-inventor of the IPv6 protocol awarded Nokia Fellow Thread-Index: AcYdAzgadpeUXIj2EdqdUAANky3PwA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060119:ipv6@ietf.org::qf5Zk68wkLY12kji:000017wL X-MDRemoteIP: 10.0.0.138 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Processed: consulintel.es, Thu, 19 Jan 2006 15:20:51 +0100 X-MDAV-Processed: consulintel.es, Thu, 19 Jan 2006 15:20:52 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Subject: The co-inventor of the IPv6 protocol awarded Nokia Fellow X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Bob, Congratulations ! http://www.ipv6tf.org/news/newsroom.php?id=1731 Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 19 15:06:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg2l-0004zg-18; Thu, 19 Jan 2006 15:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg2h-0004zM-Ec for ipv6@megatron.ietf.org; Thu, 19 Jan 2006 15:06:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22577 for ; Thu, 19 Jan 2006 15:04:32 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzgBI-0003WV-BQ for ipv6@ietf.org; Thu, 19 Jan 2006 15:14:52 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0JK3Y9J003540; Thu, 19 Jan 2006 22:03:38 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jan 2006 22:05:52 +0200 Received: from [172.19.69.50] ([172.19.69.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 19 Jan 2006 22:05:52 +0200 In-Reply-To: References: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> <20060110080737.GA12312@boskop.local> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <09818EB9-9B8C-4B1D-8414-4D05F23287A8@nokia.com> Content-Transfer-Encoding: quoted-printable From: Bob Hinden Date: Thu, 19 Jan 2006 12:05:50 -0800 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 19 Jan 2006 20:05:52.0522 (UTC) FILETIME=[BFCF76A0:01C61D33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jinmei, On Jan 18, 2006, at 8:40 PM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: >>>>>> On Wed, 18 Jan 2006 09:54:51 -0800, >>>>>> Bob Hinden said: > >> Here is the text I propose to send to the RFC-Editor to resolve the >> issue. Take a look and let me know it is is OK. > > I personally support this text with one very minor nit: > >> Add: > >> Add to the end of the appendix: > >> Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be >> inserted to create an IEEE EUI-64 identifier from an IEEE MAC-48 >> identifier. The 0xFF and 0xFE values are used when starting =20 >> with an >> IEEE EUI-48 identifier. The incorrect value was used in earlier >> versions of the specification due to an misunderstanding about =20= >> the > > s/an misunderstanding/a misunderstanding/ Thanks, I will fix this. >> differences between IEEE MAC-48 and EUI-48 identifiers. > >> This document purposely continues the use of 0xFF and 0xFE >> because it meets >> the requirements for IPv6 interface identifiers, specifically =20 >> that >> they must be unique on the link, and that it doesn't cause any >> problems in practice. If in the future, a new link type is =20 >> invented >> that uses IEEE EUI-48 and MAC-48 identifiers on the same link, =20= >> the >> 0xFF and 0xFF values could be used to convert the EUI-48 =20 >> identifiers >> for use as IPv6 interface identifiers to avoid any potential for >> duplicate interface identifiers. > > I said 'personally' because it may be controversial to mention the > possibility of the future use of 0xFFFF at this stage (i.e., it may be > beyond the level of 'clarification'). But if the IESG accepts the > description (or the RFC editor agrees this is minor enough), I'm happy > with that. It's only a note at the end of an appendix, but I wouldn't object to =20 removing the last sentence if others are troubled by it. The intent =20 was to provide some advice to someone writing an IPv6 over =20 specification. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jan 19 21:38:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmAn-0008GL-Ax; Thu, 19 Jan 2006 21:38:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmAl-0008GG-MC for ipv6@megatron.ietf.org; Thu, 19 Jan 2006 21:38:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25222 for ; Thu, 19 Jan 2006 21:37:16 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmJP-0000Af-8o for ipv6@ietf.org; Thu, 19 Jan 2006 21:47:40 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16421359; Thu, 19 Jan 2006 21:38:01 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jan 2006 21:38:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jan 2006 21:34:27 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302217B32@PACDCEXCMB01.cable.comcast.com> Thread-Topic: why 0xFFFE is used in the modified EUI-64 format Thread-Index: AcYdNOhkhz18xF9aQyW9G0voWFMxHwANSBVy From: "Durand, Alain" To: "Bob Hinden" , "JINMEI Tatuya / ????" X-OriginalArrivalTime: 20 Jan 2006 02:38:01.0605 (UTC) FILETIME=[883C9B50:01C61D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>> that uses IEEE EUI-48 and MAC-48 identifiers on the same link,=20 >>> the >>> 0xFF and 0xFF values could be used to convert the EUI-48=20 >>> identifiers >>> for use as IPv6 interface identifiers to avoid any potential for >>> duplicate interface identifiers. >> >> I said 'personally' because it may be controversial to mention the >> possibility of the future use of 0xFFFF at this stage (i.e., it may = be >> beyond the level of 'clarification'). But if the IESG accepts the >> description (or the RFC editor agrees this is minor enough), I'm = happy >> with that. > > It's only a note at the end of an appendix, but I wouldn't object to=20 > removing the last sentence if others are troubled by it. The intent=20 > was to provide some advice to someone writing an IPv6 over =20 > specification. I concur that the last sentence should be removed. It doesn't help to = clarify the current situation and may be read as closing the door to other future use of 0xFF and = 0xFF. =20 - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 20 12:54:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00TJ-0005oK-9r; Fri, 20 Jan 2006 12:54:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00TH-0005np-OG for ipv6@megatron.ietf.org; Fri, 20 Jan 2006 12:54:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05264 for ; Fri, 20 Jan 2006 12:53:19 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00c3-0005Fe-2x for ipv6@ietf.org; Fri, 20 Jan 2006 13:03:52 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0KHscPh020575; Fri, 20 Jan 2006 19:54:43 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 19:53:50 +0200 Received: from [172.19.69.50] ([172.19.69.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Jan 2006 19:53:49 +0200 In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302217B32@PACDCEXCMB01.cable.comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C7302217B32@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FE4C067-0889-4DC7-9E55-098D7947CA86@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Fri, 20 Jan 2006 09:53:47 -0800 To: "Durand, Alain" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 20 Jan 2006 17:53:49.0855 (UTC) FILETIME=[77F22AF0:01C61DEA] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: IPv6 WG , JINMEI Tatuya / ???? Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, >> It's only a note at the end of an appendix, but I wouldn't object to >> removing the last sentence if others are troubled by it. The intent >> was to provide some advice to someone writing an IPv6 over >> specification. > > I concur that the last sentence should be removed. It doesn't help > to clarify the current situation > and may be read as closing the door to other future use of 0xFF and > 0xFF. OK, I will remove the last sentence and send the text off to the RFC- Editor. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 20 15:10:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02aK-00059h-TS; Fri, 20 Jan 2006 15:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02aJ-00059S-7P for ipv6@megatron.ietf.org; Fri, 20 Jan 2006 15:10:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15582 for ; Fri, 20 Jan 2006 15:08:44 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02j5-0001G6-Og for ipv6@ietf.org; Fri, 20 Jan 2006 15:19:17 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0KK5NAd030284; Fri, 20 Jan 2006 22:05:25 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 22:10:03 +0200 Received: from [172.19.69.50] ([172.19.69.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 20 Jan 2006 22:10:00 +0200 In-Reply-To: References: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> <20060110080737.GA12312@boskop.local> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <93228125-1307-42FB-BB17-69F14DF6768F@nokia.com> Content-Transfer-Encoding: quoted-printable From: Bob Hinden Date: Fri, 20 Jan 2006 12:10:01 -0800 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 20 Jan 2006 20:10:00.0923 (UTC) FILETIME=[7E4832B0:01C61DFD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Before submitting the new text, I went back and tried to find out =20 what the difference is between an MAC-48 and an EUI-48. In the =20 document: http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html I found the following: "The (obsolete label) MAC-48 is a concatenation of a 24-bit OUI =20 assigned by the IEEE Registration Authority and a 24-bit extension =20 identifier assigned by the organization with that OUI assignment. The EUI-48=99 is a concatenation of a 24-bit OUI value assigned by the =20= IEEE Registration Authority and a 24-bit extension identifier =20 assigned by the organization with that OUI assignment." and: "The use of the MAC-48 identifier is obsolete; the EUI-48 or =20 EUI-64 should be used in current and future applications requiring =20 the use of unique 48-bit identifiers." My reading of this is that from a technical point of view MAC-48 and =20 EUI-48 are equivalant. They are both have the same definition: Mac-48: "a concatenation of a 24-bit OUI assigned by the IEEE =20 Registration Authority and a 24-bit extension identifier assigned by =20 the organization with that OUI assignment" EUI-48: "a concatenation of a 24-bit OUI value assigned by the =20 IEEE Registration Authority and a 24-bit extension identifier =20 assigned by the organization with that OUI assignment" They both use the same 24-bit OUI values. It looks to me like IEEE =20 decided to deprecate the name MAC-48. Why IEEE choose to have two =20 different ways to create EUI-64 from these 48-bit identifiers is a =20 mystery to me. As far as bits on the wire, EUI-48 and MAC-48 appear =20 to be exactly the same. The link in Jinmei's email that started this =20= discussion confirms this: "The distinction between EUI-48 and MAC-48 identifiers is purely =20 semantic: MAC-48 is used for network hardware; EUI-48 is used to =20 identify other sorts of devices and software. (Thus, by definition, =20 an EUI-48 is not in fact a "MAC address", although it is =20 syntactically indistinguishable from one and assigned from the same =20 numbering space.)" I will still plan to submit the new text as it clarifies our use of =20 these identifiers. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 20 17:24:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04fy-0006Gy-6O; Fri, 20 Jan 2006 17:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04fw-0006FP-5y for ipv6@megatron.ietf.org; Fri, 20 Jan 2006 17:24:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06622 for ; Fri, 20 Jan 2006 17:22:40 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04ok-0001Fn-Lj for ipv6@ietf.org; Fri, 20 Jan 2006 17:33:15 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0KMO4sJ022659; Sat, 21 Jan 2006 00:24:05 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jan 2006 00:24:05 +0200 Received: from [172.19.69.50] ([172.19.69.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 21 Jan 2006 00:24:04 +0200 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <93228125-1307-42FB-BB17-69F14DF6768F@nokia.com> References: <02C5C0B4-6D25-410F-B87E-F9506CA2F787@nokia.com> <20060110080737.GA12312@boskop.local> <93228125-1307-42FB-BB17-69F14DF6768F@nokia.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81363F5E-42CB-44FE-B10B-6A2D0DAE1BAF@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Fri, 20 Jan 2006 14:24:06 -0800 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= , IPv6 WG X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 20 Jan 2006 22:24:04.0228 (UTC) FILETIME=[38772440:01C61E10] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org One more thing, On Jan 20, 2006, at 12:10 PM, Bob Hinden wrote: > .... > They both use the same 24-bit OUI values. It looks to me like IEEE > decided to deprecate the name MAC-48. Why IEEE choose to have two > different ways to create EUI-64 from these 48-bit identifiers is a > mystery to me. As far as bits on the wire, EUI-48 and MAC-48 > appear to be exactly the same. The link in Jinmei's email that > started this discussion confirms this: > > "The distinction between EUI-48 and MAC-48 identifiers is purely > semantic: MAC-48 is used for network hardware; EUI-48 is used to > identify other sorts of devices and software. (Thus, by definition, > an EUI-48 is not in fact a "MAC address", although it is > syntactically indistinguishable from one and assigned from the same > numbering space.)" > > I will still plan to submit the new text as it clarifies our use of > these identifiers. On further thought, I will change the last paragraph of the Note to: This document purposely continues the use of 0xFF and 0xFE because it meets the requirements for IPv6 interface identifiers (i.e., that they must be unique on the link), IEEE EUI-48 and MAC-48 identifiers are syntactically equivalent, and that it doesn't cause any problems in practice. Let me know if anyone objects. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jan 20 17:30:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04mQ-0001Rx-Vu; Fri, 20 Jan 2006 17:30:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04mP-0001Q7-0V for ipv6@megatron.ietf.org; Fri, 20 Jan 2006 17:30:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07561 for ; Fri, 20 Jan 2006 17:29:21 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04vA-0001dY-O2 for ipv6@ietf.org; Fri, 20 Jan 2006 17:39:56 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA13717; Fri, 20 Jan 2006 14:30:28 -0800 (PST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k0KMUSW06141; Fri, 20 Jan 2006 14:30:28 -0800 (PST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Jan 2006 17:30:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Fri, 20 Jan 2006 17:30:27 -0500 Message-ID: Thread-Topic: why 0xFFFE is used in the modified EUI-64 format Thread-Index: AcYeEINVR/lHkYOtTM6B9QnjdZAIOQAACAYA From: "Manfredi, Albert E" To: "Bob Hinden" , =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "IPv6 WG" X-OriginalArrivalTime: 20 Jan 2006 22:30:27.0426 (UTC) FILETIME=[1CDE8420:01C61E11] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Subject: RE: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I prefer this latest wording. I was puzzled why there was any difference between EUI-48 and MAC-48, and was about to start searching when you provided the answer. I think it's best not to imply there's anything more to this than there actually is. FF-FE resulted from some misinterpretation in the past, and so be it. Bert > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com] > Sent: Friday, January 20, 2006 5:24 PM > To: JINMEI Tatuya / 神明達哉; IPv6 WG > Subject: Re: why 0xFFFE is used in the modified EUI-64 format > > One more thing, > > On Jan 20, 2006, at 12:10 PM, Bob Hinden wrote: > > > .... > > They both use the same 24-bit OUI values. It looks to me > like IEEE > > decided to deprecate the name MAC-48. Why IEEE choose to have two > > different ways to create EUI-64 from these 48-bit identifiers is a > > mystery to me. As far as bits on the wire, EUI-48 and MAC-48 > > appear to be exactly the same. The link in Jinmei's email that > > started this discussion confirms this: > > > > "The distinction between EUI-48 and MAC-48 identifiers is purely > > semantic: MAC-48 is used for network hardware; EUI-48 is used to > > identify other sorts of devices and software. (Thus, by > definition, > > an EUI-48 is not in fact a "MAC address", although it is > > syntactically indistinguishable from one and assigned from > the same > > numbering space.)" > > > > I will still plan to submit the new text as it clarifies > our use of > > these identifiers. > > On further thought, I will change the last paragraph of the Note to: > > This document purposely continues the use of 0xFF and 0xFE > because it meets > the requirements for IPv6 interface identifiers (i.e., that they > must be unique on > the link), IEEE EUI-48 and MAC-48 identifiers are syntactically > equivalent, > and that it doesn't cause any problems in practice. > > Let me know if anyone objects. > > Thanks, > 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 22 00:00:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0XLD-0002py-Ne; Sun, 22 Jan 2006 00:00:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0XLC-0002p8-3C for ipv6@megatron.ietf.org; Sun, 22 Jan 2006 00:00:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20217 for ; Sat, 21 Jan 2006 23:59:09 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0XUG-0007En-2B for ipv6@ietf.org; Sun, 22 Jan 2006 00:10:01 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id E58F2175 for ; Sun, 22 Jan 2006 00:00:09 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 22 Jan 2006 00:00:09 -0500 Message-Id: <20060122050009.E58F2175@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group ¥(ipv6¥)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 38.46% | 5 | 36.95% | 27190 | bob.hinden@nokia.com 7.69% | 1 | 15.31% | 11265 | dthaler@windows.microsoft.com 7.69% | 1 | 11.40% | 8386 | h.soliman@flarion.com 7.69% | 1 | 7.99% | 5882 | albert.e.manfredi@boeing.com 7.69% | 1 | 6.92% | 5093 | jinmei@isl.rdc.toshiba.co.jp 7.69% | 1 | 5.98% | 4401 | alain_durand@cable.comcast.com 7.69% | 1 | 5.62% | 4134 | sra+ipng@hactrn.net 7.69% | 1 | 5.43% | 3997 | jordi.palet@consulintel.es 7.69% | 1 | 4.39% | 3231 | ietf@handynerds.com --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 73579 | 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 ipv6-bounces@ietf.org Tue Jan 24 13:25:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1SrK-0003wH-1H; Tue, 24 Jan 2006 13:25:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1SrH-0003w2-AH for ipv6@megatron.ietf.org; Tue, 24 Jan 2006 13:25:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07184 for ; Tue, 24 Jan 2006 13:24:04 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1T0r-0005os-Fu for ipv6@ietf.org; Tue, 24 Jan 2006 13:35:30 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.13091893; Tue, 24 Jan 2006 13:25:00 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Date: Tue, 24 Jan 2006 13:24:59 -0500 To: IPv6 WG X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Bob Hinden Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group ¥(ipv6¥)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0482033696==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0482033696== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-906109983; protocol="application/pkcs7-signature" --Apple-Mail-2-906109983 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The WG Last Call has passed on this with two substantive comments. The following is the proposed changes to -13 to address them. Please voice your support or disagreement with these changes. 1. Length of appended MD5 hash value: OLD: Compute the MD5 hash [7] of the first label of the Subject Name -- the portion beginning with the first one-octet length field and up to, but excluding, any subsequent length field. Append the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:FF::/104. NEW: Compute the MD5 hash [7] of the first label of the Subject Name -- the portion beginning with the first one-octet length field and up to, but excluding, any subsequent length field. Append the first 24 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:FF::/104. 2. Default configuration text for discarding NI Queries OLD: A node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es) but if so, the default configuration SHOULD be not to discard them. An exception is made in the previous rule in the case of the All-Routers (FF02::2) and All-Nodes (FF02::1) multicast addresses. The default configuration for responding to NI Queries to these multicast addresses MUST be to discard them. NEW: A node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es) but if so, the default configuration SHOULD be not to discard them. Please respond by 01/31/06. Regards, Brian --Apple-Mail-2-906109983 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMTI0MTgyNDYwWjAjBgkqhkiG9w0B CQQxFgQURV45Im4fAHEynJH6QK+nm2jw6qIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAbi8JAiM4uh+cHgGX/Xu4Goad1usoaSUCFRTAHHKZKmce/43vwDVrSOOAzKTMcfUQFSVm SNlzspVHwZ2MPh6O0GxtdHLE6QhCfzL2voXd1PWmWIb6sGdHKHgYyDVZEq9CPoFywdAUX9pk9xdp VgX2QIsVN0qYtp8SiUc8I05XocoC3Kr4Lpbr0To2Z9lWhJo0/bUuzuyfBJqgQ0ggh1tecbPS0HnX UuWezithmiS5K9UhngBAS3CzC+Yyq4NS8NBAY4KJikfjA6DGlDWoSmFQMSsHcOm1TAAeAH/oUpB6 uvhwc5B6qGRxlOJhFOutMwcZQz5+ugv6Uv2g8H4QWOxu+AAAAAAAAA== --Apple-Mail-2-906109983-- --===============0482033696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0482033696==-- From ipv6-bounces@ietf.org Wed Jan 25 00:42:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1dQp-00060N-9e; Wed, 25 Jan 2006 00:42:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1dQn-00060I-W6 for ipv6@megatron.ietf.org; Wed, 25 Jan 2006 00:42:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10610 for ; Wed, 25 Jan 2006 00:41:27 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1daT-0001oL-9q for ipv6@ietf.org; Wed, 25 Jan 2006 00:52:59 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0P5gaHa010924; Wed, 25 Jan 2006 07:42:36 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0P5gWp8010921; Wed, 25 Jan 2006 07:42:36 +0200 Date: Wed, 25 Jan 2006 07:42:32 +0200 (EET) From: Pekka Savola To: Brian Haberman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1248/Tue Jan 24 12:54:38 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Bob Hinden , IPv6 WG Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group ¥(ipv6¥)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 24 Jan 2006, Brian Haberman wrote: > The WG Last Call has passed on this with two substantive comments. > The following is the proposed changes to -13 to address them. Please voice > your support or disagreement with these changes. I'm fine with these changes. > 1. Length of appended MD5 hash value: > > OLD: > Compute the MD5 hash [7] of the first label of the > Subject Name -- the portion beginning with the first one-octet length > field and up to, but excluding, any subsequent length field. Append > the first 32 bits of that 128-bit hash to the prefix > FF02:0:0:0:0:2:FF::/104. > > NEW: > Compute the MD5 hash [7] of the first label of the > Subject Name -- the portion beginning with the first one-octet length > field and up to, but excluding, any subsequent length field. Append > the first 24 bits of that 128-bit hash to the prefix > FF02:0:0:0:0:2:FF::/104. > > 2. Default configuration text for discarding NI Queries > > OLD: > A node MAY be configured to discard NI Queries to > multicast addresses other than its NI Group Address(es) but if so, > the default configuration SHOULD be not to discard them. An > exception is made in the previous rule in the case of the All-Routers > (FF02::2) and All-Nodes (FF02::1) multicast addresses. The default > configuration for responding to NI Queries to these multicast > addresses MUST be to discard them. > > NEW: > A node MAY be configured to discard NI Queries to > multicast addresses other than its NI Group Address(es) but if so, > the default configuration SHOULD be not to discard them. > > Please respond by 01/31/06. > > Regards, > Brian > > -- 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 ipv6-bounces@ietf.org Wed Jan 25 05:33:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1hyP-0001tx-8n; Wed, 25 Jan 2006 05:33:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1hyN-0001tj-1j for ipv6@megatron.ietf.org; Wed, 25 Jan 2006 05:33:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28964 for ; Wed, 25 Jan 2006 05:32:22 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1i85-0002sT-A8 for ipv6@ietf.org; Wed, 25 Jan 2006 05:43:58 -0500 Date: Wed, 25 Jan 2006 10:33:24 +0000 From: David Malone To: Brian Haberman Message-ID: <20060125103324.GA43927@salmon.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Bob Hinden , IPv6 WG Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group ¥(ipv6¥)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Jan 24, 2006 at 01:24:59PM -0500, Brian Haberman wrote: > The WG Last Call has passed on this with two substantive comments. > The following is the proposed changes to -13 to address them. Please > voice your support or disagreement with these changes. Looks good to me too. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jan 25 08:24:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1kdi-000069-86; Wed, 25 Jan 2006 08:24:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1kdg-0008Vx-B6 for ipv6@megatron.ietf.org; Wed, 25 Jan 2006 08:24:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11870 for ; Wed, 25 Jan 2006 08:23:13 -0500 (EST) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1knO-0000iQ-1T for ipv6@ietf.org; Wed, 25 Jan 2006 08:34:49 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 25 Jan 2006 13:24:38 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 25 Jan 2006 13:24:36 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2006 07:24:31 -0600 Message-ID: <041052AD735329479241C23E0813EB7E9768DA@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: IPv6 WG Last Call: Thread-Index: AcYhm1ZsbFzP6mE9QY+PQmr6CiEuxAAF0gOg From: "Pashby, Ronald W CTR NSWCDD-B35" To: "David Malone" , "Brian Haberman" X-OriginalArrivalTime: 25 Jan 2006 13:24:31.0685 (UTC) FILETIME=[ACFDD750:01C621B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG , Bob Hinden Subject: RE: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group ¥(ipv6¥)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I agree with the changes too Ron -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of David Malone Sent: Wednesday, January 25, 2006 5:33 To: Brian Haberman Cc: Bob Hinden; IPv6 WG Subject: Re: IPv6 WG Last Call: On Tue, Jan 24, 2006 at 01:24:59PM -0500, Brian Haberman wrote: > The WG Last Call has passed on this with two substantive = comments. > The following is the proposed changes to -13 to address them. Please=20 > voice your support or disagreement with these changes. Looks good to me too. David. -------------------------------------------------------------------- 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 ipv6-bounces@ietf.org Wed Jan 25 08:31:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1kk5-00029l-51; Wed, 25 Jan 2006 08:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1kk3-000287-8L for ipv6@megatron.ietf.org; Wed, 25 Jan 2006 08:31:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12336 for ; Wed, 25 Jan 2006 08:29:48 -0500 (EST) Date: Wed, 25 Jan 2006 08:29:48 -0500 (EST) Message-Id: <200601251329.IAA12336@ietf.org> Received: from mail.arrocha.com ([201.224.218.244] helo=optiplex) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1ktm-0000wg-Ia for ipv6@ietf.org; Wed, 25 Jan 2006 08:41:24 -0500 From: "brian" To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_9.67864394187927E-02" X-Spam-Score: 2.0 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: the file X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group ¥(ipv6¥)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_9.67864394187927E-02 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA12336 Norman Virus Control ha borrado el e-mail original porque conten=EDa el v= irus Small.KI@mm =20 ------=_NextPart_9.67864394187927E-02 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_NextPart_9.67864394187927E-02--