From mailman-bounces@ietf.org Fri Oct 1 10:17:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03286 for ; Fri, 1 Oct 2004 10:17:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOMd-0008Bp-OR for ipv6-web-archive@ietf.org; Fri, 01 Oct 2004 10:26:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKDV-0007ew-MN for ipv6-web-archive@ietf.org; Fri, 01 Oct 2004 06:00:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipv6-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:23:23 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipv6-web-archive@ietf.org: List Password // URL ---- -------- ipv6@ietf.org azsube https://www1.ietf.org/mailman/options/ipv6/ipv6-web-archive%40ietf.org From ipv6-bounces@ietf.org Fri Oct 1 11:20:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09477 for ; Fri, 1 Oct 2004 11:20:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDPLW-0000uS-N6 for ipv6-web-archive@ietf.org; Fri, 01 Oct 2004 11:29:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKoB-0005u6-Fq; Fri, 01 Oct 2004 06:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJhQ-0002vz-SN; Fri, 01 Oct 2004 05:27:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09609; Fri, 1 Oct 2004 05:27:34 -0400 (EDT) Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJpn-0002Yn-T6; Fri, 01 Oct 2004 05:36:19 -0400 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5275A81A5; Fri, 1 Oct 2004 11:27:25 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 23328-34; Fri, 1 Oct 2004 11:27:09 +0200 (CEST) Received: from [9.4.68.125] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 363007FC0; Fri, 1 Oct 2004 11:27:07 +0200 (CEST) From: Jeroen Massar To: "Manfredi, Albert E" In-Reply-To: References: Organization: Unfix Message-Id: <1096622818.14349.155.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 01 Oct 2004 11:26:58 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: magma@ietf.org, ipv6@ietf.org Subject: RE: [magma] Re: RC3810: MLD Hop Limit is 1 / random reply time / exclude 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="===============0058081216==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --===============0058081216== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-b/az1z6sTGvmahluQLEy" --=-b/az1z6sTGvmahluQLEy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-09-27 at 18:35, Manfredi, Albert E wrote: > Jeroen Massar wrote: >=20 > > Brian Haberman wrote: > > > The hop limit of 1 is to keep MLD consistent with IGMP. > >=20 > > You mean IGMPv3, thus actually IPv4? >=20 > MLDv2 is actually IGMPv3 modified to the IPv6 way of doing things. > Just as MLDv1 was basically IGMPv2. >=20 > I think that the advantages of source filtering are somewhat less > critical with IPv6. I think one of the primary reasons to add source > filtering in IGMPv3 was an effort to conserve on Class D addresses > used for multicasting in IPv4. It's another scheme to extend the > useful life of IPv4. One could also have eg a multicast NTP setup (FF0X::101) and using source filtering mention that you do not want traffic from certain NTP sources, or a specific address which can be used for a video conference chat, using the source address for the quality of the stream etc, eg: 2001:db8::1 =3D 1mbit stream, 2001:db8::64 =3D 64mbit stream, or some similar scheme, thus it has some value for IPv6 too, but indeed for IPv4 it is yet another prolongation. > > But wouldn't it be better to use > > 255 here to make it consistent with the "we don't want remote hosts to > > set a TTL to 5, let the packet hop 4 routers and tada do ND=20 > > there' idea? >=20 > The idea with IGMP and MLD is for local hosts to inform only the last > hop router(s), which must obviously be multicast routers, as to the group > membership of each of their directly attached segments. The routers then > relay this information up the multicast tree using multicast routing > protocols, such as PIM. That's another whole subject area. > > So the TTL of 1 makes sense. You don't want to clutter up multiple IP > subnets with information that is meant only for the local last-hop > multicast router(s). It's a scaling issue. In any event, multicast > routers won't forward IGMP packets, so the TTL value is not that critical= perhaps. Agreed, but maybe to keep in sync with the ND idea, it would be better to do it anyway in case someone sets up a default, or ff0x::/8 unicast route towards another router, as most unicast routers will then simply handle this as a unicast packet and route it along. Someone could then craft a packet with a 4 hoplimit, being 3 router hops away and be able to inject a MLD packet into your network. The 255 hoplimit allows one to at least check if the packet really came from the local network, otherwise it will be <255, just like in ND. afaik some BGP implementations also started doing this trick to make sure that the packet really is from the local net and not coming in over some spoofed source in a far far away country. Greets, Jeroen --=-b/az1z6sTGvmahluQLEy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBXSLhKaooUjM+fCMRAoebAJsFoOeYVJ5c/qZGoSu3sd5P6q8qrACff/GN 7ppLJKZAYsJ/OMucDQ5UJvw= =gOIs -----END PGP SIGNATURE----- --=-b/az1z6sTGvmahluQLEy-- --===============0058081216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0058081216==-- From ipv6-bounces@ietf.org Fri Oct 1 13:14:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26625 for ; Fri, 1 Oct 2004 13:14:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR87-0004B0-WF for ipv6-web-archive@ietf.org; Fri, 01 Oct 2004 13:23:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQAB-0007Re-Fj; Fri, 01 Oct 2004 12:21:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDODf-0001dC-RZ for ipv6@megatron.ietf.org; Fri, 01 Oct 2004 10:17:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03204 for ; Fri, 1 Oct 2004 10:17:10 -0400 (EDT) Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOLx-00087x-Lu for ipv6@ietf.org; Fri, 01 Oct 2004 10:25:57 -0400 Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4W008SERI2SA@mta2.huawei.com> for ipv6@ietf.org; Fri, 01 Oct 2004 21:44:27 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 82003)) with ESMTP id <0I4W00GOARI2IL@mta2.huawei.com> for ipv6@ietf.org; Fri, 01 Oct 2004 21:44:26 +0800 (CST) Received: from arvindsaproo ([10.18.4.94]) by mailin.huawei.com (Netscape Messaging Server 4.15)with ESMTP id I4WROY01.50Q for ; Fri, 01 Oct 2004 21:48:34 +0800 Date: Fri, 01 Oct 2004 19:14:17 +0530 From: arvind saproo To: ipv6@ietf.org Message-id: <000001c4a7bc$bf0f7cd0$5e04120a@in.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Subject: Query:IPv6 Over ATM PVC Operation 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="===============0068219196==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 This is a multi-part message in MIME format. --===============0068219196== Content-type: multipart/alternative; boundary="Boundary_(ID_9hoA+5RbWNIMUEQjWZq4iw)" This is a multi-part message in MIME format. --Boundary_(ID_9hoA+5RbWNIMUEQjWZq4iw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, I have the following query regarding IPv6 Over ATM PVC operation (rfc2492). I would appreciate if someone could answer the same. Query - ===== RFC does not clearly mention what to fill as the Source/Target Link Layer address in the Source/Target Link Layer options of IND (Inverse ND) messages. Also, there is no mention of any reference document which covers the same. All that is said is [Section 3. PVC Environments] - "Since ATM PVC links do not use link-layer addresses, the link-layer address options SHOULD not be included in any ND message [11]. If a link-layer address option is present in an ND message, then the option SHOULD be ignored." Does this mean that we zero fill the Link Layer address in Source/Target Link Layer options of the IND messages? This information must be clearly mentioned to avoid interoperability issues. Thanks for your time, Rgds, arvind --Boundary_(ID_9hoA+5RbWNIMUEQjWZq4iw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

  I have the following query regarding IPv6 Over ATM PVC operation (rfc2492).

  I would appreciate if someone could answer the same.

 

 Query –

=====

RFC does not clearly mention what to fill as the Source/Target

Link Layer address in the Source/Target Link Layer options

of IND (Inverse ND) messages.

 

Also, there is no mention of any reference document which

covers the same.

 

All that is said is [Section 3. PVC Environments] –

 

“Since ATM PVC links do not use link-layer addresses, the link-layer

address options SHOULD not be included in any ND message [11].  If a

link-layer address option is present in an ND message, then the

option SHOULD be ignored.”

 

Does this mean that we zero fill the Link Layer address in Source/Target

Link Layer options of the IND messages?

 

This information must be clearly mentioned to avoid interoperability issues.

 

 

Thanks for your time,

Rgds,

arvind

--Boundary_(ID_9hoA+5RbWNIMUEQjWZq4iw)-- --===============0068219196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0068219196==-- From ipv6-bounces@ietf.org Sat Oct 2 14:18:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00236 for ; Sat, 2 Oct 2004 14:18:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDob2-0000Cb-9b for ipv6-web-archive@ietf.org; Sat, 02 Oct 2004 14:27:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDoOb-0002vk-BC; Sat, 02 Oct 2004 14:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDoO3-0002P4-RA; Sat, 02 Oct 2004 14:13:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00060; Sat, 2 Oct 2004 14:13:38 -0400 (EDT) Received: from castlerea.stdlib.net ([212.13.199.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDoWk-00007W-St; Sat, 02 Oct 2004 14:22:39 -0400 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1CDoNr-0006LB-G6; Sat, 02 Oct 2004 19:13:27 +0100 Date: Sat, 2 Oct 2004 19:13:27 +0100 From: Colm MacCarthaigh To: Jeroen Massar Message-ID: <20041002181327.GA24369@castlerea.stdlib.net.> References: <1096622818.14349.155.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1096622818.14349.155.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA00060 Cc: magma@ietf.org, ipv6@ietf.org Subject: Re: [magma] Re: RC3810: MLD Hop Limit is 1 / random reply time / exclude X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: colm@stdlib.net 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable On Fri, Oct 01, 2004 at 11:26:58AM +0200, Jeroen Massar wrote: > > I think that the advantages of source filtering are somewhat less > > critical with IPv6. I think one of the primary reasons to add source > > filtering in IGMPv3 was an effort to conserve on Class D addresses > > used for multicasting in IPv4. It's another scheme to extend the > > useful life of IPv4. >=20 > One could also have eg a multicast NTP setup (FF0X::101) and using > source filtering mention that you do not want traffic from certain NTP > sources, or a specific address which can be used for a video conference > chat, using the source address for the quality of the stream etc, eg: > 2001:db8::1 =3D 1mbit stream, 2001:db8::64 =3D 64mbit stream, or some > similar scheme, thus it has some value for IPv6 too, but indeed for IPv= 4 > it is yet another prolongation. It's also a means of some DoS mitigation for abritrary one-to-many multicast applications (in that arbitrary sources can no longer flood the group-id). To my mind the advantages of source-filtering are equally critical in IPv6 as in IPv4. Mitigating some address exhaustion is just a nice benefit. --=20 Colm MacC=E1rthaigh Public Key: colm+pgp@stdlib.ne= t -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 3 00:08:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29371 for ; Sun, 3 Oct 2004 00:08:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDxoL-0003mE-Hv for ipv6-web-archive@ietf.org; Sun, 03 Oct 2004 00:17:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDxax-0001Hm-08; Sun, 03 Oct 2004 00:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDxYV-0008Ck-LI for ipv6@megatron.ietf.org; Sun, 03 Oct 2004 00:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28893 for ; Sun, 3 Oct 2004 00:01:00 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDxhI-0003dP-GQ for ipv6@ietf.org; Sun, 03 Oct 2004 00:10:09 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 51E6451B for ; Sun, 3 Oct 2004 00:00:29 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 03 Oct 2004 00:00:29 -0400 Message-Id: <20041003040029.51E6451B@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.04% | 3 | 21.05% | 28566 | humphrey.gu@nfs.com.cn 13.04% | 3 | 15.90% | 21573 | jeroen@unfix.org 13.04% | 3 | 9.47% | 12851 | francis.dupont@enst-bretagne.fr 8.70% | 2 | 6.74% | 9147 | join@uni-muenster.de 4.35% | 1 | 7.74% | 10500 | arvindsaproo@huawei.com 4.35% | 1 | 7.35% | 9974 | brian@innovationslab.net 4.35% | 1 | 4.17% | 5662 | internet-drafts@ietf.org 4.35% | 1 | 3.92% | 5314 | erik.nordmark@sun.com 4.35% | 1 | 3.45% | 4687 | albert.e.manfredi@boeing.com 4.35% | 1 | 3.29% | 4468 | rhkaram@inco.com.lb 4.35% | 1 | 3.03% | 4111 | colm@stdlib.net 4.35% | 1 | 3.01% | 4087 | stig.venaas@uninett.no 4.35% | 1 | 2.91% | 3955 | david.carmean@netapp.com 4.35% | 1 | 2.78% | 3776 | sra+ipng@hactrn.net 4.35% | 1 | 2.64% | 3584 | mailman-owner@ietf.org 4.35% | 1 | 2.53% | 3437 | margaret@thingmagic.com --------+------+--------+----------+------------------------ 100.00% | 23 |100.00% | 135692 | 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 Oct 4 05:14:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15190 for ; Mon, 4 Oct 2004 05:14:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEP4U-0004AT-2j for ipv6-web-archive@ietf.org; Mon, 04 Oct 2004 05:23:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOt4-0006QS-Jy; Mon, 04 Oct 2004 05:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOpd-0005su-Pn for ipv6@megatron.ietf.org; Mon, 04 Oct 2004 05:08:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14679 for ; Mon, 4 Oct 2004 05:08:30 -0400 (EDT) Received: from [80.74.106.237] (helo=star.radlan.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOyV-00043m-Gc for ipv6@ietf.org; Mon, 04 Oct 2004 05:17:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2004 11:07:38 +0200 Message-ID: <1612A4FBCAA7434FB246A491ECF20EC302882C@star.radlan.net> Thread-Topic: Query:IPv6 Over ATM PVC Operation Thread-Index: AcSn2kd6fF4p7rovT6u1I6wI9Wz7YgCEmM4g From: "Nimrod Sterrn" To: "arvind saproo" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Query:IPv6 Over ATM PVC Operation 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable see my comments in =3D=3D> -----Original Message----- From: arvind saproo [mailto:arvindsaproo@huawei.com] Sent: Fri, October 01, 2004 3:44 PM To: ipv6@ietf.org Subject: Query:IPv6 Over ATM PVC Operation Hi,=20 I have the following query regarding IPv6 Over ATM PVC operation = (rfc2492). I would appreciate if someone could answer the same. Query - =3D=3D=3D=3D=3D=20 RFC does not clearly mention what to fill as the Source/Target Link Layer address in the Source/Target Link Layer options=20 of IND (Inverse ND) messages.=20 Also, there is no mention of any reference document which covers the same. All that is said is [Section 3. PVC Environments] -=20 "Since ATM PVC links do not use link-layer addresses, the link-layer address options SHOULD not be included in any ND message [11]. If a link-layer address option is present in an ND message, then the option SHOULD be ignored." =3D=3D> It may be confusing after reading RFC3122 (inverse ND) which = requires it as part of the=20 solicitation (src and dst LL address) and reply (target LL = address). but since PVC in "permanent" its not needed (?!) =20 Does this mean that we zero fill the Link Layer address in Source/Target = Link Layer options of the IND messages? This information must be clearly mentioned to avoid interoperability = issues.=20 Thanks for your time, Rgds, arvind -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 5 03:00:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25650 for ; Tue, 5 Oct 2004 03:00:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEjSa-0002vw-G5 for ipv6-web-archive@ietf.org; Tue, 05 Oct 2004 03:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjGU-0005zk-4c; Tue, 05 Oct 2004 02:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjAn-0004xr-3E for ipv6@megatron.ietf.org; Tue, 05 Oct 2004 02:51:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24919 for ; Tue, 5 Oct 2004 02:51:43 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEjK1-0001KX-0l for ipv6@ietf.org; Tue, 05 Oct 2004 03:01:17 -0400 Received: from [128.176.184.238] (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.1/8.12.9) with ESMTP id i956pc9o009351 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 5 Oct 2004 08:51:38 +0200 (CEST) From: "Christian Schild (JOIN Project Team)" To: Erik Nordmark In-Reply-To: <415C32D1.1080609@sun.com> References: <1096530231.17680.139.camel@lemy.ipv6.uni-muenster.de> <415C32D1.1080609@sun.com> Content-Type: text/plain Message-Id: <1096959129.10951.68.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Tue, 05 Oct 2004 08:52:09 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: No RS after valid lifetime times out 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Am Do, den 30.09.2004 schrieb Erik Nordmark um 18:22: > Christian Schild wrote: > > > I would have expected, that immediately when an interface removes its > > (last) global address, it will try to obtain a new one, sending out an > > immediate RS. This is not the case on various platforms. > > [..] > > Shouldn't a client react when its valid lifetime times out and the > > interface loses the address? [..] > But that wasn't the root of your question. > Doesn't your case fall in a misconfiguration of the routers? > For instance, I've tested things in the past with a periodic RA > annoucement of 10 minutes with a valid lifetime of 5 minutes and > observed that the loose the address after 5 minutes and regain it when > hearing an RA 5 minutes later. That's a fine test case, but it wouldn't > be a useful configuration for an operational network. > > So why do you think we need to change something? [..] > You seem to want to solve the problem when the routers have been > configured with a bad set of parameters to use in the advertisements. > Why can't this be fixed by configuring the routers properly? > > If you think the hosts need to do more work to handle misconfigured > routers I fear it is a very slippery slope; for instance, should the > hosts guard against the routers advertising incorrect prefixes as well? I agree to most of your arguments. The valid lifetime timeouts can only occur when something is wrong. The RFCs handle prefixes and their lifetimes perfectly well. But still, the real world out there is often different from the nice and clean behaviour described in an RFC. In fact, misconfiguration does happen, be it because of ignorance or by mistake. Also, packet loss it not so uncommon in the real world. There were times, when in some areas of our network we had close to 1 percent packet loss, and it was accepted, because it was just to expensive to fix it. Sometimes an admin doesn't even know that there is packet loss in the network. What is new in IPv6 and SLAAC, is that packet loss might lead to a complete loss of connectivity. I admit that the probability is not very high, that a node misses some consecutive RAs, but it is possible. And it is hell for a network admin to find out, why "some" clients loose their connectivity for "some time". What counts in the end, is that the customer gets a non-interrupted service. The problems above can all be solved, when the client is allowed to react itself, when it loses it's connectivity. The list in RFC2461, when it has to send RS, is a good list in what cases this might happen. Timing out of the valid lifetime is just one more of them. So why not give the client the opportunity to heal himself by adding something like "an implementation may choose to send a RS after the valid lifetime times out" to the RFC(s)? So long, Christian -- JOIN - IPv6 reference center Christian Schild A WWU project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: schild@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 6 09:17:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22880 for ; Wed, 6 Oct 2004 09:17:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBpH-0001R5-UX for ipv6-web-archive@ietf.org; Wed, 06 Oct 2004 09:27:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBZS-0003TM-Ro; Wed, 06 Oct 2004 09:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBUa-0002aP-V4 for ipv6@megatron.ietf.org; Wed, 06 Oct 2004 09:06:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21420 for ; Wed, 6 Oct 2004 09:06:03 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBe5-0000Xx-Fy for ipv6@ietf.org; Wed, 06 Oct 2004 09:15:54 -0400 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 168367; Wed, 06 Oct 2004 09:01:06 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Wed, 6 Oct 2004 09:05:53 -0400 To: JINMEI Tatuya From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: Thomas Narten , ipv6@ietf.org Subject: AD Review of draft-ietf-ipv6-rfc2462bis-06.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Hi Jinmei, I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have several comments on this document that I believe should be resolved before this document is sent to IETF Last Call for publication as a Draft Standard. All of my comments are included below, but my most serious concerns are: (1) Having decided that "the stateful configuration" mechanism is DHCPv6, I don't think that there is a reason to maintain the awkward and confusing wording about "the stateful mechanism" in many places. I've pointed out the worst cases, but there are many others. I know that this is largely an editorial concern, but the awkwardness and lack of clarity are bad enough in some places (see below) that I consider this a blocking problem for publication at DS. (2) I am not comfortable with the idea that we would punt the interpretation of the M & O bits to a "separate document" with no reference. I believe that information about how to interpret these bits is essential to implementing IPv6 address autoconfiguration. See below for the specific text that concerns me. I'd be interested in your feedback on these issues, as well as on the other more minor issues I've noted below. I've cc:ed the IPv6 WG on this message, and other IPv6 folks should also feel free to respond, especially if you think that I'm mistaken about something. Margaret --- My comments are in-line, marked with ">>" Abstract This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both. >> whether they can be obtained through stateless autoconfiguration, >>the Dynamic Host Configuration Protocol (DHCP) or both? This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified in RFC 3315; an alternative way of using the stateful protocol to deliver 'other information' only is specified in RFC 3736. >> I'd move the whole last sentence to an introduction and take it >>out of the abstract. Since we can't have references in an >>abstract, I think it is useless, anyway. 1. INTRODUCTION This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both. >> s/the stateful mechanism/DHCP This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol is specified in [RFC3315] and [RFC3736]. >> s/the stateful protocol/DHCP IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a Dynamic Host Configuration Protocol (DHCPv6) server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. To obtain other configuration information without configuring addresses in the stateful autoconfiguration model, a subset of DHCPv6 [RFC3736] will be used. While the model is called "stateful" here in order to highlight the contrast to the stateless protocol defined in this document, the intended protocol is also defined to work in a stateless fashion. This is based on a result, through operational experiments, that all known "other" configuration information can be managed by a stateless server, that is, a server that does not maintain state of each client that the server provides with the configuration information. >> This is the part that I consider to be quite awkward, particularly >>the vague references to operational experiments that aren't >>documented or referenced here. If you switch to just referring to >>DHCP, the preceeding three paragraphs can be substantially >>simplified. I also thin it is unnecessary to say so much about how >>DHCP works -- that is the subject of other document. There are >>many other places where the text would be much clearer if DHCP (or >>DHCPv6) were used instead of "the stateful mechanism", but I will >>not mark them all. The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. The stateful approach is used when a site requires tighter control over exact address assignments. Both stateful and stateless address autoconfiguration may be used simultaneously. The site administrator specifies which type of autoconfiguration is available through the setting of appropriate fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis]. >> Given this normative reference, would it make sense to hold >>2462bis until 2461bis is completed and send them forward together? >>Otherwise, this will just block in the RFC Editor, and we won't >>have the ability to change it again if we discover issue while >>finishing the 2461 update. Thoughts? 2. TERMINOLOGY >> Is this terminology section intended to be in logical order? Is >>there a reason to prefer this order over an alphabetical listing? Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending the interface's identifier to the well-known link-local prefix. >> I think that there should be a reference to the addressing >>architecture or the scoped address architecture here... Something >>that tells me how I actually create a link-local address. A "managed address configuration (M)" flag indicates whether hosts can use stateful autoconfiguration [RFC3315] to obtain addresses. An "other stateful configuration (O)" flag indicates whether hosts can use stateful autoconfiguration [RFC3736] to obtain additional information (excluding addresses). The details of how a host may use the M flag, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for address assignment will be described in a separate document. Similarly, the details of how a host may use the O flag, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for getting other configuration information will be described in a separate document. However a host uses the M and O flags, and local configuration to control autoconfiguration, the default setting will result in received Router Advertisements being processed for stateless address autoconfiguration. >> I don't think it is okay to publish a DS that leaves important >>implementation details to a "separate document". Has the separate >>document been published? If so, it needs to be normatively >>referenced here. Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. It should be noted that the stateless and stateful address autoconfiguration fields in Router Advertisements are processed independently of one another, and a host may use both stateful and stateless address autoconfiguration simultaneously. One Prefix Information option field, the "autonomous address-configuration flag", indicates whether or not the option even applies to stateless autoconfiguration. If it does, additional option fields contain a subnet prefix together with lifetime values indicating how long addresses created from the prefix remain preferred and valid. >> What happens if the value of the "autonomous address-configuration >>flag" changes over time? For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via stateful address autoconfiguration. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. >> I am not sure how the last sentence is consistent with the must in >>the first sentence. Change the must in the first sentence to a >>should? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 7 00:56:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23301 for ; Thu, 7 Oct 2004 00:56:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFQUV-0006Xv-Io for ipv6-web-archive@ietf.org; Thu, 07 Oct 2004 01:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFQIK-00082s-Be; Thu, 07 Oct 2004 00:54:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFQFD-0007T7-I1 for ipv6@megatron.ietf.org; Thu, 07 Oct 2004 00:51:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22830 for ; Thu, 7 Oct 2004 00:51:08 -0400 (EDT) Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFQOl-00060Y-L3 for ipv6@ietf.org; Thu, 07 Oct 2004 01:01:09 -0400 Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5700MBK6UGP6@mta2.huawei.com> for ipv6@ietf.org; Thu, 07 Oct 2004 12:51:53 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 82003)) with ESMTP id <0I5700N656UF1R@mta2.huawei.com> for ipv6@ietf.org; Thu, 07 Oct 2004 12:51:52 +0800 (CST) Received: from arvindsaproo ([10.18.4.94]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id I5771E00.S0D; Thu, 07 Oct 2004 12:56:02 +0800 Date: Thu, 07 Oct 2004 10:26:27 +0530 From: arvind saproo In-reply-to: <1612A4FBCAA7434FB246A491ECF20EC302882C@star.radlan.net> To: "'Nimrod Sterrn'" , aconta@txc.com Message-id: <000001c4ac2a$00d9bc90$5e04120a@in.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: RE: Query:IPv6 Over ATM PVC Operation 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7BIT Hi, Thanks for the reply. If the Source and Target Link Layer Address Options are not included in (IPv6 Over ATM PVC) IND message, then the message will straight-away be considered an invalid one as per the message validation checks specified in IND RFC (rfc 3122). A better option would be to zero fill the options though the options would be useless in that scenario (?) Alex, could you help on this issue since the authors of IPv6 Over ATM RFC (rfc 2492) are not reachable at the e-mail address specified in the RFC? Rgds, arvind -----Original Message----- From: Nimrod Sterrn [mailto:NimrodS@radlan.com] Sent: Monday, October 04, 2004 2:38 PM To: arvind saproo Cc: ipv6@ietf.org Subject: RE: Query:IPv6 Over ATM PVC Operation see my comments in ==> -----Original Message----- From: arvind saproo [mailto:arvindsaproo@huawei.com] Sent: Fri, October 01, 2004 3:44 PM To: ipv6@ietf.org Subject: Query:IPv6 Over ATM PVC Operation Hi, I have the following query regarding IPv6 Over ATM PVC operation (rfc2492). I would appreciate if someone could answer the same. Query - ===== RFC does not clearly mention what to fill as the Source/Target Link Layer address in the Source/Target Link Layer options of IND (Inverse ND) messages. Also, there is no mention of any reference document which covers the same. All that is said is [Section 3. PVC Environments] - "Since ATM PVC links do not use link-layer addresses, the link-layer address options SHOULD not be included in any ND message [11]. If a link-layer address option is present in an ND message, then the option SHOULD be ignored." ==> It may be confusing after reading RFC3122 (inverse ND) which requires it as part of the solicitation (src and dst LL address) and reply (target LL address). but since PVC in "permanent" its not needed (?!) Does this mean that we zero fill the Link Layer address in Source/Target Link Layer options of the IND messages? This information must be clearly mentioned to avoid interoperability issues. Thanks for your time, Rgds, arvind -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 7 10:14:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18713 for ; Thu, 7 Oct 2004 10:14:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZCT-0007WZ-Ep for ipv6-web-archive@ietf.org; Thu, 07 Oct 2004 10:24:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZ0Y-0007U6-T8; Thu, 07 Oct 2004 10:12:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYph-0001VI-Dx for ipv6@megatron.ietf.org; Thu, 07 Oct 2004 10:01:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17073 for ; Thu, 7 Oct 2004 10:01:23 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYzN-0006aA-PP for ipv6@ietf.org; Thu, 07 Oct 2004 10:11:28 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.4166916; Thu, 07 Oct 2004 09:59:39 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <213457E0-1869-11D9-9413-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Thu, 7 Oct 2004 09:59:39 -0400 To: Suresh Krishnan X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipv6@ietf.org Subject: Re: Privacy extensions to Stateless Address Autoconf 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="===============0590256001==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --===============0590256001== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-738778600; protocol="application/pkcs7-signature" --Apple-Mail-7-738778600 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I see two issues with making a change to the hash algorithm. First, changing the algorithm will not affect interoperability. The generation of the IID is local to each node. Second, we are attempting to move this document from PS to DS, so making a gratuitous change to the hash algorithm is not usually favored. In addition, will we change it again when a newer algorithm comes along? Perhaps an alternative, if people feel a need to move away from MD5, would be to not specify a single hash, but rather give a list of possible hashes. And an informative pointer to RFC 1750 would help with this direction. Other thoughts? Regards, Brian --Apple-Mail-7-738778600 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDA3MTM1OTM5WjAjBgkqhkiG9w0B CQQxFgQUqAVEAKg8CI22bONZmwWGWAUTONkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAIDD46TQq77ZMb3cpIokAf7So15Oduqwq7WpoV0jxdjqQOtvK/2d0/hJPAQ7oBTM6QVPB AZQv0A7+RDPpi3qEbjap9HxCS/H/9SmF4QJlNMPbd/bCDi7DVqUDk6UBQvn5sWul46mutxfisAE1 djl0wOiuEeYOjhiJQpEeGbZDzcm7gpYWnHi8GXOZNIpJkbWcqdrPk1/u67Z/fT+E3PUMAa7T/Si2 ozVg3TqlGuH4/OnALXOYefHSiBDZcx9akgnpRuTEDF8EXu5UEbHr9EL0L8h3SpUqWC4MmWI8h+s5 ALe/ETdVHLlWdZFYz222RSeAQ4+bIUvZPfRl9VITLXsPIwAAAAAAAA== --Apple-Mail-7-738778600-- --===============0590256001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0590256001==-- From ipv6-bounces@ietf.org Thu Oct 7 16:57:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26160 for ; Thu, 7 Oct 2004 16:57:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFfUC-0003dr-4K for ipv6-web-archive@ietf.org; Thu, 07 Oct 2004 17:07:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFeQb-0002sW-5Q; Thu, 07 Oct 2004 15:59:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFeC3-00040T-1b for ipv6@megatron.ietf.org; Thu, 07 Oct 2004 15:44:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16616 for ; Thu, 7 Oct 2004 15:44:48 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFeLn-0005TH-Bf for ipv6@ietf.org; Thu, 07 Oct 2004 15:54:56 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i97JiCa09372; Thu, 7 Oct 2004 21:44:12 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i97JiCSj031521; Thu, 7 Oct 2004 21:44:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410071944.i97JiCSj031521@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman In-reply-to: Your message of Thu, 07 Oct 2004 09:59:39 EDT. <213457E0-1869-11D9-9413-000D93330CAA@innovationslab.net> Date: Thu, 07 Oct 2004 21:44:12 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: Privacy extensions to Stateless Address Autoconf 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 In your previous mail you wrote: First, changing the algorithm will not affect interoperability. The generation of the IID is local to each node. => so the change should not be a problem if it is justified. Second, we are attempting to move this document from PS to DS, so making a gratuitous change to the hash algorithm is not usually favored. => the argument is that MD5 is/shall be not available by default. I suggest to give it to security area directors for an advice. In addition, will we change it again when a newer algorithm comes along? => your proposal is a nice answer. Perhaps an alternative, if people feel a need to move away from MD5, would be to not specify a single hash, but rather give a list of possible hashes. And an informative pointer to RFC 1750 would help with this direction. => this seems a wOnderful idea! Thanks Francis.Dupont@enst-bretagne.fr PS: draft-ietf-ipsec-esp-ah-algorithms-02.txt changes MD5 based algo requirement levels from MUST to MAY so the argument about MD5 seems to be right. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 7 20:49:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20417 for ; Thu, 7 Oct 2004 20:49:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFj6R-00022Z-5O for ipv6-web-archive@ietf.org; Thu, 07 Oct 2004 20:59:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFiuU-0000UA-0L; Thu, 07 Oct 2004 20:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFisr-0008Q5-5E for ipv6@megatron.ietf.org; Thu, 07 Oct 2004 20:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19967 for ; Thu, 7 Oct 2004 20:45:18 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFj2f-0001mo-3A for ipv6@ietf.org; Thu, 07 Oct 2004 20:55:29 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i980jFKm022160; Thu, 7 Oct 2004 19:45:16 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Oct 2004 19:43:11 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L007ZFT; Thu, 7 Oct 2004 20:44:36 -0400 Date: Thu, 7 Oct 2004 20:39:26 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Francis Dupont In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD3E7@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Suresh Krishnan , Brian Haberman , ipv6@ietf.org Subject: Re: Privacy extensions to Stateless Address Autoconf X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi Brian and Francis, Thanks for your comments. I have made some changes to the draft to address the issues you raised. Let me know if these changes are OK. * I have removed all references to MD5 in the document. * I have added a reference to draft-ietf-ipsec-esp-ah-algorithms-02 * I added the following paragraph about the hash algorithm "The randomized interface identifier generation algorithm assumes that the node is capable of running a hash algorithm which is capable of producing a 128 bit random value. The selected hash algorithm SHOULD follow the guidelines set forth in [RANDOM] to ensure randomness of the result. The node MAY use one of the hash algorithms specified in [IPSECALGO] as these algorithms will be available on every IPv6 compliant node" where [IPSECALGO] is draft-ietf-ipsec-esp-ah-algorithms-02 and [RANDOM] is RFC1750 Thanks Suresh On Thu, 7 Oct 2004, Francis Dupont wrote: > In your previous mail you wrote: > > First, changing the algorithm will not affect interoperability. The > generation of the IID is local to each node. > >=> so the change should not be a problem if it is justified. > > Second, we are attempting to move this document from PS to > DS, so making a gratuitous change to the hash algorithm is not > usually favored. > >=> the argument is that MD5 is/shall be not available by default. >I suggest to give it to security area directors for an advice. > > In addition, will we change it again when a newer algorithm comes along? > >=> your proposal is a nice answer. > > Perhaps an alternative, if people feel a need to move away from > MD5, would be to not specify a single hash, but rather give a list > of possible hashes. And an informative pointer to RFC 1750 > would help with this direction. > >=> this seems a wOnderful idea! > >Thanks > >Francis.Dupont@enst-bretagne.fr > >PS: draft-ietf-ipsec-esp-ah-algorithms-02.txt changes MD5 based algo >requirement levels from MUST to MAY so the argument about MD5 seems >to be right. > >-------------------------------------------------------------------- >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 Oct 8 01:44:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10258 for ; Fri, 8 Oct 2004 01:44:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFniM-0006fa-BJ for ipv6-web-archive@ietf.org; Fri, 08 Oct 2004 01:54:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnWM-0005jJ-EI; Fri, 08 Oct 2004 01:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnOK-0004Rh-5r for ipv6@megatron.ietf.org; Fri, 08 Oct 2004 01:34:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09706 for ; Fri, 8 Oct 2004 01:34:07 -0400 (EDT) Received: from out002pub.verizon.net ([206.46.170.141] helo=out002.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnYA-0006WL-S7 for ipv6@ietf.org; Fri, 08 Oct 2004 01:44:19 -0400 Received: from S018431 ([151.203.119.130]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20041008053405.KARC6722.out002.verizon.net@S018431> for ; Fri, 8 Oct 2004 00:34:05 -0500 From: "timothy enos" To: Date: Fri, 8 Oct 2004 01:35:13 -0400 Message-ID: <000001c4acf8$995f8f20$bcf0fea9@S018431> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [151.203.119.130] at Fri, 8 Oct 2004 00:34:01 -0500 X-Spam-Score: 1.5 (+) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Subject: RE: AH and flow label 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="===============0265749229==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 This is a multi-part message in MIME format. --===============0265749229== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C4ACD7.12551B10" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C4ACD7.12551B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning. Having been away from the list for a while, it's not clear to me what (if any) the consensus (and subsequent decision) is regarding inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a decision were reached, what were/are they? If so, I'd like to start a separate thread concerning how to best protect the IPv6 Flow Label. If not, I'd like to continue the thread until consensus and a decision are reached. There seems no reasonable question that protection of the IPv6 Flow Label is needed, in light of the fact that (according to RFC 3697, section 2) '... The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)'. Taken to their logical conclusions Theft-of-Service attacks can become de facto DoS attacks. Given the ability to filter and subsequently route/forward based upon Flow Label values (much as has been/is done with DSCP/TOS values) it seems worthwhile to be able to include the IPv6 Flow Label within the cryptographic functions of the AH ICV. I'm also not certain that a contention in RFC 3697 (section 5.2, regarding IPsec tunneling) is correct: '. modification of the Flow Label by a network node has no effect on IPsec end-to-end security, because it cannot cause any IPsec integrity check to fail.' Presuming one of the intermediate nodes has a policy that drops all traffic with IPv6 Flow Label value 'x', to mark such tunnel traffic (talking about the Flow Label of the outer IPv6 header here) with value 'x' would be to mark it (thus all that is encapsulated within it) for death. Stealing of the Flow Label value being assigned to the legitimate tunnel traffic could also seemingly lead to a denial of service if there is also a bandwidth limitation applied to that type of traffic (e.g. LLQ). In either case, it would appear that the IPsec integrity check would in fact fail due to the modification of the Flow Label (ICV can't be checked if the traffic cannot get to the destination in the first place). Again, from RFC 3697: '. since the treatment of IP headers by nodes is typically unverified, there is no guarantee that flow labels sent by a node are set according to the recommendations in this document. Therefore, any assumptions made by the network about header fields such as flow labels should be limited to the extent that the upstream nodes are explicitly trusted.' I'm not sure a lot of explicit trust is warranted. Whether by the AH ICV, a Hop-by-Hop option, or another mechanism, the IPv6 Flow Label needs to be protected. Any feedback would be most sincerely appreciated. Best regards, Tim Enos 1Sam16:7 ------=_NextPart_000_0001_01C4ACD7.12551B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: AH and flow label

Good morning. Having been away from the list for a while, it's not = clear to me what (if = any) = the consensus (and subsequent decision) = is regarding inclusion of the IPv6 Flow Label field in the AH ICV. If = consensus and a decision were reached, what were/are they? If so, I'd = like to start a separate thread concerning how to best protect the IPv6 = Flow Label. If not, I'd like to continue the thread until consensus and = a decision are reached.

There seems no reasonable question that protection of = the IPv6 Flow Label is needed, in light of the fact that (according to = RFC 3697, section 2) '... The Flow Label value set by the source MUST be = delivered unchanged to the destination node(s)'.

Taken to their logical = conclusions Theft-of-Service attacks can become de facto DoS = attacks. Given the ability to filter and subsequently = route/forward based upon Flow Label values (much as has been/is done = with DSCP/TOS values) it seems worthwhile to = be able to include the IPv6 Flow Label within the cryptographic = functions of the AH ICV. I'm also not certain that a contention in RFC = 3697 (section 5.2, regarding IPsec = tunneling) is correct: = '… modification of the Flow = Label by a network node has no effect on IPsec end-to-end security, because it cannot cause any IPsec = integrity check to fail.' Presuming one of the = intermediate nodes has a policy that = drops = all traffic with IPv6 Flow Label value 'x', to mark such tunnel = traffic = (talking about the Flow Label of the = outer IPv6 header here) with value = 'x' would be to mark = it (thus all that is encapsulated within = it) for death. Stealing of the Flow Label value = being = assigned to the = legitimate tunnel = traffic could also seemingly lead to a denial of service if there is = also a bandwidth limitation applied to that type of traffic (e.g. = LLQ). = In either case, it would appear that the = IPsec integrity check would in fact fail due to the modification of the = Flow Label (ICV can't be checked if the traffic cannot get to the destination in the first = place). =

Again, from RFC 3697: '… since the treatment of = IP headers by nodes is typically unverified, there is no guarantee that = flow labels sent by a node are set according to the = recommendations in this document. = Therefore, any assumptions made by the network about header fields such = as flow labels should be limited to the extent that the upstream nodes = are explicitly trusted.' I'm not sure a lot of = explicit trust is warranted. Whether = by the AH ICV, a Hop-by-Hop option, or another mechanism, = the IPv6 Flow Label needs to be = protected.

Any = feedback would be most sincerely appreciated.

Best regards,

Tim = Enos

1Sam16:7

------=_NextPart_000_0001_01C4ACD7.12551B10-- --===============0265749229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0265749229==-- From ipv6-bounces@ietf.org Fri Oct 8 09:48:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23930 for ; Fri, 8 Oct 2004 09:48:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvGd-0006rw-0u for ipv6-web-archive@ietf.org; Fri, 08 Oct 2004 09:58:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFv2r-0003Re-1R; Fri, 08 Oct 2004 09:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFv09-0002iT-9C for ipv6@megatron.ietf.org; Fri, 08 Oct 2004 09:41:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23571 for ; Fri, 8 Oct 2004 09:41:40 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvA4-0006lu-Hk for ipv6@ietf.org; Fri, 08 Oct 2004 09:51:56 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.4205712; Fri, 08 Oct 2004 09:40:36 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Brian Haberman Date: Fri, 8 Oct 2004 09:40:35 -0400 To: Suresh Krishnan X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ipv6@ietf.org, Francis Dupont Subject: Re: Privacy extensions to Stateless Address Autoconf 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="===============0506217414==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 --===============0506217414== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-824034772; protocol="application/pkcs7-signature" --Apple-Mail-2-824034772 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Suresh, On Oct 7, 2004, at 20:39, Suresh Krishnan wrote: > Hi Brian and Francis, > Thanks for your comments. I have made some changes to the draft to > address the issues you raised. Let me know if these changes are OK. > > * I have removed all references to MD5 in the document. I don't think you want to remove all references to MD5. The document just doesn't need to mandate that MD5 be the only hash algorithm. > * I have added a reference to draft-ietf-ipsec-esp-ah-algorithms-02 I don't think we want to do that. This document is supposed to be going from PS to DS. Adding a reference to an I-D will delay publication until all references are RFC's. And if the above draft is Normative, it has to be at the same (DS) level. > * I added the following paragraph about the hash algorithm > > "The randomized interface identifier generation algorithm assumes > that > the node is capable of running a hash algorithm which is capable of > producing a 128 bit random value. The selected hash algorithm > SHOULD > follow the guidelines set forth in [RANDOM] to ensure randomness of > the result. The node MAY use one of the hash algorithms specified > in > [IPSECALGO] as these algorithms will be available on every IPv6 > compliant node" > See my comment above about Normative references and my initial recommendation to make a reference to 1750 Informative. Regards, Brian --Apple-Mail-2-824034772 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDA4MTM0MDM1WjAjBgkqhkiG9w0B CQQxFgQUZjIn6v5MjHN0oSLr1yxqEtgVj8oweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAWdJ61crtXu+jKKYNSp4JhpTZw9aGmjm82el3laCHnMeW+S5k3II6niRMmxlWf5Z0pawc f7n5rjUfxYE8msrA6dQHkcTPRKK8EMf5VTxR94oV9HjE4OzGWojEGcjP8fOhRiUdoNOwHBdCiPdV 8Mh30JuNkza0lGLvg4i6lXrr4eE/P9PZXIhAxP6fIdmujt95SFQ44GW6GKC5UtijYhAUGHMcXOxQ NHmQKeHYT1GBapABuuN7acDqx0QUEE84KTFPd4wI2Cm1MUSv5fPBbU5F9NbumIUvnQ38iMsCd+jZ 08dw6OH8Zmvfiqwqi5qiXW5sqWOrZYfzJgJgAxslOlKifQAAAAAAAA== --Apple-Mail-2-824034772-- --===============0506217414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0506217414==-- From ipv6-bounces@ietf.org Fri Oct 8 10:02:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24843 for ; Fri, 8 Oct 2004 10:02:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvTl-00078G-Ny for ipv6-web-archive@ietf.org; Fri, 08 Oct 2004 10:12:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvBa-00051y-AP; Fri, 08 Oct 2004 09:53:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFv5s-0003sd-78 for ipv6@megatron.ietf.org; Fri, 08 Oct 2004 09:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23908 for ; Fri, 8 Oct 2004 09:47:34 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvFm-0006qj-65 for ipv6@ietf.org; Fri, 08 Oct 2004 09:57:51 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i98DktR10952; Fri, 8 Oct 2004 15:46:55 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i98DktSj035175; Fri, 8 Oct 2004 15:46:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410081346.i98DktSj035175@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Suresh Krishnan In-reply-to: Your message of Thu, 07 Oct 2004 20:39:26 EDT. Date: Fri, 08 Oct 2004 15:46:55 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Brian Haberman , ipv6@ietf.org Subject: Re: Privacy extensions to Stateless Address Autoconf 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 In your previous mail you wrote: the result. The node MAY use one of the hash algorithms specified in [IPSECALGO] as these algorithms will be available on every IPv6 => s/specified/required/ ? Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 8 10:22:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28046 for ; Fri, 8 Oct 2004 10:22:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvnw-0007n5-UB for ipv6-web-archive@ietf.org; Fri, 08 Oct 2004 10:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvOe-0001rA-FC; Fri, 08 Oct 2004 10:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvH8-0005xt-Qh for ipv6@megatron.ietf.org; Fri, 08 Oct 2004 09:59:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24565 for ; Fri, 8 Oct 2004 09:59:13 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvR3-00073z-ML for ipv6@ietf.org; Fri, 08 Oct 2004 10:09:31 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i98DwQR12080; Fri, 8 Oct 2004 15:58:26 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i98DwQSj035297; Fri, 8 Oct 2004 15:58:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410081358.i98DwQSj035297@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "timothy enos" In-reply-to: Your message of Fri, 08 Oct 2004 01:35:13 EDT. <000001c4acf8$995f8f20$bcf0fea9@S018431> Date: Fri, 08 Oct 2004 15:58:26 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: AH and flow label 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 In your previous mail you wrote: Good morning. Having been away from the list for a while, it's not clear to me what (if any) the consensus (and subsequent decision) is regarding inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a decision were reached, what were/are they? => a consensus was reached and its result announced by Stephen Kent (1- keep compatibility, 2- fix the rationale). Cf draft-ietf-ipsec-rfc2402bis-08.txt: (*) The flow label described in AHv1 was mutable, and in RFC 2460 [DH98] was potentially mutable. To retain compatibility with existing AH implementations, the flow label is not included in the ICV in AHv2. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 8 14:04:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16552 for ; Fri, 8 Oct 2004 14:04:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzGC-0004bN-As for ipv6-web-archive@ietf.org; Fri, 08 Oct 2004 14:14:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFz3A-0004NO-Pn; Fri, 08 Oct 2004 14:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFyvN-0002UE-Rp for ipv6@megatron.ietf.org; Fri, 08 Oct 2004 13:53:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15608 for ; Fri, 8 Oct 2004 13:53:02 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFz5C-0004L4-9s for ipv6@ietf.org; Fri, 08 Oct 2004 14:03:21 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA06991; Fri, 8 Oct 2004 10:52:19 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i98HqID21123; Fri, 8 Oct 2004 10:52:18 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Oct 2004 13:51:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Oct 2004 13:51:54 -0400 Message-ID: Thread-Topic: AH and flow label Thread-Index: AcSs+ftIzJ/N4VvvQIaO6UwzKs+2lwAY+Pjg From: "Manfredi, Albert E" To: "timothy enos" , X-OriginalArrivalTime: 08 Oct 2004 17:51:54.0973 (UTC) FILETIME=[7FBBD0D0:01C4AD5F] X-Spam-Score: 1.6 (+) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Subject: RE: AH and flow label 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="===============0056745226==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 This is a multi-part message in MIME format. --===============0056745226== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AD5F.7F837F4C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AD5F.7F837F4C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe I had the last word on this thread until today. =20 The original version of AH, RFC 2402, has the Flow Spec value as being = mutable. =20 RFC 2460, IPv6 spec, has the Flow Spec value potentially mutable. =20 Diffserv, RFC 2475, has the DS codepoint as being potentially mutable. =20 Seems to me that even RFC 3697 allows for the Flow Spec to be changed in = transit, as long as it's returned to its original state before arriving = at the destination. =20 I had suggested that the Flow Spec not be included in AH bis, and to use = the above older references as reason. That is to say, existing AH = algorithms could break if this was changed. In addition, I had also = suggested that perhaps the best way to protect a flow where the Flow = Spec value really matters is to use ESP and send the critical traffic = through a tunnel. =20 Bert =20 =20 -----Original Message----- From: timothy enos [mailto:timbeck04@verizon.net] Sent: Friday, October 08, 2004 12:35 AM To: ipv6@ietf.org Subject: RE: AH and flow label Good morning. Having been away from the list for a while, it's not clear = to me what (if any) the consensus (and subsequent decision) is regarding = inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a = decision were reached, what were/are they? If so, I'd like to start a = separate thread concerning how to best protect the IPv6 Flow Label. If = not, I'd like to continue the thread until consensus and a decision are = reached.=20 There seems no reasonable question that protection of the IPv6 Flow = Label is needed, in light of the fact that (according to RFC 3697, = section 2) '... The Flow Label value set by the source MUST be delivered = unchanged to the destination node(s)'.=20 Taken to their logical conclusions Theft-of-Service attacks can become = de facto DoS attacks. Given the ability to filter and subsequently = route/forward based upon Flow Label values (much as has been/is done = with DSCP/TOS values) it seems worthwhile to be able to include the IPv6 = Flow Label within the cryptographic functions of the AH ICV. I'm also = not certain that a contention in RFC 3697 (section 5.2, regarding IPsec = tunneling) is correct: '... modification of the Flow Label by a network = node has no effect on IPsec end-to-end security, because it cannot cause = any IPsec integrity check to fail.' Presuming one of the intermediate = nodes has a policy that drops all traffic with IPv6 Flow Label value = 'x', to mark such tunnel traffic (talking about the Flow Label of the = outer IPv6 header here) with value 'x' would be to mark it (thus all = that is encapsulated within it) for death. Stealing of the Flow Label = value being assigned to the legitimate tunnel traffic could also = seemingly lead to a denial of service if there is also a bandwidth = limitation applied to that type of traffic (e.g. LLQ). In either case, = it would appear that the IPsec integrity check would in fact fail due to = the modification of the Flow Label (ICV can't be checked if the traffic = cannot get to the destination in the first place).=20 Again, from RFC 3697: '... since the treatment of IP headers by nodes is = typically unverified, there is no guarantee that flow labels sent by a = node are set according to the recommendations in this document. = Therefore, any assumptions made by the network about header fields such = as flow labels should be limited to the extent that the upstream nodes = are explicitly trusted.' I'm not sure a lot of explicit trust is = warranted. Whether by the AH ICV, a Hop-by-Hop option, or another = mechanism, the IPv6 Flow Label needs to be protected.=20 Any feedback would be most sincerely appreciated. Best regards, Tim Enos 1Sam16:7 ------_=_NextPart_001_01C4AD5F.7F837F4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AH and flow label
I believe I = had the last=20 word on this thread until today.
 
The original = version of=20 AH, RFC 2402, has the Flow Spec value as being = mutable.
 
RFC 2460, = IPv6=20 spec, has the Flow Spec value potentially = mutable.
 
Diffserv, = RFC 2475, has=20 the DS codepoint as being potentially mutable.
 
Seems to me = that even=20 RFC 3697 allows for the Flow Spec to be changed in transit, as long as = it's=20 returned to its original state before arriving at the=20 destination.
 
I had = suggested that the=20 Flow Spec not be included in AH bis, and to use the above older = references as=20 reason. That is to say, existing AH algorithms could break if this was = changed.=20 In addition, I had also suggested that perhaps the best way to protect a = flow=20 where the Flow Spec value really matters is to use ESP and send the = critical=20 traffic through a tunnel.
 
Bert
 
 
-----Original Message-----
From: timothy enos=20 [mailto:timbeck04@verizon.net]
Sent: Friday, October 08, = 2004 12:35=20 AM
To: ipv6@ietf.org
Subject: RE: AH and flow=20 label

Good=20 morning. = Having been away from the list for a while, = it's not clear=20 to me what = (if any) the consensus (and = subsequent decision)=20 is regarding inclusion of the IPv6 Flow Label field in the AH ICV. If=20 consensus and a decision were reached, what were/are they? If so, I'd = like to=20 start a separate thread concerning how to best protect the IPv6 Flow = Label. If=20 not, I'd like to continue the thread until consensus and a decision = are=20 reached.=20

There = seems no=20 reasonable question that protection of the IPv6 Flow Label is needed, = in light=20 of the fact that (according to RFC 3697, section 2) '... The Flow = Label value=20 set by the source MUST be delivered unchanged to the destination=20 node(s)'.=20

Taken to their logical conclusions Theft-of-Service = attacks can=20 become de facto DoS attacks. Given the=20 ability to filter and subsequently route/forward based upon Flow Label = values=20 (much as has been/is done with DSCP/TOS values) = it seems=20 worthwhile to be able to include the IPv6 Flow Label within the = cryptographic=20 functions of the AH ICV. I'm also not certain that a contention in RFC = 3697=20 (section 5.2, regarding IPsec tunneling) = is correct:=20 '…=20 modification of the Flow Label by a = network node has=20 no effect on IPsec=20 end-to-end security, because it cannot = cause any=20 IPsec integrity check to fail.' Presuming one of the=20 intermediate nodes has a policy that = drops all traffic with IPv6 Flow Label value = 'x', to mark such tunnel = traffic (talking about=20 the Flow Label of the outer IPv6 header here) with value=20 'x' would be to mark = it (thus all that=20 is encapsulated within it) for death. Stealing of the = Flow Label=20 value being = assigned to the=20 legitimate tunnel traffic could also seemingly=20 lead to a denial of service if there is also a bandwidth limitation = applied to=20 that type of traffic (e.g. LLQ). In either case, it would = appear that the=20 IPsec integrity check would in fact fail due to the modification of = the Flow=20 Label (ICV can't be checked if the traffic cannot get to=20 the destination in the first place).

Again, from RFC 3697:=20 '… since the treatment of IP headers by nodes is = typically=20 unverified, there is no guarantee that flow labels sent by a node are = set=20 according to the recommendations in this document. = Therefore, any=20 assumptions made by the network about header fields such as flow = labels should=20 be limited to the extent that the upstream nodes are explicitly=20 trusted.' = I'm not sure a lot of explicit trust = is warranted.=20 Whether by the AH ICV, a Hop-by-Hop option, or another = mechanism,=20 the IPv6 Flow Label needs to be protected.

Any = feedback would be=20 most sincerely appreciated.

Best=20 regards,

Tim=20 Enos

1Sam16:7

------_=_NextPart_001_01C4AD5F.7F837F4C-- --===============0056745226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0056745226==-- From ipv6-bounces@ietf.org Fri Oct 8 17:54:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21265 for ; Fri, 8 Oct 2004 17:54:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2ql-0005vy-Em for ipv6-web-archive@ietf.org; Fri, 08 Oct 2004 18:04:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2ZN-0007xE-8K; Fri, 08 Oct 2004 17:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2UM-0005G8-F7 for ipv6@megatron.ietf.org; Fri, 08 Oct 2004 17:41:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20198 for ; Fri, 8 Oct 2004 17:41:19 -0400 (EDT) Received: from web80505.mail.yahoo.com ([66.218.79.75]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CG2eK-0005aT-Et for ipv6@ietf.org; Fri, 08 Oct 2004 17:51:41 -0400 Message-ID: <20041008214049.3841.qmail@web80505.mail.yahoo.com> Received: from [63.197.18.101] by web80505.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 14:40:49 PDT Date: Fri, 8 Oct 2004 14:40:49 -0700 (PDT) From: Fred Templin To: ipv6@ietf.org, v6ops@ops.ietf.org, rbridge@postel.org, pmtud@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.4 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: Re: IPvLX 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="===============1396784411==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 --===============1396784411== Content-Type: multipart/alternative; boundary="0-1980266083-1097271649=:1569" --0-1980266083-1097271649=:1569 Content-Type: text/plain; charset=us-ascii Hello, On August 23, 2004 I announced to this distribution a -00 document entitled: "IPvLX: IPv6 Addressing in the IPv4 Internet" Since that time, a -01 revision of the base document has obsoleted the -00 version, and a new document entitled: "IPvLX Errata" that specifies patches to be applied against the base document has been submitted to internet-drafts@ietf.org. The documents are currently available at the following URLs (the latter of the two should soon be appearing in the I-D repository): http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt http://www.geocities.com/osprey67/ipvlx/ipvlx_errata-00.txt Sincerely, Fred L. Templin osprey67@yahoo.com --0-1980266083-1097271649=:1569 Content-Type: text/html; charset=us-ascii
Hello,
 
On August 23, 2004 I announced to this distribution a -00 document entitled:
 
  "IPvLX: IPv6 Addressing in the IPv4 Internet"
 
Since that time, a -01 revision of the base document has obsoleted the
-00 version, and a new document entitled: "IPvLX Errata" that specifies
patches to be applied against the base document has been submitted
 
The documents are currently available at the following URLs (the latter
of the two should soon be appearing in the I-D repository):
 
 
Sincerely,
 
Fred L. Templin
--0-1980266083-1097271649=:1569-- --===============1396784411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1396784411==-- From ipv6-bounces@ietf.org Sat Oct 9 09:10:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12127 for ; Sat, 9 Oct 2004 09:10:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGH9l-00063l-FB for ipv6-web-archive@ietf.org; Sat, 09 Oct 2004 09:21:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGGxN-00037a-PP; Sat, 09 Oct 2004 09:08:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGGvP-0002h5-Co for ipv6@megatron.ietf.org; Sat, 09 Oct 2004 09:06:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11824 for ; Sat, 9 Oct 2004 09:06:13 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGH5V-0005wa-5b for ipv6@ietf.org; Sat, 09 Oct 2004 09:16:42 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i99D5fFW073530; Sat, 9 Oct 2004 13:05:41 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i99D5eN9172528; Sat, 9 Oct 2004 15:05:40 +0200 Received: from zurich.ibm.com (sig-9-146-217-195.de.ibm.com [9.146.217.195]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA87198; Sat, 9 Oct 2004 15:05:39 +0200 Message-ID: <4167E222.903@zurich.ibm.com> Date: Sat, 09 Oct 2004 15:05:38 +0200 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: timothy enos References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: AH and flow label 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Bert and Francis are correct that there is no plan to change AH for this. > Seems to me that even RFC 3697 allows for the Flow Spec to be > changed in transit, as long as it's returned to its original > state before arriving at the destination. The authors of 3697 were fairly careful about that, since we know that some people have use cases in mind for the flow label where it would be twiddled en route. But the basic model is that it is an e2e field. Brian Manfredi, Albert E wrote: > I believe I had the last word on this thread until today. > > The original version of AH, RFC 2402, has the Flow Spec value as being mutable. > > RFC 2460, IPv6 spec, has the Flow Spec value potentially mutable. > > Diffserv, RFC 2475, has the DS codepoint as being potentially mutable. > > Seems to me that even RFC 3697 allows for the Flow Spec to be changed in transit, as long as it's returned to its original state before arriving at the destination. > > I had suggested that the Flow Spec not be included in AH bis, and to use the above older references as reason. That is to say, existing AH algorithms could break if this was changed. In addition, I had also suggested that perhaps the best way to protect a flow where the Flow Spec value really matters is to use ESP and send the critical traffic through a tunnel. > > Bert > > > > -----Original Message----- > From: timothy enos [mailto:timbeck04@verizon.net] > Sent: Friday, October 08, 2004 12:35 AM > To: ipv6@ietf.org > Subject: RE: AH and flow label > > > > Good morning. Having been away from the list for a while, it's not clear to me what (if any) the consensus (and subsequent decision) is regarding inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a decision were reached, what were/are they? If so, I'd like to start a separate thread concerning how to best protect the IPv6 Flow Label. If not, I'd like to continue the thread until consensus and a decision are reached. > > There seems no reasonable question that protection of the IPv6 Flow Label is needed, in light of the fact that (according to RFC 3697, section 2) '... The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)'. > > Taken to their logical conclusions Theft-of-Service attacks can become de facto DoS attacks. Given the ability to filter and subsequently route/forward based upon Flow Label values (much as has been/is done with DSCP/TOS values) it seems worthwhile to be able to include the IPv6 Flow Label within the cryptographic functions of the AH ICV. I'm also not certain that a contention in RFC 3697 (section 5.2, regarding IPsec tunneling) is correct: '... modification of the Flow Label by a network node has no effect on IPsec end-to-end security, because it cannot cause any IPsec integrity check to fail.' Presuming one of the intermediate nodes has a policy that drops all traffic with IPv6 Flow Label value 'x', to mark such tunnel traffic (talking about the Flow Label of the outer IPv6 header here) with value 'x' would be to mark it (thus all that is encapsulated within it) for death. Stealing of the Flow Label value being assigned to the legitimate tunnel traffic could also seeming ly lead to a denial of service if there is also a bandwidth limitation applied to that type of traffic (e.g. LLQ). In either case, it would appear that the IPsec integrity check would in fact fail due to the modification of the Flow Label (ICV can't be checked if the traffic cannot get to the destination in the first place). > > Again, from RFC 3697: '... since the treatment of IP headers by nodes is typically unverified, there is no guarantee that flow labels sent by a node are set according to the recommendations in this document. Therefore, any assumptions made by the network about header fields such as flow labels should be limited to the extent that the upstream nodes are explicitly trusted.' I'm not sure a lot of explicit trust is warranted. Whether by the AH ICV, a Hop-by-Hop option, or another mechanism, the IPv6 Flow Label needs to be protected. > > Any feedback would be most sincerely appreciated. > > Best regards, > > Tim Enos > > 1Sam16:7 > > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > 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 Oct 10 00:06:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27157 for ; Sun, 10 Oct 2004 00:06:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGV93-0003KH-R9 for ipv6-web-archive@ietf.org; Sun, 10 Oct 2004 00:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGUuH-00044I-5w; Sun, 10 Oct 2004 00:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGUtN-0003tO-Ur for ipv6@megatron.ietf.org; Sun, 10 Oct 2004 00:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26940 for ; Sun, 10 Oct 2004 00:01:03 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGV3d-0003F5-FL for ipv6@ietf.org; Sun, 10 Oct 2004 00:11:42 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 0972E66D for ; Sun, 10 Oct 2004 00:00:30 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 10 Oct 2004 00:00:30 -0400 Message-Id: <20041010040030.0972E66D@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.65% | 3 | 20.66% | 28566 | humphrey.gu@nfs.com.cn 17.65% | 3 | 8.34% | 11530 | francis.dupont@enst-bretagne.fr 11.76% | 2 | 12.16% | 16816 | brian@innovationslab.net 5.88% | 1 | 14.09% | 19483 | albert.e.manfredi@boeing.com 5.88% | 1 | 11.13% | 15384 | timbeck04@verizon.net 5.88% | 1 | 9.63% | 13314 | margaret@thingmagic.com 5.88% | 1 | 5.78% | 7994 | brc@zurich.ibm.com 5.88% | 1 | 4.46% | 6160 | join@uni-muenster.de 5.88% | 1 | 4.03% | 5570 | suresh.krishnan@ericsson.ca 5.88% | 1 | 3.97% | 5491 | arvindsaproo@huawei.com 5.88% | 1 | 2.89% | 3991 | nimrods@radlan.com 5.88% | 1 | 2.86% | 3951 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 17 |100.00% | 138250 | 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 Oct 10 13:51:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27618 for ; Sun, 10 Oct 2004 13:51:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGi17-0003hH-QY for ipv6-web-archive@ietf.org; Sun, 10 Oct 2004 14:01:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGhnb-0002B7-VF; Sun, 10 Oct 2004 13:47:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGhhv-00012L-3o for ipv6@megatron.ietf.org; Sun, 10 Oct 2004 13:42:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26894 for ; Sun, 10 Oct 2004 13:42:05 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGhsH-0003Ud-MH for ipv6@ietf.org; Sun, 10 Oct 2004 13:52:50 -0400 Received: from [69.173.190.121] (account margaret HELO [192.168.1.103]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 170786 for ipv6@ietf.org; Sun, 10 Oct 2004 13:37:01 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Sun, 10 Oct 2004 13:40:31 -0400 To: ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: AD Review comments on draft-ietf-ipv6-link-scoped-mcast-05.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Hi All, Just FYI -- I sent the attached AD review comments to the WG chairs and the authors of draft-ietf-ipv6-link-scoped-mcast-05.txt on October 3rd. I usually try to copy the WG on substantive AD review comments, and I am not sure why I failed to do so in this case. Anyway, you can read my comments below. This document has been placed in "AD Review -- Revised ID Needed State" and I am waiting for these issues to be resolved before sending the document to IETF Last Call. Your comments are welcome! Margaret --- I have completed my AD review of draft-ietf-ipv6-link-scoped-mcast-05.txt, and I have several comments on this draft. As some of these comments are substantive, I would like the draft to be updated to address these concerns before we send it to IETF Last Call. Let me start with a couple of general comments: (1) There are several places in this document where it says that these link-scoped multicast addresses will be assigned "at the same time" as link-local addresses are auto-configured. I don't see any reason for this restriction, and I believe that these addresses could safely be configured at any time after DAD is completed. (2) The document says: The lifetime of link scoped multicast addresses has no dependency on the Valid Lifetime field in the Prefix Information option, corresponding to the unicast address being used, contained in the Router Advertisement message [RFC 2461]. This makes sense to me, but I think it misses the point... Since these addresses are created from the unique IID, their useful lifetime is linked to the period during which the IID is known to be unique. Right? So, the document needs to discuss what happens to these addresses if there is a later IID conflict, due to a new node joining the network that uses the same IID. I also have some specific comments on the text (marked with '>>'): Abstract This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-IDs to allocate multicast addresses. When a link- >> I would refer to Interface Idenfitiers (IIDs) the first time and later use the IID acronym for consistency with other IPv6 documents. Consequently, this technique MUST be used for link scoped multicast >> MUST only be used for link scoped multicast? (s/MUST/MUST only) ?? addresses. If you want to use multicast addresses greater than link-local scope, you need other methods such as [RFC 3306]. That is, flgs, scop, and LSM fields are used to identify whether an address is a multicast address as specified in this document and to be processed any further. >> What type of further processing is done on these addresses? I wouldn't think that, after they are generated, these addresses would be handled any differently than other link scoped multicast addresses... Interface ID field is used to distinguish each node from others. And this value is obtained from the IEEE EUI-64 based interface identifier of the link-local unicast IPv6 address. Given the use of this method for link-local scope, the interface ID embedded in the multicast address SHOULD come from the interface ID of the link-local unicast address on the interface after DAD has completed. That is, the creation of the multicast address MUST occur after DAD has completed as part of the auto-config process. >> This paragraph conflicts with itself. It is not clear whether the link scoped address SHOULD only be configured after DAD has completed or MUST only be configured after DAD has completed. I think you mean MUST... 6. Security Considerations [RFC 3041] describes the privacy extension to IPv6 stateless address autoconfiguration for an interface ID. The interface ID, generated by [RFC 3041], is also used in this method since the uniqueness is verified by DAD procedure as part of the secure auto- config process. >> You should probably indicate whether link scoped multicast addresses can be configured using IIDs generated for privacy addresses or not. Informative [RFC 2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. >> I think that you need a normative reference to this and to IPv6 Auto Configuration. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 11 08:27:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00854 for ; Mon, 11 Oct 2004 08:27:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGzRc-0006qB-Qt for ipv6-web-archive@ietf.org; Mon, 11 Oct 2004 08:38:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzF7-0008H6-05; Mon, 11 Oct 2004 08:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzE8-000828-P9 for ipv6@megatron.ietf.org; Mon, 11 Oct 2004 08:24:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00553 for ; Mon, 11 Oct 2004 08:24:31 -0400 (EDT) Received: from web60204.mail.yahoo.com ([216.109.118.99]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CGzOf-0006mN-DK for ipv6@ietf.org; Mon, 11 Oct 2004 08:35:26 -0400 Message-ID: <20041011122355.42187.qmail@web60204.mail.yahoo.com> Received: from [192.116.98.51] by web60204.mail.yahoo.com via HTTP; Mon, 11 Oct 2004 13:23:55 BST Date: Mon, 11 Oct 2004 13:23:55 +0100 (BST) From: Doo Timbir To: members@ipv6forum.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.4 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org, meav6tf@ipv6net.tn Subject: AFRICAST 2004 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 X-Spam-Score: 1.4 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 8bit One of the biggest events on the African continent that showcases the best in its broadcast wherewithal[technology] will take place in Abuja,Nigeria from Tuesday 26th of October to Thursday 28th of October 2004. The theme of this year's conference is "Broadcast Technology and Democracy in Africa". The venue is SHERATON HOTELS & TOWERS,a stone throw from the magnificent Shehu Musa Yar'adua Centre in the heart of Abuja,F.C.T. More information can be obtained from /www.nbc-nig.org/.The official website of National Broadcasting Commission.Or betterstil,the nearest Nigerian Embassy/Consulate. Sincerely, Doo Timbir. ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 11 12:49:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21120 for ; Mon, 11 Oct 2004 12:49:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3Ww-00037G-1m for ipv6-web-archive@ietf.org; Mon, 11 Oct 2004 13:00:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3JJ-0001Vg-FO; Mon, 11 Oct 2004 12:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3It-0001LO-1u for ipv6@megatron.ietf.org; Mon, 11 Oct 2004 12:45:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20916 for ; Mon, 11 Oct 2004 12:45:40 -0400 (EDT) From: shawn.routhier@windriver.com Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3TR-000331-Vg for ipv6@ietf.org; Mon, 11 Oct 2004 12:56:38 -0400 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA29601; Mon, 11 Oct 2004 09:44:51 -0700 (PDT) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id <44XH9RJR>; Mon, 11 Oct 2004 09:44:52 -0700 Message-ID: <47DD7107796EF94CBE7873B8F31DF2C30567723F@ala-mail01.wrs.com> To: Sanjaya.Choudhury@marconi.com, ipv6@ietf.org Date: Mon, 11 Oct 2004 09:44:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: RE: Question on draft-ietf-ipv6-rfc2011-update-10.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c As the editor it was not my intention that the ipv4 and ipv6 interface tables would be fully populated with all interfaces only those on which the ipv4 or ipv6 protocols had been administratevly attached. This may turn out to be all capable interfaces in some systems. ** As to the difference you mention at the end of your message. If I understood correctly to which statement you refer it discusses the difference between the interface tables from previous IPv6 mib and this mib. In the previous mib the ipv6ifTable attempted to replace (at least for IPv6) the ifTable. In the current mib the interface tables are additional information to the ifTable. ** If I were writing the code to handle the if and ip mibs I'd consider simply adding some new fields to the if structure to include the IP information. Obviously this may not be possible in some situations and then other implementation styles would need to be used. regards, Shawn A. Routhier > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Choudhury, Sanjaya > Sent: Friday, September 17, 2004 12:36 PM > To: IPv6 > Subject: RE: Question on draft-ietf-ipv6-rfc2011-update-10.txt > > > > -----Original Message----- > > From: C. M. Heard [mailto:heard@pobox.com] > > Sent: Wednesday, September 15, 2004 1:16 PM > > To: Choudhury, Sanjaya > > Cc: IPv6 > > Subject: Re: Question on draft-ietf-ipv6-rfc2011-update-10.txt > > > > In other words, why not include IPv4 and IPv6 layers in the > > ifStackTable, and allow them to be dynamically manipulated. > > > > Partly, the reason is historical. When the MIB-II was first > > > > It is true that historically, IPv4 and IPv6 layers has not > been included in the ifStackTable, now the question is should > they be? > As we know, the "interface stacking" concept has been as very > flexible and useful tool to effectively manage system > interfaces. I can think of the following reasons for such a change: > > [Note:Infact RFC2465 kind of introduced this concept for IPv6.] > > 1. Scalability Issue: > --------------------- > With the introduction of the logical/virtual interfaces, a > single system can host thousands of "IP capable" interfaces. > As per the RFC2011-update, all of these show up in the > ipv4InterfaceTable, even if user never intends to configure > IP over them!! A snmp-walk by a NMS of this table can be very > expensive and difficult to use. > > By using a unique index in the ipv4InterfaceTable, user has > explicit control over the interface over which he can enable > IP. This will make the ip4InterfaceTable more scalable and > usable (fewer entries). > > 2. System Resources Issue: > ------------------------- > Depending on implementation, supporting thousands of "unused" > entries in the ipv4InterfaceTable can consume system resources. > > 3. User control > --------------- > There may be cases, where IP can be configured at multiple > lower layer interfaces (IP on ppp-over-rfc1483-over-ATM vs > IP over rfc1483-over-ATM). > User based on his deployment scenarios may choose one of > these interfaces to configure IP on. > > [After all, the interface stacking concept has allowed NMS > platforms (and > administrators) manage the interfaces below the IP layer > efficiently for a long time!] > > 4. Ability to Stack > ------------------ > By modeling the IP layer as "IP interfaces" stacked on top of > some lower layer interface allows stacking of IPv6 interfaces > over IPv4 interfaces [ RFC2465] > > In future, this model can be extended to allow other "higher > layer interfaces" > to be stacked on IP layer -primarily to let users/NMS manage > the interfaces uniformly. > > 5. Model > -------- > Current MIB models the IP layer as "IP properties and address > associated with a layer2 interface". The proposed approach > models it as "IP interface with IP specific properties and > addresses stacked on a lower layer" (as defined in RFC2465 > for IPv6 case). > > > Did I mis-interpret the draft-2011-update? It does have one > statement that states that there is a "difference" between > the ipv6InterfaceTable and ipv6IfTable, but I am not sure > what it means!! > > > Thoughts? > > Thanks, > sanjay > > > -------------------------------------------------------------------- > 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 Mon Oct 11 14:03:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28276 for ; Mon, 11 Oct 2004 14:03:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4h7-00054u-BA for ipv6-web-archive@ietf.org; Mon, 11 Oct 2004 14:14:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4TJ-0005pI-0L; Mon, 11 Oct 2004 14:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4Mc-0001lK-0p for ipv6@megatron.ietf.org; Mon, 11 Oct 2004 13:53:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27307 for ; Mon, 11 Oct 2004 13:53:36 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4XB-0004qL-Gc for ipv6@ietf.org; Mon, 11 Oct 2004 14:04:34 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F11FE15263; Tue, 12 Oct 2004 02:53:12 +0900 (JST) Date: Tue, 12 Oct 2004 02:53:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Thomas Narten , ipv6@ietf.org Subject: Re: AD Review of draft-ietf-ipv6-rfc2462bis-06.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi Margaret, >>>>> On Wed, 6 Oct 2004 09:05:53 -0400, >>>>> Margaret Wasserman said: > I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have > several comments on this document that I believe should be resolved > before this document is sent to IETF Last Call for publication as a > Draft Standard. Thanks for your careful reading and the detailed review. I'll answer the review comments within a couple of days (sorry for the delay). 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 Oct 12 04:36:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29413 for ; Tue, 12 Oct 2004 04:36:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHIJL-0008PU-9g for ipv6-web-archive@ietf.org; Tue, 12 Oct 2004 04:47:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHHzg-0008QK-A4; Tue, 12 Oct 2004 04:26:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHHtW-00073I-7d for ipv6@megatron.ietf.org; Tue, 12 Oct 2004 04:20:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28327 for ; Tue, 12 Oct 2004 04:20:27 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHI4C-00088b-2v for ipv6@ietf.org; Tue, 12 Oct 2004 04:31:33 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9C8Jux32301 for ; Tue, 12 Oct 2004 11:19:56 +0300 Date: Tue, 12 Oct 2004 11:19:56 +0300 (EEST) From: Pekka Savola To: ipv6@ietf.org In-Reply-To: <200409221933.PAA04270@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Subject: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 On Wed, 22 Sep 2004 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. > > Title : Privacy Extensions for Stateless Address > Autoconfiguration in IPv6 > Author(s) : T. Narten, et al. > Filename : draft-ietf-ipv6-privacy-addrs-v2-00.txt > Pages : 26 > Date : 2004-9-23 FWIW, I think we should make the specification agnostic of the hash algorithm. Either MD5 and SHA1 or whatever is just fine. There is no interoperability problem because I don't see a need to be able to reverse the hashes, and it's just an implementation's internal matter. I guess this is intended for Draft Standard (based on the charter page), but there are a few issues which need to be nailed down first (e.g., about the normative refs to lower maturity specs). substantial ----------- 1) The document goes at great depth to discuss the scenarios and justification for privacy addresses, but I don't think the document produces a concise problem statement (like one paragraph of less than 5 sentences) or description about the scenarios or the threat model. The factoids are dribbled through section 2 but it might make sense to try to collect the important bits together and try to coin up a nice and neat description of the problem that's being fixed. For example, one should take note of the following: - what is the observation point? (e.g., first paragraph of 2.1 takes IMHO bad example of sniffing the traffic might be better removed or reworded) - what is the assumption about the (in)stability of the prefix to the effects of privacy addresses? - how does this effect stationary nodes? nomadic nodes? Also, security considerations talks about ingress filtering, but doesn't really talk about the main meat of draft-dupont-ipv6-rfc3041harmful-XX.txt, that is, why privacy addresses give privacy only with certain assumptions about the dynamicity (or not) of the used prefixes. This should go in as a paragraph of its own in security considerations after the above is clear. 2) the document also goes on at least in 3 different places to list issues with reverse lookups and such. Is this really necessary? I'm not objecting strongly, but there have been arguments that rather than fiddling with protocols, one should consider fixing the broken applications. This is also discussed in draft-ietf-dnsop-ipv6-issues (as are the issues with DDNS), so it might be worth referring to that informatively from here. 3) DNA is referred to in section 3.5, unfortunately I think (at least with the current wording) this would need to be a normative reference because it's required for implementation of this spec. And normative refs must be at least the same maturity level of this spec, and this may pose a problem. A few possibilities which might solve this problem: - describe DNA just as one alternative to note whether the link change has occurred, and possibly detail some others as well - just wait for DNA spec, and keep this as proposed standard - remove (some of) the specification about link changes, e.g., just saying that for wired interfaces plug in/out and wireless interfaces the interface restart could be the events -- no need for DNA then. semi-substantial ---------------- ==> the draft talks a lot about 'global scope addresses', but I don't think is really accurate. The privacy address practices could be applied to site-local or ULA addresses as well, it's just a matter of local policy. RFC2462bis might provide some ideas how to express 'non-link-local' in a better way. On the other hand, I see benefit in restricting the scope of privacy addresses to just global scope addresses, but then you have to define those somehow and that may be tricky.. because ULA addresses, by some terminology, are also global scope.. Not all nodes and interfaces contain IEEE identifiers. In such cases, an interface identifier is generated through some other means (e.g., at random), and the resultant interface identifier is not globally unique and may also change over time. ==> 'globally unique interface identifier' is a rather absolute statement and may not actually be accurate because it has happened that identifiers have been duplicated. Maybe soften the tone a bit. (also see the robert elz appeal on addrarch and unique/local bits.) A more troubling case concerns mobile devices (e.g., laptops, PDAs, etc.) that move topologically within the Internet. Whenever they move (in the absence of technology such as mobile IP [MOBILEIP]), they form new addresses for their current topological point of attachment. ==> the document mentions Mobile IP, but this doesn't actually matter much, depending on the actual problem statement. Remember, unless the mobile node would *only* do bidirectional tunneling back to the home agent, every node the MN talks to will know the care-of address in any case, which seems equal in privacy considerations to just laptop moving without mobile IP. Mobile IP is actually relatively incompatible with privacy addresses as the home address probably acts as a stable identifier, nullifying the effect of using privacy addresses for care-of address if you do route optimization. This could maybe be discussed in security considerations. A workaround is having multiple home addresses (rfc3041 ones), but I don't recall if that's supported or not, and even then, you reveal the stable prefix as the identifier. One way to avoid some of the problems discussed above is to use DHCP for obtaining addresses. With DHCP, the DHCP server could arrange to hand out addresses that change over time. ==> 'change over time' seems relative. The key point here is that DHCP should not provide the addresses with (similar) stable identifiers. Looking at current or planned DHCPv6 deployments, at least some are using (AFAIR) DHCPv6 to give the hosts the same addresses they'd get with stateless address autoconfiguration, including EUI64. Obviously, such would likely not change sufficiently often, and would include the stable identifier. How I see it, the document seems slightly too forthcoming with proposing DHCPv6 as a solution for privacy here, but that only works if DHCPv6 gives temporary addresses without the stable identifiers, and rotates even those non-identifying addresses in a regular basis ("strict pool"). But that seems unnecessary complexity, because there is no need (no address shortage) to do that with IPv6. So, I don't why anyone would use DHCPv6 to avoid this problem rather than privacy addresses. 4. By default, generate a set of addresses from the same (randomized) interface identifier, one address for each prefix for which a global address has been generated via stateless address autoconfiguration. Using the same interface identifier to generate a set of temporary addresses reduces the number of IP multicast groups a host must join. Nodes join the solicited-node multicast address for each unicast address they support, and solicited-node addresses are dependent only on the low-order bits of the corresponding address. This default behaviour was made to address the concern that a node that joins a large number of multicast groups may be required to put its interface into promiscuous mode, resulting in possible reduced performance. ==> what you seem to be saying, in a rather complex way in these steps, that a random address is generated for each received prefix [regardless of interfaces]. Wouldn't there a simpler way to specify that ? A node highly concerned about privacy MAY use different interface identifiers on different prefixes, resulting in a set of global addresses that cannot be easily tied to each other. This may be useful, for example, to a mobile node using multiple wireless interfaces to connect to multiple independent networks. ==> I think the example is flawed, or I don't understand this concern. Multiple wireless interfaces have their own MAC addresses, and multiple independent networks have their own prefixes. If you connect using interface 1 to network 1 and interface 2 to network 2, there is no way to connect the privacy addresses derived from them. Rather, if you use interface 1 to connect to networks 1,2,..,N, you're identifiable, but this is then again the the regular roaming scenario and requires no special considerations... As it is, there's nothing in the spec that would propose that a multi-interface node could pick one of its identifiers and use it as a basis for privacy address generation on all of its interfaces. As I read it, for every physical interface, the 'seed' must be different. ... B. + If the received Valid Lifetime is greater than 2 hours update the lifetime of the temporary address to the received lifetime. + If the RemainingLifetime of the temporary address is less than or equal to 2 hours ignore the received option. + Otherwise set the valid lifetime to 2 hours. C. These steps are necessary to prevent a denial of service attack where a bogus advertisement contains prefixes with very small Valid Lifetimes ==> isn't this fundamentally duplication of specification from rfc2462 checks ? Couldn't you just specify that the lifetimes are checked as specified in section X.X.X.y of rfc2462 ? 6. The node MUST Perform duplicate address detection (DAD) on the generated temporary address. If DAD indicates the address is already in use, the node MUST generate a new randomized interface identifier as described in Section 3.2 above, and repeat the previous steps as appropriate up to 5 times. If after 5 consecutive attempts no non-unique address was generated, ==> 5 times seems like really a strech. Couldn't we lower that down to, say, 3 times? That would still be sufficiently many repetitions, but lower the unnecessary delay and attempts significantly in case there are problems. When a temporary address becomes deprecated, a new one MUST be generated. This is done by repeating the actions described in Section 3.3, starting at step 3). Note that, except for the transient period when a temporary address is being regenerated, in normal operation at most one temporary address corresponding to a public address should be in a non-deprecated state at any given time. ==> I'm flinching back at the 'corresponding' language. The implementation shouldn't need to keep track of public -> private address mappings, and if it does, this should be made more explicit. Instead, it may need to track prefixes, and possibly interfaces (or interface-identifiers). If a very small number of nodes(say only one) use a given prefix for extended periods of time, just changing the interface identifier part of the prefix may not be sufficient to ensure privacy, since the prefix acts as a constant identifier. ==> i'd rather say s/may not be/is not/, because there's nothing conditional (IMHO) about it. 10 References ==> needs to be broken down to informative and normative. It's not clear whether this is intended for PS or DS, but if DS, normative refs must only include those specs which are of DS of BCP; if PS, PS is also OK. editorial --------- 2.2 Address Usage in IPv4 Today Addresses used in today's Internet are often non-changing in practice for extended periods of time, especially in non-home environments (e.g., corporations, campuses, etc.). ==> it's not so much 'home' environments as such but whether the ISP has assigned a static (or gives de-facto static) addresses. This is obviously mostly an issue at home, but could maybe be a bit more general in the text. A more interesting case concerns always-on connections (e.g., cable modems, ISDN, DSL, etc.) that result in a home site using the same address for extended periods of time. This is a scenario that is just starting to become common in IPv4 and promises to become more of a concern as always-on internet connectivity becomes widely available. Although it might appear that changing an address regularly in such environments would be desirable to lessen privacy concerns, it should be noted that the network prefix portion of an address also serves as a constant identifier. All nodes at (say) a home, would have the same network prefix, which identifies the topological location of those nodes. This has implications for privacy, though not at the same granularity as the concern that this document addresses. Specifically, all nodes within a home would be grouped together for the purposes of collecting information. This issue is difficult to address, because the routing prefix part of an address contains topology information and cannot contain arbitrary values. ==> while the topic was 'Address Usage in IPv4 today', the text jumps in the middle to describe v6 considerations (about the prefix portion). Maybe this needs to go somewhere else, or at least broken down more explicitly (e.g., to a different paragraph). Finally, this document assumes that when a node initiates outgoing communication, temporary addresses can be given preference over public addresses, when the device is configured to do so. This is consistent with on-going work that addresses the topic of source-address selection in the more general case [ADDR_SELECT] ==> on-going work no longer... applications are used by end users. Thus, the default value given of one week (TEMP_VALID_LIFETIME) may not be appropriate in all ==> s/default value given/given default value/ temporary addresses in order to simply network debugging and ==> s/simply/simplify/ An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). [...] ==> this issue seems to be discussed in nearly the same fashion in two different places in the draft. Could this just be summarized in one, and described in full in the other, or something? 8. Security Considerations Ingress filtering is being deployed as a means of preventing the use of spoofed source addresses in Distributed Denial of Service(DDoS) attacks. ==> s/is being/has been/ ? legitimately changing temporary addresses and spoofed source addresses which "in-prefix"(They use a topologically correct prefix and non-existent interface ID). This can be addressed by using ==> s/which/which are/, add space after " [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. ==> 3513 [MOBILEIP] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. ==> rather use 3775. -- 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 Tue Oct 12 05:12:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02009 for ; Tue, 12 Oct 2004 05:12:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHIss-0000bE-R8 for ipv6-web-archive@ietf.org; Tue, 12 Oct 2004 05:23:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHIgV-0000dA-AW; Tue, 12 Oct 2004 05:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHIed-00004q-JG for ipv6@megatron.ietf.org; Tue, 12 Oct 2004 05:09:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01743 for ; Tue, 12 Oct 2004 05:09:09 -0400 (EDT) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHIpI-0000Wp-D7 for ipv6@ietf.org; Tue, 12 Oct 2004 05:20:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 82DF126C0A4; Tue, 12 Oct 2004 11:09:06 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 3C38626C099; Tue, 12 Oct 2004 11:09:05 +0200 (CEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i9C9958q829021; Tue, 12 Oct 2004 11:09:05 +0200 (CEST) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.12.10/8.12.10) with ESMTP id i9C994bU018852; Tue, 12 Oct 2004 11:09:04 +0200 (CEST) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.12.10/8.12.10/Submit) id i9C9948B018850; Tue, 12 Oct 2004 11:09:04 +0200 (CEST) (envelope-from souissi) Date: Tue, 12 Oct 2004 11:09:04 +0200 From: Mohsen Souissi To: John.Loughney@Nokia.com Message-ID: <20041012090904.GB89721@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Comment on 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi John, I was browsing through draft-ietf-ipv6-node-requirements-11.txt when I found that you are referring to RFC 3152 for ip6.arpa support for reverese DNS (cf. section 5.1). Please note that RFC 3152 (PS) has been obsoleted by RFC 3596 (DS). The latter deals at the same time with IPv6 support in the forward (AAAA) and the reverse DNS (ip6.arpa). So you should remove that RFC from the "Normative references" and you can cite RFC 3596 also for ip6.arpa support :-) Regards, Mohsen. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 12 12:39:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07248 for ; Tue, 12 Oct 2004 12:39:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHPrQ-0001ly-6Z for ipv6-web-archive@ietf.org; Tue, 12 Oct 2004 12:50:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPWO-0000MX-TH; Tue, 12 Oct 2004 12:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHP87-0000gg-Nn for ipv6@megatron.ietf.org; Tue, 12 Oct 2004 12:04:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03323 for ; Tue, 12 Oct 2004 12:04:00 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHPF4-00007p-TJ for ipv6@ietf.org; Tue, 12 Oct 2004 12:11:18 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CG03F00619; Tue, 12 Oct 2004 19:00:03 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 18:57:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9CFv4LU025567; Tue, 12 Oct 2004 18:57:04 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00tMfKvo; Tue, 12 Oct 2004 18:56:52 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CFupS06232; Tue, 12 Oct 2004 18:56:51 +0300 (EET DST) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 18:56:51 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 18:56:51 +0300 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: Tue, 12 Oct 2004 18:56:51 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D1FFCA3@esebe056.ntc.nokia.com> Thread-Topic: Comment on draft-ietf-ipv6-node-requirements-11.txt Thread-Index: AcSwO7QOk6kXB4x2Tsel+Ljsr4EunAAOEz0g To: X-OriginalArrivalTime: 12 Oct 2004 15:56:51.0386 (UTC) FILETIME=[168709A0:01C4B074] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Comment on 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Hi Mohsen, Good catch, I think I should be able to update this during the author's = 48=20 hours, as this draft has been approved by the IESG. thanks, John > -----Original Message----- > From: ext Mohsen Souissi [mailto:Mohsen.Souissi@nic.fr] > Sent: 12 October, 2004 12:09 > To: Loughney John (Nokia-NRC/Helsinki) > Cc: ipv6@ietf.org > Subject: Comment on draft-ietf-ipv6-node-requirements-11.txt >=20 >=20 > Hi John, >=20 > I was browsing through draft-ietf-ipv6-node-requirements-11.txt when I > found that you are referring to RFC 3152 for ip6.arpa support for > reverese DNS (cf. section 5.1). >=20 > Please note that RFC 3152 (PS) has been obsoleted by RFC 3596 > (DS). The latter deals at the same time with IPv6 support in the > forward (AAAA) and the reverse DNS (ip6.arpa). >=20 > So you should remove that RFC from the "Normative references" and you > can cite RFC 3596 also for ip6.arpa support :-) >=20 > Regards, >=20 > Mohsen. >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 13 01:36:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23060 for ; Wed, 13 Oct 2004 01:36:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHbyz-0004Wy-Ug for ipv6-web-archive@ietf.org; Wed, 13 Oct 2004 01:47:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHbkB-0003tM-Cx; Wed, 13 Oct 2004 01:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHbje-0003fX-LA for ipv6@megatron.ietf.org; Wed, 13 Oct 2004 01:31:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22880 for ; Wed, 13 Oct 2004 01:31:37 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHbuV-0004Tj-85 for ipv6@ietf.org; Wed, 13 Oct 2004 01:42:51 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i9D5VTKm029872; Wed, 13 Oct 2004 00:31:29 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 13 Oct 2004 00:29:17 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L0088CH; Wed, 13 Oct 2004 01:30:49 -0400 Date: Wed, 13 Oct 2004 01:25:27 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Brian Haberman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipv6@ietf.org, Francis Dupont , "Suresh Krishnan \(QB/EMC\)" Subject: Re: Privacy extensions to Stateless Address Autoconf X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hi Brian, Thanks for the comments. Please find my responses inline. Regards Suresh On Fri, 8 Oct 2004, Brian Haberman wrote: >Suresh, > >On Oct 7, 2004, at 20:39, Suresh Krishnan wrote: > >> Hi Brian and Francis, >> Thanks for your comments. I have made some changes to the draft to >> address the issues you raised. Let me know if these changes are OK. >> >> * I have removed all references to MD5 in the document. > >I don't think you want to remove all references to MD5. The >document just doesn't need to mandate that MD5 be the only >hash algorithm. OK. Would it be fine fine if I retain the references to MD5 as is and add the following text at the end of section 3.2 "The random interface identifier generation algorithm, as described in this document, uses MD5 as the hash algorithm. The node MAY use another algorithm instead of MD5 to produce the random interface identifier." > >> * I have added a reference to draft-ietf-ipsec-esp-ah-algorithms-02 > >I don't think we want to do that. This document is supposed to be >going from PS to DS. Adding a reference to an I-D will delay >publication until all references are RFC's. And if the above >draft is Normative, it has to be at the same (DS) level. Agreed. Since we are no longer mandating what algorithm to use, I will remove this reference. > >> * I added the following paragraph about the hash algorithm >> >> "The randomized interface identifier generation algorithm assumes >> that >> the node is capable of running a hash algorithm which is capable of >> producing a 128 bit random value. The selected hash algorithm >> SHOULD >> follow the guidelines set forth in [RANDOM] to ensure randomness >of >> the result. The node MAY use one of the hash algorithms specified >> in >> [IPSECALGO] as these algorithms will be available on every IPv6 >> compliant node" >> > >See my comment above about Normative references and my initial >recommendation to make a reference to 1750 Informative. Will do. > >Regards, >Brian > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 13 01:54:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24237 for ; Wed, 13 Oct 2004 01:54:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHcGJ-0004st-Qs for ipv6-web-archive@ietf.org; Wed, 13 Oct 2004 02:05:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHc3T-0000nE-P8; Wed, 13 Oct 2004 01:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHc31-0000Xx-Ow for ipv6@megatron.ietf.org; Wed, 13 Oct 2004 01:51:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24087 for ; Wed, 13 Oct 2004 01:51:38 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHcDr-0004pu-W0 for ipv6@ietf.org; Wed, 13 Oct 2004 02:02:52 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i9D5piKm002837; Wed, 13 Oct 2004 00:51:44 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 13 Oct 2004 00:49:31 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L0088F6; Wed, 13 Oct 2004 01:50:59 -0400 Date: Wed, 13 Oct 2004 01:45:37 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Pekka Savola In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD3F0@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a50b6fe619b8c4df89c7095cedd22e37 Hi Pekka, Thanks for the detailed comments. See my responses inline. Regards Suresh On Tue, 12 Oct 2004, Pekka Savola wrote: >FWIW, I think we should make the specification agnostic of the hash >algorithm. Either MD5 and SHA1 or whatever is just fine. There is no >interoperability problem because I don't see a need to be able to >reverse the hashes, and it's just an implementation's internal matter. > Please see my reply to Brian earlier on the list and let me know if this addresses your concern. >I guess this is intended for Draft Standard (based on the charter >page), but there are a few issues which need to be nailed down first >(e.g., about the normative refs to lower maturity specs). I have addressed this later in the mail. > >substantial >----------- > >1) > >The document goes at great depth to discuss the scenarios and justification >for privacy addresses, but I don't think the document produces a concise >problem statement (like one paragraph of less than 5 sentences) or >description about the scenarios or the threat model. The factoids are >dribbled through section 2 but it might make sense to try to collect the >important bits together and try to coin up a nice and neat description of >the problem that's being fixed. How about the following text for the problem statement? "Addresses generated using Stateless address autoconfiguration [ADDRCONF] contain an embedded 64-bit interface identifier which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlateseemingly unrelated activity using this identifier. Since the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. This document proposes a solution to this issue by generating interface identifiers which vary over time." > >For example, one should take note of the following: > - what is the observation point? (e.g., first paragraph of 2.1 takes IMHO >bad example of sniffing the traffic might be better removed or reworded) > - what is the assumption about the (in)stability of the prefix to the >effects of privacy addresses? This is covered in Section 3.6 "Deployment Considerations" > - how does this effect stationary nodes? nomadic nodes? I will cover the effect on nomadic nodes in the section I am going to write about mobile IP. > >Also, security considerations talks about ingress filtering, but >doesn't really talk about the main meat of >draft-dupont-ipv6-rfc3041harmful-XX.txt, that is, why privacy >addresses give privacy only with certain assumptions about the >dynamicity (or not) of the used prefixes. This should go in as a >paragraph of its own in security considerations after the above is >clear. I had already added text in the draft, which I thought would address this issue. It is the last paragraph of Section 3.6 "Deployment Considerations" "If a very small number of nodes(say only one) use a given prefix for extended periods of time, just changing the interface identifier part of the prefix may not be sufficient to ensure privacy, since the prefix acts as a constant identifier. The procedures described in this document are most effective when the prefix is reasonably non static or is used by a fairly large number of nodes" Do you think this is not sufficient? > >2) the document also goes on at least in 3 different places to list >issues with reverse lookups and such. Is this really necessary? I'm >not objecting strongly, but there have been arguments that rather than >fiddling with protocols, one should consider fixing the broken >applications. This is also discussed in draft-ietf-dnsop-ipv6-issues >(as are the issues with DDNS), so it might be worth referring to that >informatively from here. The dnsop ipv6 issues draft just refers back to RFC3041 regarding reverse lookups. Would you still like me to reference it? > >3) DNA is referred to in section 3.5, unfortunately I think (at least with >the current wording) this would need to be a normative reference because >it's required for implementation of this spec. And normative refs must be >at least the same maturity level of this spec, and this may pose a problem. >A few possibilities which might solve this problem: > - describe DNA just as one alternative to note whether the link change has >occurred, and possibly detail some others as well > - just wait for DNA spec, and keep this as proposed standard > - remove (some of) the specification about link changes, e.g., just saying >that for wired interfaces plug in/out and wireless interfaces the interface >restart could be the events -- no need for DNA then. I like option 1. I will reword this and change the DNA reference to informational. > > >semi-substantial >---------------- > > ==> the draft talks a lot about 'global scope addresses', >but I don't think is really accurate. The privacy address practices could >be applied to site-local or ULA addresses as well, it's just a matter of >local policy. RFC2462bis might provide some ideas how to express >'non-link-local' in a better way. Site local has been deprecated and ULAs are within the scope of the document. I have the following text in the draft at the end of Section 1 "Introduction" " The term "global scope addresses" is used in this document to collectively refer to "Global unicast addresses" as defined in [ADDRARCH] and "Unique local addresses" as defined in [ULA]" Do you have any issues with this definition? > >On the other hand, I see benefit in restricting the scope of privacy >addresses to just global scope addresses, but then you have to define >those somehow and that may be tricky.. because ULA addresses, by some >terminology, are also global scope.. > > Not all nodes and interfaces contain IEEE identifiers. In such > cases, an interface identifier is generated through some other means > (e.g., at random), and the resultant interface identifier is not > globally unique and may also change over time. > >==> 'globally unique interface identifier' is a rather absolute >statement and may not actually be accurate because it has happened >that identifiers have been duplicated. Maybe soften the tone a bit. >(also see the robert elz appeal on addrarch and unique/local bits.) OK. The problem in fixing this is that there is no explicit claim that IIDs formed from EUIs are globally unique. Would it be OK if I changed " resultant interface identifier is not globally unique" to " resultant interface identifier may not be globally unique" > > A more troubling case concerns mobile devices (e.g., laptops, PDAs, > etc.) that move topologically within the Internet. Whenever they > move (in the absence of technology such as mobile IP [MOBILEIP]), > they form new addresses for their current topological point of > attachment. > >==> the document mentions Mobile IP, but this doesn't actually matter much, >depending on the actual problem statement. Remember, unless the mobile node >would *only* do bidirectional tunneling back to the home agent, every node >the MN talks to will know the care-of address in any case, which seems equal >in privacy considerations to just laptop moving without mobile IP. > >Mobile IP is actually relatively incompatible with privacy addresses >as the home address probably acts as a stable identifier, nullifying >the effect of using privacy addresses for care-of address if you do >route optimization. This could maybe be discussed in security >considerations. A workaround is having multiple home addresses >(rfc3041 ones), but I don't recall if that's supported or not, and >even then, you reveal the stable prefix as the identifier. I will add a paragraph in "Deployment Considerations" about Mobile IP. > > One way to avoid some of the problems discussed above is to use DHCP > for obtaining addresses. With DHCP, the DHCP server could arrange to > hand out addresses that change over time. > >==> 'change over time' seems relative. The key point here is that DHCP >should not provide the addresses with (similar) stable identifiers. Looking >at current or planned DHCPv6 deployments, at least some are using (AFAIR) >DHCPv6 to give the hosts the same addresses they'd get with stateless >address autoconfiguration, including EUI64. Obviously, such would likely >not change sufficiently often, and would include the stable identifier. > >How I see it, the document seems slightly too forthcoming with >proposing DHCPv6 as a solution for privacy here, but that only works >if DHCPv6 gives temporary addresses without the stable identifiers, >and rotates even those non-identifying addresses in a regular basis >("strict pool"). But that seems unnecessary complexity, because there >is no need (no address shortage) to do that with IPv6. So, I don't >why anyone would use DHCPv6 to avoid this problem rather than privacy >addresses. Agreed. DHCP is proposed as a solution and is qualified by the following sentence "With DHCP, the DHCP server could arrange to hand out addresses that change over time" and the issue you are mentioning is discussed earlier in section 2.2 "In theory, the address a client gets via DHCP can change over time, but in practice servers often return the same address to the same client (unless addresses are in such short supply that they are reused immediately by a different node when they become free). Thus, even within sites using DHCP, clients frequently end up using the same address for weeks to months at a time." Would you like me to add stronger wording or to explicitly discourage the use of DHCPv6 for privacy purposes? > > 4. By default, generate a set of addresses from the same > (randomized) interface identifier, one address for each prefix > for which a global address has been generated via stateless > address autoconfiguration. Using the same interface identifier > to generate a set of temporary addresses reduces the number of IP > multicast groups a host must join. Nodes join the solicited-node > multicast address for each unicast address they support, and > solicited-node addresses are dependent only on the low-order bits > of the corresponding address. This default behaviour was made to > address the concern that a node that joins a large number of > multicast groups may be required to put its interface into > promiscuous mode, resulting in possible reduced performance. > >==> what you seem to be saying, in a rather complex way in these >steps, that a random address is generated for each received prefix >[regardless of interfaces]. Wouldn't there a simpler way to specify >that ? Not really. The identifier is generated per interface. So a random address is generated per prefix per interface. The idea of the paragraph is to explain the rationale behind using the same random identifier with all the prefixes received on an interface. I agree there might be a simpler way of stating this. I will try to come up with something. > > A node highly concerned about privacy MAY use different interface > identifiers on different prefixes, resulting in a set of global > addresses that cannot be easily tied to each other. This may be > useful, for example, to a mobile node using multiple wireless > interfaces to connect to multiple independent networks. > >==> I think the example is flawed, or I don't understand this concern. >Multiple wireless interfaces have their own MAC addresses, and >multiple independent networks have their own prefixes. If you connect >using interface 1 to network 1 and interface 2 to network 2, there is >no way to connect the privacy addresses derived from them. Rather, if >you use interface 1 to connect to networks 1,2,..,N, you're >identifiable, but this is then again the the regular roaming scenario >and requires no special considerations... This paragraph explicitly allows the following scenario. Let's say interface IF1 is connected to networks N1,N2 and N3. The node MAY generate DIFFERENT identifiers I1,I2 and I3 for each of these prefixes to make addresses N1|I1, N2|I2, and N3|I3 if it so desires, instead of being limited to N1|I1,N2|I1, and N3|I1. > >As it is, there's nothing in the spec that would propose that a >multi-interface node could pick one of its identifiers and use it as a >basis for privacy address generation on all of its interfaces. As I >read it, for every physical interface, the 'seed' must be different. Yes. This is true. > >... > > B. > + If the received Valid Lifetime is greater than 2 hours > update the lifetime of the temporary address to the > received lifetime. > + If the RemainingLifetime of the temporary address is less > than or equal to 2 hours ignore the received option. > + Otherwise set the valid lifetime to 2 hours. > C. These steps are necessary to prevent a denial of service > attack where a bogus advertisement contains prefixes with > very small Valid Lifetimes > >==> isn't this fundamentally duplication of specification from rfc2462 >checks ? Couldn't you just specify that the lifetimes are checked as >specified in section X.X.X.y of rfc2462 ? No. This check does not exist in RFC2462. It was added later in RFC2462bis. Since 2462bis is still a draft I included it here. I can remove it and add a reference to 2462bis if needed. But this needs to be a normative reference. > > 6. The node MUST Perform duplicate address detection (DAD) on the > generated temporary address. If DAD indicates the address is > already in use, the node MUST generate a new randomized interface > identifier as described in Section 3.2 above, and repeat the > previous steps as appropriate up to 5 times. If after 5 > consecutive attempts no non-unique address was generated, > >==> 5 times seems like really a strech. Couldn't we lower that down >to, say, 3 times? That would still be sufficiently many repetitions, >but lower the unnecessary delay and attempts significantly in case >there are problems. I will make this a configuration variable and default it to 3. > > When a temporary address becomes deprecated, a new one MUST be > generated. This is done by repeating the actions described in > Section 3.3, starting at step 3). Note that, except for the > transient period when a temporary address is being regenerated, in > normal operation at most one temporary address corresponding to a > public address should be in a non-deprecated state at any given time. > >==> I'm flinching back at the 'corresponding' language. The >implementation shouldn't need to keep track of public -> private >address mappings, and if it does, this should be made more explicit. >Instead, it may need to track prefixes, and possibly interfaces (or >interface-identifiers). I will change the language to make the node track the prefixes instead of corresponding public addresses. > > If a very small number of nodes(say only one) use a given prefix for > extended periods of time, just changing the interface identifier > part of the prefix may not be sufficient to ensure privacy, since > the prefix acts as a constant identifier. > >==> i'd rather say s/may not be/is not/, because there's nothing conditional >(IMHO) about it. There is. The data collector NEEDS to know that there is only one node. Otherwise she/he may not be able to correlate the collected data with two different addresses. > >10 References > >==> needs to be broken down to informative and normative. It's not clear >whether this is intended for PS or DS, but if DS, normative refs must only >include those specs which are of DS of BCP; if PS, PS is also OK. OK. I have made this change for the new version of the draft based on Brian's comments. > >editorial >--------- > >2.2 Address Usage in IPv4 Today > > Addresses used in today's Internet are often non-changing in practice > for extended periods of time, especially in non-home environments > (e.g., corporations, campuses, etc.). > >==> it's not so much 'home' environments as such but whether the ISP has >assigned a static (or gives de-facto static) addresses. This is obviously >mostly an issue at home, but could maybe be a bit more general in the text. OK. I will add a more general description. > > A more interesting case concerns always-on connections (e.g., cable > modems, ISDN, DSL, etc.) that result in a home site using the same > address for extended periods of time. This is a scenario that is > just starting to become common in IPv4 and promises to become more of > a concern as always-on internet connectivity becomes widely > available. Although it might appear that changing an address > regularly in such environments would be desirable to lessen privacy > concerns, it should be noted that the network prefix portion of an > address also serves as a constant identifier. All nodes at (say) a > home, would have the same network prefix, which identifies the > topological location of those nodes. This has implications for > privacy, though not at the same granularity as the concern that this > document addresses. Specifically, all nodes within a home would be > grouped together for the purposes of collecting information. This > issue is difficult to address, because the routing prefix part of an > address contains topology information and cannot contain arbitrary > values. > >==> while the topic was 'Address Usage in IPv4 today', the text jumps in the >middle to describe v6 considerations (about the prefix portion). Maybe this >needs to go somewhere else, or at least broken down more explicitly (e.g., >to a different paragraph). Not necessarily. It is still talking about IPv4 prefixes and IPv4 addresses. > > Finally, this document assumes that when a node initiates outgoing > communication, temporary addresses can be given preference over > public addresses, when the device is configured to do so. This is > consistent with on-going work that addresses the topic of > source-address selection in the more general case [ADDR_SELECT] > >==> on-going work no longer... Good catch. I will change the text. I already have ADDR_SELECT referencing RFC3484. > > applications are used by end users. Thus, the default value given of > one week (TEMP_VALID_LIFETIME) may not be appropriate in all > >==> s/default value given/given default value/ OK. > > > temporary addresses in order to simply network debugging and > > >==> s/simply/simplify/ OK. > > An implementation might want to keep track of which addresses are > being used by upper layers so as to be able to remove a deprecated > temporary address from internal data structures once no upper layer > protocols are using it (but not before). [...] > >==> this issue seems to be discussed in nearly the same fashion in two >different places in the draft. Could this just be summarized in one, and >described in full in the other, or something? One of the places talks about WHEN an application is allowed to remove deprecated addresses. The other one talks about Future Work to be done. I don't see any elegant way of combining these two. > >8. Security Considerations > > > Ingress filtering is being deployed as a means of preventing the use > of spoofed source addresses in Distributed Denial of Service(DDoS) > attacks. > >==> s/is being/has been/ ? Subjective ;-). "Has been" makes it sound like everyone has it deployed already. I will leave it as it is unless you have strong feelings. > > legitimately changing temporary addresses and spoofed source > addresses which "in-prefix"(They use a topologically correct prefix > and non-existent interface ID). This can be addressed by using > >==> s/which/which are/, add space after " OK. > > [ADDRARCH] > Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 2373, July 1998. > >==> 3513 Will do. > > [MOBILEIP] > Perkins, C., "IP Mobility Support", RFC 2002, October > 1996. > >==> rather use 3775. Will do. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 13 03:25:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27312 for ; Wed, 13 Oct 2004 03:25:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHdh2-0006Eo-Ae for ipv6-web-archive@ietf.org; Wed, 13 Oct 2004 03:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHdRZ-0000ro-Jz; Wed, 13 Oct 2004 03:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHdMw-0008Id-VP for ipv6@megatron.ietf.org; Wed, 13 Oct 2004 03:16:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26870 for ; Wed, 13 Oct 2004 03:16:16 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHdXm-00065W-D3 for ipv6@ietf.org; Wed, 13 Oct 2004 03:27:31 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9D7FPW31667; Wed, 13 Oct 2004 10:15:25 +0300 Date: Wed, 13 Oct 2004 10:15:25 +0300 (EEST) From: Pekka Savola To: Suresh Krishnan In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Francis Dupont , Brian Haberman , ipv6@ietf.org, "Suresh Krishnan \(QB/EMC\)" Subject: Re: Privacy extensions to Stateless Address Autoconf 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Wed, 13 Oct 2004, Suresh Krishnan wrote: > "The random interface identifier generation algorithm, as described in > this document, uses MD5 as the hash algorithm. The node MAY use another > algorithm instead of MD5 to produce the random interface identifier." OK. > >> * I have added a reference to draft-ietf-ipsec-esp-ah-algorithms-02 > > > >I don't think we want to do that. This document is supposed to be > >going from PS to DS. Adding a reference to an I-D will delay > >publication until all references are RFC's. And if the above > >draft is Normative, it has to be at the same (DS) level. > > Agreed. Since we are no longer mandating what algorithm to use, I will > remove this reference. However, I don't see a problem with having the draft as an Informative reference. That might influence which algorithm the implementor selects. -- 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 Oct 13 09:36:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26752 for ; Wed, 13 Oct 2004 09:36:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHjTo-0005Eb-5p for ipv6-web-archive@ietf.org; Wed, 13 Oct 2004 09:47:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjDa-0007lt-4O; Wed, 13 Oct 2004 09:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHj8O-0006gY-Gt for ipv6@megatron.ietf.org; Wed, 13 Oct 2004 09:25:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25676 for ; Wed, 13 Oct 2004 09:25:35 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHjJD-00051D-1N for ipv6@ietf.org; Wed, 13 Oct 2004 09:36:54 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.8392084; Wed, 13 Oct 2004 09:24:11 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <2B117C02-1D1B-11D9-9EB8-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Wed, 13 Oct 2004 09:24:10 -0400 To: Suresh Krishnan X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ipv6@ietf.org, Francis Dupont , "Suresh Krishnan \(QB/EMC\)" Subject: Re: Privacy extensions to Stateless Address Autoconf 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="===============1963421371==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 --===============1963421371== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--892433428; protocol="application/pkcs7-signature" --Apple-Mail-1--892433428 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Suresh On Oct 13, 2004, at 1:25, Suresh Krishnan wrote: > Hi Brian, > Thanks for the comments. Please find my responses inline. > > Regards > Suresh > > On Fri, 8 Oct 2004, Brian Haberman wrote: > >> Suresh, >> >> On Oct 7, 2004, at 20:39, Suresh Krishnan wrote: >> >>> Hi Brian and Francis, >>> Thanks for your comments. I have made some changes to the draft to >>> address the issues you raised. Let me know if these changes are OK. >>> >>> * I have removed all references to MD5 in the document. >> >> I don't think you want to remove all references to MD5. The >> document just doesn't need to mandate that MD5 be the only >> hash algorithm. > > OK. Would it be fine fine if I retain the references to MD5 as is > and add the following text at the end of section 3.2 > > "The random interface identifier generation algorithm, as described in > this document, uses MD5 as the hash algorithm. The node MAY use another > algorithm instead of MD5 to produce the random interface identifier." This sounds fine to me. > >> >>> * I have added a reference to draft-ietf-ipsec-esp-ah-algorithms-02 >> >> I don't think we want to do that. This document is supposed to be >> going from PS to DS. Adding a reference to an I-D will delay >> publication until all references are RFC's. And if the above >> draft is Normative, it has to be at the same (DS) level. > > Agreed. Since we are no longer mandating what algorithm to use, I will > remove this reference. I agree with Pekka that we can make this an informative reference. Regards, Brian --Apple-Mail-1--892433428 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDEzMTMyNDExWjAjBgkqhkiG9w0B CQQxFgQU1p/CBx+mfH/SP/9Dc0NYoUS7OaAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAKfcfQW89zIBbPbSGAqDYmUcc+3A/65gJeXTa+YE0AYpYbxyJRYeBP4WDw2cfl4lmCCCn d6Z1AQFdpa6es74spOSJ7fhsNPJLG58p0M9r7b6VMWLkWuy2oj1H5yxhZHSzTR33mQ0sPiaqBpWw gcsBa39xs8D6KYv0f7A4KEPU69rSvHUk+n4nAfPqMdir+neess70DqL4VX+ipbNMIMeNsXNMr/K7 5DgRswIL8GpXN3pqzkhn8O2gPJkROQYjvXXJkjxvP10EV8K0H81jgTV+jBfn0O+nQwIxceWKX6QS Dl365SXkWiSRUtN/5bB5000bcBtmOoaCM0zl/Rf4mjNMrwAAAAAAAA== --Apple-Mail-1--892433428-- --===============1963421371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1963421371==-- From ipv6-bounces@ietf.org Thu Oct 14 04:59:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20232 for ; Thu, 14 Oct 2004 04:59:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI1dX-0004n7-Pt for ipv6-web-archive@ietf.org; Thu, 14 Oct 2004 05:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI1Ou-0004Fc-6B; Thu, 14 Oct 2004 04:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI1GQ-0003Hi-PH for ipv6@megatron.ietf.org; Thu, 14 Oct 2004 04:47:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19605 for ; Thu, 14 Oct 2004 04:47:09 -0400 (EDT) Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI1RJ-0004a6-AN for ipv6@ietf.org; Thu, 14 Oct 2004 04:58:41 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.135.175]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i9E8k5fd026771 for ; Thu, 14 Oct 2004 10:46:05 +0200 Received: from vies194a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i9E8k4L3022329 for ; Thu, 14 Oct 2004 10:46:05 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <4L37NM18>; Thu, 14 Oct 2004 10:48:31 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AC41@viee10pa.erd.siemens.at> From: Grubmair Peter To: "'Pekka Savola'" , "IPV6 IETF (E-mail)" Date: Thu, 14 Oct 2004 10:44:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 I want to state that I personally do not like the new idea from the draft to consider total lifetimes of a temporary address in case of some RAs renew prefixes. (Previously lifetimes of temporary addresses could only be lowered by RAs). This adds additional complexity for the rather rare event of a sites address renumbering. Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 14 16:59:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02172 for ; Thu, 14 Oct 2004 16:59:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICsa-0004ac-I1 for ipv6-web-archive@ietf.org; Thu, 14 Oct 2004 17:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICND-0006bR-3j; Thu, 14 Oct 2004 16:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIC4l-0008Tp-Uy; Thu, 14 Oct 2004 16:19:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25538; Thu, 14 Oct 2004 16:19:49 -0400 (EDT) Message-Id: <200410142019.QAA25538@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 14 Oct 2004 16:19:49 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-router-selection-06.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Default Router Preferences and More-Specific Routes Author(s) : R. Draves, D. Thaler Filename : draft-ietf-ipv6-router-selection-06.txt Pages : 14 Date : 2004-10-14 This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-06.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-ipv6-router-selection-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-router-selection-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-14164540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-router-selection-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-router-selection-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-14164540.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Oct 15 08:45:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24124 for ; Fri, 15 Oct 2004 08:45:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIRdb-0006GO-NF for ipv6-web-archive@ietf.org; Fri, 15 Oct 2004 08:56:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIROj-0003Ov-6o; Fri, 15 Oct 2004 08:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIRMF-00032N-PK for ipv6@megatron.ietf.org; Fri, 15 Oct 2004 08:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23603 for ; Fri, 15 Oct 2004 08:38:53 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIRXZ-00066R-8O for ipv6@ietf.org; Fri, 15 Oct 2004 08:50:40 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9FCcJbj004940; Fri, 15 Oct 2004 07:38:19 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47VZVZZH>; Fri, 15 Oct 2004 07:38:18 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L009RWW; Fri, 15 Oct 2004 08:38:16 -0400 Date: Fri, 15 Oct 2004 08:32:50 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Grubmair Peter In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD3F8@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "IPV6 IETF \(E-mail\)" , "'Pekka Savola'" Subject: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi, I am not exactly sure what part of the draft you are referring about, but without the 2 hour lifetime rule stateless address autoconf is susceptible to a denial of service attack using fake RAs with low lifetimes. Can you give me the specifics regarding the text in the draft which you are worried about (section number, paragraph etc.)? Regards Suresh On Thu, 14 Oct 2004, Grubmair Peter wrote: >I want to state that I personally do not like the new >idea from the draft to consider total lifetimes of a >temporary address in case of some RAs renew prefixes. >(Previously lifetimes of temporary addresses could only be >lowered by RAs). >This adds additional complexity for the rather rare >event of a sites address renumbering. >Best regards > Peter > > >-------------------------------------------------------------------- >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 Oct 15 09:24:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26424 for ; Fri, 15 Oct 2004 09:24:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CISFW-00070M-C8 for ipv6-web-archive@ietf.org; Fri, 15 Oct 2004 09:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIS11-0000ux-DQ; Fri, 15 Oct 2004 09:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIRyD-0000KS-3G for ipv6@megatron.ietf.org; Fri, 15 Oct 2004 09:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26100 for ; Fri, 15 Oct 2004 09:18:06 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIS9Y-0006ts-CQ for ipv6@ietf.org; Fri, 15 Oct 2004 09:29:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9FDHQD08250; Fri, 15 Oct 2004 16:17:26 +0300 Date: Fri, 15 Oct 2004 16:17:26 +0300 (EEST) From: Pekka Savola To: Suresh Krishnan In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 Sorry for the delay to respond to your quick response.. long email ;-) On Wed, 13 Oct 2004, Suresh Krishnan wrote: > On Tue, 12 Oct 2004, Pekka Savola wrote: > >FWIW, I think we should make the specification agnostic of the hash > >algorithm. Either MD5 and SHA1 or whatever is just fine. There is no > >interoperability problem because I don't see a need to be able to > >reverse the hashes, and it's just an implementation's internal matter. > > > > Please see my reply to Brian earlier on the list and let me know if this > addresses your concern. OK. > >substantial > >----------- > > > >1) > > > >The document goes at great depth to discuss the scenarios and justification > >for privacy addresses, but I don't think the document produces a concise > >problem statement (like one paragraph of less than 5 sentences) or > >description about the scenarios or the threat model. The factoids are > >dribbled through section 2 but it might make sense to try to collect the > >important bits together and try to coin up a nice and neat description of > >the problem that's being fixed. > > How about the following text for the problem statement? > > "Addresses generated using Stateless address autoconfiguration [ADDRCONF] > contain an embedded 64-bit interface identifier which remains constant > over time. Anytime a fixed identifier is used in multiple contexts, it > becomes possible to correlateseemingly unrelated activity using this > identifier. Since the identifier is embedded within the IPv6 address, > which is a fundamental requirement of communication, it cannot be easily > hidden. This document proposes a solution to this issue by generating > interface identifiers which vary over time." This describes rather well the approach against correlation, but what I was more concerned about was what I wrote below -- i.e., that the case _where_ and _by whom_ you expect that correlation to happen. > >For example, one should take note of the following: > > - what is the observation point? (e.g., first paragraph of 2.1 takes IMHO > >bad example of sniffing the traffic might be better removed or reworded) > > - what is the assumption about the (in)stability of the prefix to the > >effects of privacy addresses? > > This is covered in Section 3.6 "Deployment Considerations" See above. At least some of this should probably be prominent in the justification of this mechanism. > > - how does this effect stationary nodes? nomadic nodes? > > I will cover the effect on nomadic nodes in the section I am going to > write about mobile IP. OK. > >Also, security considerations talks about ingress filtering, but > >doesn't really talk about the main meat of > >draft-dupont-ipv6-rfc3041harmful-XX.txt, that is, why privacy > >addresses give privacy only with certain assumptions about the > >dynamicity (or not) of the used prefixes. This should go in as a > >paragraph of its own in security considerations after the above is > >clear. > > I had already added text in the draft, which I thought would address > this issue. It is the last paragraph of Section 3.6 "Deployment > Considerations" > > "If a very small number of nodes(say only one) use a given prefix for > extended periods of time, just changing the interface identifier > part of the prefix may not be sufficient to ensure privacy, since > the prefix acts as a constant identifier. The procedures described > in this document are most effective when the prefix is reasonably non > static or is used by a fairly large number of nodes" > > Do you think this is not sufficient? Yes -- that seems like an afterthought which is not applied sufficiently to the rest of the document -- the discussion & problem statement in the introduction and the first paragraphs and the security considerations in particular. The point is that if you use stable prefixes, RFC3041 addresses don't help you at all to ensure privacy for stationary nodes in that network. That needs to be said loud and clear in the critical places in the document. > >2) the document also goes on at least in 3 different places to list > >issues with reverse lookups and such. Is this really necessary? I'm > >not objecting strongly, but there have been arguments that rather than > >fiddling with protocols, one should consider fixing the broken > >applications. This is also discussed in draft-ietf-dnsop-ipv6-issues > >(as are the issues with DDNS), so it might be worth referring to that > >informatively from here. > > The dnsop ipv6 issues draft just refers back to RFC3041 regarding > reverse lookups. Would you still like me to reference it? The part in dnsop ipv6 issues draft I referred to was the discussiona bout the techiniques for using DDNS, and the discussion of the applicability of reverse DNS in the first place. Not sure if it needs to be referred to here, but if the draft talks a bit about these subjects, referring to another document which tries to do a more extensive discussion might not hurt. > >3) DNA is referred to in section 3.5, unfortunately I think (at least with > >the current wording) this would need to be a normative reference because > >it's required for implementation of this spec. And normative refs must be > >at least the same maturity level of this spec, and this may pose a problem. > >A few possibilities which might solve this problem: > > - describe DNA just as one alternative to note whether the link change has > >occurred, and possibly detail some others as well > > - just wait for DNA spec, and keep this as proposed standard > > - remove (some of) the specification about link changes, e.g., just saying > >that for wired interfaces plug in/out and wireless interfaces the interface > >restart could be the events -- no need for DNA then. > > I like option 1. I will reword this and change the DNA reference to > informational. OK. I guess some other techniques than DNA also need to be noted (maybe less optimal as DNA)? > >semi-substantial > >---------------- > > > > ==> the draft talks a lot about 'global scope addresses', > >but I don't think is really accurate. The privacy address practices could > >be applied to site-local or ULA addresses as well, it's just a matter of > >local policy. RFC2462bis might provide some ideas how to express > >'non-link-local' in a better way. > > Site local has been deprecated and ULAs are within the scope of the > document. I have the following text in the draft at the end of Section 1 > > "Introduction" > > " The term "global scope addresses" is used in this > document to collectively refer to "Global unicast addresses" as > defined in [ADDRARCH] and "Unique local addresses" as defined in > [ULA]" > > Do you have any issues with this definition? Yes -- this brings up the issue why one would like to use privacy addresses with unique local addresses ? This gets back to the question of correlating by whom and where. In the domains where you use ULA addresses, I'd expect you wouldn't be concerned of correlation.. > >On the other hand, I see benefit in restricting the scope of privacy > >addresses to just global scope addresses, but then you have to define > >those somehow and that may be tricky.. because ULA addresses, by some > >terminology, are also global scope.. > > > > Not all nodes and interfaces contain IEEE identifiers. In such > > cases, an interface identifier is generated through some other means > > (e.g., at random), and the resultant interface identifier is not > > globally unique and may also change over time. > > > >==> 'globally unique interface identifier' is a rather absolute > >statement and may not actually be accurate because it has happened > >that identifiers have been duplicated. Maybe soften the tone a bit. > >(also see the robert elz appeal on addrarch and unique/local bits.) > > OK. The problem in fixing this is that there is no explicit claim that > IIDs formed from EUIs are globally unique. Would it be OK if I changed > " resultant interface identifier is not globally unique" > to > " resultant interface identifier may not be globally unique" That seems to be sufficiently softening the wording and it's OK by me. > > A more troubling case concerns mobile devices (e.g., laptops, PDAs, > > etc.) that move topologically within the Internet. Whenever they > > move (in the absence of technology such as mobile IP [MOBILEIP]), > > they form new addresses for their current topological point of > > attachment. > > > >==> the document mentions Mobile IP, but this doesn't actually matter much, > >depending on the actual problem statement. Remember, unless the mobile node > >would *only* do bidirectional tunneling back to the home agent, every node > >the MN talks to will know the care-of address in any case, which seems equal > >in privacy considerations to just laptop moving without mobile IP. > > > >Mobile IP is actually relatively incompatible with privacy addresses > >as the home address probably acts as a stable identifier, nullifying > >the effect of using privacy addresses for care-of address if you do > >route optimization. This could maybe be discussed in security > >considerations. A workaround is having multiple home addresses > >(rfc3041 ones), but I don't recall if that's supported or not, and > >even then, you reveal the stable prefix as the identifier. > > I will add a paragraph in "Deployment Considerations" about Mobile IP. OK. > > One way to avoid some of the problems discussed above is to use DHCP > > for obtaining addresses. With DHCP, the DHCP server could arrange to > > hand out addresses that change over time. > > > >==> 'change over time' seems relative. The key point here is that DHCP > >should not provide the addresses with (similar) stable identifiers. Looking > >at current or planned DHCPv6 deployments, at least some are using (AFAIR) > >DHCPv6 to give the hosts the same addresses they'd get with stateless > >address autoconfiguration, including EUI64. Obviously, such would likely > >not change sufficiently often, and would include the stable identifier. > > > >How I see it, the document seems slightly too forthcoming with > >proposing DHCPv6 as a solution for privacy here, but that only works > >if DHCPv6 gives temporary addresses without the stable identifiers, > >and rotates even those non-identifying addresses in a regular basis > >("strict pool"). But that seems unnecessary complexity, because there > >is no need (no address shortage) to do that with IPv6. So, I don't > >why anyone would use DHCPv6 to avoid this problem rather than privacy > >addresses. > > Agreed. DHCP is proposed as a solution and is qualified by the following > sentence > > "With DHCP, the DHCP server could arrange to hand out addresses that > change over time" > > and the issue you are mentioning is discussed earlier in section 2.2 > > "In theory, the address a client gets via DHCP can change over time, but > in practice servers often return the same address to the same client > (unless addresses are in such short supply that they are reused immediately > by a different node when they become free). Thus, even within sites using > DHCP, clients frequently end up using the same address for weeks to > months at a time." > > Would you like me to add stronger wording or to explicitly discourage > the use of DHCPv6 for privacy purposes? The discussion in section 2.2 is about IPv4 where there arguably there can be some some address shortage. The quote you give is not sufficiently strong for DHCPv6, because the node would basically NEVER have to change the address. So DHCPv6 does not practically address this concern, unless the address rotation is manually configured, and nobody will bother to do that. Therefore I think stating that DHCP(v6) can solve this problem needs to be stated rather in a fashion like "DHCPv6 could only solve the problem if addresses it gave didn't have stable identifiers, and those addresses were manually rotated periodically so that each node would get new addresses suitably frequently. Because this does not happen automatically, and manual renumbering operations can be considered extremely burdensome, DHCPv6 is not a solution for address privacy; DHCPv6 can only be used as an alternative for handing temporary addresses [but explain why this doesn't necessarily make much difference compared to just doing RFC3041]". > > 4. By default, generate a set of addresses from the same > > (randomized) interface identifier, one address for each prefix > > for which a global address has been generated via stateless > > address autoconfiguration. Using the same interface identifier > > to generate a set of temporary addresses reduces the number of IP > > multicast groups a host must join. Nodes join the solicited-node > > multicast address for each unicast address they support, and > > solicited-node addresses are dependent only on the low-order bits > > of the corresponding address. This default behaviour was made to > > address the concern that a node that joins a large number of > > multicast groups may be required to put its interface into > > promiscuous mode, resulting in possible reduced performance. > > > >==> what you seem to be saying, in a rather complex way in these > >steps, that a random address is generated for each received prefix > >[regardless of interfaces]. Wouldn't there a simpler way to specify > >that ? > > Not really. The identifier is generated per interface. So a random address > is generated per prefix per interface. The idea of the paragraph is to > explain the rationale behind using the same random identifier with all > the prefixes received on an interface. I agree there might be a simpler > way of stating this. I will try to come up with something. OK. > > A node highly concerned about privacy MAY use different interface > > identifiers on different prefixes, resulting in a set of global > > addresses that cannot be easily tied to each other. This may be > > useful, for example, to a mobile node using multiple wireless > > interfaces to connect to multiple independent networks. > > > >==> I think the example is flawed, or I don't understand this concern. > >Multiple wireless interfaces have their own MAC addresses, and > >multiple independent networks have their own prefixes. If you connect > >using interface 1 to network 1 and interface 2 to network 2, there is > >no way to connect the privacy addresses derived from them. Rather, if > >you use interface 1 to connect to networks 1,2,..,N, you're > >identifiable, but this is then again the the regular roaming scenario > >and requires no special considerations... > > This paragraph explicitly allows the following scenario. > > Let's say interface IF1 is connected to networks N1,N2 and N3. The node > MAY generate DIFFERENT identifiers I1,I2 and I3 for each of these prefixes > to make addresses N1|I1, N2|I2, and N3|I3 if it so desires, instead of > being limited to N1|I1,N2|I1, and N3|I1. Then you should be saying 'a single wireless interface' instead of 'multiple wireless interfaces', and this would be OK. > > B. > > + If the received Valid Lifetime is greater than 2 hours > > update the lifetime of the temporary address to the > > received lifetime. > > + If the RemainingLifetime of the temporary address is less > > than or equal to 2 hours ignore the received option. > > + Otherwise set the valid lifetime to 2 hours. > > C. These steps are necessary to prevent a denial of service > > attack where a bogus advertisement contains prefixes with > > very small Valid Lifetimes > > > >==> isn't this fundamentally duplication of specification from rfc2462 > >checks ? Couldn't you just specify that the lifetimes are checked as > >specified in section X.X.X.y of rfc2462 ? > > No. This check does not exist in RFC2462. It was added later in > RFC2462bis. Since 2462bis is still a draft I included it here. I can > remove it and add a reference to 2462bis if needed. But this needs to be > a normative reference. 2462bis is slated for (recycling at) DS, and is also relatively far in the process, so I don't think it would be a problem normatively referring to what that doc specifies. That is, if there are folks who would implement the RFC3041bis but not 2462bis could just look at 2462bis and take that specification from there. > > 6. The node MUST Perform duplicate address detection (DAD) on the > > generated temporary address. If DAD indicates the address is > > already in use, the node MUST generate a new randomized interface > > identifier as described in Section 3.2 above, and repeat the > > previous steps as appropriate up to 5 times. If after 5 > > consecutive attempts no non-unique address was generated, > > > >==> 5 times seems like really a strech. Couldn't we lower that down > >to, say, 3 times? That would still be sufficiently many repetitions, > >but lower the unnecessary delay and attempts significantly in case > >there are problems. > > I will make this a configuration variable and default it to 3. OK. > > When a temporary address becomes deprecated, a new one MUST be > > generated. This is done by repeating the actions described in > > Section 3.3, starting at step 3). Note that, except for the > > transient period when a temporary address is being regenerated, in > > normal operation at most one temporary address corresponding to a > > public address should be in a non-deprecated state at any given time. > > > >==> I'm flinching back at the 'corresponding' language. The > >implementation shouldn't need to keep track of public -> private > >address mappings, and if it does, this should be made more explicit. > >Instead, it may need to track prefixes, and possibly interfaces (or > >interface-identifiers). > > I will change the language to make the node track the prefixes instead > of corresponding public addresses. OK. > > If a very small number of nodes(say only one) use a given prefix for > > extended periods of time, just changing the interface identifier > > part of the prefix may not be sufficient to ensure privacy, since > > the prefix acts as a constant identifier. > > > >==> i'd rather say s/may not be/is not/, because there's nothing conditional > >(IMHO) about it. > > There is. The data collector NEEDS to know that there is only one node. > Otherwise she/he may not be able to correlate the collected data with > two different addresses. This depends on whether the data collector is interested in tracking a particular user inside the prefix, or just the prefix and whoever are using it. For example, FBI might want to correlate traffic that's originated from the particular house. They might not care that much whether it's the father or the son whose laptop is doing the talking -- it wouldn't probably even much, because the people inside the prefix might even share their computers. What the data collector NEEDS to know (or make an educated guess about) AFAICS is whether the specific set of prefixes have a small or large number of users behind them. But that kind of information can usually be gleaned from publically available information if they really want. > >10 References > > > >==> needs to be broken down to informative and normative. It's not clear > >whether this is intended for PS or DS, but if DS, normative refs must only > >include those specs which are of DS of BCP; if PS, PS is also OK. > > OK. I have made this change for the new version of the draft based > on Brian's comments. OK. > > A more interesting case concerns always-on connections (e.g., cable > > modems, ISDN, DSL, etc.) that result in a home site using the same > > address for extended periods of time. This is a scenario that is > > just starting to become common in IPv4 and promises to become more of > > a concern as always-on internet connectivity becomes widely > > available. Although it might appear that changing an address > > regularly in such environments would be desirable to lessen privacy > > concerns, it should be noted that the network prefix portion of an > > address also serves as a constant identifier. All nodes at (say) a > > home, would have the same network prefix, which identifies the > > topological location of those nodes. This has implications for > > privacy, though not at the same granularity as the concern that this > > document addresses. Specifically, all nodes within a home would be > > grouped together for the purposes of collecting information. This > > issue is difficult to address, because the routing prefix part of an > > address contains topology information and cannot contain arbitrary > > values. > > > >==> while the topic was 'Address Usage in IPv4 today', the text jumps in the > >middle to describe v6 considerations (about the prefix portion). Maybe this > >needs to go somewhere else, or at least broken down more explicitly (e.g., > >to a different paragraph). > > Not necessarily. It is still talking about IPv4 prefixes and IPv4 > addresses. I fail to see that.. homes aren't allocated a /24, /25, /26 or whatever v4 prefixes, so saying that "the network prefix portion of an address also serves as a constant identifier" seems wrong -- especially if the observer cannot know or reasonably guess where the prefix part ends and the address part begins. > > An implementation might want to keep track of which addresses are > > being used by upper layers so as to be able to remove a deprecated > > temporary address from internal data structures once no upper layer > > protocols are using it (but not before). [...] > > > >==> this issue seems to be discussed in nearly the same fashion in two > >different places in the draft. Could this just be summarized in one, and > >described in full in the other, or something? > > One of the places talks about WHEN an application is allowed to remove > deprecated addresses. The other one talks about Future Work to be done. > I don't see any elegant way of combining these two. Couldn't one just say in section 3.4 like: As an optional optimization, an implementation MAY remove a deprecated temporary address that is not in use by applications or upper-layers as outlined in section 6. .. and delete the rest ? (Note: I'm not sure whether this has been even implemented -- if not, it should be removed completely, at least from sect 3.4) > >8. Security Considerations > > > > > > Ingress filtering is being deployed as a means of preventing the use > > of spoofed source addresses in Distributed Denial of Service(DDoS) > > attacks. > > > >==> s/is being/has been/ ? > > Subjective ;-). "Has been" makes it sound like everyone has it deployed > already. I will leave it as it is unless you have strong feelings. Sufficiently fine with me right now. 'is being' just sounds as if it hasn't been deployed at all yet, and it was just recently started being deployed.. The more complex way would be to say "has been and is being".. -- 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 Oct 15 10:04:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01965 for ; Fri, 15 Oct 2004 10:04:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CISse-00088f-O1 for ipv6-web-archive@ietf.org; Fri, 15 Oct 2004 10:16:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CISYl-0005N8-Oo; Fri, 15 Oct 2004 09:55:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CISVr-0004m2-L9 for ipv6@megatron.ietf.org; Fri, 15 Oct 2004 09:52:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00370 for ; Fri, 15 Oct 2004 09:52:53 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIShF-0007lk-1P for ipv6@ietf.org; Fri, 15 Oct 2004 10:04:41 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.4468524; Fri, 15 Oct 2004 09:51:45 -0400 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <5A0F2498-1EB1-11D9-AEF2-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Fri, 15 Oct 2004 09:51:45 -0400 X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: Call for Agenda Items 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="===============0719011954==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============0719011954== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--717978918; protocol="application/pkcs7-signature" --Apple-Mail-1--717978918 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The chairs are currently drafting the agenda for the upcoming IPv6 WG meeting in D.C. Please submit any agenda requests you have at this time. Regards, Brian --Apple-Mail-1--717978918 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDE1MTM1MTQ1WjAjBgkqhkiG9w0B CQQxFgQUvpVzNzSBdkrQo25HXCxnweClrOwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAwgRPezz5kPMakffAZgVRA+w+tHyADz1WGTw2bLSVfixhePr7UADtrOWf8C6UqbctCvqF kPwg4PS9GkcwosoCigpAxRYXnDeOsEEyvDoNwS+HazCXHNyBeIsLCWtZs04BRtaPJQOjkhtgH2At o72NOZZv3J8BjGwn8nl0JHaSnxf5v8YYk2PLKv4zxd08YmhKWM9oiovEey1zrn+rmSx8W3ykkvL4 u7aw64rQU6Swizqb0lgpjjHe+NCVgHy2GVVZcvTJ6oDBcpXqgEdVIOTsQIz0HaSvL5jiZ/mgoQgW nwwTzooPTbT1eLrUNg/GAwq6vXiPrNixTYLhw10GkvZWywAAAAAAAA== --Apple-Mail-1--717978918-- --===============0719011954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0719011954==-- From ipv6-bounces@ietf.org Fri Oct 15 15:00:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29175 for ; Fri, 15 Oct 2004 15:00:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIXVN-0006ul-J0 for ipv6-web-archive@ietf.org; Fri, 15 Oct 2004 15:12:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIXGu-00056K-GM; Fri, 15 Oct 2004 14:57:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIXEx-0004q2-7M for ipv6@megatron.ietf.org; Fri, 15 Oct 2004 14:55:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28897 for ; Fri, 15 Oct 2004 14:55:41 -0400 (EDT) Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIXQ6-0006pY-36 for ipv6@ietf.org; Fri, 15 Oct 2004 15:07:32 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.135.175]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i9FIsnfd012560 for ; Fri, 15 Oct 2004 20:54:49 +0200 Received: from vies194a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i9FIsmL3031660 for ; Fri, 15 Oct 2004 20:54:48 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <4L37P0Z9>; Fri, 15 Oct 2004 20:57:14 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AC43@viee10pa.erd.siemens.at> From: Grubmair Peter To: "'Suresh Krishnan'" Date: Fri, 15 Oct 2004 20:52:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "IPV6 IETF \(E-mail\)" Subject: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, I am referring to page 14, chapter D. It suggests to remember creation time of temporary addresses and allows RAs to extend lifetimes of temporary addresses. In original RFC3041 lifetime of temporary addresses could only be lowered by RAs. No need to remember creation time. (RFC3041, p. 10, 3.3 -> 1) .. When adjusting the lifetime of an existing temporary address, only lower the lifetime.) Best regards Peter -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.ca] Sent: Freitag, 15. Oktober 2004 14:33 To: Grubmair Peter Cc: 'Pekka Savola'; IPV6 IETF (E-mail) Subject: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt Hi, I am not exactly sure what part of the draft you are referring about, but without the 2 hour lifetime rule stateless address autoconf is susceptible to a denial of service attack using fake RAs with low lifetimes. Can you give me the specifics regarding the text in the draft which you are worried about (section number, paragraph etc.)? Regards Suresh On Thu, 14 Oct 2004, Grubmair Peter wrote: >I want to state that I personally do not like the new >idea from the draft to consider total lifetimes of a >temporary address in case of some RAs renew prefixes. >(Previously lifetimes of temporary addresses could only be >lowered by RAs). >This adds additional complexity for the rather rare >event of a sites address renumbering. >Best regards > Peter > > >-------------------------------------------------------------------- >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 Oct 15 17:00:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18202 for ; Fri, 15 Oct 2004 17:00:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZN9-00048f-F9 for ipv6-web-archive@ietf.org; Fri, 15 Oct 2004 17:12:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYSs-00009m-HE; Fri, 15 Oct 2004 16:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIY6r-0002ZD-DX; Fri, 15 Oct 2004 15:51:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04141; Fri, 15 Oct 2004 15:51:27 -0400 (EDT) Message-Id: <200410151951.PAA04141@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 15 Oct 2004 15:51:27 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-06.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --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 : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, et al. Filename : draft-ietf-ipv6-link-scoped-mcast-06.txt Pages : 6 Date : 2004-10-15 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-IDs to allocate multicast addresses. When the link- local unicast address is configured at each interface of a host, an interface ID is uniquely determined. By delegating multicast addresses at the same time as the interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in serverless environments. Basically, it is preferred to use this method for the link-local scope rather than Unicast-Prefix-based IPv6 Multicast Addresses [RFC 3306]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-06.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-ipv6-link-scoped-mcast-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-15154228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-15154228.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Oct 15 19:51:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06654 for ; Fri, 15 Oct 2004 19:51:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIc32-0000rt-Fz for ipv6-web-archive@ietf.org; Fri, 15 Oct 2004 20:03:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIbq0-0006vA-Ta; Fri, 15 Oct 2004 19:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIbk5-0004ea-FM for ipv6@megatron.ietf.org; Fri, 15 Oct 2004 19:44:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05978 for ; Fri, 15 Oct 2004 19:44:09 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIbvX-0000el-Es for ipv6@ietf.org; Fri, 15 Oct 2004 19:56:04 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E17191525D; Sat, 16 Oct 2004 08:44:05 +0900 (JST) Date: Sat, 16 Oct 2004 08:44:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Thomas Narten , ipv6@ietf.org Subject: Re: AD Review of draft-ietf-ipv6-rfc2462bis-06.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Hello, Sorry about the long delay. I'll first comment on the two major points. >>>>> On Wed, 6 Oct 2004 09:05:53 -0400, >>>>> Margaret Wasserman said: > I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have > several comments on this document that I believe should be resolved > before this document is sent to IETF Last Call for publication as a > Draft Standard. > All of my comments are included below, but my most serious concerns are: > (1) Having decided that "the stateful configuration" mechanism is > DHCPv6, I don't think that there is a reason to maintain the awkward > and confusing wording about "the stateful mechanism" in many places. > I've pointed out the worst cases, but there are many others. I know > that this is largely an editorial concern, but the awkwardness and > lack of clarity are bad enough in some places (see below) that I > consider this a blocking problem for publication at DS. I actually wanted to remove the word "stateful" for clarity. But this would also require changes to more normative statements in rfc2461bis. For example, RFC2461 hardcodes the term "stateful" for the 'O' flag of RA: O 1-bit "Other stateful configuration" flag. When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information. The use of this flag is described in [ADDRCONF]. If we remove "stateful" from rfc2462bis, I think we'd also need to change the name of the bit in rfc2461bis accordingly. Otherwise, the result would rather be more confusing. So I asked the wg whether - we should clean up all the occurrences of "stateful" and replace them with "DHCPv6" in rfc2461bis and rfc2462bis, or - we should keep the wording but clarify what "stateful" actually means (and clarify the possible confusion RFC3736 is also called "stateless" while it's a part of DHCPv6) See the following message and the succeding thread for more details: http://www1.ietf.org/mail-archive/web/ipv6/current/msg02597.html Unfortunately, I didn't see many responses to the question, so I decided to take the second action, considering the "conservative" nature of the 2462bis work. But if we, as a wg, can agree on the first choice, which includes modifications to rfc2461bis, I'm willing to make that change. (I'd object to just changing 2462bis with keeping the current wording in 2461bis. That would just introduce further confusion.) > (2) I am not comfortable with the idea that we would punt the > interpretation of the M & O bits to a "separate document" with no > reference. I believe that information about how to interpret these > bits is essential to implementing IPv6 address autoconfiguration. > See below for the specific text that concerns me. Please let me check: regarding the M/O flags, we basically introduced the following two changes from RFC2462: 1. remove some "mandatory" wording on these flags and clarify that these flags are just hints of availability of the corresponding services (DHCPv6). 2. leave more details to other document(s) And, I believe how to "interpret" these bits is very clear with change 1. In fact, the "mandatory" nature of these flags in RFC2462 has been confusing people, and I believe the change in rfc2462bis makes the interpretation much clearer. Actually, the course of this change was based on a pretty clear consensus in the wg. See, for example, the following messages and succeeding threads: http://www1.ietf.org/mail-archive/web/ipv6/current/msg02512.html http://www1.ietf.org/mail-archive/web/ipv6/current/msg02513.html So, I interpret your main concern is about mentioning other document(s) without a concrete reference. Is this correct? If so, there is an ongoing work in this area, although it's still an individual document: draft-daniel-ipv6-ra-mo-flags-00.txt. (A new revision of this document will be submitted before the coming IETF meeting). With this ongoing work, I can think of the following three choices: 1. simply remove the "other document". As I said above, the "interpretation" of these flags should already be pretty clear. And removing the "other document" solves the dangling reference issue. 2. assuming the above ongoing work or a different (non existing) document is adopted as a wg document, refer to it as an *informative* reference. At the moment, we only have an individual I-D, but even a wg I-D cannot be a normative reference in a draft standard. Also, based on our consensus the separate document will be published as a BCP. I'm not sure if a DS can safely have a normative reference to a BCP regarding the reference dependency issue (the rule is too complicated and it is very hard to find an appropriate document!). BTW: in this sense, we can even not refer to the DHCPv6 RFCs as normative references, since those are still PS. I don't have a particular preference between these two, but if none of them is acceptable, I can't imagine how we can proceed. Please let me know what you think. 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 Sat Oct 16 12:21:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00522 for ; Sat, 16 Oct 2004 12:21:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIrV1-0000ux-Ik for ipv6-web-archive@ietf.org; Sat, 16 Oct 2004 12:33:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIrFE-00059H-9T; Sat, 16 Oct 2004 12:17:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIrBq-0003bk-Rj for ipv6@megatron.ietf.org; Sat, 16 Oct 2004 12:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29903 for ; Sat, 16 Oct 2004 12:13:51 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIrNS-0000j6-7S for ipv6@ietf.org; Sat, 16 Oct 2004 12:25:54 -0400 Received: from [24.61.30.237] (account margaret HELO [192.168.1.103]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 174686; Sat, 16 Oct 2004 12:08:38 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Sat, 16 Oct 2004 12:13:46 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Thomas Narten , ipv6@ietf.org Subject: Re: AD Review of draft-ietf-ipv6-rfc2462bis-06.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Hi Jinmei, Thanks for the response! >If we remove "stateful" from rfc2462bis, I think we'd also need to >change the name of the bit in rfc2461bis accordingly. Otherwise, the >result would rather be more confusing. So I asked the wg whether > >- we should clean up all the occurrences of "stateful" and replace > them with "DHCPv6" in rfc2461bis and rfc2462bis, or >- we should keep the wording but clarify what "stateful" actually > means (and clarify the possible confusion RFC3736 is also called > "stateless" while it's a part of DHCPv6) I agree that we would need to make some similar changes to RFC 2461bis, but I don't see that as a huge change. It could read something like: O 1-bit "Other DHCPv6 configuration" flag. When set, hosts use DHCP to configure other (non-address) information. The use of this flag is described in [ADDRCONF]. The bigger problem is that the use of this flag is not described in the new version of ADDRCONF, so 2461bis will need a normative reference to the new document that does describe the use of these flags (unless we put it back here). There is, of course, also a big ambiguity here about whether this flag indicates that hosts MUST, SHOULD or MAY use DHCPv6 to configure other information. As you indicated below, we've known about, and struggled with, that ambiguity for a while, so I hope it will be resolved in RFC 2461bis or 2462bis. >> (2) I am not comfortable with the idea that we would punt the >> interpretation of the M & O bits to a "separate document" with no >> reference. I believe that information about how to interpret these >> bits is essential to implementing IPv6 address autoconfiguration. >> See below for the specific text that concerns me. > >Please let me check: regarding the M/O flags, we basically introduced >the following two changes from RFC2462: > >1. remove some "mandatory" wording on these flags and clarify that > these flags are just hints of availability of the corresponding > services (DHCPv6). >2. leave more details to other document(s) > >So, I interpret your main concern is about mentioning other >document(s) without a concrete reference. Is this correct? Yes, but maybe not quite in the way you think. RFC 2461bis and RFC2462bis are closely related documents that I think should probably go forward together on a single ballot (as I said elsewhere in my message). By moving the description of the M&O bits to another document, you aren't really simplifying anything (IMO), you are merely creating a third document that is essential to understanding these two. It also presents some problems, because the document is not complete yet and will have to start out at PS before moving to DS, which may block the publication of 2461bis and 2462bis at DS. There is really a basic question here: Are we _changing_ how the M&O bits are interpreted, or are we merely clarifying how they are interpreted? If we are merely clarifying, then I think we should do it here and keep the documents at DS. If we are changing it, I think we need to figure out how to handle this so that neither 2461bis nor 2462bis needs to have a normative reference to the new document. To accomplish this, we would need to say enough (or perhaps little enough) in these documents that readers can completely implement address autoconfiguration and ND without knowing anything about the meaning of those bits. This may be possible, if they are truly ignored in deciding how/if to perform ND, DAD, address autoconfiguration, etc. But, that isn't currently clear in the documents. >1. simply remove the "other document". As I said above, the > "interpretation" of these flags should already be pretty clear. > And removing the "other document" solves the dangling reference > issue. I could accept this if you make it very clear what hosts that implement rfc2461bis and rfc2462bis are supposed to do when these bits are set. >2. assuming the above ongoing work or a different (non existing) > document is adopted as a wg document, refer to it as an > *informative* reference. At the moment, we only have an individual > I-D, but even a wg I-D cannot be a normative reference in a draft > standard. Also, based on our consensus the separate document will > be published as a BCP. I'm not sure if a DS can safely have a > normative reference to a BCP regarding the reference dependency > issue (the rule is too complicated and it is very hard to find an > appropriate document!). BTW: in this sense, we can even not refer > to the DHCPv6 RFCs as normative references, since those are still > PS. As I'm sure you know, we can't just declare a reference informative because the referenced document isn't at a state that would allow this document to be published at DS. IMO, it is quite clear that one can implement ND and addrconf without implementing DHCPv6, so it is fine for DHCPv6 to be an informative reference. We either need to make sure that the M&O bits can be handle the same way (ignore them in implementations of ND and autoconf, worry about them only if you implement DHCPv6), or we need to explain them appropriately here. Either one works, but a hanging textual reference to an as-yet-unpublished document doesn't. I don't think we have any fundamental disagreements here, we just need to figure out how to get this right before we send it to IETF LC. Thanks for all of your work on this document -- you are doing a very good job and this is important work! Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 17 00:05:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03048 for ; Sun, 17 Oct 2004 00:05:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2Tn-0002mH-BP for ipv6-web-archive@ietf.org; Sun, 17 Oct 2004 00:17:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2FU-00083y-9e; Sun, 17 Oct 2004 00:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2EF-0007gN-DW for ipv6@megatron.ietf.org; Sun, 17 Oct 2004 00:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02660 for ; Sun, 17 Oct 2004 00:01:03 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2Pw-0002iL-TB for ipv6@ietf.org; Sun, 17 Oct 2004 00:13:13 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 4E2176B8 for ; Sun, 17 Oct 2004 00:00:32 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 17 Oct 2004 00:00:32 -0400 Message-Id: <20041017040032.4E2176B8@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.50% | 3 | 24.69% | 48807 | pekkas@netcore.fi 12.50% | 3 | 17.00% | 33597 | suresh.krishnan@ericsson.ca 12.50% | 3 | 14.45% | 28566 | humphrey.gu@nfs.com.cn 8.33% | 2 | 8.08% | 15965 | brian@innovationslab.net 8.33% | 2 | 7.92% | 15664 | margaret@thingmagic.com 8.33% | 2 | 6.14% | 12137 | internet-drafts@ietf.org 8.33% | 2 | 5.99% | 11838 | jinmei@isl.rdc.toshiba.co.jp 8.33% | 2 | 4.11% | 8117 | peter.grubmair@siemens.com 4.17% | 1 | 3.72% | 7350 | shawn.routhier@windriver.com 4.17% | 1 | 2.40% | 4740 | john.loughney@nokia.com 4.17% | 1 | 1.93% | 3812 | mohsen.souissi@nic.fr 4.17% | 1 | 1.88% | 3721 | sra+ipng@hactrn.net 4.17% | 1 | 1.70% | 3356 | doo090@yahoo.ie --------+------+--------+----------+------------------------ 100.00% | 24 |100.00% | 197670 | 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 Oct 17 00:35:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04883 for ; Sun, 17 Oct 2004 00:35:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2wr-0003GG-Rk for ipv6-web-archive@ietf.org; Sun, 17 Oct 2004 00:47:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2hj-0006mb-4H; Sun, 17 Oct 2004 00:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2dh-0006AB-QK for ipv6@megatron.ietf.org; Sun, 17 Oct 2004 00:27:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04373 for ; Sun, 17 Oct 2004 00:27:22 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2pQ-00038Y-0h for ipv6@ietf.org; Sun, 17 Oct 2004 00:39:32 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9H4Qrbj003510; Sat, 16 Oct 2004 23:26:54 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47VZ5NAD>; Sat, 16 Oct 2004 23:26:50 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L0099HR; Sun, 17 Oct 2004 00:26:48 -0400 Date: Sun, 17 Oct 2004 00:21:18 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Grubmair Peter In-Reply-To: <4D50D5110555D5119F270800062B41650532AC43@viee10pa.erd.siemens.at> Message-ID: <21A5F45EFF209A44B3057E35CE1FE6E4035BFAEE-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "'Suresh Krishnan'" , "IPV6 IETF \(E-mail\)" Subject: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Hi Peter, Remembering the creation time is not mandatory. It is just one way of satisfying the constraints. The node can use any other means if it so desires. If you are worried about renumbering issues you can set a lower value for TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME. An RA extending the lifetimes of a temporary address can NEVER extend it past the values you set in these variables. i.e. These values serve as a ceiling for the lifetimes of a temporary address. Would that address your renumbering issues? Thanks Suresh On Fri, 15 Oct 2004, Grubmair Peter wrote: >Hi, >I am referring to page 14, chapter D. >It suggests to remember creation time of temporary addresses >and allows RAs to extend lifetimes of temporary addresses. > >In original RFC3041 lifetime of temporary addresses could >only be lowered by RAs. No need to remember creation time. >(RFC3041, p. 10, 3.3 -> 1) .. When adjusting the lifetime of > an existing temporary address, only lower the lifetime.) >Best regards > Peter > >-----Original Message----- >From: Suresh Krishnan [ mailto:suresh.krishnan@ericsson.ca > ] >Sent: Freitag, 15. Oktober 2004 14:33 >To: Grubmair Peter >Cc: 'Pekka Savola'; IPV6 IETF (E-mail) >Subject: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt > > >Hi, > I am not exactly sure what part of the draft you are referring about, >but without the 2 hour lifetime rule stateless address autoconf is >susceptible to a denial of service attack using fake RAs with low >lifetimes. Can you give me the specifics regarding the text in the draft > >which you are worried about (section number, paragraph etc.)? > >Regards >Suresh > >On Thu, 14 Oct 2004, >Grubmair Peter wrote: > >>I want to state that I personally do not like the new >>idea from the draft to consider total lifetimes of a >>temporary address in case of some RAs renew prefixes. >>(Previously lifetimes of temporary addresses could only be >>lowered by RAs). >>This adds additional complexity for the rather rare >>event of a sites address renumbering. >>Best regards >> Peter >> >> >>-------------------------------------------------------------------- >>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 Mon Oct 18 13:59:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06872 for ; Mon, 18 Oct 2004 13:59:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbz4-0005nV-Ea for ipv6-web-archive@ietf.org; Mon, 18 Oct 2004 14:11:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJb3U-0001OQ-Mh; Mon, 18 Oct 2004 13:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJamu-0007qB-Md for ipv6@megatron.ietf.org; Mon, 18 Oct 2004 12:55:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01525 for ; Mon, 18 Oct 2004 12:54:50 -0400 (EDT) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm2.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJayZ-0004Ly-J5 for ipv6@ietf.org; Mon, 18 Oct 2004 13:07:19 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id i9IGshMB017109 for ; Mon, 18 Oct 2004 12:54:44 -0400 (EDT) Message-ID: <4173F553.9050404@alcatel.com> Date: Mon, 18 Oct 2004 12:54:43 -0400 From: Hansen Chan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipv6@ietf.org References: <40BC8EA7.50902@alcatel.fr> In-Reply-To: <40BC8EA7.50902@alcatel.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: DHCPv6 Server 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hello all, Don't know whether this is the right mailing list to pose this question. I am looking for commercial DHCPv6 server. Can someone recommend some names to me? Thanks, Hansen > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 18 21:47:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16915 for ; Mon, 18 Oct 2004 21:47:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJjIb-0007or-AD for ipv6-web-archive@ietf.org; Mon, 18 Oct 2004 22:00:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJijr-0007J7-MD; Mon, 18 Oct 2004 21:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJiVm-0004BK-TE for ipv6@megatron.ietf.org; Mon, 18 Oct 2004 21:10:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13631 for ; Mon, 18 Oct 2004 21:09:56 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJihl-0006q4-5d for ipv6@ietf.org; Mon, 18 Oct 2004 21:22:28 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9J19Hbj028960; Mon, 18 Oct 2004 20:09:17 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47V5BDH6>; Mon, 18 Oct 2004 20:09:11 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L000L4T; Mon, 18 Oct 2004 21:09:12 -0400 Date: Mon, 18 Oct 2004 21:03:37 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Hansen Chan In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD401@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org Subject: Re: DHCPv6 Server X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Hansen, I remember seeing two of them. One is from HP and is included in HP-UX 11i v1. The other one is from NEC. There is also an open source implementation at http://dhcpv6.sourceforge.net Regards Suresh On Mon, 18 Oct 2004, Hansen Chan wrote: >Hello all, > >Don't know whether this is the right mailing list to pose this question. >I am looking for commercial DHCPv6 server. Can someone recommend some >names to me? > >Thanks, >Hansen > >> > > >-------------------------------------------------------------------- >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 Oct 19 01:30:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04092 for ; Tue, 19 Oct 2004 01:30:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJmlh-0003pT-MW for ipv6-web-archive@ietf.org; Tue, 19 Oct 2004 01:42:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJlts-0007gC-27; Tue, 19 Oct 2004 00:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJlbQ-0003sm-FB for ipv6@megatron.ietf.org; Tue, 19 Oct 2004 00:28:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29108 for ; Tue, 19 Oct 2004 00:27:52 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJlnO-0002XJ-GS for ipv6@ietf.org; Tue, 19 Oct 2004 00:40:27 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5T00E6SDPLRD@mailout3.samsung.com> for ipv6@ietf.org; Tue, 19 Oct 2004 13:27:21 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5T005LRDNOAC@mailout3.samsung.com> for ipv6@ietf.org; Tue, 19 Oct 2004 13:26:12 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I5T001U2DNMBF@mmp1.samsung.com> for ipv6@ietf.org; Tue, 19 Oct 2004 13:26:12 +0900 (KST) Date: Tue, 19 Oct 2004 09:54:35 +0530 From: "O.L.N. Rao" To: Hansen Chan Message-id: <009101c4b593$8ba9fd90$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: DHCPv6 Server 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7BIT Hi Hansen, And, NEC's DHCPv6 Relay Agent is open under GPL at http://dhcpv6.ccrle.nec.de/downloads.htm However, NEC's DHCPv6 Client and Server are not open. Regards, O. L. N. Rao ----- Original Message ----- From: "Suresh Krishnan" To: "Hansen Chan" Cc: Sent: Tuesday, October 19, 2004 6:33 AM Subject: Re: DHCPv6 Server > Hi Hansen, > I remember seeing two of them. One is from HP and is included in HP-UX > 11i v1. The other one is from NEC. There is also an open source > implementation at http://dhcpv6.sourceforge.net > > Regards > Suresh > > On Mon, 18 Oct 2004, Hansen Chan wrote: > >>Hello all, >> >>Don't know whether this is the right mailing list to pose this question. >>I am looking for commercial DHCPv6 server. Can someone recommend some >>names to me? >> >>Thanks, >>Hansen >> >>> >> >> >>-------------------------------------------------------------------- >>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 Oct 19 03:29:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25968 for ; Tue, 19 Oct 2004 03:29:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJode-00064J-8o for ipv6-web-archive@ietf.org; Tue, 19 Oct 2004 03:42:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJnos-0000yd-L9; Tue, 19 Oct 2004 02:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJnRB-0004d1-5G for ipv6@megatron.ietf.org; Tue, 19 Oct 2004 02:25:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22547 for ; Tue, 19 Oct 2004 02:25:25 -0400 (EDT) Received: from mail.nttv6.net ([192.68.245.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJnd6-0004yf-2l for ipv6@ietf.org; Tue, 19 Oct 2004 02:37:59 -0400 Received: from [10.0.22.187] ([192.16.178.225]) by mail.nttv6.net (8.13.1/3.7Wpl2-00020918) with ESMTP id i9J6MkZu019064 for ; Tue, 19 Oct 2004 15:22:46 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ipv6@ietf.org From: Arifumi Matsumoto Date: Tue, 19 Oct 2004 15:25:23 +0900 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: New Draft on Source Address Selection Posted 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi, all. I posted the following e-mail to multi6-wg a few days ago. But I guess many of people in this wg also should have interests in it. So let me cross-post it to here. I submitted 3 new I-Ds about Source Address Selection issue. These will appear on ietf web site soon. The first one is a brief overview of our proposed model. In short, in our model, ISPs provide Source Address Selection Policies as well as Prefix Delegation Info by DHCP. The consumer edge router receives those policies (from multiple ISPs) and re-distribute them to end nodes. End nodes put them into policy table, which leads to appropriate source address selection. http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist -00.txt The second and third draft are new option proposals for Neighbor Discovery Router Advertisement Message and DHCPv6. Though I think these drafts should be posted to other WG, such as IPv6 and DHC, these drafts have close relationship with site-multihoming, so I posted here first. http://www.nttv6.net/~arifumi/draft-arifumi-ipv6-nd-source-address- selection-opt-00.txt http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address- selection-opt-00.txt IMHO, the second one, namely an extension to RA, has close relationship with draft-ietf-ipv6-router-selection-06.txt, these two are essentially targeted for different issues though. Questions and comments are welcome. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 20 01:46:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02138 for ; Wed, 20 Oct 2004 01:46:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK9Uy-00084O-EZ for ipv6-web-archive@ietf.org; Wed, 20 Oct 2004 01:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK6Cs-0005T0-8l; Tue, 19 Oct 2004 22:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4IY-0006mi-U6 for ipv6@megatron.ietf.org; Tue, 19 Oct 2004 20:25:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06714 for ; Tue, 19 Oct 2004 20:25:44 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK4Uk-0000YU-MH for ipv6@ietf.org; Tue, 19 Oct 2004 20:38:28 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 08F861535F; Wed, 20 Oct 2004 09:25:35 +0900 (JST) Date: Wed, 20 Oct 2004 09:25:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Thomas Narten , ipv6@ietf.org Subject: Re: AD Review of draft-ietf-ipv6-rfc2462bis-06.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 >>>>> On Sat, 16 Oct 2004 12:13:46 -0400, >>>>> Margaret Wasserman said: >>> (2) I am not comfortable with the idea that we would punt the >>> interpretation of the M & O bits to a "separate document" with no >>> reference. [...] > Yes, but maybe not quite in the way you think. RFC 2461bis and > RFC2462bis are closely related documents that I think should probably > go forward together on a single ballot (as I said elsewhere in my > message). By moving the description of the M&O bits to another > document, you aren't really simplifying anything (IMO), you are > merely creating a third document that is essential to understanding > these two. It also presents some problems, because the document is > not complete yet and will have to start out at PS before moving to > DS, which may block the publication of 2461bis and 2462bis at DS. > There is really a basic question here: > Are we _changing_ how the M&O bits are interpreted, or are we merely > clarifying how they are interpreted? > If we are merely clarifying, then I think we should do it here and > keep the documents at DS. > If we are changing it, I think we need to figure out how to handle > this so that neither 2461bis nor 2462bis needs to have a normative > reference to the new document. To accomplish this, we would need to > say enough (or perhaps little enough) in these documents that readers > can completely implement address autoconfiguration and ND without > knowing anything about the meaning of those bits. This may be > possible, if they are truly ignored in deciding how/if to perform ND, > DAD, address autoconfiguration, etc. But, that isn't currently clear > in the documents. Okay, I think I understand your point, thanks for the detailed explanation. I think many other comments from depend on this issue, so I'll concentrate on this one at the moment. Regarding your basic question, it probably depends on the meaning of "change/clarify". But we are at least going to *change* some part of the specification that was described in RFC2462. To explain the background motivation of the *change*, I'd refer to a past message in this ML from Christian Huitema: >>>>> On Sat, 24 Apr 2004 22:08:28 -0700, >>>>> "Christian Huitema" said: > The normal IETF practice is that when a document progresses from PS > do DS and then to standard, parts of the specification that are not > actually present in implementations get removed from the spec. As > much as I can tell, we don't have much actual implementation of the > M/O bits. If we follow the logic of the process, we should remove > the corresponding sections from the spec. (Or see http://www1.ietf.org/mail-archive/web/ipv6/current/msg02372.html to get the entire message with the context of the discussion) In the actual discussion, this was just an intermediate post, and we did not actually "remove" the corresponding sections for the M/O flags altogether. But I believe our consensus in this discussion was that we'd need more time to bake the precise behavior for the M/O flags and that the status of the specific action had not reached the level of a DS. That's why we decided to leave the specific behavior to a separate document. I'd first like to know whether the decision so far is acceptable. If this is acceptable, the "resolution" for this issue is to make rfc2462bis (and perhaps 2461bis) less confusing (if it currently is) on the status of the M/O flags. I personally do not think it is that confusing to say like: "The details of how a host may use the M flag, [...] will be described in a separate document" (rfc24622bis-06, Section 4). In fact, when RFC2462 became a DS, we even did not have a (standardized) specific "stateful protocol", but we could still say in the RFC that "the details of autoconfiguration using the stateful protocol are specified elsewhere." (abstract of RFC2462) A possible approach that may help is to clarify why we decided to leave the specific usage to a separate document, explaining the current maturity of the M/O flags, without referring to a particular document. This is my first (and preferred) proposal. If this is not enough, we'd need to refer to the "separate document". In this case, we seriously have to consider the reference category as you pointed out. But I personally think we can refer to it (whatever it is) as an Informational reference, considering the current maturity. I also believe we'll then have to wait for at least one wg document for this (since individual documents are so fragile even as an informational reference). Thus, my second proposal is to wait for a wg document and to refer to it as an informational reference. (This is the "second" proposal because I *personally* believe we can safely explain the current situation without specifying a concrete reference and also because even wg I-Ds are still often subject to change.) Again, I'd like to know whether the background motivation is acceptable, and if it is, whether one of the above proposals can be a resolution for the issue. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 20 04:30:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10326 for ; Wed, 20 Oct 2004 04:30:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKC3v-0002eg-Vt for ipv6-web-archive@ietf.org; Wed, 20 Oct 2004 04:43:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9Lr-00056f-QZ; Wed, 20 Oct 2004 01:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK7nE-0001cY-Ld for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 00:09:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24535 for ; Wed, 20 Oct 2004 00:09:36 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK7zT-0005pD-7J for ipv6@ietf.org; Wed, 20 Oct 2004 00:22:24 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9K495bj029034; Tue, 19 Oct 2004 23:09:06 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47V5GV6C>; Tue, 19 Oct 2004 23:08:58 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L000W28; Wed, 20 Oct 2004 00:09:04 -0400 Date: Wed, 20 Oct 2004 00:03:27 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Pekka Savola In-Reply-To: Message-ID: <21A5F45EFF209A44B3057E35CE1FE6E4038FE481-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi Pekka, I am proposing the following changes to resolve the issues that you raised. * I have made all the changes we both agreed on. * I have added the following problem statement "Addresses generated using Stateless address autoconfiguration [ADDRCONF]contain an embedded 64-bit interface identifier, which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. The correlation can be performed by o An attacker who is in the path between the node in question and the peer(s) it is communicating to, and can view the IPv6 addresses present in the datagrams. o An attacker who can access the communication logs of the peers with which the node has communicated. Since the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. This document proposes a solution to this issue by generating interface identifiers which vary over time." * I have added the following text to the background section 2.1 "Although it might appear that changing an address regularly in such environments would be desirable to lessen privacy concerns, it should be noted that the network prefix portion of an address also serves as a constant identifier. All nodes at (say) a home, would have the same network prefix, which identifies the topological location of those nodes. This has implications for privacy, though not at the same granularity as the concern that this document addresses. Specifically, all nodes within a home could be grouped together for the purposes of collecting information. If the network contains a very small number of nodes, say just one, changing just the interface identifier will not enhance privacy at all, since the prefix serves as a constant identifier." * Added an informative reference to the dnsop issues draft. * I hope the problem statement above justifies the use of privacy addresses for ULAs * Added the following text specifying the conditions for DHCPv6 to be used for privacy "One way to avoid some of the problems discussed above is to use DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be configured to hand out addresses that change over time. But DHCPv6 will solve the privacy issue only if it frequently handed out constantly changing addresses to the nodes. Since this does not happen automatically, and is difficult to configure manually, DHCPv6 is not really suited for solving the privacy issues addressed by this document." * Removed the text about processing router advertisements and added a normative reference to rfc2462bis * Removed the v6 specific text in "Address Usage in IPv4 today" Let me know if these changes address your concerns. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 20 06:46:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19995 for ; Wed, 20 Oct 2004 06:46:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKEBU-0005T1-KE for ipv6-web-archive@ietf.org; Wed, 20 Oct 2004 06:59:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKCk0-0003ai-3f; Wed, 20 Oct 2004 05:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKApU-0004oT-D3 for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 03:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07408 for ; Wed, 20 Oct 2004 03:24:09 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKB1k-0001Vh-Ns for ipv6@ietf.org; Wed, 20 Oct 2004 03:36:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9K7NZv05609; Wed, 20 Oct 2004 10:23:35 +0300 Date: Wed, 20 Oct 2004 10:23:35 +0300 (EEST) From: Pekka Savola To: Suresh Krishnan In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E4038FE481-100000@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 On Wed, 20 Oct 2004, Suresh Krishnan wrote: > "Addresses generated using Stateless address autoconfiguration > [ADDRCONF]contain an embedded 64-bit interface identifier, which > remains constant over time. Anytime a fixed identifier is used in > multiple contexts, it becomes possible to correlate seemingly > unrelated activity using this identifier. > > The correlation can be performed by > o An attacker who is in the path between the node in question and > the peer(s) it is communicating to, and can view the IPv6 > addresses present in the datagrams. > o An attacker who can access the communication logs of the peers > with which the node has communicated. In other words, this extension is not only aimed at protecting the privacy the outside observers (like the nodes you're communicating with), but also those who are able to perform on-the-path privacy violations (ISPs, FBI/NSA intercepting the packets, etc.). Has the protection from your ISPs and federal agencies etc. really been the requirement/goal from the start? I'd like to observe that anyone who will be able to do on-the-path analysis will be able to jeopardize the privacy of the user typically in any case. While I think privacy is pretty important, I fear that this mechanism is insufficient to provide privacy to the users if we're concerned about on-path analysis, and I'd be hesitant to include it in the problem statement without warnings. I'm interested if others have comments on this. > * I hope the problem statement above justifies the use of privacy > addresses for ULAs I'm not so sure: so, you'd assume that the evil enterprise administrator would be eavesdropping and correlating enterprise's internal traffic, or the enterprise's internal web servers would be correlating the behaviour? As far as I can see, it's exactly the opposite -- privacy extensions should not be enabled by default for ULAs. > * Added the following text specifying the conditions for DHCPv6 to be used > for privacy > > "One way to avoid some of the problems discussed above is to use > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be > configured to hand out addresses that change over time. But DHCPv6 > will solve the privacy issue only if it frequently handed out > constantly changing addresses to the nodes. Since this does not > happen automatically, and is difficult to configure manually, DHCPv6 > is not really suited for solving the privacy issues addressed by this > document." This doesn't mention that DHCPv6 can hand out the temporary addresses, but that there is little benefit to do so compared to just doing RFC3041 (unless the site has disabled stateless address autoconf complately), but this is good enough for me now. -- 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 Oct 20 10:34:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09715 for ; Wed, 20 Oct 2004 10:34:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHkD-0001wd-St for ipv6-web-archive@ietf.org; Wed, 20 Oct 2004 10:47:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGXy-0003X4-MB; Wed, 20 Oct 2004 09:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFnw-0000Qd-Oe for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 08:43:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28321 for ; Wed, 20 Oct 2004 08:42:53 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG0F-0007vy-J9 for ipv6@ietf.org; Wed, 20 Oct 2004 08:55:45 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9KCgMbj000932; Wed, 20 Oct 2004 07:42:22 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47V52J83>; Wed, 20 Oct 2004 07:42:15 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L000YKX; Wed, 20 Oct 2004 08:42:18 -0400 Date: Wed, 20 Oct 2004 08:36:40 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Pekka Savola In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Hi Pekka, Thanks for the quick review. See comments inline Regards Suresh On Wed, 20 Oct 2004, Pekka Savola wrote: >On Wed, 20 Oct 2004, Suresh Krishnan wrote: >> "Addresses generated using Stateless address autoconfiguration >> [ADDRCONF]contain an embedded 64-bit interface identifier, which >> remains constant over time. Anytime a fixed identifier is used in >> multiple contexts, it becomes possible to correlate seemingly >> unrelated activity using this identifier. >> >> The correlation can be performed by >> o An attacker who is in the path between the node in question and >> the peer(s) it is communicating to, and can view the IPv6 >> addresses present in the datagrams. >> o An attacker who can access the communication logs of the peers >> with which the node has communicated. > >In other words, this extension is not only aimed at protecting the >privacy the outside observers (like the nodes you're communicating >with), but also those who are able to perform on-the-path privacy >violations (ISPs, FBI/NSA intercepting the packets, etc.). Yes. > >Has the protection from your ISPs and federal agencies etc. really >been the requirement/goal from the start? On-path does not have to be FBI/NSA or ISPs. It can be anyone on an upstream network (even in the same organization as the user). I would assume if the FBI/NSA or the ISPs wanted to intercept they could do so at the layer 2 connection to the provider. Do you want me to add a statement about lawful intercept still being possible? > >I'd like to observe that anyone who will be able to do on-the-path >analysis will be able to jeopardize the privacy of the user typically >in any case. While I think privacy is pretty important, I fear that >this mechanism is insufficient to provide privacy to the users if >we're concerned about on-path analysis, and I'd be hesitant to include >it in the problem statement without warnings. > >I'm interested if others have comments on this. > >> * I hope the problem statement above justifies the use of privacy >> addresses for ULAs > >I'm not so sure: so, you'd assume that the evil enterprise >administrator would be eavesdropping and correlating enterprise's >internal traffic, or the enterprise's internal web servers would be >correlating the behaviour? > >As far as I can see, it's exactly the opposite -- privacy extensions >should not be enabled by default for ULAs. This is already the case. Privacy extensions are disabled by default for ALL types of global addresses (including the ULA). > >> * Added the following text specifying the conditions for DHCPv6 to be used >> for privacy >> >> "One way to avoid some of the problems discussed above is to use >> DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be >> configured to hand out addresses that change over time. But DHCPv6 >> will solve the privacy issue only if it frequently handed out >> constantly changing addresses to the nodes. Since this does not >> happen automatically, and is difficult to configure manually, DHCPv6 >> is not really suited for solving the privacy issues addressed by this >> document." > >This doesn't mention that DHCPv6 can hand out the temporary addresses, >but that there is little benefit to do so compared to just doing >RFC3041 (unless the site has disabled stateless address autoconf >complately), but this is good enough for me now. OK. That was the reason I left it out. I will leave it as is. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 20 11:33:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14900 for ; Wed, 20 Oct 2004 11:33:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIfH-00038y-Ak for ipv6-web-archive@ietf.org; Wed, 20 Oct 2004 11:46:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHkZ-0001dD-1q; Wed, 20 Oct 2004 10:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKH7D-0004ZO-ET for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 10:06:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04790 for ; Wed, 20 Oct 2004 10:06:50 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHJV-0001Fo-G7 for ipv6@ietf.org; Wed, 20 Oct 2004 10:19:42 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2004 07:16:29 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KE6Bk2003366 for ; Wed, 20 Oct 2004 07:06:15 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-460.cisco.com [10.21.97.204]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMK66235; Wed, 20 Oct 2004 10:06:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20041020083747.01f47e10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Oct 2004 10:06:08 -0400 To: ipv6@ietf.org From: Ralph Droms In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E4038FE481-100000@eammlex037 .lmc.ericsson.se> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 I disagree with the wording of this section regarding the use of DHCPv6 for privacy addresses: At 12:03 AM 10/20/2004 -0400, Suresh Krishnan wrote: >* Added the following text specifying the conditions for DHCPv6 to be used >for privacy > > "One way to avoid some of the problems discussed above is to use > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be > configured to hand out addresses that change over time. But DHCPv6 > will solve the privacy issue only if it frequently handed out > constantly changing addresses to the nodes. Since this does not > happen automatically, and is difficult to configure manually, DHCPv6 > is not really suited for solving the privacy issues addressed by this > document." DHCPv6 includes mechanisms for assignment and management of "temporary addresses" (see section 12 of RFC 3315). The frequency of reassignment for temporary addresses can be as often as desired, and is independent of the lifetimes for non-temporary addresses. "difficult to configure manually" is an entirely subjective assessment, and is dependent on the specific implementation rather than the protocol itself. Therefore, I think the text should be edited to read: One way to avoid some of the problems discussed above is to use DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 discusses the use of DHCPv6 for the assignment and management of "temporary addresses" (privacy addresses). Temporary addresses are managed separately from non-temporary addresses, so a host can differentiate between the two types of addresses. The lifetimes of temporary addresses are independent of the lifetimes of any other addresses, so the frequency of replacement for temporary addresses can be adjusted as required. I wonder if section 2.2 is required at all? I don't think experience with IPv4 addressing has much bearing on IPv6. For example, a device gets an entirely new IPv4 address when it moves to a new connection point, so tracking that device as it moves between connection points is hard. If section 2.2 is retained, some of the details should be corrected. Finally, at the risk of nit-picking, I wonder if the phrase "without the necessity of a Dynamic Host Configuration Protocol (DHCP) server" is really necessary? Is the sole purpose of stateless address autoconfiguration to avoid the menace of DHCP, or does stateless address autoconfiguration avoid manual configuration, as well? How about "Nodes use IPv6 stateless address autoconfiguration generate addresses using a combination of locally available information and information advertised by routers." (borrowed from RFC 2462)? - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 20 11:35:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15093 for ; Wed, 20 Oct 2004 11:35:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIgx-0003BB-5n for ipv6-web-archive@ietf.org; Wed, 20 Oct 2004 11:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHkY-0001d6-2D; Wed, 20 Oct 2004 10:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKH67-00044d-G1 for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 10:05:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04671 for ; Wed, 20 Oct 2004 10:05:43 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHIR-0001EG-Er for ipv6@ietf.org; Wed, 20 Oct 2004 10:18:36 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KE5BxD102054; Wed, 20 Oct 2004 14:05:11 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KE5AkJ170846; Wed, 20 Oct 2004 16:05:10 +0200 Received: from zurich.ibm.com (sig-9-145-128-178.de.ibm.com [9.145.128.178]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA85786; Wed, 20 Oct 2004 16:05:08 +0200 Message-ID: <4176708F.80300@zurich.ibm.com> Date: Wed, 20 Oct 2004 16:05:03 +0200 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: Pekka Savola References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Pekka Savola wrote: ... >>* I hope the problem statement above justifies the use of privacy >>> addresses for ULAs > > > I'm not so sure: so, you'd assume that the evil enterprise > administrator would be eavesdropping and correlating enterprise's > internal traffic, or the enterprise's internal web servers would be > correlating the behaviour? > > As far as I can see, it's exactly the opposite -- privacy extensions > should not be enabled by default for ULAs. > Certainly not by default; the default IID for ULAs is whatever it is for any other native IPv6 address. Actually, it will be a matter of corporate IT policy what IIDs are used within an enterprise network. As draft-vandevelde-v6ops-nap-00.txt discusses, privacy addresses will be useful in enterprise networks for use with global prefixes, but there is no obvious need to use them with ULA prefixes. But I don't find anything in draft-ietf-ipv6-privacy-addrs-v2-00 that makes privacy addresses a default, unless the implementer happens to make that a configuration choice, which isn't the IETF's decision. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 20 23:10:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18516 for ; Wed, 20 Oct 2004 23:10:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKTYD-0004Eh-6I for ipv6-web-archive@ietf.org; Wed, 20 Oct 2004 23:23:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIZl-0001lo-GB; Wed, 20 Oct 2004 11:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKI3j-0006K0-EP for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 11:07:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13009 for ; Wed, 20 Oct 2004 11:07:19 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIG4-0002dZ-TA for ipv6@ietf.org; Wed, 20 Oct 2004 11:20:13 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9KF6hq15770; Wed, 20 Oct 2004 18:06:43 +0300 Date: Wed, 20 Oct 2004 18:06:43 +0300 (EEST) From: Pekka Savola To: Suresh Krishnan In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Wed, 20 Oct 2004, Suresh Krishnan wrote: > >Has the protection from your ISPs and federal agencies etc. really > >been the requirement/goal from the start? > > On-path does not have to be FBI/NSA or ISPs. It can be anyone on an > upstream network (even in the same organization as the user). I would > assume if the FBI/NSA or the ISPs wanted to intercept they could do > so at the layer 2 connection to the provider. Do you want me to add a > statement about lawful intercept still being possible? It doesn't need to be about lawful intercept, but I'd add something about the power of being on the path, maybe like: o An attacker who is in the path between the node in question and the peer(s) it is communicating to, and can view the IPv6 addresses present in the datagrams. However, note that such on the path attacks are likely able to perform significant correlation even with RFC 3041 addresses especially if the payloads are not encrypted. > >As far as I can see, it's exactly the opposite -- privacy extensions > >should not be enabled by default for ULAs. > > This is already the case. Privacy extensions are disabled by default for > ALL types of global addresses (including the ULA). Yes, it's not default -- but what I want to have is being able to distinguish between "enabling privacy for all prefixes" and "enabling privacy for global range prefixes". I.e., the implementations, when privacy is enabled, should not start using privacy extensions by default for ULA addresses, but doing so might be configurable. I think that would be in line with most ULA users' goals.. too bad it's relatively difficult to unambugously say what those global, non-ULA addresses should be called.. -- 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 Oct 21 07:32:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04251 for ; Thu, 21 Oct 2004 07:32:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbOI-00056h-7k for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 07:45:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUHc-0005VV-2t; Thu, 21 Oct 2004 00:10:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIuH-0001Kn-5Z for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 12:01:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17456 for ; Wed, 20 Oct 2004 12:01:37 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJ6c-0003lc-1I for ipv6@ietf.org; Wed, 20 Oct 2004 12:14:31 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9KFxvk17182; Wed, 20 Oct 2004 18:59:57 +0300 Date: Wed, 20 Oct 2004 18:59:57 +0300 (EEST) From: Pekka Savola To: Ralph Droms In-Reply-To: <4.3.2.7.2.20041020083747.01f47e10@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 On Wed, 20 Oct 2004, Ralph Droms wrote: > I disagree with the wording of this section regarding the use of DHCPv6 for > privacy addresses: I thought you would, it was just a question when ;-) > At 12:03 AM 10/20/2004 -0400, Suresh Krishnan wrote: > >* Added the following text specifying the conditions for DHCPv6 to be used > >for privacy > > > > "One way to avoid some of the problems discussed above is to use > > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be > > configured to hand out addresses that change over time. But DHCPv6 > > will solve the privacy issue only if it frequently handed out > > constantly changing addresses to the nodes. Since this does not > > happen automatically, and is difficult to configure manually, DHCPv6 > > is not really suited for solving the privacy issues addressed by this > > document." > > DHCPv6 includes mechanisms for assignment and management > of "temporary addresses" (see section 12 of RFC 3315). The frequency of > reassignment for temporary addresses can be as often as desired, and is > independent of the lifetimes for non-temporary addresses. "difficult to > configure manually" is an entirely subjective assessment, and is dependent > on the specific implementation rather than the protocol itself. The statement was referring to the changing the permanent addresses regularly to avoid giving out stable identifiers. > Therefore, I think the text should be edited to read: > > One way to avoid some of the problems discussed above is to use > DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 > discusses the use of DHCPv6 for the assignment and management of > "temporary addresses" (privacy addresses). Temporary addresses are > managed separately from non-temporary addresses, so a host can > differentiate between the two types of addresses. The lifetimes of > temporary addresses are independent of the lifetimes of any other > addresses, so the frequency of replacement for temporary addresses > can be adjusted as required. I think this misses the main point. The text seems to be saying, "if you want privacy, DHCPv6 allocating public + privacy addresses provides you a way to do that", but there is no fundamental reason why to use DHCPv6 for that. Certainly it wouldn't make sense to deploy DHCPv6 privacy address assignment (if public ones are done with SLAAC), right? So, I think the tone of text should be something like: "If DHCPv6 is already used for address assignment, it makes sense to use DHCPv6 for privacy address assignment as well especially if SLAAC is not used at all; if not, using RFC 3041(bis) for privacy addresses makes much more sense" > Finally, at the risk of nit-picking, I wonder if the phrase "without the > necessity of a Dynamic Host Configuration Protocol (DHCP) server" is really > necessary? Is the sole purpose of stateless address autoconfiguration to > avoid the menace of DHCP, or does stateless address autoconfiguration avoid > manual configuration, as well? How about "Nodes use IPv6 stateless address > autoconfiguration generate addresses using a combination of locally > available information and information advertised by routers." (borrowed from > RFC 2462)? No objections from me, even though I don't think that's an issue one way or the other. "Menace of DHCP" for address assignment may or may not be an issue. Beyond that, whether or not DHCP server (e.g., for info requests) exists is irrelevant. -- 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 Oct 21 07:59:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10079 for ; Thu, 21 Oct 2004 07:59:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbnr-0006hd-LH for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 08:12:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKani-00017L-Iq; Thu, 21 Oct 2004 07:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKLhe-0005LT-4o for ipv6@megatron.ietf.org; Wed, 20 Oct 2004 15:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11441 for ; Wed, 20 Oct 2004 15:00:52 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKLu6-0001dT-R9 for ipv6@ietf.org; Wed, 20 Oct 2004 15:13:47 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9KJ0Mbj024452; Wed, 20 Oct 2004 14:00:22 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47V5JTC2>; Wed, 20 Oct 2004 14:00:14 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L0007AH; Wed, 20 Oct 2004 14:59:49 -0400 Date: Wed, 20 Oct 2004 14:54:11 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Pekka Savola In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Hi Pekka, Please see comments inline. Thanks Suresh On Wed, 20 Oct 2004, Pekka Savola wrote: >On Wed, 20 Oct 2004, Suresh Krishnan wrote: >> >Has the protection from your ISPs and federal agencies etc. really >> >been the requirement/goal from the start? >> >> On-path does not have to be FBI/NSA or ISPs. It can be anyone on an >> upstream network (even in the same organization as the user). I would >> assume if the FBI/NSA or the ISPs wanted to intercept they could do >> so at the layer 2 connection to the provider. Do you want me to add a >> statement about lawful intercept still being possible? > >It doesn't need to be about lawful intercept, but I'd add something >about the power of being on the path, maybe like: > >o An attacker who is in the path between the node in question and > the peer(s) it is communicating to, and can view the IPv6 > addresses present in the datagrams. > > However, note that such on the path > attacks are likely able to perform significant correlation > even with RFC 3041 addresses especially if the payloads are not > encrypted. I would rather state something like this "However, note that an attacker, who is on path, may be able to perform significant correlation based on the payloads of the packets on the wire. Use of temporary addresses will not prevent such payload based correlation" This clearly indicates that the correlation is done using data present in the payload. Is this text acceptable to you? > >> >As far as I can see, it's exactly the opposite -- privacy extensions >> >should not be enabled by default for ULAs. >> >> This is already the case. Privacy extensions are disabled by default for >> ALL types of global addresses (including the ULA). > >Yes, it's not default -- but what I want to have is being able to >distinguish between "enabling privacy for all prefixes" and "enabling >privacy for global range prefixes". > >I.e., the implementations, when privacy is enabled, should not start >using privacy extensions by default for ULA addresses, but doing so >might be configurable. > >I think that would be in line with most ULA users' goals.. too bad >it's relatively difficult to unambugously say what those global, >non-ULA addresses should be called.. One way to go about this will be to attach a disable flag for specific prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the global enable setting if present for the fc00::/7 range. I will add the following text after the first paragraph of "Deployment Considerations" "Additionally, sites might wish to disable the use of temporary addresses for some prefixes while still using them for other global prefixes. For example, a site might wish to disable temporary address generation for "Unique local" [ULA] prefixes while still generating temporary addresses for all other global prefixes.To support this behavior, implementations MAY provide a way to disable generation of temporary addresses for specific prefix subranges. This setting, if present, MUST override the global settings on the node with respect to the specified prefix subranges." > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 21 08:40:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18151 for ; Thu, 21 Oct 2004 08:40:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcRF-0000FB-OS for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 08:53:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbLc-0000sy-MF; Thu, 21 Oct 2004 07:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUuX-0002Xj-Em for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 00:50:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25020 for ; Thu, 21 Oct 2004 00:50:35 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKV6s-00063A-4l for ipv6@ietf.org; Thu, 21 Oct 2004 01:03:37 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9L4nxa03821; Thu, 21 Oct 2004 07:49:59 +0300 Date: Thu, 21 Oct 2004 07:49:59 +0300 (EEST) From: Pekka Savola To: Suresh Krishnan In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 On Wed, 20 Oct 2004, Suresh Krishnan wrote: > >o An attacker who is in the path between the node in question and > > the peer(s) it is communicating to, and can view the IPv6 > > addresses present in the datagrams. > > > > However, note that such on the path > > attacks are likely able to perform significant correlation > > even with RFC 3041 addresses especially if the payloads are not > > encrypted. > > I would rather state something like this > > "However, note that an attacker, who is on path, may be able to > perform significant correlation based on the payloads of the packets > on the wire. Use of temporary addresses will not prevent such payload > based correlation" > > This clearly indicates that the correlation is done using data present > in the payload. Is this text acceptable to you? That's fine. > >> >As far as I can see, it's exactly the opposite -- privacy extensions > >> >should not be enabled by default for ULAs. > >> > >> This is already the case. Privacy extensions are disabled by default for > >> ALL types of global addresses (including the ULA). > > > >Yes, it's not default -- but what I want to have is being able to > >distinguish between "enabling privacy for all prefixes" and "enabling > >privacy for global range prefixes". > > > >I.e., the implementations, when privacy is enabled, should not start > >using privacy extensions by default for ULA addresses, but doing so > >might be configurable. > > > >I think that would be in line with most ULA users' goals.. too bad > >it's relatively difficult to unambugously say what those global, > >non-ULA addresses should be called.. > > One way to go about this will be to attach a disable flag for specific > prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the > global enable setting if present for the fc00::/7 range. > > I will add the following text after the first paragraph of > "Deployment Considerations" > > "Additionally, sites might wish to disable the use of temporary > addresses for some prefixes while still using them for other global > prefixes. For example, a site might wish to disable temporary address > generation for "Unique local" [ULA] prefixes while still generating > temporary addresses for all other global prefixes.To support this behavior, > implementations MAY provide a way to disable generation of temporary > addresses for specific prefix subranges. This setting, if present, > MUST override the global settings on the node with respect to the > specified prefix subranges." I'm slightly unconformtable with this approach for a couple of reasons. First, by default, privacy addresses are generated for ULAs as well. Second, such a flag is just a MAY. What I'd propose is specify that ULAs SHOULD be excluded by default when privacy addresses are enabled, but that there MAY [or SHOULD] be a flag to enable privacy addresses for ULAs. Would that be reasonable? Note that this will create a dependency on ULA spec(s) becoming RFC before this one does (so that the IANA assigns the prefix range), but that might not be a problem, as AFAIR they're relatively far in the process. There's no need for normative reference as we want just to know the prefix(es). -- 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 Oct 21 10:45:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08383 for ; Thu, 21 Oct 2004 10:45:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeOV-0004th-Tu for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 10:58:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe8A-0001kA-Pf; Thu, 21 Oct 2004 10:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdvu-00054f-40 for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 10:28:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05659 for ; Thu, 21 Oct 2004 10:28:47 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe8X-0004Nr-8i for ipv6@ietf.org; Thu, 21 Oct 2004 10:41:53 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9LESHEx757592 for ; Thu, 21 Oct 2004 10:28:18 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9LESHSE207604 for ; Thu, 21 Oct 2004 08:28:17 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9LERu3Y012588 for ; Thu, 21 Oct 2004 08:27:56 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9LERssE012354; Thu, 21 Oct 2004 08:27:55 -0600 Received: from zurich.ibm.com (sig-9-145-252-182.de.ibm.com [9.145.252.182]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA59496; Thu, 21 Oct 2004 16:27:51 +0200 Message-ID: <4177C764.1010302@zurich.ibm.com> Date: Thu, 21 Oct 2004 16:27:48 +0200 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: Pekka Savola References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Suggestion at the end... Pekka Savola wrote: > On Wed, 20 Oct 2004, Suresh Krishnan wrote: > >>>o An attacker who is in the path between the node in question and >>> the peer(s) it is communicating to, and can view the IPv6 >>> addresses present in the datagrams. >>> >>> However, note that such on the path >>> attacks are likely able to perform significant correlation >>> even with RFC 3041 addresses especially if the payloads are not >>> encrypted. >> >>I would rather state something like this >> >>"However, note that an attacker, who is on path, may be able to >> perform significant correlation based on the payloads of the packets >> on the wire. Use of temporary addresses will not prevent such payload >> based correlation" >> >>This clearly indicates that the correlation is done using data present >>in the payload. Is this text acceptable to you? > > > That's fine. > > >>>>>As far as I can see, it's exactly the opposite -- privacy extensions >>>>>should not be enabled by default for ULAs. >>>> >>>>This is already the case. Privacy extensions are disabled by default for >>>>ALL types of global addresses (including the ULA). >>> >>>Yes, it's not default -- but what I want to have is being able to >>>distinguish between "enabling privacy for all prefixes" and "enabling >>>privacy for global range prefixes". >>> >>>I.e., the implementations, when privacy is enabled, should not start >>>using privacy extensions by default for ULA addresses, but doing so >>>might be configurable. >>> >>>I think that would be in line with most ULA users' goals.. too bad >>>it's relatively difficult to unambugously say what those global, >>>non-ULA addresses should be called.. >> >>One way to go about this will be to attach a disable flag for specific >>prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the >>global enable setting if present for the fc00::/7 range. >> >>I will add the following text after the first paragraph of >>"Deployment Considerations" >> >>"Additionally, sites might wish to disable the use of temporary >> addresses for some prefixes while still using them for other global >> prefixes. For example, a site might wish to disable temporary address >> generation for "Unique local" [ULA] prefixes while still generating >> temporary addresses for all other global prefixes.To support this behavior, >> implementations MAY provide a way to disable generation of temporary >> addresses for specific prefix subranges. This setting, if present, >> MUST override the global settings on the node with respect to the >> specified prefix subranges." > > > I'm slightly unconformtable with this approach for a couple of > reasons. First, by default, privacy addresses are generated for ULAs > as well. Second, such a flag is just a MAY. > > What I'd propose is specify that ULAs SHOULD be excluded by default > when privacy addresses are enabled, but that there MAY [or SHOULD] be > a flag to enable privacy addresses for ULAs. > > Would that be reasonable? > > Note that this will create a dependency on ULA spec(s) becoming RFC > before this one does (so that the IANA assigns the prefix range), but > that might not be a problem, as AFAIR they're relatively far in the > process. There's no need for normative reference as we want just to > know the prefix(es). > I think it would be better to RECOMMEND that an implementation should support netmasks for privacy addresses to be enabled, e.g. enable them for 2001::/16 and 2002::/16 only, else disable. Then you don't have to call out ULAs at all. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 21 10:54:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09606 for ; Thu, 21 Oct 2004 10:54:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeXP-00059c-8Y for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 11:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe9I-0002BR-RG; Thu, 21 Oct 2004 10:42:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe0F-0007qZ-1s for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 10:33:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06408 for ; Thu, 21 Oct 2004 10:33:16 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeCr-0004VX-9T for ipv6@ietf.org; Thu, 21 Oct 2004 10:46:22 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9LEWkbj004047; Thu, 21 Oct 2004 09:32:46 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47V5N3W8>; Thu, 21 Oct 2004 09:32:37 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ837VM3; Thu, 21 Oct 2004 10:32:40 -0400 Date: Thu, 21 Oct 2004 10:27:00 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Ralph Droms In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD40B@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi Ralph, Please see my comments inline. Thanks Suresh On Wed, 20 Oct 2004, Ralph Droms wrote: >I disagree with the wording of this section regarding the use of DHCPv6 for >privacy addresses: > >At 12:03 AM 10/20/2004 -0400, Suresh Krishnan wrote: >>* Added the following text specifying the conditions for DHCPv6 to be used >>for privacy >> >> "One way to avoid some of the problems discussed above is to use >> DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be >> configured to hand out addresses that change over time. But DHCPv6 >> will solve the privacy issue only if it frequently handed out >> constantly changing addresses to the nodes. Since this does not >> happen automatically, and is difficult to configure manually, DHCPv6 >> is not really suited for solving the privacy issues addressed by this >> document." > >DHCPv6 includes mechanisms for assignment and management >of "temporary addresses" (see section 12 of RFC 3315). The frequency of >reassignment for temporary addresses can be as often as desired, and is >independent of the lifetimes for non-temporary addresses. "difficult to >configure manually" is an entirely subjective assessment, and is dependent >on the specific implementation rather than the protocol itself. > >Therefore, I think the text should be edited to read: > > One way to avoid some of the problems discussed above is to use > DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 > discusses the use of DHCPv6 for the assignment and management of > "temporary addresses" (privacy addresses). Temporary addresses are > managed separately from non-temporary addresses, so a host can > differentiate between the two types of addresses. The lifetimes of > temporary addresses are independent of the lifetimes of any other > addresses, so the frequency of replacement for temporary addresses > can be adjusted as required. I see your point, but the text is about ALTERNATIVE approaches to privacy addresses, which means that DHCPv6 needs to be able create random addresses and rotate the addresses without the aid of the client. AFAIK, the IA_TA option requires the client to still generate the interface identifier and send it to the server. Nothing in the text precludes the use of DHCP to hand out temporary addresses. > >I wonder if section 2.2 is required at all? I don't think experience with >IPv4 addressing has much bearing on IPv6. For example, a device gets an >entirely new IPv4 address when it moves to a new connection point, so >tracking that device as it moves between connection points is hard. If >section 2.2 is retained, some of the details should be corrected. It is more like "why this problem did not exist with IPv4 in the same scale". I would like to retain the text since it provides background information. Do you have any specific issues with the text? I will make changes to correct any wrong details. > >Finally, at the risk of nit-picking, I wonder if the phrase "without the >necessity of a Dynamic Host Configuration Protocol (DHCP) server" is really >necessary? Is the sole purpose of stateless address autoconfiguration to >avoid the menace of DHCP, or does stateless address autoconfiguration avoid >manual configuration, as well? How about "Nodes use IPv6 stateless address >autoconfiguration generate addresses using a combination of locally >available information and information advertised by routers." (borrowed from >RFC 2462)? I retained the text from the previous version because I could not come up with anything better and accurate. I will come up with some text which will not vilify DHCP ;-) > >- Ralph > > > > > > >-------------------------------------------------------------------- >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 Oct 21 11:21:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12640 for ; Thu, 21 Oct 2004 11:21:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKexq-0005qg-AQ for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 11:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKecg-0000tr-BP; Thu, 21 Oct 2004 11:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeUQ-0004YR-8y for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 11:04:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10770 for ; Thu, 21 Oct 2004 11:04:27 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeh3-0005Qu-Rk for ipv6@ietf.org; Thu, 21 Oct 2004 11:17:34 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9LF3wbj010328; Thu, 21 Oct 2004 10:03:58 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47V5N4LP>; Thu, 21 Oct 2004 10:03:49 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ837VXV; Thu, 21 Oct 2004 11:02:30 -0400 Date: Thu, 21 Oct 2004 10:56:49 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Brian E Carpenter In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD40E@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Suresh Krishnan , ipv6@ietf.org, Pekka Savola Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Hi Brian, That sounds fair to me. I will come up with text with SHOULD language for per-prefix enabling of privacy addresses. I just have to figure out how it will interact/override with the global enable/disable option. Pekka, If I make this change, would you still like me to add specific defaults for ULAs? Thanks Suresh On Thu, 21 Oct 2004, Brian E Carpenter wrote: >Suggestion at the end... > >Pekka Savola wrote: >> On Wed, 20 Oct 2004, Suresh Krishnan wrote: >> >>>>o An attacker who is in the path between the node in question and >>>> the peer(s) it is communicating to, and can view the IPv6 >>>> addresses present in the datagrams. >>>> >>>> However, note that such on the path >>>> attacks are likely able to perform significant correlation >>>> even with RFC 3041 addresses especially if the payloads are not >>>> encrypted. >>> >>>I would rather state something like this >>> >>>"However, note that an attacker, who is on path, may be able to >>> perform significant correlation based on the payloads of the packets >>> on the wire. Use of temporary addresses will not prevent such payload >>> based correlation" >>> >>>This clearly indicates that the correlation is done using data present >>>in the payload. Is this text acceptable to you? >> >> >> That's fine. >> >> >>>>>>As far as I can see, it's exactly the opposite -- privacy extensions >>>>>>should not be enabled by default for ULAs. >>>>> >>>>>This is already the case. Privacy extensions are disabled by default for >>>>>ALL types of global addresses (including the ULA). >>>> >>>>Yes, it's not default -- but what I want to have is being able to >>>>distinguish between "enabling privacy for all prefixes" and "enabling >>>>privacy for global range prefixes". >>>> >>>>I.e., the implementations, when privacy is enabled, should not start >>>>using privacy extensions by default for ULA addresses, but doing so >>>>might be configurable. >>>> >>>>I think that would be in line with most ULA users' goals.. too bad >>>>it's relatively difficult to unambugously say what those global, >>>>non-ULA addresses should be called.. >>> >>>One way to go about this will be to attach a disable flag for specific >>>prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the >>>global enable setting if present for the fc00::/7 range. >>> >>>I will add the following text after the first paragraph of >>>"Deployment Considerations" >>> >>>"Additionally, sites might wish to disable the use of temporary >>> addresses for some prefixes while still using them for other global >>> prefixes. For example, a site might wish to disable temporary address >>> generation for "Unique local" [ULA] prefixes while still generating >>> temporary addresses for all other global prefixes.To support this behavior, >>> implementations MAY provide a way to disable generation of temporary >>> addresses for specific prefix subranges. This setting, if present, >>> MUST override the global settings on the node with respect to the >>> specified prefix subranges." >> >> >> I'm slightly unconformtable with this approach for a couple of >> reasons. First, by default, privacy addresses are generated for ULAs >> as well. Second, such a flag is just a MAY. >> >> What I'd propose is specify that ULAs SHOULD be excluded by default >> when privacy addresses are enabled, but that there MAY [or SHOULD] be >> a flag to enable privacy addresses for ULAs. >> >> Would that be reasonable? >> >> Note that this will create a dependency on ULA spec(s) becoming RFC >> before this one does (so that the IANA assigns the prefix range), but >> that might not be a problem, as AFAIR they're relatively far in the >> process. There's no need for normative reference as we want just to >> know the prefix(es). >> > >I think it would be better to RECOMMEND that an implementation should >support netmasks for privacy addresses to be enabled, e.g. enable >them for 2001::/16 and 2002::/16 only, else disable. Then you don't >have to call out ULAs at all. > > Brian > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 21 11:50:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15557 for ; Thu, 21 Oct 2004 11:50:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfPw-0006W7-H8 for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 12:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKf7F-0005t8-1i; Thu, 21 Oct 2004 11:44:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKf0m-0003Ie-Hp for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 11:37:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14088 for ; Thu, 21 Oct 2004 11:37:53 -0400 (EDT) Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfDC-0006CA-Rp for ipv6@ietf.org; Thu, 21 Oct 2004 11:51:00 -0400 Received: from SAURABHR (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I5X00KNHXGLVH@mta1.huawei.com> for ipv6@ietf.org; Thu, 21 Oct 2004 23:24:22 +0800 (CST) Date: Thu, 21 Oct 2004 21:13:23 +0530 From: Saurabh Rastogi To: ipv6@ietf.org Message-id: <007001c4b784$b3383d70$d904120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 2.3 (++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Unsubscribe 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="===============0755249737==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 This is a multi-part message in MIME format. --===============0755249737== Content-type: multipart/alternative; boundary="Boundary_(ID_l0cLfOEc6GguYnRxykzedw)" This is a multi-part message in MIME format. --Boundary_(ID_l0cLfOEc6GguYnRxykzedw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT --Boundary_(ID_l0cLfOEc6GguYnRxykzedw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

 

--Boundary_(ID_l0cLfOEc6GguYnRxykzedw)-- --===============0755249737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0755249737==-- From ipv6-bounces@ietf.org Thu Oct 21 12:14:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17981 for ; Thu, 21 Oct 2004 12:14:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfmb-00074b-Dm for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 12:27:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfLA-0003Yh-Dy; Thu, 21 Oct 2004 11:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKec8-0000TP-Hr for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 11:12:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11697 for ; Thu, 21 Oct 2004 11:12:25 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeol-0005dr-49 for ipv6@ietf.org; Thu, 21 Oct 2004 11:25:32 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9LFCN7q025914; Thu, 21 Oct 2004 08:12:23 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9LFCMQH002914; Thu, 21 Oct 2004 11:12:22 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9LFCMUs019164; Thu, 21 Oct 2004 11:12:22 -0400 (EDT) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id i9LFCM1Y019163; Thu, 21 Oct 2004 11:12:22 -0400 (EDT) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Pekka Savola In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1098371541.19112.16.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 21 Oct 2004 11:12:22 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Oct 2004 11:58:58 -0400 Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On Thu, 2004-10-21 at 00:49, Pekka Savola wrote: > > "However, note that an attacker, who is on path, may be able to > > perform significant correlation based on the payloads of the packets > > on the wire. Use of temporary addresses will not prevent such payload > > based correlation" > > > > This clearly indicates that the correlation is done using data present > > in the payload. Is this text acceptable to you? > That's fine. I would also mention packet sizes and timing in addition to payload content. My understanding is that you can recover a surprising amount of useful information without even looking at the payloads. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 21 13:31:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26125 for ; Thu, 21 Oct 2004 13:31:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgzX-0000cX-J0 for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 13:44:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgcW-00018R-AC; Thu, 21 Oct 2004 13:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgZV-0007c3-2p for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 13:17:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24700 for ; Thu, 21 Oct 2004 13:17:45 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgm5-0000FI-KB for ipv6@ietf.org; Thu, 21 Oct 2004 13:30:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9LHH6M22049; Thu, 21 Oct 2004 20:17:06 +0300 Date: Thu, 21 Oct 2004 20:17:06 +0300 (EEST) From: Pekka Savola To: Suresh Krishnan In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Brian E Carpenter , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Thu, 21 Oct 2004, Suresh Krishnan wrote: > Hi Brian, > That sounds fair to me. I will come up with text with SHOULD language > for per-prefix enabling of privacy addresses. I just have to figure out > how it will interact/override with the global enable/disable option. > > Pekka, > If I make this change, would you still like me to add specific defaults > for ULAs? I can live with 2001::/16 + 2002::/16, but I think that's a bad choice for multiple reasons. What if we invent 6to4v2 which uses 2005::/16 and we'd like to automatically apply these semantics to it? What if we run out of 2001::/16 for native allocations? -- actually we've already 1/3 used it up. Thus being generic and excluding just those that we _know_ aren't really, really global might seem as a better approach -- one that we might not need to tweak e.g., 2-3 years down the road.. -- 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 Oct 21 14:18:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01794 for ; Thu, 21 Oct 2004 14:18:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhis-0002Ci-0N for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 14:31:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhKh-0000al-Gl; Thu, 21 Oct 2004 14:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh1c-0007KM-UC for ipv6@megatron.ietf.org; Thu, 21 Oct 2004 13:46:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28532 for ; Thu, 21 Oct 2004 13:46:55 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhEG-0001Hb-Mx for ipv6@ietf.org; Thu, 21 Oct 2004 14:00:01 -0400 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel11.hp.com (Postfix) with ESMTP id 6772C24C22 for ; Thu, 21 Oct 2004 10:46:54 -0700 (PDT) Received: from cacexc04.americas.cpqcorp.net ([16.92.1.26]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 10:46:50 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2004 10:46:50 -0700 Message-ID: Thread-Topic: draft-ietf-ipngwg-icmp-name-lookups-10.txt thread-index: AcS3jlAk04uNVYyaSsySgHdAfmuUpwAB5QKA From: "Gerasimov, Sergey (CNC Roseville R&D)" To: X-OriginalArrivalTime: 21 Oct 2004 17:46:50.0354 (UTC) FILETIME=[F1896520:01C4B795] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-ipngwg-icmp-name-lookups-10.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Hello, I'd like to find out what is the current status of the draft 'draft-ietf-ipngwg-icmp-name-lookups-10.txt' and what are the plans to move or not move it forward. I notice that it expired some time ago, however it still appears to be on the WG schedule. Thanks, Sergey -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 21 19:41:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01980 for ; Thu, 21 Oct 2004 19:41:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmlb-0002i8-LV for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 19:54:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl5w-0004vq-5O; Thu, 21 Oct 2004 18:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj3G-0008Ms-Ta; Thu, 21 Oct 2004 15:56:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13792; Thu, 21 Oct 2004 15:56:44 -0400 (EDT) Message-Id: <200410211956.PAA13792@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 15:56:44 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-inet-tunnel-mib-03.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --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 : IP Tunnel MIB Author(s) : D. Thaler Filename : draft-ietf-ipv6-inet-tunnel-mib-03.txt Pages : 27 Date : 2004-10-20 This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-inet-tunnel-mib-03.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-ipv6-inet-tunnel-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-inet-tunnel-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-21154642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-inet-tunnel-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-inet-tunnel-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154642.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Thu Oct 21 19:45:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03063 for ; Thu, 21 Oct 2004 19:45:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmpg-000316-E3 for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 19:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl61-00050E-64; Thu, 21 Oct 2004 18:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj3g-0000EK-RI; Thu, 21 Oct 2004 15:57:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13824; Thu, 21 Oct 2004 15:57:10 -0400 (EDT) Message-Id: <200410211957.PAA13824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 15:57:10 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-host-load-sharing-03.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --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 Host to Router Load Sharing Author(s) : R. Hinden, D. Thaler Filename : draft-ietf-ipv6-host-load-sharing-03.txt Pages : 6 Date : 2004-10-21 The original IPv6 conceptual sending algorithm does not do load- sharing among equivalent IPv6 routers, and suggests schemes which can be problematic in practice. This document updates the conceptual sending algorithm so that traffic to different destinations can be distributed among routers in an efficient fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-03.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-ipv6-host-load-sharing-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-21154647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-host-load-sharing-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154647.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Thu Oct 21 19:49:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03711 for ; Thu, 21 Oct 2004 19:49:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmsy-0003FB-7d for ipv6-web-archive@ietf.org; Thu, 21 Oct 2004 20:02:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl65-00054H-Ml; Thu, 21 Oct 2004 18:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj4H-0000ja-Cp; Thu, 21 Oct 2004 15:57:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13849; Thu, 21 Oct 2004 15:57:47 -0400 (EDT) Message-Id: <200410211957.PAA13849@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 15:57:47 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2013-update-04.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the User Datagram Protocol (UDP) Author(s) : B. Fenner, J. Flick Filename : draft-ietf-ipv6-rfc2013-update-04.txt Pages : 25 Date : 2004-10-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-04.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-ipv6-rfc2013-update-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2013-update-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-21154654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2013-update-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2013-update-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154654.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Oct 22 00:26:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10809 for ; Fri, 22 Oct 2004 00:26:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKrDT-00059p-1W for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 00:39:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqpX-0004op-Eb; Fri, 22 Oct 2004 00:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqm0-0002M9-Mw for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 00:11:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09904 for ; Fri, 22 Oct 2004 00:11:24 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKqyk-0004un-Ac for ipv6@ietf.org; Fri, 22 Oct 2004 00:24:38 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i9M4BbCR012249; Thu, 21 Oct 2004 23:11:37 -0500 (CDT) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47W1G9NW>; Thu, 21 Oct 2004 23:10:47 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ837676; Fri, 22 Oct 2004 00:10:53 -0400 Date: Fri, 22 Oct 2004 00:05:12 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Pekka Savola In-Reply-To: Message-ID: <21A5F45EFF209A44B3057E35CE1FE6E40398181F-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Suresh Krishnan , Brian E Carpenter , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi Pekka/Brian, I was thinking of enable/disable flags for separate prefixes which override the global settings. Let's say you want privacy addresses for everything but ULA you would have the following settings Global -> Enabled fc00::/7 -> Disabled Let's say Brian just wants to enable them for 2001::/16 and 2002::/16 Global -> Disabled 2001::/16 -> Enabled 2002::/16 -> Enabled I think that should address both your concern and Brian's concern. Thanks Suresh On Thu, 21 Oct 2004, Pekka Savola wrote: >On Thu, 21 Oct 2004, Suresh Krishnan wrote: >> Hi Brian, >> That sounds fair to me. I will come up with text with SHOULD language >> for per-prefix enabling of privacy addresses. I just have to figure out >> how it will interact/override with the global enable/disable option. >> >> Pekka, >> If I make this change, would you still like me to add specific defaults >> for ULAs? > >I can live with 2001::/16 + 2002::/16, but I think that's a bad choice >for multiple reasons. What if we invent 6to4v2 which uses 2005::/16 >and we'd like to automatically apply these semantics to it? What if >we run out of 2001::/16 for native allocations? -- actually we've >already 1/3 used it up. > >Thus being generic and excluding just those that we _know_ aren't >really, really global might seem as a better approach -- one that we >might not need to tweak e.g., 2-3 years down the road.. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 22 00:28:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10989 for ; Fri, 22 Oct 2004 00:28:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKrFB-0005DN-SI for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 00:41:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqpZ-0004pD-5W; Fri, 22 Oct 2004 00:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqmK-0002pE-TJ for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 00:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09907 for ; Fri, 22 Oct 2004 00:11:44 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKqz4-0004vD-LO for ipv6@ietf.org; Fri, 22 Oct 2004 00:24:58 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i9M4BwCR012273; Thu, 21 Oct 2004 23:11:58 -0500 (CDT) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47W1G93A>; Thu, 21 Oct 2004 23:11:08 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ837677; Fri, 22 Oct 2004 00:11:11 -0400 Date: Fri, 22 Oct 2004 00:05:30 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Bill Sommerfeld In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD413@eammlex037.lmc.ericsson.se> Message-ID: <21A5F45EFF209A44B3057E35CE1FE6E403981820-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi Bill, >I would also mention packet sizes and timing in addition to payload >content. My understanding is that you can recover a surprising amount >of useful information without even looking at the payloads. I would agree with you that a an attacker can extrapolate a lot about the data, using packet sizes and timing. But do you feel that the size of the packets and the timing can be used to correlate the IDENTITY of the victim? Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 22 11:22:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13248 for ; Fri, 22 Oct 2004 11:22:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1S3-0000Iv-EB for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 11:35:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL15Y-0002Wu-0T; Fri, 22 Oct 2004 11:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL14U-00025t-2x for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 11:11:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12461 for ; Fri, 22 Oct 2004 11:11:10 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1HH-00006r-UU for ipv6@ietf.org; Fri, 22 Oct 2004 11:24:28 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9MFAebj021842; Fri, 22 Oct 2004 10:10:40 -0500 (CDT) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 10:10:39 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ8370W0; Fri, 22 Oct 2004 11:10:26 -0400 Date: Fri, 22 Oct 2004 11:04:44 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: BIll Sommerfeld In-Reply-To: <1098422274.4555.21.camel@unknown.hamachi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi Bill, Can you give me more details or a pointer to such an attack? I will add add some text and a reference to it. Thanks Suresh On Fri, 22 Oct 2004, BIll Sommerfeld wrote: >On Fri, 2004-10-22 at 00:05, Suresh Krishnan wrote: >> I would agree with you that a an attacker can extrapolate a lot about the >> data, using packet sizes and timing. But do you feel that the size of the >> packets and the timing can be used to correlate the IDENTITY of the victim? > >Yes. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 22 11:55:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16071 for ; Fri, 22 Oct 2004 11:55:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1y1-0000z3-52 for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 12:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1eu-0006fo-Lq; Fri, 22 Oct 2004 11:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1ZG-00043A-OB for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 11:43:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14824 for ; Fri, 22 Oct 2004 11:42:59 -0400 (EDT) Received: from transfire.transwitch.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1m4-0000g9-Vo for ipv6@ietf.org; Fri, 22 Oct 2004 11:56:17 -0400 Received: from [172.17.0.209] ([172.17.0.209]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i9MFfF104755; Fri, 22 Oct 2004 11:41:22 -0400 Message-ID: <41792A1A.3050505@txc.com> Date: Fri, 22 Oct 2004 11:41:14 -0400 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arvind saproo References: <000001c4ac2a$00d9bc90$5e04120a@in.huawei.com> In-Reply-To: <000001c4ac2a$00d9bc90$5e04120a@in.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: "'Nimrod Sterrn'" , ipv6@ietf.org Subject: Re: Query:IPv6 Over ATM PVC Operation 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="===============1273881175==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 This is a cryptographically signed message in MIME format. --===============1273881175== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000509050906080002060008" This is a cryptographically signed message in MIME format. --------------ms000509050906080002060008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Arvind, I believe that Inverse Discovery (RFC3122) has its own rules, within its own scope, which is Inverse Discovery, as opposed to Discovery. These rules apply generically to the typical users of Inverse Discovery, like ATM, or Frame Relay. I hope this helps, Alex arvind saproo wrote: > Hi, > Thanks for the reply. > If the Source and Target Link Layer Address Options > are not included in (IPv6 Over ATM PVC) IND > message, then the message will straight-away be considered an > invalid one as per the message validation checks > specified in IND RFC (rfc 3122). > A better option would be to zero fill the options > though the options would be useless in that scenario (?) > > Alex, could you help on this issue since the > authors of IPv6 Over ATM RFC (rfc 2492) are not > reachable at the e-mail address specified in the RFC? > > Rgds, > arvind > > -----Original Message----- > From: Nimrod Sterrn [mailto:NimrodS@radlan.com] > Sent: Monday, October 04, 2004 2:38 PM > To: arvind saproo > Cc: ipv6@ietf.org > Subject: RE: Query:IPv6 Over ATM PVC Operation > > see my comments in ==> > > -----Original Message----- > From: arvind saproo [mailto:arvindsaproo@huawei.com] > Sent: Fri, October 01, 2004 3:44 PM > To: ipv6@ietf.org > Subject: Query:IPv6 Over ATM PVC Operation > > > Hi, > I have the following query regarding IPv6 Over ATM PVC operation > (rfc2492). > I would appreciate if someone could answer the same. > > Query - > ===== > RFC does not clearly mention what to fill as the Source/Target > Link Layer address in the Source/Target Link Layer options > of IND (Inverse ND) messages. > > Also, there is no mention of any reference document which > covers the same. > > All that is said is [Section 3. PVC Environments] - > > "Since ATM PVC links do not use link-layer addresses, the link-layer > address options SHOULD not be included in any ND message [11]. If a > link-layer address option is present in an ND message, then the > option SHOULD be ignored." > > ==> It may be confusing after reading RFC3122 (inverse ND) which requires > it as part of the > solicitation (src and dst LL address) and reply (target LL address). > but since PVC in "permanent" its not needed (?!) > > Does this mean that we zero fill the Link Layer address in Source/Target > Link Layer options of the IND messages? > > This information must be clearly mentioned to avoid interoperability issues. > > > > Thanks for your time, > Rgds, > arvind > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --------------ms000509050906080002060008 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM0DCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIEyzCCBDSgAwIBAgIQRY9PVVj3ePhsLb03a2b4yjANBgkqhkiG9w0BAQUFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDEwMDgw MDAwMDBaFw0wNTEwMDgyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM8xTSF3F08ybYUCj+WH4lkPUcpuZSYIJ/LO5unkXd79I1KEqizW9H+dOrAqHVdHrwYqYyKH JO5AjpNKZhFX86bPDWS+XgMO7qqhUByPN6GlFwNx1sNdffOU+5ihboht9oPPbaTv0KdhXSmL iaa5a4KXUuF4PwkACOMk5lh5W851TEhSJ2OPIGEcdD2R3wE4pt0AvwDbHqvzF7Ek62SRTDwy fqfH+Nu74lBiBTeMP403THgR/YwY8k/Aqd/ycgjgzkbpCMctRI2X05kkUhJyTy3FGMc504Hl 3B3X2NymB8D8B4QuAQlsxSryRZuEvNiAt/GKL3F+meEIx64A/OT9rK0CAwEAAaOB5zCB5DAJ BgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggrBgEFBQcCARYcaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYB BQUHAwQGCCsGAQUFBwMCMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQCvKbDNvQZAc9yB9DFKkn1Al+3y23MQrENE eb73uVEy5Iwb59g7T9giuTbYGjCmkyepa3eVi7gBbfJR85gRfTFomXr2siSP3Cnj2d8nmp8w GE0HD0zCNMotCtoS9ZSv0Ey7xAtSaLJCnbV+XbCZ6xPj+qRmgsrbYp8Z0b73CoINRjCCBMsw ggQ0oAMCAQICEEWPT1VY93j4bC29N2tm+MowDQYJKoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixM SUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQxMDA4MDAwMDAwWhcNMDUx MDA4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBl IEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3DQEJARYOYWNv bnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPMU0hdxdPMm2F Ao/lh+JZD1HKbmUmCCfyzubp5F3e/SNShKos1vR/nTqwKh1XR68GKmMihyTuQI6TSmYRV/Om zw1kvl4DDu6qoVAcjzehpRcDcdbDXX3zlPuYoW6IbfaDz22k79CnYV0pi4mmuWuCl1LheD8J AAjjJOZYeVvOdUxIUidjjyBhHHQ9kd8BOKbdAL8A2x6r8xexJOtkkUw8Mn6nx/jbu+JQYgU3 jD+NN0x4Ef2MGPJPwKnf8nII4M5G6QjHLUSNl9OZJFISck8txRjHOdOB5dwd19jcpgfA/AeE LgEJbMUq8kWbhLzYgLfxii9xfpnhCMeuAPzk/aytAgMBAAGjgecwgeQwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEFBQADgYEArymwzb0GQHPcgfQxSpJ9QJft8ttzEKxDRHm+97lRMuSMG+fY O0/YIrk22BowppMnqWt3lYu4AW3yUfOYEX0xaJl69rIkj9wp49nfJ5qfMBhNBw9MwjTKLQra EvWUr9BMu8QLUmiyQp21fl2wmesT4/qkZoLK22KfGdG+9wqCDUYxggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQRY9PVVj3ePhs Lb03a2b4yjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNDEwMjIxNTQxMTRaMCMGCSqGSIb3DQEJBDEWBBQtN2MZDV8NEHsSdVgc oPHAhKbjyzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBFj09V WPd4+GwtvTdrZvjKMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQRY9PVVj3ePhsLb03a2b4yjANBgkqhkiG9w0B AQEFAASCAQB4rzhwaLjktfZQBc+9Kz7mlUk6YHQXCIfro/iwMlE+tE1lirPOfIWweplErPXO Z7h6FwX2uKnA1BiJG9br09CTHAllhZ7HP7h93AAh35ri9M1vbOm5SxcJuROggnM34dxTo08q M39Kqv8+75CDunsU5NwYBG58s81gBcm3QriPYgtsN21DXFhUkLf2sD0hoNafQTHMkjMuXFBD NX7ZhAQUTgGcLV19jYtc9Sgx0BobCEGF9T5THVOLDWHqv0eotwNMAiAEUCIwBFeNjjuxugTC b1bH4SZ//n4Lo+4Xi2MHILuFPNgYOv5FWtImxvBOaAJcI/xw1nBVJqILE6pnxGcvAAAAAAAA --------------ms000509050906080002060008-- --===============1273881175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1273881175==-- From ipv6-bounces@ietf.org Fri Oct 22 15:00:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29618 for ; Fri, 22 Oct 2004 15:00:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4rc-0004Rl-Ut for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 15:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4aD-0006ut-8o; Fri, 22 Oct 2004 14:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4X1-0005tk-BI for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 14:52:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29026 for ; Fri, 22 Oct 2004 14:52:52 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4jq-0004Hx-Tc for ipv6@ietf.org; Fri, 22 Oct 2004 15:06:11 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.4741352; Fri, 22 Oct 2004 14:51:28 -0400 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <61888AFA-245B-11D9-9FCC-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Fri, 22 Oct 2004 14:51:27 -0400 X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: Draft IPv6 WG Agenda 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="===============0344194718==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --===============0344194718== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--95196121; protocol="application/pkcs7-signature" --Apple-Mail-4--95196121 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Comments/changes welcome... Agenda Bashing Chairs 4 minutes Document Status Chairs 1 minute Milestone Updates Chairs 5 minutes Node Information Queries Chairs 10 minutes Privacy Addresses v2 Krishnan 15 minutes IPv6 over PPP v2 Varada 10 minutes AD feedback on 2462bis Jinmei 20 minutes Multi6 Update multi6 chairs 20 minutes Source Addr Selection Matsumoto 10 minutes Anycast Analysis Chairs 10 minutes Regards, Bob & Brian --Apple-Mail-4--95196121 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDIyMTg1MTI4WjAjBgkqhkiG9w0B CQQxFgQUiwYcSnCo+lEdHzJIOsoc0UGB6ZEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAlcWeJIboSJ4UJDXBjQQckbXwf4Baof5BdELkr9FEyV6k6oKcH2bdjRzakDgKIGgnma1k jTt9yoEkNSt4VFSfWNH0KIeB5UZgSz1xyLc0GMt6Z+X1IdpUnUGcGVCPbmehJQCQu5zyCnX6A3Gk D/iW3GQIdyK1gfWMqtwUi9d9QHTBb44cHmccHxMvj06GqR11kTOxoPvNGUMyD72xV1Tgw8pB6VAs wBaJO84kZRM7CqJR3DGg9b9cjDuk6TqttCu/YkoYZ/ctUqrf/7Ivg4mIkYW0uVJS3nC9CX7735Ya IMT4bXsf8rimyMFboPsnwNuoZWXNRcRviiS2cYzUtSVPHgAAAAAAAA== --Apple-Mail-4--95196121-- --===============0344194718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0344194718==-- From ipv6-bounces@ietf.org Fri Oct 22 17:29:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20981 for ; Fri, 22 Oct 2004 17:29:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7B4-0002DJ-Ip for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 17:42:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6g0-00077d-Jh; Fri, 22 Oct 2004 17:10:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5kI-0000GD-9j; Fri, 22 Oct 2004 16:10:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06233; Fri, 22 Oct 2004 16:10:38 -0400 (EDT) Message-Id: <200410222010.QAA06233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 22 Oct 2004 16:10:38 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, et al. Filename : draft-ietf-ipngwg-icmp-v3-05.txt Pages : 26 Date : 2004-10-22 This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-05.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-v3-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-05.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: <2004-10-22162000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22162000.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Oct 22 20:31:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17030 for ; Fri, 22 Oct 2004 20:31:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLA1S-0001c7-MI for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 20:44:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9Tl-0006aG-2g; Fri, 22 Oct 2004 20:09:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9MJ-0002EU-VC for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 20:02:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15186 for ; Fri, 22 Oct 2004 20:02:11 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9ZF-0001Ap-3X for ipv6@ietf.org; Fri, 22 Oct 2004 20:15:33 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9N01dbj005001; Fri, 22 Oct 2004 19:01:40 -0500 (CDT) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 19:01:39 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ838FSV; Fri, 22 Oct 2004 20:00:12 -0400 Date: Fri, 22 Oct 2004 19:54:29 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Brian E Carpenter , Pekka Savola In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD419@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ipv6@ietf.org Subject: Adding Per-prefix Knob (WAS Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi Pekka/Brian, This is the text I added to have a per-prefix enable/disable setting. Hope it resolves your issues. "Additionally, sites might wish to selectively enable or disable the use of temporary addresses for some prefixes. For example, a site might wish to disable temporary address generation for "Unique local" [ULA] prefixes while still generating temporary addresses for all other global prefixes. Another site might wish to enable temporary address generation only for the prefixes 2001::/16 and 2002::/16 while disabling it for all other prefixes. To support this behavior, implementations SHOULD provide a way to enable and disable generation of temporary addresses for specific prefix subranges. This per-prefix setting SHOULD override the global settings on the node with respect to the specified prefix subranges." Thanks Suresh On Fri, 22 Oct 2004, Suresh Krishnan wrote: >Hi Pekka/Brian, > I was thinking of enable/disable flags for separate prefixes which >override the global settings. > >Let's say you want privacy addresses for everything but ULA >you would have the following settings > >Global -> Enabled >fc00::/7 -> Disabled > >Let's say Brian just wants to enable them for 2001::/16 and 2002::/16 > >Global -> Disabled >2001::/16 -> Enabled >2002::/16 -> Enabled > >I think that should address both your concern and Brian's concern. > >Thanks >Suresh > > On Thu, 21 Oct 2004, Pekka Savola wrote: > >>On Thu, 21 Oct 2004, Suresh Krishnan wrote: >>> Hi Brian, >>> That sounds fair to me. I will come up with text with SHOULD language >>> for per-prefix enabling of privacy addresses. I just have to figure out >>> how it will interact/override with the global enable/disable option. >>> >>> Pekka, >>> If I make this change, would you still like me to add specific defaults >>> for ULAs? >> >>I can live with 2001::/16 + 2002::/16, but I think that's a bad choice >>for multiple reasons. What if we invent 6to4v2 which uses 2005::/16 >>and we'd like to automatically apply these semantics to it? What if >>we run out of 2001::/16 for native allocations? -- actually we've >>already 1/3 used it up. >> >>Thus being generic and excluding just those that we _know_ aren't >>really, really global might seem as a better approach -- one that we >>might not need to tweak e.g., 2-3 years down the road.. >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 22 20:32:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17188 for ; Fri, 22 Oct 2004 20:32:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLA2K-0001eF-V0 for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 20:45:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9Tm-0006as-9C; Fri, 22 Oct 2004 20:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9N9-0002aS-1v for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 20:03:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15218 for ; Fri, 22 Oct 2004 20:03:02 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9a4-0001Bp-BV for ipv6@ietf.org; Fri, 22 Oct 2004 20:16:24 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9N02Vbj005588; Fri, 22 Oct 2004 19:02:32 -0500 (CDT) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 19:02:27 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ838FTM; Fri, 22 Oct 2004 20:02:23 -0400 Date: Fri, 22 Oct 2004 19:56:40 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Bill Sommerfeld In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD413@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: Correlation based on size/timing (WAS Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi Bill, I have added the following text to include packet sizes and timing "Please note that an attacker, who is on path, may be able to perform significant correlation based on o The payload contents of the packets on the wire o The characteristics of the packets such as packet size and timing Use of temporary addresses will not prevent such payload based correlation" Hope that resolves your issue. Thanks Suresh On Thu, 21 Oct 2004, Bill Sommerfeld wrote: >On Thu, 2004-10-21 at 00:49, Pekka Savola wrote: >> > "However, note that an attacker, who is on path, may be able to >> > perform significant correlation based on the payloads of the packets >> > on the wire. Use of temporary addresses will not prevent such payload >> > based correlation" >> > >> > This clearly indicates that the correlation is done using data present >> > in the payload. Is this text acceptable to you? >> That's fine. > >I would also mention packet sizes and timing in addition to payload >content. My understanding is that you can recover a surprising amount >of useful information without even looking at the payloads. > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 22 20:33:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17452 for ; Fri, 22 Oct 2004 20:33:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLA34-0001go-1S for ipv6-web-archive@ietf.org; Fri, 22 Oct 2004 20:46:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9VY-0007sz-M0; Fri, 22 Oct 2004 20:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9Rn-00056p-Nb for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 20:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15505 for ; Fri, 22 Oct 2004 20:07:51 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9ej-0001FP-0v for ipv6@ietf.org; Fri, 22 Oct 2004 20:21:13 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i9N07Jbj006255; Fri, 22 Oct 2004 19:07:19 -0500 (CDT) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 19:07:19 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJ838F4N; Fri, 22 Oct 2004 20:07:17 -0400 Date: Fri, 22 Oct 2004 20:01:34 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: Ralph Droms In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E46BD40B@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ipv6@ietf.org Subject: DHCPv6 (WAS Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Hi Ralph, * The abstract no longer refers to DHCP. "Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier" * The alternate approach text now reads "One way to avoid some of the problems discussed above is to use DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be configured to hand out addresses that change over time. But DHCPv6 will solve the privacy issue only if it frequently handed out constantly changing addresses to the nodes. Since this does not happen automatically, and is difficult to configure manually, DHCPv6 is not a self contained alternative for solving the privacy issues addressed by this document. However, in the absence of stateless address autoconfiguration, DHCPv6 can be used for distributing temporary addresses to clients." Hope that resolves your issues. Thanks Suresh On Wed, 20 Oct 2004, Ralph Droms wrote: >I disagree with the wording of this section regarding the use of DHCPv6 >for >privacy addresses: > >At 12:03 AM 10/20/2004 -0400, Suresh Krishnan wrote: >>* Added the following text specifying the conditions for DHCPv6 to be >used >>for privacy >> >> "One way to avoid some of the problems discussed above is to use >> DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could >be >> configured to hand out addresses that change over time. But DHCPv6 >> will solve the privacy issue only if it frequently handed out >> constantly changing addresses to the nodes. Since this does not >> happen automatically, and is difficult to configure manually, >DHCPv6 >> is not really suited for solving the privacy issues addressed by >this >> document." > >DHCPv6 includes mechanisms for assignment and management >of "temporary addresses" (see section 12 of RFC 3315). The frequency of >reassignment for temporary addresses can be as often as desired, and is >independent of the lifetimes for non-temporary addresses. "difficult to >configure manually" is an entirely subjective assessment, and is >dependent >on the specific implementation rather than the protocol itself. > >Therefore, I think the text should be edited to read: > > One way to avoid some of the problems discussed above is to use > DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 > discusses the use of DHCPv6 for the assignment and management of > "temporary addresses" (privacy addresses). Temporary addresses are > managed separately from non-temporary addresses, so a host can > differentiate between the two types of addresses. The lifetimes of > temporary addresses are independent of the lifetimes of any other > addresses, so the frequency of replacement for temporary addresses > can be adjusted as required. > >I wonder if section 2.2 is required at all? I don't think experience >with >IPv4 addressing has much bearing on IPv6. For example, a device gets an >entirely new IPv4 address when it moves to a new connection point, so >tracking that device as it moves between connection points is hard. If >section 2.2 is retained, some of the details should be corrected. > >Finally, at the risk of nit-picking, I wonder if the phrase "without the >necessity of a Dynamic Host Configuration Protocol (DHCP) server" is >really >necessary? Is the sole purpose of stateless address autoconfiguration >to >avoid the menace of DHCP, or does stateless address autoconfiguration >avoid >manual configuration, as well? How about "Nodes use IPv6 stateless >address >autoconfiguration generate addresses using a combination of locally >available information and information advertised by routers." (borrowed >from >RFC 2462)? > >- Ralph > > > > > > >-------------------------------------------------------------------- >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 Oct 23 01:20:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14250 for ; Sat, 23 Oct 2004 01:20:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLEXh-00066t-8Z for ipv6-web-archive@ietf.org; Sat, 23 Oct 2004 01:34:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLEAR-0004eF-ST; Sat, 23 Oct 2004 01:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLE3O-0001kO-BZ for ipv6@megatron.ietf.org; Sat, 23 Oct 2004 01:02:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12995 for ; Sat, 23 Oct 2004 01:02:57 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLEGL-0005qO-UW for ipv6@ietf.org; Sat, 23 Oct 2004 01:16:22 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9N52K104673; Sat, 23 Oct 2004 08:02:20 +0300 Date: Sat, 23 Oct 2004 08:02:20 +0300 (EEST) From: Pekka Savola To: Suresh Krishnan In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Brian E Carpenter , ipv6@ietf.org Subject: Re: Adding Per-prefix Knob (WAS Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Fri, 22 Oct 2004, Suresh Krishnan wrote: > Hi Pekka/Brian, > This is the text I added to have a per-prefix enable/disable > setting. Hope it resolves your issues. > > "Additionally, sites might wish to selectively enable or disable the > use of temporary addresses for some prefixes. For example, a site > might wish to disable temporary address generation for "Unique local" > [ULA] prefixes while still generating temporary addresses for all > other global prefixes. Another site might wish to enable temporary > address generation only for the prefixes 2001::/16 and 2002::/16 > while disabling it for all other prefixes. To support this behavior, > implementations SHOULD provide a way to enable and disable generation > of temporary addresses for specific prefix subranges. This > per-prefix setting SHOULD override the global settings on the node > with respect to the specified prefix subranges." This would be OK by me if you added a SHOULD or RECOMMENDED that fc00::/7 should be in the 'disable' list by default. -- 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 Sat Oct 23 06:23:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14498 for ; Sat, 23 Oct 2004 06:23:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLJH5-0002PQ-6A for ipv6-web-archive@ietf.org; Sat, 23 Oct 2004 06:37:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLIxE-0004NK-By; Sat, 23 Oct 2004 06:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLIum-0002IT-MU for ipv6@megatron.ietf.org; Sat, 23 Oct 2004 06:14:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13786 for ; Sat, 23 Oct 2004 06:14:21 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLJ7j-0002FT-St for ipv6@ietf.org; Sat, 23 Oct 2004 06:27:51 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6100L0G8EZ34@mailout1.samsung.com> for ipv6@ietf.org; Sat, 23 Oct 2004 19:13:47 +0900 (KST) Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6100HMN8ED8Z@mailout1.samsung.com> for ipv6@ietf.org; Sat, 23 Oct 2004 19:13:25 +0900 (KST) Received: from localhost (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0I6100MJD8EDSH@ms3.samsung.com> for ipv6@ietf.org; Sat, 23 Oct 2004 19:13:25 +0900 (KST) Date: Sat, 23 Oct 2004 10:13:24 +0000 (GMT) From: Daniel Park X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: Brian Haberman , soohong.park@samsung.com Message-id: <0I6100MJE8EDSH@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20041023101315487@soohong.park X-MTR: 20041023101315487@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Score: 1.7 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IPv6 WG Subject: [Updated I-D] Considerations on M and O Flags of IPv6 RA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0454063379==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 --===============0454063379== Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

We have submitted the updated version of "Considerations on M

and O Flags of IPv6 RA" and it will appear in the IETF repository soon.

Please use below link before publishing.

http://daniel.vsix.net/daniel/draft-daniel-ipv6-ra-mo-flags-01.txt 

 

After San Diego meeting, we've tried to reflect all comments and

feedbacks surrounding M and O flag of IPv6 RA and the revised

version  is more clear than before IMO,

 

<Change log from initial version>

1. lots of text improvement and clarification from the initial version.

2. New term. such as "Host Configuration Behaviour" and "Information Configuration Behaviour"

3. New IPv6 host variables such as "M-Flag" and "O-Flag" instead of  "ManagedFlag" and "OtherConfigFlag"

4. Clarification of Host Behaviour

5. New section as "Router Advertisement Unavailability"

6. An Open Issue: Default Policy Values

7. New appendix as "Handling of M and O flags from multiple routers "

 

All comments are highly welcome.

 

 

Regards   
 
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory. SAMSUNG Electronics
 
 

--===============0454063379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0454063379==-- From ipv6-bounces@ietf.org Sat Oct 23 09:23:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25327 for ; Sat, 23 Oct 2004 09:23:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLM4W-0005GX-NA for ipv6-web-archive@ietf.org; Sat, 23 Oct 2004 09:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLLo2-0001mb-8k; Sat, 23 Oct 2004 09:19:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLLk9-0000MJ-9F for ipv6@megatron.ietf.org; Sat, 23 Oct 2004 09:15:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25154 for ; Sat, 23 Oct 2004 09:15:35 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLLxA-0005Bj-QJ for ipv6@ietf.org; Sat, 23 Oct 2004 09:29:06 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9NDF3CE342656; Sat, 23 Oct 2004 09:15:03 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9NDF10v249108; Sat, 23 Oct 2004 09:15:02 -0400 Received: from zurich.ibm.com (sig-9-146-222-30.de.ibm.com [9.146.222.30]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA25582; Sat, 23 Oct 2004 15:15:00 +0200 Message-ID: <417A5958.6090101@zurich.ibm.com> Date: Sat, 23 Oct 2004 15:15:04 +0200 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: Pekka Savola References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Suresh Krishnan , ipv6@ietf.org Subject: Re: Adding Per-prefix Knob (WAS Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 22 Oct 2004, Suresh Krishnan wrote: > >>Hi Pekka/Brian, >> This is the text I added to have a per-prefix enable/disable >>setting. Hope it resolves your issues. >> >> "Additionally, sites might wish to selectively enable or disable the >> use of temporary addresses for some prefixes. For example, a site >> might wish to disable temporary address generation for "Unique local" >> [ULA] prefixes while still generating temporary addresses for all >> other global prefixes. Another site might wish to enable temporary >> address generation only for the prefixes 2001::/16 and 2002::/16 >> while disabling it for all other prefixes. To support this behavior, >> implementations SHOULD provide a way to enable and disable generation >> of temporary addresses for specific prefix subranges. This >> per-prefix setting SHOULD override the global settings on the node >> with respect to the specified prefix subranges." > > > This would be OK by me if you added a SHOULD or RECOMMENDED that > fc00::/7 should be in the 'disable' list by default. > OK for me too Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 24 00:10:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14224 for ; Sun, 24 Oct 2004 00:10:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLZv8-00020g-Vd for ipv6-web-archive@ietf.org; Sun, 24 Oct 2004 00:23:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLZcg-0000qt-6P; Sun, 24 Oct 2004 00:04:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLZZ5-0008Tl-9r for ipv6@megatron.ietf.org; Sun, 24 Oct 2004 00:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13836 for ; Sun, 24 Oct 2004 00:01:03 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLZmF-0001sM-1A for ipv6@ietf.org; Sun, 24 Oct 2004 00:14:43 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id BE05B66D for ; Sun, 24 Oct 2004 00:00:32 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 24 Oct 2004 00:00:32 -0400 Message-Id: <20041024040032.BE05B66D@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Messages | Bytes | Who --------+------+--------+----------+------------------------ 31.71% | 13 | 30.26% | 72617 | suresh.krishnan@ericsson.ca 14.63% | 6 | 12.70% | 30472 | pekkas@netcore.fi 9.76% | 4 | 9.67% | 23206 | internet-drafts@ietf.org 7.32% | 3 | 11.90% | 28566 | humphrey.gu@nfs.com.cn 7.32% | 3 | 6.74% | 16177 | brc@zurich.ibm.com 2.44% | 1 | 5.35% | 12832 | aconta@txc.com 2.44% | 1 | 3.50% | 8406 | jinmei@isl.rdc.toshiba.co.jp 2.44% | 1 | 3.30% | 7911 | brian@innovationslab.net 2.44% | 1 | 2.48% | 5950 | soohong.park@samsung.com 2.44% | 1 | 2.46% | 5910 | rdroms@cisco.com 2.44% | 1 | 2.00% | 4808 | olnrao@samsung.com 2.44% | 1 | 2.00% | 4804 | saurabh@huawei.com 2.44% | 1 | 1.72% | 4137 | a@arifumi.net 2.44% | 1 | 1.71% | 4096 | sommerfeld@sun.com 2.44% | 1 | 1.58% | 3782 | sra+ipng@hactrn.net 2.44% | 1 | 1.40% | 3358 | sergey.gerasimov@hp.com 2.44% | 1 | 1.22% | 2934 | hansen.chan@alcatel.com --------+------+--------+----------+------------------------ 100.00% | 41 |100.00% | 239966 | 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 Oct 24 23:17:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24167 for ; Sun, 24 Oct 2004 23:17:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvaF-00031B-65 for ipv6-web-archive@ietf.org; Sun, 24 Oct 2004 23:31:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvKj-0000xg-M6; Sun, 24 Oct 2004 23:15:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvGd-0000Tr-Do for ipv6@megatron.ietf.org; Sun, 24 Oct 2004 23:11:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23731 for ; Sun, 24 Oct 2004 23:11:28 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvTz-0002t4-Fi for ipv6@ietf.org; Sun, 24 Oct 2004 23:25:20 -0400 Received: from www by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLvGX-000Ms1-Uz for ipv6@ietf.org; Mon, 25 Oct 2004 03:11:25 +0000 CC: ipv6@ietf.org MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.62 Content-Type: text/plain; charset="utf-8" RT-Originator: h.soliman@flarion.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.11 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #599 Message-Id: Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2461bis@rt.psg.com Date: Mon, 25 Oct 2004 03:11:25 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [psg.com #599] State diagram does not consider NA with S=1 O = 0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2461bis@rt.psg.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: State diagram does not consider NA with S=1 O = 0 Issue description: >From Peter Grubmair: In the state diagram in RFC2461-bis in Appendic C, page 79, the event of receiving a NA with solicitated = 1 and Override = 0 in state DELAY is not handled. To my understanding the same treatment as in state STALE or PROBE has to be applied. To me it also seems, that the state DELAY can be treated to equal to PROBE, only the start of timer in state STALE has to use another timing value as starting the timer uppon timeout in PROBE state. In my model entering the PROBE state does not send NS, but only starts the delay timer. This can be done without changing behavior, maybe state DELAY should be dropped. => I've added DELAY to the states STALE and PROBE in the state machine. This issue is now resolved. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 24 23:21:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24535 for ; Sun, 24 Oct 2004 23:21:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvdO-00036G-S4 for ipv6-web-archive@ietf.org; Sun, 24 Oct 2004 23:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvKl-0000yJ-6T; Sun, 24 Oct 2004 23:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvGd-0000Ts-Fe for ipv6@megatron.ietf.org; Sun, 24 Oct 2004 23:11:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23730 for ; Sun, 24 Oct 2004 23:11:28 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvTz-0002t5-E7 for ipv6@ietf.org; Sun, 24 Oct 2004 23:25:20 -0400 Received: from www by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLvGY-000Ms4-71 for ipv6@ietf.org; Mon, 25 Oct 2004 03:11:26 +0000 CC: ipv6@ietf.org MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.62 Content-Type: text/plain; charset="utf-8" RT-Originator: h.soliman@flarion.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.11 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #599 Message-Id: Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2461bis@rt.psg.com Date: Mon, 25 Oct 2004 03:11:26 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [psg.com #599] State diagram does not consider NA with S=1 O = 0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2461bis@rt.psg.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: State diagram does not consider NA with S=1 O = 0 Issue description: >From Peter Grubmair: In the state diagram in RFC2461-bis in Appendic C, page 79, the event of receiving a NA with solicitated = 1 and Override = 0 in state DELAY is not handled. To my understanding the same treatment as in state STALE or PROBE has to be applied. To me it also seems, that the state DELAY can be treated to equal to PROBE, only the start of timer in state STALE has to use another timing value as starting the timer uppon timeout in PROBE state. In my model entering the PROBE state does not send NS, but only starts the delay timer. This can be done without changing behavior, maybe state DELAY should be dropped. => I've added DELAY to the states STALE and PROBE in the state machine. This issue is now resolved. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 24 23:30:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25432 for ; Sun, 24 Oct 2004 23:30:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvmD-0003IY-Ou for ipv6-web-archive@ietf.org; Sun, 24 Oct 2004 23:44:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvXL-0002aK-Pp; Sun, 24 Oct 2004 23:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvWn-0002W8-0S for ipv6@megatron.ietf.org; Sun, 24 Oct 2004 23:28:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25270 for ; Sun, 24 Oct 2004 23:28:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvk9-0003Fb-S5 for ipv6@ietf.org; Sun, 24 Oct 2004 23:42:02 -0400 Received: from www by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLvWl-000PoC-Jh for ipv6@ietf.org; Mon, 25 Oct 2004 03:28:11 +0000 CC: ipv6@ietf.org MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.62 Content-Type: text/plain; charset="utf-8" RT-Originator: h.soliman@flarion.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.11 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #260 Message-Id: Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2461bis@rt.psg.com Date: Mon, 25 Oct 2004 03:28:11 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [psg.com #260] NC entries set to STALE X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2461bis@rt.psg.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Issue description: An NA with O=0, S=0, and no LLAO can cause neighbor cache entries to be marked STALE. This will cause NUD to be performed on the address. See section 7.2.5. => This was a simple editorial change in 7.2.5. Starting from the third paragraph, this is how section 7.2.5 now reads: In any state, if the link layer has addresses and an unsolicited Neighbor Advertisement is received with the O flag cleared, with no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. Otherwise, the receiving node performs the following steps: This issue is now resolved. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 24 23:34:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25721 for ; Sun, 24 Oct 2004 23:34:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvq7-0003MV-1C for ipv6-web-archive@ietf.org; Sun, 24 Oct 2004 23:48:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvXR-0002aZ-RB; Sun, 24 Oct 2004 23:28:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvWn-0002WA-JL for ipv6@megatron.ietf.org; Sun, 24 Oct 2004 23:28:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25273 for ; Sun, 24 Oct 2004 23:28:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLvk9-0003Fa-JS for ipv6@ietf.org; Sun, 24 Oct 2004 23:42:02 -0400 Received: from www by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLvWl-000Po9-BF for ipv6@ietf.org; Mon, 25 Oct 2004 03:28:11 +0000 CC: ipv6@ietf.org MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.62 Content-Type: text/plain; charset="utf-8" RT-Originator: h.soliman@flarion.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.11 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #260 Message-Id: Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2461bis@rt.psg.com Date: Mon, 25 Oct 2004 03:28:11 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [psg.com #260] NC entries set to STALE X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2461bis@rt.psg.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Issue description: An NA with O=0, S=0, and no LLAO can cause neighbor cache entries to be marked STALE. This will cause NUD to be performed on the address. See section 7.2.5. => This was a simple editorial change in 7.2.5. Starting from the third paragraph, this is how section 7.2.5 now reads: In any state, if the link layer has addresses and an unsolicited Neighbor Advertisement is received with the O flag cleared, with no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. Otherwise, the receiving node performs the following steps: This issue is now resolved. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 25 01:33:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04819 for ; Mon, 25 Oct 2004 01:33:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxhk-0005h4-2t for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 01:47:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxSJ-0007DF-Nb; Mon, 25 Oct 2004 01:31:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxRd-00079m-2o for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 01:31:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04661 for ; Mon, 25 Oct 2004 01:30:59 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxf0-0005e8-EQ for ipv6@ietf.org; Mon, 25 Oct 2004 01:44:51 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 01:30:28 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 01:30:28 -0400 Message-ID: Thread-Topic: Comments for rc2461bis Thread-Index: AcR6QbP1FYabhAlQQ46As5x23i3NmBABYjmg From: "Soliman, Hesham" To: "Elwyn Davies" , X-OriginalArrivalTime: 25 Oct 2004 05:30:28.0355 (UTC) FILETIME=[BCAA5D30:01C4BA53] X-Spam-Score: 0.9 (/) X-Scan-Signature: 9ba883ba659fcd62a05a0ed0aea6f612 Subject: RE: Comments for rc2461bis 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="===============1704599821==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b8a1197ccd66a793eeb911fe8a37f5bd This is a multi-part message in MIME format. --===============1704599821== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BA53.BC904580" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BA53.BC904580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Elwyn,=20 =20 Thanks for your detailed review. =20 Sorry for the late response, comments inline. I addressed all = editorials.=20 BTW, I'd appreciate it if you could respond in text format. Substantive comments:=20 S2.2 and S3:=20 The note after the NBMA definition says that '...all link types = (including NBMA) are expected to provide multicast service for IP...'. A naive interpretation of the phrase in S3 'On multicast-capable = links...' (just after the Redirect bullet) in conjunction with the = previous note might take it that actually all links are = multicast-capable. The term should be explicitly defined so as to = explicitly exclude NBMA and any other sort of links that this phrase is = not supposed to apply to - or to allow it to be done optionally on this = sort of link - the current wordings are too vague. This is also related = to the comment on 6.2.1 below.=20 =3D> I'm not sure I see the problem you see (and I looked at the 2462 = thread). We can make the=20 link definition for multicast, a definition for "multicast capable". But = apart from that the current spec states refers to other docs in the introduction when it discusses = NBMA links. The text you refer to above is talking about multicast services, which = is a different issue. So for now, I'll s/multicast/multicast capable in 2.2 and that should do = the job IMO. =20 S3: Technically DAD is not defined in 2461 but in 2462 =20 =3D> Changed it to : Address Autoconfiguration: Introduces the mechanisms needed in = order to allow nodes to automatically configure =20 an address for an interface . =20 S3.1: Next to last para: 'Using the Hop Limit equal to 255 trick' is = rather informal and also what the trick is should either be defined here = or a forward ref given as this is the first mention of this 'trick'. = [Metaquestion: should the same trick be used in MLD?]=20 =3D> Changed the wording there. I don't really have an answer to the MLD = question right now. Interesting point=20 though.=20 S4.1, 4.2, 4.3, 4.4 and 4.5: I believe that in many circumstances the = addressing of the ND packets does not meet the standard scope = consistency rules for source and destination addresses. This is not a = problem but it would probably be wise to add a note that these packets = should not be subject to such consistency checks.=20 =3D> Done. I added the following text to the end of S2.3: Note that this specification does not strictly comply with the = consistency requirements for the scopes of source and destination = addresses. It is possible in some cases for hosts to use a source = address of a larger scope than the destination address in the IPv6 = header.=20 S4.6, S4.6.1, S4.6.3: Option lengths are measured in units of 8 octets = but nothing is said about padding out options if the content does not = make it up to an even multiple of 8 bytes. Some link layer addresses = (s4.6.1) might not be obliging and there is no guarantee that the packet = body in 4.6.3 will be an obliging multiple of 8 octets.=20 =3D> S4.6 now starts with the following paragraph: Neighbor Discovery messages include zero or more options, some of = which may appear multiple times in the same message. Options should be = padded when necessary to ensure that they end on their natural 64-bit = boundaries. All options are of the form:=20 [S5: Prefix List: Having removed the 'assume it is on link' if no = routers, it might be useful to allow a prefix to be inserted into the = prefix list by manual configuration when dealing with a single link = net.]=20 =3D> Is this really needed? Isn't enough to be able to configure an = address given that the next hop determination is based on a longest prefix match? I won't add this = unless you see a reason for it.=20 s5.2: It ought to be stated that if the default router list is empty = then off-link unicast packets will have to be dropped and an = 'unreachable' ICMP message sent.[whether the packet ought to have got as = far as the interface processing is a moot point].=20 =3D> Hmmm. How does this work in the case where the destination = address is on the other end of an IPv4 tunnel and there is no default router in the list? This = is why the onlink assumption was removed.=20 s 6.3.4: (next to last para on p49): The restriction in setting the = LinkMTU to be not greater than the default value specified in the link = type specific document is odd and actually inconsistent with the = statements in RFC2590 for example (which allows LinkMTUs both larger and = smaller than the default).=20 =3D> I don't know why this restriction was put, so I'll start a separate = thread on this issue. =20 S6.3.6 (Item 3) should be removed (agreed elsewhere) - but it should be = emphasised that this may result in the default router list being empty=20 =3D> Done.=20 S6.1, 7.1, 8.1: S7.1 refers to checking that if the message has an AH = header then it should authenticate correctly: S6.1 and 8.1 should be = consistent with this and there should probably be mention of = authentication with ESP and ensuring that the packet decrypts properly = (or alternatively remove the note from 7.1 perhaps).=20 =3D> I think you meant 8.1. I removed the reference to AH there.=20 s6.2.1: What is a 'multicast interface'? Is it a 'multicast-capable' = interface? But most of this ought to apply to any interface on a router = if it does ND. This is tied into the lack of precision as to what a = 'multicast capable' interface is.=20 =3D> I removed "multicast", it now reads: "For each interface". I think = this is more accurate because it works for any interface where ND is used, including point to point links. Is = this ok? or do you prefer to keep=20 it and instead make it "multicast capable interface" given the = definition of multicast capable in 2.2? S6.2.2, 7.2.1,7.2.8: The expression 'join the multicast group' needs to = be reinforced to explicitly call out the use of MLD i.e. the interface = has to be configured to listen to the multicast address and send the = appropriate MLD Listener message in all cases. It should probably also = be made clear that the the Listener report has to be sent again after = the interface has acquired a preferred address.=20 =20 =3D> 6.2.2 talks about routers joining the all routers multicast = address. This doesn't need MLD,=20 it's a constant.=20 7.2.1 Talks about both, all nodes and the solicited node's multicast = address. I agree with you on the latter and added text to clarify the nodes should use MLD.=20 7.2.8 was updated to include a SHOULD use MLD as was done for 7.2.1. Thanks, Hesham=20 =20 Regards,=20 Elwyn=20 -------------------------------------------------------------------------= ---------=20 Elwyn B Davies=20 Routing and Addressing Strategy Prime & IPv6 Core Team Leader=20 CTO Office, Portfolio Integration Solutions Ready = =20 Nortel Networks plc Email: = elwynd@nortelnetworks.com=20 Harlow Laboratories ESN = 6-742-5498=20 London Road, Harlow, Direct Line = +44-1279-405498=20 Essex, CM17 9NA, UK Fax = +44-1279-402047=20 Registered Office: Maidenhead Office Park, = Westacott Way,=20 Company No. 3937799 Maidenhead, Berkshire, = SSL6 3QH=20 -------------------------------------------------------------------------= ---=20 This message may contain information proprietary to Nortel Networks plc = so any=20 unauthorised disclosure, copying or distribution of its contents is = strictly prohibited.=20 -------------------------------------------------------------------------= ---=20 "The Folly is mostly mine"=20 and the opinions are mine and not those of my employer.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 ------_=_NextPart_001_01C4BA53.BC904580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments for rc2461bis
Elwyn,=20
 
Thanks=20 for your detailed review.
 
Sorry=20 for the late response, comments inline. I addressed all editorials.=20
BTW,=20 I'd appreciate it if you could respond in text = format.

Substantive comments:
S2.2 and S3:
The note = after the NBMA=20 definition says that '...all link types (including NBMA) are expected = to=20 provide multicast service for IP...'.

A naive interpretation of the = phrase in S3=20 'On multicast-capable links...' (just after the Redirect bullet) in=20 conjunction with the previous note might take it that actually all = links are=20 multicast-capable.  The term should be explicitly defined so as = to=20 explicitly exclude NBMA and any other sort of links that this phrase = is not=20 supposed to apply to - or to allow it to be done optionally on this = sort of=20 link - the current wordings are too vague.  This is also related = to the=20 comment on 6.2.1 below. 

=3D> I'm not=20 sure I see the problem you see (and I looked at the 2462 thread). We = can make=20 the

link=20 definition for multicast, a definition for "multicast capable". But = apart from=20 that the current

spec states=20 refers to other docs in the introduction when it discusses NBMA=20 links.

The text you=20 refer to above is talking about multicast services, which is a = different=20 issue.

So for now,=20 I'll s/multicast/multicast capable in 2.2 and that should do the job=20 IMO.

 

S3: Technically DAD is not defined in = 2461 but in=20 2462  

=3D>=20 Changed it to :

Address=20 Autoconfiguration: Introduces the mechanisms needed in

           &n= bsp; =20 order to allow nodes to automatically configure  

       &nbs= p;    =20  an  address for an=20 interface .

 

S3.1: Next to last para:  = 'Using the Hop=20 Limit equal to 255 trick'  is rather informal and also what the = trick is=20 should either be defined here or a forward ref given as this is the = first=20 mention of this 'trick'. [Metaquestion: should the same trick be used = in=20 MLD?] 

=3D> Changed the wording there. I don't really have = an answer=20 to the MLD question right now. Interesting=20 point 

though. 

S4.1, 4.2, 4.3, 4.4 and = 4.5:  I believe=20 that in many circumstances the addressing of the ND packets does not = meet the=20 standard scope consistency rules for source and destination = addresses. =20 This is not a problem but it would probably be wise to add a note that = these=20 packets should not be subject to such consistency checks. 

=3D> Done. I added the following text to the end of = S2.3:

   =20 Note that this specification does not strictly comply with the = consistency=20 requirements for the scopes of source=20 and  destination addresses.=20 It is possible in some cases for hosts to use a source address of a = larger=20 scope than the destination address in the IPv6=20 header. 

S4.6, S4.6.1, S4.6.3: Option = lengths are=20 measured in units of 8 octets but nothing is said about padding out = options if=20 the content does not make it up to an even multiple of 8 bytes.  = Some=20 link layer addresses (s4.6.1) might not be obliging and there is no = guarantee=20 that the packet body in 4.6.3 will be an obliging multiple of 8 = octets. 

=3D> S4.6 now starts with the following=20 paragraph:

Neighbor Discovery messages include zero or more = options,=20 some of =20  which=20 may appear multiple times in the same message.  Options should be padded = when=20 necessary to ensure that they end on their natural 64-bit boundaries. = All=20 options are of the form: 

[S5:  Prefix List:  = Having removed=20 the 'assume it is on link' if no routers, it might be useful to allow = a prefix=20 to be inserted into the prefix list by manual configuration when = dealing with=20 a single link net.] 

=3D> Is this really needed? Isn't enough to be able = to=20 configure an address given that the next = hop

determination is based on a longest prefix match? = I won't add this unless you see a reason for=20 it. 

s5.2: It ought to be stated that = if the=20 default router list is empty then off-link unicast packets will have = to be=20 dropped and an 'unreachable' ICMP message sent.[whether the packet = ought to=20 have got as far as the interface processing is a moot point]. 

=3D>   Hmmm. = How does this=20 work in the case where the destination address is on the=20 other

end of an IPv4 tunnel and there is no = default router=20 in the list? This is why the onlink = assumption

was removed.

s 6.3.4: (next to last para on = p49): =20 The restriction in setting the LinkMTU to be not greater than the = default=20 value specified in the link type specific document is odd and actually = inconsistent with the statements in RFC2590 for example (which allows = LinkMTUs=20 both larger and smaller than the default). 

=3D> I don't know why this restriction was = put, so I'll=20 start a separate thread on this issue.=20  

S6.3.6 (Item 3) should be removed = (agreed=20 elsewhere) - but it should be emphasised that this may result in the = default=20 router list being empty 

=3D> Done. 

S6.1, 7.1, 8.1: S7.1 refers to = checking that=20 if the message has an AH header then it should authenticate = correctly: =20 S6.1 and 8.1 should be consistent with this and there should probably = be=20 mention of authentication with ESP and ensuring that the packet = decrypts=20 properly (or alternatively remove the note from 7.1 perhaps). 

=3D> I think you meant 8.1. I removed the reference = to AH=20 there. 

s6.2.1: What is a 'multicast = interface'? Is=20 it a 'multicast-capable' interface?  But most of this ought to = apply to=20 any interface on a router if it does ND. This is tied into the lack of = precision as to what a 'multicast capable' interface is. 

 =3D> I removed "multicast", it now reads: "For each = interface".=20 I think this is more accurate because it = works

for any interface where ND is used,=20 including point to point links. Is this ok? or do you prefer = to keep=20

it and instead make it "multicast capable = interface"=20 given the definition of multicast capable in = 2.2?

S6.2.2, 7.2.1,7.2.8: The = expression 'join the=20 multicast group' needs to be reinforced to explicitly call out the use = of MLD=20 i.e. the interface has to be configured to listen to the multicast = address and=20 send the appropriate MLD Listener message in all cases. It should = probably=20 also be made clear that the the Listener report has to be sent again = after the=20 interface has acquired a preferred address. 

 

=3D> 6.2.2 talks about routers joining = the all=20 routers multicast address. This doesn't need MLD, =

it's a constant.

7.2.1 Talks about both, all nodes and the = solicited=20 node's multicast address. I agree with you

on the latter and added text to clarify the = nodes=20 should use MLD.

 7.2.8 was updated to include a SHOULD use MLD as was = done for=20 7.2.1.

Thanks,

Hesham 

 

 Regards, =
Elwyn

----------------------------------------------------------------= ------------------=20

Elwyn B Davies

        Routing=20 and Addressing Strategy Prime & IPv6 Core Team Leader =
        CTO = Office,=20 Portfolio Integration      =20         Solutions Ready=20        

        Nortel Networks=20 plc             =         Email: elwynd@nortelnetworks.com
        = Harlow=20 Laboratories    =20        =20        =20        =20 = ESN           &nbs= p;=20         6-742-5498
       =20 London Road, Harlow,   =20        =20        =20         Direct = Line    =20         +44-1279-405498 =
       =20 Essex, CM17 9NA, UK    =20        =20        =20 = Fax           &nbs= p;=20         +44-1279-402047 =
       =20 Registered Office:     =20        =20         Maidenhead Office Park, = Westacott=20 Way,
        Company No. = 3937799    =20        =20         Maidenhead, Berkshire, SSL6 3QH =
----------------------------------------------------------------= ------------=20
This message may = contain information=20 proprietary to Nortel Networks plc so any
unauthorised disclosure, copying or = distribution of its=20 contents is strictly prohibited.
----------------------------------------------------------------= ------------=20
"The Folly is mostly mine" =
and the opinions are mine and not those of my=20 employer.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
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

------_=_NextPart_001_01C4BA53.BC904580-- --===============1704599821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1704599821==-- From ipv6-bounces@ietf.org Mon Oct 25 01:42:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05487 for ; Mon, 25 Oct 2004 01:42:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxpk-0005si-Kf for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 01:55:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxYB-0007os-Pc; Mon, 25 Oct 2004 01:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxWK-0007aR-Ud for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 01:35:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05051 for ; Mon, 25 Oct 2004 01:35:51 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxjj-0005jE-6w for ipv6@ietf.org; Mon, 25 Oct 2004 01:49:43 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 01:35:21 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 01:35:21 -0400 Message-ID: Thread-Topic: Link MTU restriction in 2461 Thread-Index: AcS6VGSYjvZi3TOoQh2qtrQRKHGyDg== From: "Soliman, Hesham" To: X-OriginalArrivalTime: 25 Oct 2004 05:35:21.0871 (UTC) FILETIME=[6B9D59F0:01C4BA54] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: narten@us.ibm.com, Erik Nordmark Subject: Link MTU restriction in 2461 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Hi,=20 The following comment was received from Elwyn Davies: S6.3.4: (next to last para on p49): The restriction in setting the = LinkMTU to be not greater than the default value specified in the link = type specific document is odd and actually inconsistent with the = statements in RFC2590 for example (which allows LinkMTUs both larger = and smaller than the default).=20 I'm not sure about the history of this so I wanted to get some=20 feedback from the authors or other members if possible. It is=20 true that RFC 2590 allows for MTUs to be larger or smaller than the default, provided that they're above 1280.=20 Thoughts? Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Mon Oct 25 02:18:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21636 for ; Mon, 25 Oct 2004 02:18:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyOm-0006Wk-K8 for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 02:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLy8q-0006lL-UO; Mon, 25 Oct 2004 02:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLy7H-00067y-Gf for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 02:14:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20865 for ; Mon, 25 Oct 2004 02:14:01 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyKe-0006TA-QU for ipv6@ietf.org; Mon, 25 Oct 2004 02:27:54 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9P6Dvui014375; Mon, 25 Oct 2004 00:13:58 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9P6DsJQ001271; Mon, 25 Oct 2004 08:13:55 +0200 (MEST) Message-ID: <417C99CE.3080704@sun.com> Date: Sun, 24 Oct 2004 23:14:38 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: narten@us.ibm.com, ipv6@ietf.org Subject: Re: Link MTU restriction in 2461 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Soliman, Hesham wrote: > Hi, > > The following comment was received from Elwyn Davies: > > S6.3.4: (next to last para on p49): The restriction in setting the LinkMTU to be not greater than the default value specified in the link type specific document is odd and actually inconsistent with the statements in RFC2590 for example (which allows LinkMTUs both larger and smaller than the default). > > I'm not sure about the history of this so I wanted to get some > feedback from the authors or other members if possible. It is > true that RFC 2590 allows for MTUs to be larger or smaller > than the default, provided that they're above 1280. I think this is an error in RFC 2461. To correct it there is perhaps a need to make the destinction between the default MTU and the upper limit. In the case of Ethernet (ignoring jumboframes) both values are the same which is why the wording is off. So if the IP-over-foo specification has a hard upper limit, then MTU options larger than this should be ignored. But is it ok for the MTU option to be larger than the default MTU. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Oct 25 02:23:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22617 for ; Mon, 25 Oct 2004 02:23:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyTz-0006fP-RR for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 02:37:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyEs-0000yS-Aq; Mon, 25 Oct 2004 02:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyBu-0008Dm-Jz for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 02:18:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21719 for ; Mon, 25 Oct 2004 02:18:49 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyPI-0006Wq-4t for ipv6@ietf.org; Mon, 25 Oct 2004 02:32:41 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 02:18:18 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 02:18:18 -0400 Message-ID: Thread-Topic: Link MTU restriction in 2461 Thread-Index: AcS6WdIWvcHS6dn6RnedrKV6aCxumwAAIoig From: "Soliman, Hesham" To: "Erik Nordmark" X-OriginalArrivalTime: 25 Oct 2004 06:18:18.0433 (UTC) FILETIME=[6B5D8310:01C4BA5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: narten@us.ibm.com, ipv6@ietf.org Subject: RE: Link MTU restriction in 2461 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Thanks. > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: Monday, October 25, 2004 2:15 AM > To: Soliman, Hesham > Cc: ipv6@ietf.org; narten@us.ibm.com > Subject: Re: Link MTU restriction in 2461 >=20 >=20 > Soliman, Hesham wrote: > > Hi,=20 > >=20 > > The following comment was received from Elwyn Davies: > >=20 > > S6.3.4: (next to last para on p49): The restriction in=20 > setting the LinkMTU to be not greater than the=20 > default value specified in the link type specific document=20 > is odd and actually inconsistent with the statements in=20 > RFC2590 for example (which allows LinkMTUs both larger and=20 > smaller than the default).=20 > >=20 > > I'm not sure about the history of this so I wanted to get some=20 > > feedback from the authors or other members if possible. It is=20 > > true that RFC 2590 allows for MTUs to be larger or smaller > > than the default, provided that they're above 1280.=20 >=20 > I think this is an error in RFC 2461. To correct it there is=20 > perhaps a=20 > need to make the destinction between the default MTU and the upper=20 > limit. In the case of Ethernet (ignoring jumboframes) both=20 > values are=20 > the same which is why the wording is off. >=20 > So if the IP-over-foo specification has a hard upper limit, then MTU=20 > options larger than this should be ignored. But is it ok for the MTU=20 > option to be larger than the default MTU. >=20 > Erik >=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 Mon Oct 25 10:51:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01520 for ; Mon, 25 Oct 2004 10:51:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6PC-0008C5-T6 for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 11:05:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM68L-0003XX-Eq; Mon, 25 Oct 2004 10:47:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM63o-0003An-TJ for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 10:43:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01098 for ; Mon, 25 Oct 2004 10:42:58 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6HH-000816-GL for ipv6@ietf.org; Mon, 25 Oct 2004 10:56:56 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.8858117; Mon, 25 Oct 2004 10:41:44 -0400 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: From: Brian Haberman Date: Mon, 25 Oct 2004 10:41:45 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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="===============1969341331==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============1969341331== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-149021611; protocol="application/pkcs7-signature" --Apple-Mail-1-149021611 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This is the start of a 1-week IPv6 working group last call for recycling: Title : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, et al. Filename : draft-ietf-ipngwg-icmp-v3-05.txt Pages : 26 Date : 2004-10-22 at Draft Standard. This LC is aimed at ensuring resolution of all issues raised during the previous last call. Substantive comments should be directed to the mailing. This last call will end on 11/01/2004. Regards, Bob & Brian --Apple-Mail-1-149021611 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI1MTQ0MTQ2WjAjBgkqhkiG9w0B CQQxFgQU9pBT8SVod5oPTuNSqMmwPdccY78weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEATVmvPDKnm3iml4qjIcQdHT1sciTZI/amQ1ihvRG1YH5tY2TK0yTM/pV0Spns78vQJ3EL dPS1/nv5RDd8IswSLOPIOkkj+QrIit+y4lH/FqVpMFmNwo0Sk3cr1WFghCxIB3qexeVPeMv8Ue/M z+4NaFaBKlZn2YroXM0Z9w7JxGPYdkO0KGJD4HnBs00bMbwraLQHgC4IT3mqSAiaHOJBiskg3XTT POHJZgxEPse0MNNZ0FtjCGPLQfqRuYjI6urwgjElbwWww09ftwhU/r7v56Ksiw81Il4A6NIj97k7 7cLWSh82me7fGA/TAJbxYyqsOVpijwcv584tdfSlhO7+KgAAAAAAAA== --Apple-Mail-1-149021611-- --===============1969341331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1969341331==-- From ipv6-bounces@ietf.org Mon Oct 25 11:00:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02344 for ; Mon, 25 Oct 2004 11:00:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6Y6-0008LU-4r for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 11:14:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6Jf-0005Ke-G0; Mon, 25 Oct 2004 10:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6By-0003oi-Gi for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 10:51:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01538 for ; Mon, 25 Oct 2004 10:51:23 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6PR-0008Bn-Ir for ipv6@ietf.org; Mon, 25 Oct 2004 11:05:21 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.8858574; Mon, 25 Oct 2004 10:49:41 -0400 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <305FC29E-2695-11D9-A7B8-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Mon, 25 Oct 2004 10:50:18 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: IPv6 WG Last Call:draft-ietf-ipv6-host-load-sharing-03.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="===============0970754892==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============0970754892== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-149534538; protocol="application/pkcs7-signature" --Apple-Mail-2-149534538 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This is the start of a 1-week WG Last Call on advancing: Title : IPv6 Host to Router Load Sharing Author(s) : R. Hinden, D. Thaler Filename : draft-ietf-ipv6-host-load-sharing-03.txt Pages : 6 Date : 2004-10-21 as a Proposed Standard. The aim of this LC is to ensure resolution of all issues raised during the previous last call. Substantive comments should be directed to the mailing list. This last call will end on 11/01/2004. Regards, Bob & Brian --Apple-Mail-2-149534538 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI1MTQ1MDE5WjAjBgkqhkiG9w0B CQQxFgQUUp98OffIiC0lAUA11d8ONoN91i8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEASd5TYmZV9zg67yVcn5Eq8mHrfETlRidLpvanu0dvTgG9nzrJJIi+hNFvn4bdH288M8Jn 1P784GrrTl3qM8/+5uWOPvbBRQt/pW/ZFpMxU5pOTRcNSgqLmRl1B01L3bsW+osFOLNLT8YCOOrI gVatYVk3h0dZapVTCa8ojsNcroYcn+GybZgzt41YRoYjHIojWy85bhGXojg+gfeZYHu0gp1ogwKN GcrL3IwopRg4/5V8u9Gxg7tRG/XNWk1C7UxFDJYQOnOTk3Q9bCRv9hw3bxoNYM+otwXJNuRa4nLr Q8mDN5OUsxf1oilwK22wmuAlX21Z8FFwsrryF2mWf81j/AAAAAAAAA== --Apple-Mail-2-149534538-- --===============0970754892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0970754892==-- From ipv6-bounces@ietf.org Mon Oct 25 13:51:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18173 for ; Mon, 25 Oct 2004 13:51:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM9E7-00043N-Lu for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 14:05:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8tP-0002DO-Pm; Mon, 25 Oct 2004 13:44:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8oW-0001l1-QS for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 13:39:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17228 for ; Mon, 25 Oct 2004 13:39:23 -0400 (EDT) Received: from web80501.mail.yahoo.com ([66.218.79.71]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CM91y-0003o6-3w for ipv6@ietf.org; Mon, 25 Oct 2004 13:53:21 -0400 Message-ID: <20041025173849.73568.qmail@web80501.mail.yahoo.com> Received: from [63.197.18.101] by web80501.mail.yahoo.com via HTTP; Mon, 25 Oct 2004 10:38:49 PDT Date: Mon, 25 Oct 2004 10:38:49 -0700 (PDT) From: Fred Templin To: Brian Haberman , IPv6 WG In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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="===============1164690019==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f --===============1164690019== Content-Type: multipart/alternative; boundary="0-13859719-1098725929=:70367" --0-13859719-1098725929=:70367 Content-Type: text/plain; charset=us-ascii I would like to see a new Code added to the Parameter Problem Message Type ([ICMPv6], section 3.4) whereby the end host or a router on the path can inform the source that unspecified data corruption was encountered in the packet. The code definition should appear as a new item at the end of the current list as follows: 3 - unspecified data corruption encountered Note that in this case, the Pointer might point to a byte offset in the packet body beyond the end of the IPv6 header and header extensions. The Description text should therefore also be re-worded slightly to allow for this fact as follows: "If an IPv6 node processing a packet finds a problem such that it cannot complete processing the packet, it MUST discard the packet and SHOULD send an ICMPv6 Parameter Problem message to the packet's source, indicating the type and location of the problem. The pointer identifies the octet of the original packet where the error was detected. For example, an ICMPv6 message with Type field = 4, Code field = 1, and Pointer field = 40 would indicate that the IPv6 extension header following the IPv6 header of the original packet holds an unrecognized Next Header field value." Fred L. Templin osprey67@yahoo.com Brian Haberman wrote: All, This is the start of a 1-week IPv6 working group last call for recycling: Title : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, et al. Filename : draft-ietf-ipngwg-icmp-v3-05.txt Pages : 26 Date : 2004-10-22 at Draft Standard. This LC is aimed at ensuring resolution of all issues raised during the previous last call. Substantive comments should be directed to the mailing. This last call will end on 11/01/2004. Regards, Bob & Brian > ATTACHMENT part 1.2 application/pkcs7-signature name=smime.p7s -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-13859719-1098725929=:70367 Content-Type: text/html; charset=us-ascii
I would like to see a new Code added to the Parameter Problem Message
Type ([ICMPv6], section 3.4) whereby the end host or a router on the path
can inform the source that unspecified data corruption was encountered
in the packet. The code definition should appear as a new item at the
end of the current list as follows:
 
    3 - unspecified data corruption encountered
 
Note that in this case, the Pointer might point to a byte offset in the
packet body beyond the end of the IPv6 header and header extensions.
The Description text should therefore also be re-worded slightly to allow
for this fact as follows:

   "If an IPv6 node processing a packet finds a problem such that it cannot
   complete processing the packet, it MUST discard the packet and SHOULD
   send an ICMPv6 Parameter Problem message to the packet's source,
   indicating the type and location of the problem.

   The pointer identifies the octet of the original packet where the error was
   detected.  For example, an ICMPv6 message with Type field = 4, Code
   field = 1, and Pointer field = 40 would indicate that the IPv6 extension
   header following the IPv6 header of the original packet holds an
   unrecognized Next Header field value."

Fred L. Templin
 
  

Brian Haberman <brian@innovationslab.net> wrote:
All,
This is the start of a 1-week IPv6 working group last call for
recycling:

Title : Internet Control Message Protocol (ICMPv6)for the
Internet Protocol Version 6 (IPv6) Specification
Author(s) : A. Conta, et al.
Filename : draft-ietf-ipngwg-icmp-v3-05.txt
Pages : 26
Date : 2004-10-22

at Draft Standard. This LC is aimed at ensuring resolution of all
issues raised during the previous last call. Substantive comments
should be directed to the mailing. This last call will end on
11/01/2004.

Regards,
Bob & Brian

> ATTACHMENT part 1.2 application/pkcs7-signature name=smime.p7s
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-13859719-1098725929=:70367-- --===============1164690019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1164690019==-- From ipv6-bounces@ietf.org Mon Oct 25 18:20:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29189 for ; Mon, 25 Oct 2004 18:20:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDQA-0006iZ-Qb for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 18:34:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBSV-0001za-2u; Mon, 25 Oct 2004 16:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB2v-0005GD-FG; Mon, 25 Oct 2004 16:02:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29055; Mon, 25 Oct 2004 16:02:23 -0400 (EDT) Message-Id: <200410252002.QAA29055@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 25 Oct 2004 16:02:22 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-privacy-addrs-v2-01.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --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 : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-privacy-addrs-v2-01.txt Pages : 29 Date : 2004-10-25 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-01.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-ipv6-privacy-addrs-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-privacy-addrs-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162057.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Oct 25 18:25:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00466 for ; Mon, 25 Oct 2004 18:25:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDUm-0006zi-Af for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 18:39:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBSZ-00024E-OO; Mon, 25 Oct 2004 16:28:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB39-0005OT-NE; Mon, 25 Oct 2004 16:02:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29115; Mon, 25 Oct 2004 16:02:37 -0400 (EDT) Message-Id: <200410252002.QAA29115@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 25 Oct 2004 16:02:37 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-07.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-addr-07.txt Pages : 16 Date : 2004-10-25 This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.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-ipv6-unique-local-addr-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unique-local-addr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162102.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Oct 25 20:08:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22160 for ; Mon, 25 Oct 2004 20:08:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMF6i-0005DT-Rm for ipv6-web-archive@ietf.org; Mon, 25 Oct 2004 20:22:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEYs-0006TC-En; Mon, 25 Oct 2004 19:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDzJ-0004ph-8e for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 19:10:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11033 for ; Mon, 25 Oct 2004 19:10:49 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMECq-0001op-SV for ipv6@ietf.org; Mon, 25 Oct 2004 19:24:53 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 19:10:20 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 19:10:21 -0400 Message-ID: Thread-Topic: Link MTU restriction in 2461 Thread-Index: AcS6WdIWvcHS6dn6RnedrKV6aCxumwAjYcQA From: "Soliman, Hesham" To: X-OriginalArrivalTime: 25 Oct 2004 23:10:20.0990 (UTC) FILETIME=[CCD465E0:01C4BAE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: 2461bis update 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Folks,=20 Last night I submitted an updated 2461bis draft.=20 I believe all issues raised were addressed in this update. Please have a look at the draft when it appears on the=20 web and look for comments you might have raised and=20 were either not responded to, or agreed to be updated but were not. If I missed any of those please let me=20 know and send comments to the list. I think the draft is now ready for WG LC. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Oct 26 03:30:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06094 for ; Tue, 26 Oct 2004 03:30:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMM0c-0004RR-Sa for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 03:44:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMLid-0004sq-Ev; Tue, 26 Oct 2004 03:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMLgn-0003zu-V9 for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 03:24:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05499 for ; Tue, 26 Oct 2004 03:24:16 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMLuP-0004Js-HT for ipv6@ietf.org; Tue, 26 Oct 2004 03:38:22 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9Q7NNG14662; Tue, 26 Oct 2004 09:23:23 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 09:23:22 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458180@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Soliman, Hesham'" , ipv6@ietf.org Date: Tue, 26 Oct 2004 09:23:22 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Subject: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comme nts for rc2461bis] 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Hi, Hesham, Thanks for the updates - for the majority I'll check the draft when it appears. I split out the multicast and prefix issues into separate threads. Regards, Elwyn PS Hope my stupid mail server remembers to send this as plain text. E -----Original Message----- From: Soliman, Hesham [mailto:H.Soliman@flarion.com] Sent: 25 October 2004 06:30 To: Davies, Elwyn [HAL02:0S00:EXCH]; ipv6@ietf.org Subject: RE: Comments for rc2461bis Elwyn, Thanks for your detailed review. Sorry for the late response, comments inline. I addressed all editorials. BTW, I'd appreciate it if you could respond in text format. Substantive comments: S2.2 and S3: The note after the NBMA definition says that '...all link types (including NBMA) are expected to provide multicast service for IP...'. A naive interpretation of the phrase in S3 'On multicast-capable links...' (just after the Redirect bullet) in conjunction with the previous note might take it that actually all links are multicast-capable. The term should be explicitly defined so as to explicitly exclude NBMA and any other sort of links that this phrase is not supposed to apply to - or to allow it to be done optionally on this sort of link - the current wordings are too vague. This is also related to the comment on 6.2.1 below. => I'm not sure I see the problem you see (and I looked at the 2462 thread). We can make the link definition for multicast, a definition for "multicast capable". But apart from that the current spec states refers to other docs in the introduction when it discusses NBMA links. The text you refer to above is talking about multicast services, which is a different issue. So for now, I'll s/multicast/multicast capable in 2.2 and that should do the job IMO. S3: Technically DAD is not defined in 2461 but in 2462 => Changed it to : Address Autoconfiguration: Introduces the mechanisms needed in order to allow nodes to automatically configure an address for an interface . S3.1: Next to last para: 'Using the Hop Limit equal to 255 trick' is rather informal and also what the trick is should either be defined here or a forward ref given as this is the first mention of this 'trick'. [Metaquestion: should the same trick be used in MLD?] => Changed the wording there. I don't really have an answer to the MLD question right now. Interesting point though. S4.1, 4.2, 4.3, 4.4 and 4.5: I believe that in many circumstances the addressing of the ND packets does not meet the standard scope consistency rules for source and destination addresses. This is not a problem but it would probably be wise to add a note that these packets should not be subject to such consistency checks. => Done. I added the following text to the end of S2.3: Note that this specification does not strictly comply with the consistency requirements for the scopes of source and destination addresses. It is possible in some cases for hosts to use a source address of a larger scope than the destination address in the IPv6 header. S4.6, S4.6.1, S4.6.3: Option lengths are measured in units of 8 octets but nothing is said about padding out options if the content does not make it up to an even multiple of 8 bytes. Some link layer addresses (s4.6.1) might not be obliging and there is no guarantee that the packet body in 4.6.3 will be an obliging multiple of 8 octets. => S4.6 now starts with the following paragraph: Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries. All options are of the form: [S5: Prefix List: Having removed the 'assume it is on link' if no routers, it might be useful to allow a prefix to be inserted into the prefix list by manual configuration when dealing with a single link net.] => Is this really needed? Isn't enough to be able to configure an address given that the next hop determination is based on a longest prefix match? I won't add this unless you see a reason for it. s5.2: It ought to be stated that if the default router list is empty then off-link unicast packets will have to be dropped and an 'unreachable' ICMP message sent.[whether the packet ought to have got as far as the interface processing is a moot point]. => Hmmm. How does this work in the case where the destination address is on the other end of an IPv4 tunnel and there is no default router in the list? This is why the onlink assumption was removed. s 6.3.4: (next to last para on p49): The restriction in setting the LinkMTU to be not greater than the default value specified in the link type specific document is odd and actually inconsistent with the statements in RFC2590 for example (which allows LinkMTUs both larger and smaller than the default). => I don't know why this restriction was put, so I'll start a separate thread on this issue. S6.3.6 (Item 3) should be removed (agreed elsewhere) - but it should be emphasised that this may result in the default router list being empty => Done. S6.1, 7.1, 8.1: S7.1 refers to checking that if the message has an AH header then it should authenticate correctly: S6.1 and 8.1 should be consistent with this and there should probably be mention of authentication with ESP and ensuring that the packet decrypts properly (or alternatively remove the note from 7.1 perhaps). => I think you meant 8.1. I removed the reference to AH there. s6.2.1: What is a 'multicast interface'? Is it a 'multicast-capable' interface? But most of this ought to apply to any interface on a router if it does ND. This is tied into the lack of precision as to what a 'multicast capable' interface is. => I removed "multicast", it now reads: "For each interface". I think this is more accurate because it works for any interface where ND is used, including point to point links. Is this ok? or do you prefer to keep it and instead make it "multicast capable interface" given the definition of multicast capable in 2.2? S6.2.2, 7.2.1,7.2.8: The expression 'join the multicast group' needs to be reinforced to explicitly call out the use of MLD i.e. the interface has to be configured to listen to the multicast address and send the appropriate MLD Listener message in all cases. It should probably also be made clear that the the Listener report has to be sent again after the interface has acquired a preferred address. => 6.2.2 talks about routers joining the all routers multicast address. This doesn't need MLD, it's a constant. 7.2.1 Talks about both, all nodes and the solicited node's multicast address. I agree with you on the latter and added text to clarify the nodes should use MLD. 7.2.8 was updated to include a SHOULD use MLD as was done for 7.2.1. Thanks, Hesham Regards, Elwyn ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== ======================================================== 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 26 03:41:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06831 for ; Tue, 26 Oct 2004 03:41:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMBK-0004dX-Q8 for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 03:55:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMLvg-0007Tp-9N; Tue, 26 Oct 2004 03:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMLjR-000522-GS for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 03:27:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05765 for ; Tue, 26 Oct 2004 03:26:59 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMLx3-0004Mw-5r for ipv6@ietf.org; Tue, 26 Oct 2004 03:41:05 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9Q7QSG15625 for ; Tue, 26 Oct 2004 09:26:28 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 09:26:27 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458181@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" Cc: ipv6@ietf.org Date: Tue, 26 Oct 2004 09:26:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Subject: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comme nts for rc2461bis] 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="===============0700332680==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0700332680== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB2D.1AE4D1E4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4BB2D.1AE4D1E4 Content-Type: text/plain Hi. Using the term 'multicast services' around this area is confusing. If the link MUST provide multicast services maybe that is something that should be in the basic definition of IPv6 (it isn't stated explicitly in RFC2460) rather than in 2461bis. Expanding on what I said originally, one reasonable interpretation of the requirement that all links support multicast services is that they are in some sense 'multicast capable': if you take this view then *all* links are necessarily multicast capable. So I think the problem is that the language doesn't properly convey what I think is the intention: I believe we are trying to distinguish between: - links that provide multicast *as a Layer 2 capability* ('The hardware does multicast') - links that don't, so that the multicast services have to be provided as an overlay Hope this clarifies my point. Regards, Elwyn Original Message ================ S2.2 and S3: The note after the NBMA definition says that '...all link types (including NBMA) are expected to provide multicast service for IP...'. A naive interpretation of the phrase in S3 'On multicast-capable links...' (just after the Redirect bullet) in conjunction with the previous note might take it that actually all links are multicast-capable. The term should be explicitly defined so as to explicitly exclude NBMA and any other sort of links that this phrase is not supposed to apply to - or to allow it to be done optionally on this sort of link - the current wordings are too vague. This is also related to the comment on 6.2.1 below. => I'm not sure I see the problem you see (and I looked at the 2462 thread). We can make the link definition for multicast, a definition for "multicast capable". But apart from that the current spec states refers to other docs in the introduction when it discusses NBMA links. The text you refer to above is talking about multicast services, which is a different issue. So for now, I'll s/multicast/multicast capable in 2.2 and that should do the job IMO. ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== ------_=_NextPart_001_01C4BB2D.1AE4D1E4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RFC2461bis: Multicast capable vs Multicast Service [was RE: = Comments for rc2461bis]

Hi.

Using the term 'multicast services' around this area = is confusing.  If the link MUST provide multicast services maybe = that is something that should be in the basic definition of IPv6 (it = isn't stated explicitly in RFC2460) rather than in 2461bis.

Expanding on what I said originally, one reasonable = interpretation of the requirement that all links support multicast = services is that they are in some sense 'multicast capable': if you = take this view then *all* links are necessarily multicast = capable.

So I think the problem is that the language doesn't = properly convey what I think is the intention: I believe we are trying = to distinguish between:

- links that provide multicast *as a Layer 2 = capability* ('The hardware does multicast')
- links that don't, so that the multicast services = have to be provided as an overlay

Hope this clarifies my point.

Regards,
Elwyn

Original Message
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
S2.2 and S3:
The note after the NBMA definition says that '...all = link types (including NBMA) are expected to provide multicast service = for IP...'.

A naive interpretation of the phrase in S3 'On = multicast-capable links...' (just after the Redirect bullet) in = conjunction with the previous note might take it that actually all = links are multicast-capable.  The term should be explicitly = defined so as to explicitly exclude NBMA and any other sort of links = that this phrase is not supposed to apply to - or to allow it to be = done optionally on this sort of link - the current wordings are too = vague.  This is also related to the comment on 6.2.1 below. =

=3D> I'm not sure I see the problem you see (and I = looked at the 2462 thread). We can make the

link definition for multicast, a definition for = "multicast capable". But apart from that the current

spec states refers to other docs in the introduction = when it discusses NBMA links.

The text you refer to above is talking about = multicast services, which is a different issue.

So for now, I'll s/multicast/multicast capable in 2.2 = and that should do the job IMO.




---------------------------------------------------------------= -------------------

Elwyn B Davies

        Routing = and Addressing Strategy Prime & IPv6 Core Team Leader
        CTO = Office, Portfolio Integration       =         Solutions Ready =        

        Nortel = Networks plc     =         =         Email: = elwynd@nortelnetworks.com
        Harlow = Laboratories     =         =         =         = ESN           &nb= sp;         6-742-5498
        London = Road, Harlow,    =         =         =         Direct = Line             = +44-1279-405498
        Essex, = CM17 9NA, UK     =         =         = Fax           &nb= sp;         +44-1279-402047
        = Registered Office:      =         =         Maidenhead Office Park, = Westacott Way,
        Company = No. 3937799     =         =         Maidenhead, Berkshire, SSL6 = 3QH
---------------------------------------------------------------= -------------
This message may contain information proprietary to = Nortel Networks plc so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.
---------------------------------------------------------------= -------------
"The Folly is mostly mine"
and the opinions are mine and not those of my = employer.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


------_=_NextPart_001_01C4BB2D.1AE4D1E4-- --===============0700332680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0700332680==-- From ipv6-bounces@ietf.org Tue Oct 26 04:18:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09113 for ; Tue, 26 Oct 2004 04:18:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMl4-0005Lk-2T for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 04:32:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMNv-0004xr-9H; Tue, 26 Oct 2004 04:08:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMM7-0004gH-1e for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 04:06:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08368 for ; Tue, 26 Oct 2004 04:06:56 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMZi-0005A5-0b for ipv6@ietf.org; Tue, 26 Oct 2004 04:21:03 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9Q86L302467; Tue, 26 Oct 2004 10:06:21 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 10:06:20 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458182@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Soliman, Hesham'" Date: Tue, 26 Oct 2004 10:06:20 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "'ipv6@ietf.org'" Subject: RFC2461bis: Empty default router lists [was: RE: Comments for rc 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi. Quoting from S5.2: Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6). So if there are no routers admitting to be connected to the link and the prefix list is empty (no routers to fill it), what happens here? Presumably the longest prefix match will fail implying that the address is off link. Hence we have to find a router, but there isn't one. What do we do with the packet? With a point-to-point link (like the tunnels) we could just stuff the packet down the link and hand off the decision to the other end. For an isolated multiaccess link the decision is not so simple: Just having our own address doesn't allow us to decide whether any other address is on link, so if the destination is not in the neighbor cache already what do we do? Toss the packet or assume it is on-link? Being able to configure an on-link prefix would solve the problem IMO. Am I missing something here? Regards, elwyn Original Message ================ [S5: Prefix List: Having removed the 'assume it is on link' if no routers, it might be useful to allow a prefix to be inserted into the prefix list by manual configuration when dealing with a single link net.] => Is this really needed? Isn't enough to be able to configure an address given that the next hop determination is based on a longest prefix match? I won't add this unless you see a reason for it. s5.2: It ought to be stated that if the default router list is empty then off-link unicast packets will have to be dropped and an 'unreachable' ICMP message sent.[whether the packet ought to have got as far as the interface processing is a moot point]. => Hmmm. How does this work in the case where the destination address is on the other end of an IPv4 tunnel and there is no default router in the list? This is why the onlink assumption was removed. ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 26 04:38:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10900 for ; Tue, 26 Oct 2004 04:38:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMN3z-0005pl-Q1 for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 04:52:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMo3-0001tg-VY; Tue, 26 Oct 2004 04:35:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMil-0000qt-Kg for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 04:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10289 for ; Tue, 26 Oct 2004 04:30:21 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMwM-0005b2-O3 for ipv6@ietf.org; Tue, 26 Oct 2004 04:44:28 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9Q8TdG08717; Tue, 26 Oct 2004 11:29:39 +0300 Date: Tue, 26 Oct 2004 11:29:39 +0300 (EEST) From: Pekka Savola To: Elwyn Davies In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D458182@znsgy0k3.europe.nortel.com> Message-ID: References: <8F20221FB47FD51190AD00508BCF36BA0D458182@znsgy0k3.europe.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "'Soliman, Hesham'" , "'ipv6@ietf.org'" Subject: Re: RFC2461bis: Empty default router lists [was: RE: Comments for rc 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi, On Tue, 26 Oct 2004, Elwyn Davies wrote: > Quoting from S5.2: > > Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or > off-link. If the destination is on-link, the next-hop address is the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List (following the rules > described in Section 6.3.6). > > So if there are no routers admitting to be connected to the link and the > prefix list is empty (no routers to fill it), what happens here? Presumably > the longest prefix match will fail implying that the address is off link. > Hence we have to find a router, but there isn't one. What do we do with the > packet? > > With a point-to-point link (like the tunnels) we could just stuff the packet > down the link and hand off the decision to the other end. For an isolated > multiaccess link the decision is not so simple: Just having our own address > doesn't allow us to decide whether any other address is on link, so if the > destination is not in the neighbor cache already what do we do? Toss the > packet or assume it is on-link? Being able to configure an on-link prefix > would solve the problem IMO. > > Am I missing something here? Maybe some text needs to be updated to reflect the fact that in the previous spec, if the default router list was empty, the packet was tossed on the link ("onlink assumption"), which has now been removed. If there is no default router, and the destination address isn't in prefix, then the host has no route to the destination, and likely returns an internal ICMP error message. -- 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 Tue Oct 26 04:52:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12860 for ; Tue, 26 Oct 2004 04:52:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNI2-0006ET-8Z for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 05:06:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMvo-0004Ne-M0; Tue, 26 Oct 2004 04:43:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMsN-0003Kd-PE for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 04:40:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11150 for ; Tue, 26 Oct 2004 04:40:17 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMN5y-0005ry-VO for ipv6@ietf.org; Tue, 26 Oct 2004 04:54:24 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9Q8dN309661; Tue, 26 Oct 2004 10:39:24 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 10:39:22 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458184@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Soliman, Hesham'" Date: Tue, 26 Oct 2004 10:39:22 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "'ipv6@ietf.org'" Subject: RFC2461bis: Empty default router lists [was: RE: Comments for rc 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi. Quoting from S5.2: Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6). So if there are no routers admitting to be connected to the link and the prefix list is empty (no routers to fill it), what happens here? Presumably the longest prefix match will fail implying that the address is off link. Hence we have to find a router, but there isn't one. What do we do with the packet? With a point-to-point link (like the tunnels) we could just stuff the packet down the link and hand off the decision to the other end. For an isolated multiaccess link the decision is not so simple: Just having our own address doesn't allow us to decide whether any other address is on link, so if the destination is not in the neighbor cache already what do we do? Toss the packet or assume it is on-link? Being able to configure an on-link prefix would solve the problem IMO. Am I missing something here? Regards, elwyn Original Message ================ [S5: Prefix List: Having removed the 'assume it is on link' if no routers, it might be useful to allow a prefix to be inserted into the prefix list by manual configuration when dealing with a single link net.] => Is this really needed? Isn't enough to be able to configure an address given that the next hop determination is based on a longest prefix match? I won't add this unless you see a reason for it. s5.2: It ought to be stated that if the default router list is empty then off-link unicast packets will have to be dropped and an 'unreachable' ICMP message sent.[whether the packet ought to have got as far as the interface processing is a moot point]. => Hmmm. How does this work in the case where the destination address is on the other end of an IPv4 tunnel and there is no default router in the list? This is why the onlink assumption was removed. ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 26 04:54:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13133 for ; Tue, 26 Oct 2004 04:54:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNK0-0006IG-QV for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 05:08:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMvv-0004OS-9L; Tue, 26 Oct 2004 04:43:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMsd-0003ML-QP for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 04:40:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11240 for ; Tue, 26 Oct 2004 04:40:33 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMN6G-0005sY-AH for ipv6@ietf.org; Tue, 26 Oct 2004 04:54:40 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9Q8e2309821; Tue, 26 Oct 2004 10:40:02 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 10:40:00 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458185@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Soliman, Hesham'" Date: Tue, 26 Oct 2004 10:39:59 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "'ipv6@ietf.org'" Subject: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comme nts for rc2461bis] 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Hi. Using the term 'multicast services' around this area is confusing. If the link MUST provide multicast services maybe that is something that should be in the basic definition of IPv6 (it isn't stated explicitly in RFC2460) rather than in 2461bis. Expanding on what I said originally, one reasonable interpretation of the requirement that all links support multicast services is that they are in some sense 'multicast capable': if you take this view then *all* links are necessarily multicast capable. So I think the problem is that the language doesn't properly convey what I think is the intention: I believe we are trying to distinguish between: - links that provide multicast *as a Layer 2 capability* ('The hardware does multicast') - links that don't, so that the multicast services have to be provided as an overlay Hope this clarifies my point. Regards, Elwyn Original Message ================ S2.2 and S3: The note after the NBMA definition says that '...all link types (including NBMA) are expected to provide multicast service for IP...'. A naive interpretation of the phrase in S3 'On multicast-capable links...' (just after the Redirect bullet) in conjunction with the previous note might take it that actually all links are multicast-capable. The term should be explicitly defined so as to explicitly exclude NBMA and any other sort of links that this phrase is not supposed to apply to - or to allow it to be done optionally on this sort of link - the current wordings are too vague. This is also related to the comment on 6.2.1 below. => I'm not sure I see the problem you see (and I looked at the 2462 thread). We can make the link definition for multicast, a definition for "multicast capable". But apart from that the current spec states refers to other docs in the introduction when it discusses NBMA links. The text you refer to above is talking about multicast services, which is a different issue. So for now, I'll s/multicast/multicast capable in 2.2 and that should do the job IMO. ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 26 10:26:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09254 for ; Tue, 26 Oct 2004 10:26:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSUr-00043c-4z for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 10:40:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSEV-0007JS-9P; Tue, 26 Oct 2004 10:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMS7n-0001x6-Jb for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 10:16:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08377 for ; Tue, 26 Oct 2004 10:16:33 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSLT-0003uS-Df for ipv6@ietf.org; Tue, 26 Oct 2004 10:30:43 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.8898254; Tue, 26 Oct 2004 10:15:19 -0400 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <77435472-2759-11D9-A585-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Tue, 26 Oct 2004 10:15:18 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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="===============0010293883==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0010293883== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-233834829; protocol="application/pkcs7-signature" --Apple-Mail-2-233834829 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This is a consensus call on whether the IPv6 WG should adopt: Title : Consideration M and O Flags of IPv6 Router Advertisement Author(s) : S. Park, et al. Filename : draft-daniel-ipv6-ra-mo-flags-01.txt Pages : 12 Date : 2004-10-25 as a WG document. Comments and opinions can be sent to the mailing list and/or the chairs. We will accept comments on this call until 11/05/2004. Regards, Bob & Brian --Apple-Mail-2-233834829 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI2MTQxNTE5WjAjBgkqhkiG9w0B CQQxFgQUk7XNQj76/LL+PGC+goPgGQYx7WwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAqoNADqO8cZoQdaXFUrZO8Hb6YVkTzW/nhVYzyI8yHLOFEeHbHEf+1ZQb1uxzmTKPcl5H 862+v5XOAqm+qllZrBg/nz7Nszyhi9p0Q/CMiY6whnPMv0ngE5U1Lg5/jQ5vF7CUxw9nn+9MSam/ nbfkjN5xvVHksRuOtvc5rRhOiADNpiV85L3/XRswx1oS2GF6+DabbvZxPl3qrpiIpVfs08ITmgGR 5svBnQokb8xhyrdchnSJpTMvTiAgkKvaRDSYLZ295LXsOx7GUeC/WAmpfWkE97yy6S8X+9Zu4UYL Y3FM8JjhoABXEz+eMuhoHpPy8r5cmTGd9dXpqykOFykS3wAAAAAAAA== --Apple-Mail-2-233834829-- --===============0010293883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0010293883==-- From ipv6-bounces@ietf.org Tue Oct 26 10:49:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10889 for ; Tue, 26 Oct 2004 10:49:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSrh-0004WZ-6s for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 11:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSXI-0003dZ-Dk; Tue, 26 Oct 2004 10:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSTz-0002cG-3t for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 10:39:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10243 for ; Tue, 26 Oct 2004 10:39:28 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMShe-0004JP-ON for ipv6@ietf.org; Tue, 26 Oct 2004 10:53:39 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 10:38:59 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Oct 2004 10:38:46 -0400 Message-ID: Thread-Topic: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comments for rc2461bis] Thread-Index: AcS7L1/5gq2bhJ/uTvCi0WHjuJ9FHgAObRaw From: "Soliman, Hesham" To: "Elwyn Davies" X-OriginalArrivalTime: 26 Oct 2004 14:38:59.0105 (UTC) FILETIME=[876A0910:01C4BB69] X-Spam-Score: 0.6 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: ipv6@ietf.org Subject: RE: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comments for rc2461bis] 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="===============0459070090==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae This is a multi-part message in MIME format. --===============0459070090== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB69.80309326" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BB69.80309326 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your mail server forgot ;) Using the term 'multicast services' around this area is confusing. If = the link MUST provide multicast services maybe that is something that = should be in the basic definition of IPv6 (it isn't stated explicitly in = RFC2460) rather than in 2461bis.=20 =20 Expanding on what I said originally, one reasonable interpretation of = the requirement that all links support multicast services is that they = are in some sense 'multicast capable': if you take this view then *all* = links are necessarily multicast capable. So I think the problem is that the language doesn't properly convey what = I think is the intention: I believe we are trying to distinguish = between: - links that provide multicast *as a Layer 2 capability* ('The hardware = does multicast')=20 - links that don't, so that the multicast services have to be provided = as an overlay =20 =3D> Exactly. I guess our difference is that I get the distinction from = the spec when I read it now (with "multicsat capable" replacing "multicsat" in 2.2). = Is that a sufficient change ? Let me know if you think another change is needed.=20 Hesham =20 Hope this clarifies my point.=20 Regards,=20 Elwyn=20 Original Message=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 S2.2 and S3:=20 The note after the NBMA definition says that '...all link types = (including NBMA) are expected to provide multicast service for IP...'. A naive interpretation of the phrase in S3 'On multicast-capable = links...' (just after the Redirect bullet) in conjunction with the = previous note might take it that actually all links are = multicast-capable. The term should be explicitly defined so as to = explicitly exclude NBMA and any other sort of links that this phrase is = not supposed to apply to - or to allow it to be done optionally on this = sort of link - the current wordings are too vague. This is also related = to the comment on 6.2.1 below.=20 =3D> I'm not sure I see the problem you see (and I looked at the 2462 = thread). We can make the=20 link definition for multicast, a definition for "multicast capable". But = apart from that the current=20 spec states refers to other docs in the introduction when it discusses = NBMA links.=20 The text you refer to above is talking about multicast services, which = is a different issue.=20 So for now, I'll s/multicast/multicast capable in 2.2 and that should do = the job IMO.=20 -------------------------------------------------------------------------= ---------=20 Elwyn B Davies=20 Routing and Addressing Strategy Prime & IPv6 Core Team Leader=20 CTO Office, Portfolio Integration Solutions Ready = =20 Nortel Networks plc Email: = elwynd@nortelnetworks.com=20 Harlow Laboratories ESN = 6-742-5498=20 London Road, Harlow, Direct Line = +44-1279-405498=20 Essex, CM17 9NA, UK Fax = +44-1279-402047=20 Registered Office: Maidenhead Office Park, = Westacott Way,=20 Company No. 3937799 Maidenhead, Berkshire, = SSL6 3QH=20 -------------------------------------------------------------------------= ---=20 This message may contain information proprietary to Nortel Networks plc = so any=20 unauthorised disclosure, copying or distribution of its contents is = strictly prohibited.=20 -------------------------------------------------------------------------= ---=20 "The Folly is mostly mine"=20 and the opinions are mine and not those of my employer.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 ------_=_NextPart_001_01C4BB69.80309326 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC2461bis: Multicast capable vs Multicast Service [was RE: = Comments for rc2461bis]
Your=20 mail server forgot ;)

Using the term 'multicast services' around this area = is=20 confusing.  If the link MUST provide multicast services maybe = that is=20 something that should be in the basic definition of IPv6 (it isn't = stated=20 explicitly in RFC2460) rather than in 2461bis. 

 

Expanding on what I said originally, one reasonable=20 interpretation of the requirement that all links support multicast = services is=20 that they are in some sense 'multicast capable': if you take this view = then=20 *all* links are necessarily multicast capable.

So I think the problem is that the language doesn't = properly=20 convey what I think is the intention: I believe we are trying to = distinguish=20 between:

- links that provide multicast *as a Layer 2 = capability* ('The=20 hardware does multicast')
- links that = don't, so that=20 the multicast services have to be provided as an = overlay  

=3D>=20 Exactly.  I = guess our=20 difference is that I get the distinction from the spec = when

I read=20 it now (with "multicsat capable" replacing "multicsat" in 2.2). Is = that a=20 sufficient

change=20 ? Let me know if you think another change is needed. =

Hesham

 

Hope this clarifies my point.

Regards,
Elwyn

Original Message
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
S2.2 and S3:
The note after the NBMA definition says that '...all link = types=20 (including NBMA) are expected to provide multicast service for=20 IP...'.

A naive interpretation of the phrase in S3 'On=20 multicast-capable links...' (just after the Redirect bullet) in = conjunction=20 with the previous note might take it that actually all links are=20 multicast-capable.  The term should be explicitly defined so as = to=20 explicitly exclude NBMA and any other sort of links that this phrase = is not=20 supposed to apply to - or to allow it to be done optionally on this = sort of=20 link - the current wordings are too vague.  This is also related = to the=20 comment on 6.2.1 below.

=3D> I'm not sure I see the problem you see (and = I looked at=20 the 2462 thread). We can make the

link definition for multicast, a definition for = "multicast=20 capable". But apart from that the current

spec states refers to other docs in the introduction = when it=20 discusses NBMA links.

The text you refer to above is talking about = multicast=20 services, which is a different issue.

So for now, I'll s/multicast/multicast capable in = 2.2 and that=20 should do the job IMO.




----------------------------------------------------------------= ------------------=20

Elwyn B Davies

        Routing = and=20 Addressing Strategy Prime & IPv6 Core Team Leader
        CTO Office, = Portfolio=20 Integration      =20         Solutions Ready=20        

        Nortel = Networks=20 plc             =         Email:=20 elwynd@nortelnetworks.com
        Harlow=20 Laboratories    =20        =20        =20        =20 = ESN           &nbs= p;=20         6-742-5498
        London Road,=20 Harlow,           =20        =20         Direct = Line    =20         +44-1279-405498 =
        Essex, CM17 9NA,=20 UK            =20        =20 = Fax           &nbs= p;=20         +44-1279-402047 =
        Registered Office: =             =20         Maidenhead Office Park, = Westacott=20 Way,
       =20 Company No. 3937799    =20        =20         Maidenhead, Berkshire, SSL6 = 3QH
----------------------------------------------------------------= ------------=20
This message may contain information proprietary to = Nortel=20 Networks plc so any
unauthorised disclosure, = copying=20 or distribution of its contents is strictly prohibited. =
----------------------------------------------------------------= ------------=20
"The Folly is mostly mine"
and the=20 opinions are mine and not those of my employer.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
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

------_=_NextPart_001_01C4BB69.80309326-- --===============0459070090== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0459070090==-- From ipv6-bounces@ietf.org Tue Oct 26 11:02:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11735 for ; Tue, 26 Oct 2004 11:02:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMT3b-0004mC-TF for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 11:16:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSl0-0001HE-Mt; Tue, 26 Oct 2004 10:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMScc-0005ok-Lq for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 10:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10755 for ; Tue, 26 Oct 2004 10:48:24 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSqI-0004Tv-Q2 for ipv6@ietf.org; Tue, 26 Oct 2004 11:02:35 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 10:47:55 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2004 10:47:43 -0400 Message-ID: Thread-Topic: RFC2461bis: Empty default router lists [was: RE: Comments for rc2461bis] Thread-Index: AcS7Mqj10T5ywb0ASP2Y0J1ylqWuDQANwkzA From: "Soliman, Hesham" To: "Elwyn Davies" X-OriginalArrivalTime: 26 Oct 2004 14:47:55.0612 (UTC) FILETIME=[C73281C0:01C4BB6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: RFC2461bis: Empty default router lists [was: RE: Comments for rc2461bis] 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable > Quoting from S5.2: >=20 > Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination=20 > is on- or > off-link. If the destination is on-link, the next-hop=20 > address is the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List (following the rules > described in Section 6.3.6). >=20 > So if there are no routers admitting to be connected to the=20 > link and the > prefix list is empty (no routers to fill it), what happens=20 > here? Presumably > the longest prefix match will fail implying that the address=20 > is off link. > Hence we have to find a router, but there isn't one. What=20 > do we do with the > packet? =3D> There are two basic cases to consider: 1. Dst address is off-link (i.e. longest prefix match fails). In this case you'll either send it over the tunnel or drop the packet if there is no tunnel.=20 2. Longest prefix match works, destination is on-link. This will work.=20 >=20 > With a point-to-point link (like the tunnels) we could just=20 > stuff the packet > down the link and hand off the decision to the other end. =20 > For an isolated > multiaccess link the decision is not so simple: Just having=20 > our own address > doesn't allow us to decide whether any other address is on=20 > link, so if the > destination is not in the neighbor cache already what do we=20 > do? Toss the > packet or assume it is on-link? Being able to configure an=20 > on-link prefix > would solve the problem IMO. >=20 > Am I missing something here? =3D> You must be assuming that you can have a link with no routers and inconsistent prefixes on different hosts.=20 For instance, you're assuming that you can have an isolated link where host1's address is configured from one prefix and host2's address is configured based on a completely different one. When we discussed this issue last year there was agreement that if you have this scenario, hosts should be=20 configured from the same prefix. If that happens, there should not be a problem with on-link determination. You don't need to=20 manually add a prefix to the prefix list here, you simply=20 configure all addresses using the same prefix. Hesham >=20 > Regards, > elwyn >=20 > Original Message > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [S5: Prefix List: Having removed the 'assume it is on=20 > link' if no routers, > it might be useful to allow a prefix to be inserted into the=20 > prefix list by > manual configuration when dealing with a single link net.]=20 > =3D> Is this really needed? Isn't enough to be able to=20 > configure an address > given that the next hop > determination is based on a longest prefix match? I won't=20 > add this unless > you see a reason for it.=20 > s5.2: It ought to be stated that if the default router list=20 > is empty then > off-link unicast packets will have to be dropped and an=20 > 'unreachable' ICMP > message sent.[whether the packet ought to have got as far as=20 > the interface > processing is a moot point].=20 > =3D> Hmmm. How does this work in the case where the=20 > destination address is > on the other > end of an IPv4 tunnel and there is no default router in the=20 > list? This is > why the onlink assumption > was removed.=20 >=20 >=20 > ------------------------------------------------------------- > --------------- > ------ >=20 > Elwyn B Davies >=20 > Routing and Addressing Strategy Prime & IPv6 Core Team Leader > CTO Office, Portfolio Integration Solutions Ready >=20 >=20 > Nortel Networks plc Email: > elwynd@nortelnetworks.com > Harlow Laboratories ESN > 6-742-5498 > London Road, Harlow, Direct Line > +44-1279-405498 > Essex, CM17 9NA, UK Fax > +44-1279-402047 > Registered Office: Maidenhead Office Park, > Westacott Way, > Company No. 3937799 Maidenhead,=20 > Berkshire, SSL6 > 3QH > ------------------------------------------------------------- > --------------- > This message may contain information proprietary to Nortel=20 > Networks plc so > any > unauthorised disclosure, copying or distribution of its=20 > contents is strictly > prohibited. > ------------------------------------------------------------- > --------------- > "The Folly is mostly mine" > and the opinions are mine and not those of my employer. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D >=20 >=20 >=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 Oct 26 14:22:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01136 for ; Tue, 26 Oct 2004 14:22:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWBB-0001a7-3N for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 14:36:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVvl-0006rr-Bi; Tue, 26 Oct 2004 14:20:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVqu-00061e-Hv for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 14:15:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00724 for ; Tue, 26 Oct 2004 14:15:22 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMW4b-0001SH-Nj for ipv6@ietf.org; Tue, 26 Oct 2004 14:29:34 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 09D6C15218; Wed, 27 Oct 2004 03:15:07 +0900 (JST) Date: Wed, 27 Oct 2004 03:15:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipv6@ietf.org Subject: Re: AD Review of draft-ietf-ipv6-rfc2462bis-06.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 (This message is a response to a unicasted message, which Margaret said should have actually been sent to the list. So I'm cc'ing to the wg list) >>>>> On Thu, 21 Oct 2004 14:30:24 -0400, >>>>> Margaret Wasserman said: > What I think we should do is make it very clear that the M&O bits are > not used for either Neighbor Discovery (in 2461bis) or Address > Autoconfiguration (in 2462bis). In other words, the values of these > bits can be completely ignored for purposes of ND, DAD, AddrConf, > etc. -- we will autoconfigure exactly the same address, in exactly > the same way, regardless of the value of these bits. This is true, > right? Yes, I think so. Whatever the "stateful" protocol(s) is, or however we invoke the protocol(s) based on the M/O flags, it is completely a separate process from the base ND protocol or stateless address autoconfiguration (or DAD for that matter). In particular, we can (or "should" when necessary) run stateless address autoconfiguration and DHCPv6 for address allocation concurrently. One subtle point is that DAD should apply to addresses allocated through DHCPv6. But I believe we can handle this separately from the meaning/usage of the M/O flags. I believe the existing documents (2461/2462) already clarify the point to some extent, but perhaps we'll need to be more specific. > You could then optionally include an informational reference to a > document that describes the meaning and use of these bits and/or say > that they meaning and use of these bits will be described in a > document to be published later. > But, I'd leave out the partial description of the meaning of these > bits from both 2461bis and 2462bis, as that only creates the > impression that these bits have some implications for the protocols > described in this document. Point taken, and I tend to agree. Since this may cause a significant change to the current version of the document, I'll make a separate thread on this specific issue. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 26 15:09:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04533 for ; Tue, 26 Oct 2004 15:09:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWv2-0002aX-3T for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 15:23:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMWXt-0005R3-TP; Tue, 26 Oct 2004 14:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMWV8-0004wc-SN for ipv6@megatron.ietf.org; Tue, 26 Oct 2004 14:56:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03251 for ; Tue, 26 Oct 2004 14:56:56 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWio-0002FP-7A for ipv6@ietf.org; Tue, 26 Oct 2004 15:11:09 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C331615210 for ; Wed, 27 Oct 2004 03:56:53 +0900 (JST) Date: Wed, 27 Oct 2004 03:56:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: further clarifications on M/O flags in rfc2462bis 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 X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Hello, Based on a recent discussion on rfc2462bis with Margaret in a part of her AD review results, I now think we'll need further clarifications on the M/O flags. As I said in a previous response to Margaret, we have decided and made the following change to rfc2462bis: 1. remove some "mandatory" wording on these flags and clarify that these flags are just hints of availability of the corresponding services (DHCPv6). 2. leave more details to other document(s) The basic background of this decision is that we've not reached a matured level for a DS on deployment experiences of DHCPv6. (see http://www1.ietf.org/mail-archive/web/ipv6/current/msg02372.html to get the entire message with the context of the discussion) I'm quite sure that we saw a clear consensus on the basic idea. But as a result, we have a vague reference to the "other document", without specifying a particular document in the references section. This may make rfc2462bis "incomplete". There is an ongoing work on the detailed usage of the M/O flags, and we could refer to that document from rfc2462bis. However, the only "ongoing work" is currently just an individual document, and I'm not sure how long it takes to be completed, or even whether we adopt it as a wg item in the first place. This would make the reference from rfc2462bis unstable and/or would cause another delay for rfc2462bis. We need to endure the delay if it's inevitable. However, as Margaret indicated, most part of rfc2462bis is independent from the usage of the M/O flags. In fact, creating a link-local/global address by the stateless autoconfiguration procedure, DAD, or address lifetime management are basically all independent from how we use the M/O flags. Also, whether we invoke DHCPv6 when receiving an RA with the M flag being ON does not affect whether we perform stateless address autoconfiguration when receiving an RA with some prefix information, or vice versa. In some cases (e.g., for DAD), we need to consider addresses allocated via DHCPv6 as well as addresses configured through stateless configuration. However, I believe we can simply say "addresses allocated via DHCPv6" in such cases without mentioning the M/O flags. So, I now tend to propose the following approach: - clearly saying in rfc2462bis "it does not specify the use of the M/O flags." (not mentioning other documents). Specifically, remove the 7th paragraph of Section 4 (beginning with "The details of how a host may use the M flag...") - also clarifying in rfc2462bis that the protocol described in rfc2462bis should be performed independently from these flags (in a clearer way). (and, if we take this idea, the "separate document", whatever it is, should become a PS instead of a BCP as we originally planned). Please note that this is NOT an attempt to "remove" or "deprecate" the M/O flags. We've already discussed the idea and rejected it, and I don't see a reason for revisiting the past arguments. This is an attempt to make rfc2462bis more self-contained and more matured as a DS, considering the current implementation/deployment experiences of the M/O flags and the other parts of the original RFC2462. Still, this will require non-trivial changes to the current version of rfc2462bis, so I'd like to get explicit agreement/disagreement from the working group. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 26 21:59:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20368 for ; Tue, 26 Oct 2004 21:59:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdJN-0000v9-BY for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 22:13:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMd1T-0001Bw-Ls; Tue, 26 Oct 2004 21:54:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMd0r-0000sg-Jv; Tue, 26 Oct 2004 21:54:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20193; Tue, 26 Oct 2004 21:54:06 -0400 (EDT) Received: from tyo202.gate.nec.co.jp ([202.32.8.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdEb-0000qK-PG; Tue, 26 Oct 2004 22:08:22 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i9R1rJn26272; Wed, 27 Oct 2004 10:53:21 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i9R1rJg07967; Wed, 27 Oct 2004 10:53:19 +0900 (JST) Received: from dns02.ubq.nec.co.jp (dns02.ubq.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id i9R1rIx28641; Wed, 27 Oct 2004 10:53:18 +0900 (JST) Received: from dns03.ubq.nec.co.jp (dns03.ubq.nec.co.jp [10.17.225.65]) by dns02.ubq.nec.co.jp (8.11.7/8.11.7) with ESMTP id i9R1r3I09112; Wed, 27 Oct 2004 10:53:03 +0900 (JST) Received: from localhost ([10.17.226.96]) by dns03.ubq.nec.co.jp (8.11.7/8.11.7) with ESMTP id i9R1r3W27699; Wed, 27 Oct 2004 10:53:03 +0900 (JST) To: ipv6@ietf.org, v6ops@ops.ietf.org, mip6@ietf.org X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20041027105303P.kitamura@da.jp.nec.com> Date: Wed, 27 Oct 2004 10:53:03 +0900 From: Hiroshi KITAMURA X-Dispatcher: imput version 20000228(IM140) Lines: 46 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: anycast@anarg.jp Subject: Call for Participation on IPv6 Anycast discussion ML 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Dear All, People, who are interested in IPv6 Anycast discussion, please read this mail. I thing there are many people who are interested in IPv6 Anycast. Since IPv6 Anycast has many good potential functionalities, many people are expecting that it will be widely used in the real-world. Currently, IPv6 Anycast is only used at limited area for limited purpose. It is a pity that IPv6 Anycast is not widely used. This situation should be changed. A small IPv6 Anycast discussion team has been made by people who are interested in this topic. http://anycast.anarg.jp/ is a web site for IPv6 Anycast discussion. anycast@anarg.jp is a ML for it. People, who are interested in IPv6 Anycast discussion, please join this ML and let us know your comments. Let's discuss on IPv6 Anycast issues at this ML. (Instruction how to join the ML is written in above web site.) We have already issued four I-Ds on IPv6 Anycast. (Of course, they are under construction.) 1. IPv6 Anycast Terminology Definition 2. Applicability Statement of IPv6 Anycasting 3. A Protocol for Anycast Address Resolving 4. Possible Deployment Scenarios for IPv6 Anycasting You can find them at above web site. We'd like to have a Practical Anycasting BoF in the near future. We have already talked with Internet Area Directors on this issue. A draft for charter proposal is written in above web site, please read them and let us know your comments. Regards, Hiroshi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Oct 26 22:17:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21543 for ; Tue, 26 Oct 2004 22:17:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdbA-0001K4-Uo for ipv6-web-archive@ietf.org; Tue, 26 Oct 2004 22:31:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMdLr-0000X1-C4; Tue, 26 Oct 2004 22:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMdKK-0008Nb-74; Tue, 26 Oct 2004 22:14:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21330; Tue, 26 Oct 2004 22:14:13 -0400 (EDT) Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdY5-0001FW-4N; Tue, 26 Oct 2004 22:28:30 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id 419051C0CE; Wed, 27 Oct 2004 11:14:02 +0900 (JST) To: kitamura@da.jp.nec.com In-Reply-To: Your message of "Wed, 27 Oct 2004 10:53:03 +0900" <20041027105303P.kitamura@da.jp.nec.com> References: <20041027105303P.kitamura@da.jp.nec.com> X-Mailer: Cue version 0.8 (041013-0602/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20041027021402.419051C0CE@coconut.itojun.org> Date: Wed, 27 Oct 2004 11:14:02 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: v6ops@ops.ietf.org, mip6@ietf.org, anycast@anarg.jp, ipv6@ietf.org Subject: draft-ata-ipv6-anycast-resolving-02.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 (sorry to spam 3 wgs, i have not received response to subscription request for anycast@anarg.jp yet) > draft-ata-ipv6-anycast-resolving-02.txt > A Protocol for Anycast Address Resolving due to the way the proposal resolves (or hides) anycast address into unicast address, we will experience a severe problem. application thinks that it is communicating with anycast address AA, but ARL (basically a NAT within client) translates it into unicast address. therefore, applications which embeds address into its protocol payload (like ftp) won't work as expected. section 4 (applicability statement) is not true. appendix A (how to map anycast address into unicast) basically has no security considerations. section 5 (security consideration) is also too weak. another issue with this approach is, that anycast is being used as service discovery mechnaism on the first contact only. anycast has other benefits such as failure recovery/tolerance. these benefits are gone with this draft. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 27 05:00:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18045 for ; Wed, 27 Oct 2004 05:00:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMjtd-0000eT-Rl for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 05:15:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMjcE-0004DH-6C; Wed, 27 Oct 2004 04:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMjWu-00039x-6N for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 04:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17650 for ; Wed, 27 Oct 2004 04:51:37 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMjki-0000VB-UL for ipv6@ietf.org; Wed, 27 Oct 2004 05:05:57 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9R8p3w26959; Wed, 27 Oct 2004 10:51:03 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Oct 2004 10:51:01 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458196@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Soliman, Hesham'" Date: Wed, 27 Oct 2004 10:51:01 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: ipv6@ietf.org Subject: RE: RFC2461bis: Multicast capable vs Multicast Service [was RE: C omments for rc2461bis] 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c looking back at the text in S2.2, the reason for using multicast-capable rather than just multicast was that multicast-capable was (i think) supposed to cover both multicast links which have native support and point-to-point links which do multicast degenerately. i think that my problem could be solved by adding a sentence (or separate definition) in 2.2 to say just that i.e. multicast-capable link - a link which is either point-to-point or multicast type then i think the substitution s/multicast/multicast-capable/ elsewhere works fine. the remark that 'all link types are expected to provide multicast services for IP' really deserves some exploration other than in 2461bis. if this is really a requirement for *all* scopes of multicast service then it is manifestly not being met by most IPv6 implementations. for ND all we need is multicast at the link level. DHCPv6 may need it at the site level. but what should we expect from a general implementation in the way of multicast services? there is really a considerable amount of vagueness about this across all the specifications. Regards, Elwyn -----Original Message----- From: Soliman, Hesham [mailto:H.Soliman@flarion.com] Sent: 26 October 2004 15:39 To: Davies, Elwyn [HAL02:0S00:EXCH] Cc: ipv6@ietf.org Subject: RE: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comments for rc2461bis] Your mail server forgot ;) => Grr! Hate, hate. Using the term 'multicast services' around this area is confusing. If the link MUST provide multicast services maybe that is something that should be in the basic definition of IPv6 (it isn't stated explicitly in RFC2460) rather than in 2461bis. Expanding on what I said originally, one reasonable interpretation of the requirement that all links support multicast services is that they are in some sense 'multicast capable': if you take this view then *all* links are necessarily multicast capable. So I think the problem is that the language doesn't properly convey what I think is the intention: I believe we are trying to distinguish between: - links that provide multicast *as a Layer 2 capability* ('The hardware does multicast') - links that don't, so that the multicast services have to be provided as an overlay => Exactly. I guess our difference is that I get the distinction from the spec when I read it now (with "multicsat capable" replacing "multicsat" in 2.2). Is that a sufficient change ? Let me know if you think another change is needed. Hesham Hope this clarifies my point. Regards, Elwyn Original Message ================ S2.2 and S3: The note after the NBMA definition says that '...all link types (including NBMA) are expected to provide multicast service for IP...'. A naive interpretation of the phrase in S3 'On multicast-capable links...' (just after the Redirect bullet) in conjunction with the previous note might take it that actually all links are multicast-capable. The term should be explicitly defined so as to explicitly exclude NBMA and any other sort of links that this phrase is not supposed to apply to - or to allow it to be done optionally on this sort of link - the current wordings are too vague. This is also related to the comment on 6.2.1 below. => I'm not sure I see the problem you see (and I looked at the 2462 thread). We can make the link definition for multicast, a definition for "multicast capable". But apart from that the current spec states refers to other docs in the introduction when it discusses NBMA links. The text you refer to above is talking about multicast services, which is a different issue. So for now, I'll s/multicast/multicast capable in 2.2 and that should do the job IMO. ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== ======================================================== 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 27 12:48:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21287 for ; Wed, 27 Oct 2004 12:48:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrBo-0001Sc-VE for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 13:02:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqvE-0006yl-6s; Wed, 27 Oct 2004 12:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqq4-0005tz-Jy for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 12:39:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20966 for ; Wed, 27 Oct 2004 12:39:53 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMr3w-0001Jn-Qg for ipv6@ietf.org; Wed, 27 Oct 2004 12:54:18 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9RGd7w20108; Wed, 27 Oct 2004 19:39:12 +0300 Date: Wed, 27 Oct 2004 19:39:07 +0300 (EEST) 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-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi, On Mon, 25 Oct 2004, Brian Haberman wrote: > This is the start of a 1-week IPv6 working group last call for > recycling: > > Title : Internet Control Message Protocol (ICMPv6)for the > Internet Protocol Version 6 (IPv6) Specification > Author(s) : A. Conta, et al. > Filename : draft-ietf-ipngwg-icmp-v3-05.txt > Pages : 26 > Date : 2004-10-22 > > at Draft Standard. This LC is aimed at ensuring resolution of all > issues raised during the previous last call. Substantive comments > should be directed to the mailing. This last call will end on 11/01/2004. I think it was forgotten to clarify the ICMPv6 rate-limiting language (at the very least, using 'originate' instead of 'send') based on the consensus called at: http://www.ietf.org/mail-archive/web/ipv6/current/msg03539.html One attempt by me to fix this was at: http://www.ietf.org/mail-archive/web/ipv6/current/msg03421.html Other than that, I think the doc should be fine. -- 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 Oct 27 13:04:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22742 for ; Wed, 27 Oct 2004 13:04:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrRL-0001pc-KZ for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 13:18:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMr6N-00016d-5N; Wed, 27 Oct 2004 12:56:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqzE-0007od-AO for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 12:49:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21429 for ; Wed, 27 Oct 2004 12:49:20 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrD7-0001TY-NH for ipv6@ietf.org; Wed, 27 Oct 2004 13:03:46 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9RGmnR20390; Wed, 27 Oct 2004 19:48:49 +0300 Date: Wed, 27 Oct 2004 19:48:49 +0300 (EEST) From: Pekka Savola To: Brian Haberman In-Reply-To: <305FC29E-2695-11D9-A7B8-000D93330CAA@innovationslab.net> Message-ID: References: <305FC29E-2695-11D9-A7B8-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-host-load-sharing-03.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi, On Mon, 25 Oct 2004, Brian Haberman wrote: > All, > This is the start of a 1-week WG Last Call on advancing: > > Title : IPv6 Host to Router Load Sharing > Author(s) : R. Hinden, D. Thaler > Filename : draft-ietf-ipv6-host-load-sharing-03.txt > Pages : 6 > Date : 2004-10-21 > > as a Proposed Standard. The aim of this LC is to ensure > resolution of all issues raised during the previous last call. > Substantive comments should be directed to the mailing list. > This last call will end on 11/01/2004. My comments have been satisfactorily resolved, and I support moving it forward. -- 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 Oct 27 13:10:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23263 for ; Wed, 27 Oct 2004 13:10:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrXw-0001yi-Gw for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 13:25:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMr6V-0001B2-GF; Wed, 27 Oct 2004 12:56:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMr4X-0000XR-BS for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 12:54:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22146 for ; Wed, 27 Oct 2004 12:54:49 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrIP-0001dR-E1 for ipv6@ietf.org; Wed, 27 Oct 2004 13:09:15 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9RGhR420226; Wed, 27 Oct 2004 19:43:27 +0300 Date: Wed, 27 Oct 2004 19:43:27 +0300 (EEST) From: Pekka Savola To: Fred Templin In-Reply-To: <20041025173849.73568.qmail@web80501.mail.yahoo.com> Message-ID: References: <20041025173849.73568.qmail@web80501.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Mon, 25 Oct 2004, Fred Templin wrote: > I would like to see a new Code added to the Parameter Problem Message > Type ([ICMPv6], section 3.4) whereby the end host or a router on the path > can inform the source that unspecified data corruption was encountered > in the packet. The code definition should appear as a new item at the > end of the current list as follows: > > 3 - unspecified data corruption encountered FWIW, I don't think this should be added, remembering that we're recycling at DS, because: 1) there doesn't seem to be clear need for it in this spec, and 2) if some other spec needs it, it can just define it (Because the packets whose ICMP checksum is incorrect are silently discarded, and there is no checksum for the data payload, I can't figure how ICMPv6 could notice any further data corruption in any case, so I see no direct justification in *this* spec.) -- 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 Oct 27 13:19:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24046 for ; Wed, 27 Oct 2004 13:19:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrgk-0002CD-OU for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 13:34:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMrOy-0005B8-Jf; Wed, 27 Oct 2004 13:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMrOe-00050B-BJ for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 13:15:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23628 for ; Wed, 27 Oct 2004 13:15:36 -0400 (EDT) Received: from web80503.mail.yahoo.com ([66.218.79.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMrcW-00024q-Rt for ipv6@ietf.org; Wed, 27 Oct 2004 13:30:02 -0400 Message-ID: <20041027171506.44665.qmail@web80503.mail.yahoo.com> Received: from [63.197.18.101] by web80503.mail.yahoo.com via HTTP; Wed, 27 Oct 2004 10:15:06 PDT Date: Wed, 27 Oct 2004 10:15:06 -0700 (PDT) From: Fred Templin To: Pekka Savola In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 2.4 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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="===============1825505866==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --===============1825505866== Content-Type: multipart/alternative; boundary="0-1558457567-1098897306=:43406" --0-1558457567-1098897306=:43406 Content-Type: text/plain; charset=us-ascii Pekka Savola wrote: I can't figure how ICMPv6 could notice any further data corruption in any case, so I see no direct justification in *this* spec.) We are speaking here about the case of the IPv6 layer noticing data corruption in a received packet and then sending an ICMPv6 error message with the new Parameter Problem code back to the source. Data corruption can be detected, e.g., if the link layer has a way to inform the IPv6 layer of packets received with errors - but this is not necessarily the *only* example. Fred osprey67@yahoo.com --0-1558457567-1098897306=:43406 Content-Type: text/html; charset=us-ascii
Pekka Savola <pekkas@netcore.fi> wrote:

 I can't  figure how ICMPv6 could notice any further data corruption in any
case, so I see no direct justification in *this* spec.)

 
 
We are speaking here about the case of the IPv6 layer noticing data corruption
in a received packet and then sending an ICMPv6 error message with the new
Parameter Problem code back to the source. Data corruption can be detected,
e.g., if the link layer has a way to inform the IPv6 layer of packets received with
errors - but this is not necessarily the *only* example.
 
Fred
--0-1558457567-1098897306=:43406-- --===============1825505866== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1825505866==-- From ipv6-bounces@ietf.org Wed Oct 27 13:32:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24958 for ; Wed, 27 Oct 2004 13:32:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrso-0002TO-Ta for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 13:46:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMrcM-0008CF-S6; Wed, 27 Oct 2004 13:29:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMrXA-0006n1-Os for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 13:24:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24338 for ; Wed, 27 Oct 2004 13:24:25 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrl3-0002Gl-BF for ipv6@ietf.org; Wed, 27 Oct 2004 13:38:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9RHNqc21355; Wed, 27 Oct 2004 20:23:52 +0300 Date: Wed, 27 Oct 2004 20:23:52 +0300 (EEST) From: Pekka Savola To: Brian Haberman In-Reply-To: <77435472-2759-11D9-A585-000D93330CAA@innovationslab.net> Message-ID: References: <77435472-2759-11D9-A585-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: IPv6 WG Subject: Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hi, On Tue, 26 Oct 2004, Brian Haberman wrote: > This is a consensus call on whether the IPv6 WG should adopt: > > Title : Consideration M and O Flags of IPv6 Router > Advertisement > Author(s) : S. Park, et al. > Filename : draft-daniel-ipv6-ra-mo-flags-01.txt > Pages : 12 > Date : 2004-10-25 > > as a WG document. Comments and opinions can be sent to the > mailing list and/or the chairs. We will accept comments on this > call until 11/05/2004. I think this is valuable clarifying work, and a good starting point for the work. I think it's worth adopting. A couple of comments on the draft for improvement: - just a question on how full DHCPv6 client works with stateless DHCPv6 server: If M-Policy is 1, the host SHOULD invoke Host Configuration Behaviour for address and other configuration information, regardless of the change of the state variables. The host SHOULD NOT invoke Information Configuration Behaviour regardless of O-Policy. Note, however, that if the available DHCPv6 servers only provide the service for the Information Configuration Behaviour, the host will even not be able to configure other configuration parameters than addresses. Thus, it is generally inadvisable to set M-Policy to 1, unless there is a particular reason to do so. ==> is it really true that if a full DHCPv6 client is initiated, and the server is 'stateless', the DHCPv6 client doesn't get back the stateless information? That would seem to be a big problem for DHCPv6 deployment if servers are stateless, and I think someone has claimed that this shouldn't be a problem. If the text you wrote is correct, that would mean that to get robust behaviour, the host would have to either rely that the capabilities of the DHCPv6 servers match those that are advertised in the route advertisements, or to always just "prepare for the worst" by firing off a parallel information-request as well. And then it would seem to make sense for prudent DHCPv6 implementers to do everything they can to ensure they'll receive information-reply from stateful servers as well.. because that's better than nothing, and better than relying on how the bits in RAs have been configured! - minor issue wrt inconsistent M/O information: If the host frequently receives inconsistent M and O flags of Router Advertisement (e.g., in a mobile environment for supporting fast movement detection), it may need complex consideration on an erroneous case. However, this case is not closely related to this document; rather, it is a general issue on the inconsistent Router Advertisement parameters from multiple routers. In fact, other configuration parameters such as the MTU size and the hop limit are also possible to be inconsistent in different Router Advertisements. ==> actually M/O is IMHO a bit worse than these two, because these are just internal variables, typically implemented in the kernel, and toggling back and forth between them is not a problem. Presumably, initiating DHCPv6 requires running a non-trivial user-land process. Hence, I'd dare to say that the transitions are a bigger problem with M/O flags, as has already been discussed a bit in security considerations. Thus I'd like to see some further text, e.g. 1-2 sentences, describing why M/O transitions are a bigger problem than other inconsistent information. -- 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 Oct 27 13:36:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25404 for ; Wed, 27 Oct 2004 13:36:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrx0-0002Zz-MY for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 13:51:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMreM-0000d5-Az; Wed, 27 Oct 2004 13:31:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMraS-0007kP-3f for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 13:27:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24590 for ; Wed, 27 Oct 2004 13:27:48 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMroL-0002Mj-R4 for ipv6@ietf.org; Wed, 27 Oct 2004 13:42:14 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9RHRD321534; Wed, 27 Oct 2004 20:27:13 +0300 Date: Wed, 27 Oct 2004 20:27:13 +0300 (EEST) From: Pekka Savola To: Fred Templin In-Reply-To: <20041027171506.44665.qmail@web80503.mail.yahoo.com> Message-ID: References: <20041027171506.44665.qmail@web80503.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Wed, 27 Oct 2004, Fred Templin wrote: > Pekka Savola wrote: >> I can't figure how ICMPv6 could notice any further data corruption in any >> case, so I see no direct justification in *this* spec.) > > We are speaking here about the case of the IPv6 layer noticing data corruption > in a received packet and then sending an ICMPv6 error message with the new > Parameter Problem code back to the source. Data corruption can be detected, > e.g., if the link layer has a way to inform the IPv6 layer of packets received with > errors - but this is not necessarily the *only* example. OK. Are there link layer specifications which do this? And if so, are there implementations that do that? I have no doubt that there may be link-layers which might detect or be able to detect corruption. But the typical approach then, AFAICS, is either to silently discard packet, or to try to retransmit at link-layer if there was a link-layer problem. -- 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 Oct 27 14:09:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28311 for ; Wed, 27 Oct 2004 14:09:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMsSt-0003HE-Kv for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 14:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMs9G-0007WZ-4M; Wed, 27 Oct 2004 14:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMs5D-0006oC-5S for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 13:59:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27459 for ; Wed, 27 Oct 2004 13:59:37 -0400 (EDT) Received: from web80501.mail.yahoo.com ([66.218.79.71]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMsJ6-00035T-Ei for ipv6@ietf.org; Wed, 27 Oct 2004 14:14:01 -0400 Message-ID: <20041027175906.96930.qmail@web80501.mail.yahoo.com> Received: from [63.197.18.101] by web80501.mail.yahoo.com via HTTP; Wed, 27 Oct 2004 10:59:06 PDT Date: Wed, 27 Oct 2004 10:59:06 -0700 (PDT) From: Fred Templin To: Pekka Savola In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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="===============0675838693==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============0675838693== Content-Type: multipart/alternative; boundary="0-1318745214-1098899946=:94688" --0-1318745214-1098899946=:94688 Content-Type: text/plain; charset=us-ascii Pekka Savola wrote: I have no doubt that there may be link-layers which might detect or be able to detect corruption. But the typical approach then, AFAICS, is either to silently discard packet, or to try to retransmit at link-layer if there was a link-layer problem. Persistent reception of packets with data corruption could be an indication of congestion, in which case link-layer retransmit might not be the best thing. Also, silent discard would miss out on an opportunity to provide congestion feedback to the source whereas the ICMPv6s with the new parameter problem code could be used to provide the necessary feedback. Fred osprey67@yahoo.com --0-1318745214-1098899946=:94688 Content-Type: text/html; charset=us-ascii
Pekka Savola <pekkas@netcore.fi> wrote:
I have no doubt that there may be link-layers which might detect or be
able to detect corruption. But the typical approach then, AFAICS, is
either to silently discard packet, or to try to retransmit at
link-layer if there was a link-layer problem.
 
Persistent reception of packets with data corruption could be an indication
of congestion, in which case link-layer retransmit might not be the best thing.
Also, silent discard would miss out on an opportunity to provide congestion
feedback to the source whereas the ICMPv6s with the new parameter
problem code could be used to provide the necessary feedback.
 
Fred
osprey67@yahoo.com
--0-1318745214-1098899946=:94688-- --===============0675838693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0675838693==-- From ipv6-bounces@ietf.org Wed Oct 27 17:53:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19309 for ; Wed, 27 Oct 2004 17:53:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvx1-0000EQ-Po for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 18:07:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvf8-00005A-2f; Wed, 27 Oct 2004 17:48:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvaA-0007sv-Hj for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 17:43:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18523 for ; Wed, 27 Oct 2004 17:43:47 -0400 (EDT) Received: from hoiho.wlug.org.nz ([203.97.10.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvo2-0008Vf-RX for ipv6@ietf.org; Wed, 27 Oct 2004 17:58:15 -0400 Received: from voodoo.cs.waikato.ac.nz ([130.217.250.13]) by hoiho.wlug.org.nz with asmtp (Exim 3.35 #1 (Debian)) id 1CMvZT-0005mD-00; Thu, 28 Oct 2004 10:43:07 +1300 Message-ID: <41801660.8050909@coders.net> Date: Thu, 28 Oct 2004 10:42:56 +1300 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-nz, en, en-us MIME-Version: 1.0 To: Fred Templin References: <20041027171506.44665.qmail@web80503.mail.yahoo.com> In-Reply-To: <20041027171506.44665.qmail@web80503.mail.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 WG , Pekka Savola Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Fred Templin wrote: >Pekka Savola wrote: > I can't figure how ICMPv6 could notice any further data corruption in any >case, so I see no direct justification in *this* spec.) > > >We are speaking here about the case of the IPv6 layer noticing data corruption >in a received packet and then sending an ICMPv6 error message with the new >Parameter Problem code back to the source. Data corruption can be detected, >e.g., if the link layer has a way to inform the IPv6 layer of packets received with >errors - but this is not necessarily the *only* example. > > > I may be rather naive here, but if you detect that the packet is corrupt then how do you know if the source address is valid? How is the remote end supposed to tie it back to a packet it sent given that you've just said "this packet is corrupt, and you can't rely on any data in it"? While I agree that something like TCP would love to know if loss was due to transmission error, or due to congestion, I don't see how TCP could reliably deal with a packet that says "A packet you, (or someone else) sent that may have been from this protocol (or some other protocol, we dunno), with ports that might be a and b (but could equally be any other port), was corrupt. Good luck!" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Oct 27 18:38:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24098 for ; Wed, 27 Oct 2004 18:38:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMweu-00018e-8D for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 18:52:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwJw-0005tr-24; Wed, 27 Oct 2004 18:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMw8O-0002zQ-S5 for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 18:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22236 for ; Wed, 27 Oct 2004 18:19:09 -0400 (EDT) Received: from web80502.mail.yahoo.com ([66.218.79.72]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMwMA-0000lN-BQ for ipv6@ietf.org; Wed, 27 Oct 2004 18:33:37 -0400 Message-ID: <20041027221829.3015.qmail@web80502.mail.yahoo.com> Received: from [63.197.18.101] by web80502.mail.yahoo.com via HTTP; Wed, 27 Oct 2004 15:18:29 PDT Date: Wed, 27 Oct 2004 15:18:29 -0700 (PDT) From: Fred Templin To: Perry Lorier In-Reply-To: <41801660.8050909@coders.net> MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Brian Haberman , IPv6 WG , Pekka Savola Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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="===============0622149338==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 --===============0622149338== Content-Type: multipart/alternative; boundary="0-338292438-1098915509=:2917" --0-338292438-1098915509=:2917 Content-Type: text/plain; charset=us-ascii It wasn't specified, but the IPv6 layer should have reasonable assurance that the corruption occurred beyond the end of the header before sending ICMPs. Fred osprey67@yahoo.com Perry Lorier wrote: Fred Templin wrote: >Pekka Savola wrote: > I can't figure how ICMPv6 could notice any further data corruption in any >case, so I see no direct justification in *this* spec.) > > >We are speaking here about the case of the IPv6 layer noticing data corruption >in a received packet and then sending an ICMPv6 error message with the new >Parameter Problem code back to the source. Data corruption can be detected, >e.g., if the link layer has a way to inform the IPv6 layer of packets received with >errors - but this is not necessarily the *only* example. > > > I may be rather naive here, but if you detect that the packet is corrupt then how do you know if the source address is valid? How is the remote end supposed to tie it back to a packet it sent given that you've just said "this packet is corrupt, and you can't rely on any data in it"? While I agree that something like TCP would love to know if loss was due to transmission error, or due to congestion, I don't see how TCP could reliably deal with a packet that says "A packet you, (or someone else) sent that may have been from this protocol (or some other protocol, we dunno), with ports that might be a and b (but could equally be any other port), was corrupt. Good luck!" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-338292438-1098915509=:2917 Content-Type: text/html; charset=us-ascii
It wasn't specified, but the IPv6 layer should have reasonable assurance that
the corruption occurred beyond the end of the header before sending ICMPs.
 
Fred


Perry Lorier <perry@coders.net> wrote:
Fred Templin wrote:

>Pekka Savola wrote:
> I can't figure how ICMPv6 could notice any further data corruption in any
>case, so I see no direct justification in *this* spec.)
>
>
>We are speaking here about the case of the IPv6 layer noticing data corruption
>in a received packet and then sending an ICMPv6 error message with the new
>Parameter Problem code back to the source. Data corruption can be detected,
>e.g., if the link layer has a way to inform the IPv6 layer of packets received with
>errors - but this is not necessarily the *only* example.
>
>
>
I may be rather naive here, but if you detect that the packet is corrupt
then how do you know if the source address is valid? How is the remote
end supposed to tie it back to a packet it sent given that you've j! ust
said "this packet is corrupt, and you can't rely on any data in it"?

While I agree that something like TCP would love to know if loss was due
to transmission error, or due to congestion, I don't see how TCP could
reliably deal with a packet that says "A packet you, (or someone else)
sent that may have been from this protocol (or some other protocol, we
dunno), with ports that might be a and b (but could equally be any
other port), was corrupt. Good luck!"



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-338292438-1098915509=:2917-- --===============0622149338== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0622149338==-- From ipv6-bounces@ietf.org Wed Oct 27 19:22:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27056 for ; Wed, 27 Oct 2004 19:22:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxLN-00022J-9n for ipv6-web-archive@ietf.org; Wed, 27 Oct 2004 19:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMx40-0004Mf-VO; Wed, 27 Oct 2004 19:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwzV-0003pe-8p for ipv6@megatron.ietf.org; Wed, 27 Oct 2004 19:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26428 for ; Wed, 27 Oct 2004 19:14:01 -0400 (EDT) Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxDS-0001qO-DN for ipv6@ietf.org; Wed, 27 Oct 2004 19:28:31 -0400 Received: from alerion.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i9RNDD707859; Wed, 27 Oct 2004 16:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id C5CD23F0020; Wed, 27 Oct 2004 16:13:13 -0700 (PDT) Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16619-10; Wed, 27 Oct 2004 16:13:12 -0700 (PDT) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id E6D583F001F; Wed, 27 Oct 2004 16:13:12 -0700 (PDT) From: Tim Hartrick To: Fred Templin In-Reply-To: References: Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1098918748.4941.15.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 Oct 2004 16:12:29 -0700 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 WG , Pekka Savola , Perry Lorier Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@mentat.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit All, On Wed, 2004-10-27 at 15:18, Fred Templin wrote: > It wasn't specified, but the IPv6 layer should have reasonable > assurance that > the corruption occurred beyond the end of the header before sending > ICMPs. > It is hard to imagine the IESG allowing functionality this speculative to arrive in a specification that is recycling at DS. And for good reason. There is no chance that any functionality like this could get implementation reports sufficient to qualify for DS within three IETFs let alone within a couple of days or weeks. This work doesn't belong in this specification. It may not belong anywhere because of the issues cited by Perry. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Oct 28 03:10:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12163 for ; Thu, 28 Oct 2004 03:10:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN4eB-0001gA-Ft for ipv6-web-archive@ietf.org; Thu, 28 Oct 2004 03:24:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN4M5-0007NY-CF; Thu, 28 Oct 2004 03:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN4Ks-00079v-5x for ipv6@megatron.ietf.org; Thu, 28 Oct 2004 03:04:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11643 for ; Thu, 28 Oct 2004 03:04:37 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN4Yq-0001aV-6d for ipv6@ietf.org; Thu, 28 Oct 2004 03:19:07 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9S73vE11570; Thu, 28 Oct 2004 09:03:57 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Oct 2004 09:03:56 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D4581A3@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: Bob Hinden , ipv6@ietf.org Date: Thu, 28 Oct 2004 09:03:56 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: Last call comments for draft-ipngwg-icmp-v3-05 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Various points... Section 1: The first sentence (The Internet Protocol, version 6 (IPv6) is a new version of IP.) is not really useful for an ongoing standards document, and could be deleted without loss. Section 2.1 would be better split into three sections and reordered - it covers three things rather than just the general message format: 2.1 Message General Format Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header. (NOTE: this is different than the value used to identify ICMP for IPv4.) The ICMPv6 messages have the following general format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message Body + | | The type field indicates the type of the message. Its value determines the format of the remaining data. The code field depends on the message type. It is used to create an additional level of message granularity. The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. ICMPv6 messages are grouped into two classes: error messages and informational messages. Error messages are identified as such by having a zero in the high-order bit of their message Type field values. Thus, error messages have message Types from 0 to 127; informational messages have message Types from 128 to 255. 2.2 ICMP Messages Defined in the Document This document defines the message formats and functions for the following ICMPv6 messages: ICMPv6 error messages: 1 Destination Unreachable (see section 3.1) 2 Packet Too Big (see section 3.2) 3 Time Exceeded (see section 3.3) 4 Parameter Problem (see section 3.4) ICMPv6 informational messages: 128 Echo Request (see section 4.1) 129 Echo Reply (see section 4.2) 2.3 Format of ICMP Error Messages The subclass of ICMPv6 messages used for reporting errors, i.e., those with a Type value between 0 and 127, inclusive, all have the following, more specific format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type-specific data (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | + as will fit without the ICMPv6 packet + | exceeding the minimum IPv6 MTU [IPv6] | (Renumber remaining subsections of 2). Section 2.4 [current numbering scheme] Many implementations implement the ability to suppress responses to pings and some error messages by policy choice. Is this something that might be documented given that it is considered to be a matter of security? Section 2.4(d): There is another related circumstance in which it may not be possible to determine the protocol or port numbers: if the errored packet has an ESP, it would be necessary to decrypt the packet to determine both. This may not be possible either because the packet is truncated or because the encryption algorithm does not have the necessary state needed to decrypt this packet. This situation may become much more relevant than the truncation of long headers in future. Section 2.4(e) - Editorial nit: (e.4) a packet sent as a link-layer multicast, (the exception ---------- exceptions from e.3 applies to this case too), or ------- apply Similarly for (e.5) Sections 3.1-3.4: Given the caveat in Section 2.4(d)(and the extra, possibly more common case, identified above), the comments on the individual messages about informing the upper layer protocol should be qualified accordingly. This affects the last paragraphs of sections 3.1-3.4 - suggest changing to: A node receiving the ICMPv6 [xxx error] message MUST notify the upper-layer process if the relevant process can be identified (see Section 2.4(d)). Section 3.4 Parameter Problem message It might be useful to add a note that (presumably) Code 0 is the fallback case in case neither of the other two fit the bill. The description of code 2 (IPv6 Option) could be improved - it is (presumably) about options in hop-by-hop and destination extension headers from the base standard. Since, in principle, other headers of the same kind could be defined, would this code be used for options in those headers? ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 03:41:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03355 for ; Fri, 29 Oct 2004 03:41:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRcm-0007pg-NP for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 03:56:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRHl-00010X-6J; Fri, 29 Oct 2004 03:34:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6BO-0003mS-Cw for ipv6@megatron.ietf.org; Mon, 25 Oct 2004 10:50:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01509 for ; Mon, 25 Oct 2004 10:50:47 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6On-0008B5-ND for ipv6@ietf.org; Mon, 25 Oct 2004 11:04:45 -0400 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.8858551; Mon, 25 Oct 2004 10:49:41 -0400 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <1A85C067-2695-11D9-A7B8-000D93330CAA@jhuapl.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IPv6 WG From: Brian Haberman Date: Mon, 25 Oct 2004 10:49:42 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Oct 2004 03:34:55 -0400 Subject: IPv6 WG Last Call:draft-ietf-ipv6-host-load-sharing-03.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit All, This is the start of a 1-week WG Last Call on advancing: Title : IPv6 Host to Router Load Sharing Author(s) : R. Hinden, D. Thaler Filename : draft-ietf-ipv6-host-load-sharing-03.txt Pages : 6 Date : 2004-10-21 as a Proposed Standard. The aim of this LC is to ensure resolution of all issues raised during the previous last call. Substantive comments should be directed to the mailing list. This last call will end on 11/01/2004. Regards, Bob & Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 03:45:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03548 for ; Fri, 29 Oct 2004 03:45:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRfy-0007t8-Uh for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 04:00:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRHm-00011y-Rz; Fri, 29 Oct 2004 03:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPVt-0003F9-4g for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 01:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11054 for ; Fri, 29 Oct 2004 01:41:23 -0400 (EDT) Received: from cp.64translator.com ([202.214.123.2] helo=senegal.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPjv-0005XR-Qp for ipv6@ietf.org; Fri, 29 Oct 2004 01:56:06 -0400 Received: from localhost (localhost [IPv6:::1]) by senegal.64translator.com (8.12.11/8.12.11) with SMTP id i9T5ecpQ000848 for ; Fri, 29 Oct 2004 14:40:38 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Date: Fri, 29 Oct 2004 14:40:38 +0900 From: Nobumichi Ozoe To: ipv6@ietf.org Message-Id: <20041029144038.1e78a1c9.Nobumichi.Ozoe@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Oct 2004 03:34:55 -0400 Subject: 6th TAHI IPv6 Interoperability Test Event - 24 - 28 January 2005, Chiba, Japan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Dear All, TAHI Projcet is organizing its 6th TAHI IPv6 Interoperability Test Event. The event will be held from 24th - 28th January 2005 at the Makuhari messe of Chiba Japan. Registration will be avairable from 17 November 2004 at: http://www.tahi.org/inop/6thinterop.html Deadline to register is 31 December 2004 This time we will provide the following tests: o Conformance test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, IKE for IPv6, SNMP for IPv6 SIP, IPv6 Core Protocol, IPsec, MLDv1, Default Address Selection, Default Router Preference .... o Interoperability test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, NEMO SIP, IPv6 Core Protocol, IPsec, IKE, Prefix Delegation, MLDv2 .... For more details, please visit our web site. * TAHI Project Home Page http://www.tahi.org/ * 6th TAHI IPv6 Interoperability Test Event Announce Page http://www.tahi.org/inop/6thinterop.html #I'm sorry if you have already received this mail. Regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 03:49:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03949 for ; Fri, 29 Oct 2004 03:49:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRkD-00089K-JL for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 04:04:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRHo-00012i-HI; Fri, 29 Oct 2004 03:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQQm-0008K4-2c for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 02:40:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29337 for ; Fri, 29 Oct 2004 02:40:09 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQey-0006Z3-BN for ipv6@ietf.org; Fri, 29 Oct 2004 02:54:53 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9T6dpl24148; Fri, 29 Oct 2004 09:39:51 +0300 (EET DST) X-Scanned: Fri, 29 Oct 2004 09:36:48 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9T6amak023779; Fri, 29 Oct 2004 09:36:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00W32rKd; Fri, 29 Oct 2004 09:36:01 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9T6Zla29666; Fri, 29 Oct 2004 09:35:47 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 01:35:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2004 01:35:46 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB5FE@daebe009.americas.nokia.com> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt Thread-Index: AcS8gjjFpgRQ5CWJSA+5jbnLY3sEaAA/uYTg To: , X-OriginalArrivalTime: 29 Oct 2004 06:35:46.0784 (UTC) FILETIME=[85E22E00:01C4BD81] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 29 Oct 2004 03:34:55 -0400 Cc: brian@innovationslab.net, ipv6@ietf.org, pekkas@netcore.fi, perry@coders.net Subject: RE: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Fred, Looking at all the discussion/arguments, I think we have=20 consensus about not adding the proposed code point to the spec. I agree with all others that it is not required in this spec and it is not a good idea to add this code point at this (DS) stage. Regards Mukesh > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Tim Hartrick > Sent: Wednesday, October 27, 2004 4:12 PM > To: Fred Templin > Cc: Brian Haberman; IPv6 WG; Pekka Savola; Perry Lorier > Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt >=20 >=20 >=20 >=20 > All, >=20 > On Wed, 2004-10-27 at 15:18, Fred Templin wrote: > > It wasn't specified, but the IPv6 layer should have reasonable > > assurance that > > the corruption occurred beyond the end of the header before sending > > ICMPs. > > =20 >=20 > It is hard to imagine the IESG allowing functionality this speculative > to arrive in a specification that is recycling at DS. And for good > reason. There is no chance that any functionality like this could get > implementation reports sufficient to qualify for DS within three IETFs > let alone within a couple of days or weeks. >=20 > This work doesn't belong in this specification. It may not belong > anywhere because of the issues cited by Perry. >=20 >=20 >=20 > Tim Hartrick > Mentat Inc. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 03:54:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04370 for ; Fri, 29 Oct 2004 03:54:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRp0-0008G3-Ov for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 04:09:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRHr-000133-Bp; Fri, 29 Oct 2004 03:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQfQ-0001uN-Ik for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 02:55:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29873 for ; Fri, 29 Oct 2004 02:55:18 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQtd-0006n3-KO for ipv6@ietf.org; Fri, 29 Oct 2004 03:10:02 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9T6tCl12519; Fri, 29 Oct 2004 09:55:12 +0300 (EET DST) X-Scanned: Fri, 29 Oct 2004 09:54:55 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9T6stVI002196; Fri, 29 Oct 2004 09:54:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00MFdomL; Fri, 29 Oct 2004 09:53:03 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9T6cHa01867; Fri, 29 Oct 2004 09:38:17 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 01:38:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2004 01:38:16 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB5FF@daebe009.americas.nokia.com> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt Thread-Index: AcS8RZcHVPyOa0GzSMaLezZJmjifsQBPBVuA To: , X-OriginalArrivalTime: 29 Oct 2004 06:38:16.0783 (UTC) FILETIME=[DF4A35F0:01C4BD81] X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 29 Oct 2004 03:34:55 -0400 Cc: ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Pekka, Sorry to have that missed. I somehow assumed that we needed no=20 modification after the consensus. My bad ! I will try to rephrase the text while addressing all the other LC comments. Regards Mukesh > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Pekka Savola > Sent: Wednesday, October 27, 2004 9:39 AM > To: Brian Haberman > Cc: IPv6 WG > Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt >=20 >=20 > Hi, >=20 > On Mon, 25 Oct 2004, Brian Haberman wrote: > > This is the start of a 1-week IPv6 working group last call for > > recycling: > > > > Title : Internet Control Message Protocol=20 > (ICMPv6)for the > > Internet Protocol Version 6 (IPv6)=20 > Specification > > Author(s) : A. Conta, et al. > > Filename : draft-ietf-ipngwg-icmp-v3-05.txt > > Pages : 26 > > Date : 2004-10-22 > > > > at Draft Standard. This LC is aimed at ensuring resolution of all > > issues raised during the previous last call. Substantive comments > > should be directed to the mailing. This last call will end=20 > on 11/01/2004. >=20 > I think it was forgotten to clarify the ICMPv6 rate-limiting language=20 > (at the very least, using 'originate' instead of 'send') based on the=20 > consensus called at: >=20 > http://www.ietf.org/mail-archive/web/ipv6/current/msg03539.html >=20 > One attempt by me to fix this was at: >=20 > http://www.ietf.org/mail-archive/web/ipv6/current/msg03421.html >=20 > Other than that, I think the doc should be fine. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 03:56:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04590 for ; Fri, 29 Oct 2004 03:56:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRrK-0008KR-Rb for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 04:11:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRHt-00013B-0M; Fri, 29 Oct 2004 03:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQhm-0003WI-2v for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 02:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29990 for ; Fri, 29 Oct 2004 02:57:43 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQvy-0006p4-90 for ipv6@ietf.org; Fri, 29 Oct 2004 03:12:27 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9T6qIe23180; Fri, 29 Oct 2004 09:52:18 +0300 (EET DST) X-Scanned: Fri, 29 Oct 2004 09:47:09 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9T6l9W9017287; Fri, 29 Oct 2004 09:47:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00EaV3ez; Fri, 29 Oct 2004 09:45:03 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9T6j0a07229; Fri, 29 Oct 2004 09:45:01 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 01:44:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2004 01:44:59 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB5FE@daebe009.americas.nokia.com> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt Thread-Index: AcS8gjjFpgRQ5CWJSA+5jbnLY3sEaAA/uYTg To: , X-OriginalArrivalTime: 29 Oct 2004 06:44:59.0746 (UTC) FILETIME=[CF797C20:01C4BD82] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 29 Oct 2004 03:34:55 -0400 Cc: brian@innovationslab.net, ipv6@ietf.org, pekkas@netcore.fi, perry@coders.net Subject: RE: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Fred, Looking at all the discussion/arguments, I think we have=20 consensus about not adding the proposed code point to the spec. I agree with all others that it is not required in this spec and it is not a good idea to add this code point at this (DS) stage. Regards Mukesh > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Tim Hartrick > Sent: Wednesday, October 27, 2004 4:12 PM > To: Fred Templin > Cc: Brian Haberman; IPv6 WG; Pekka Savola; Perry Lorier > Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt >=20 >=20 >=20 >=20 > All, >=20 > On Wed, 2004-10-27 at 15:18, Fred Templin wrote: > > It wasn't specified, but the IPv6 layer should have reasonable > > assurance that > > the corruption occurred beyond the end of the header before sending > > ICMPs. > > =20 >=20 > It is hard to imagine the IESG allowing functionality this speculative > to arrive in a specification that is recycling at DS. And for good > reason. There is no chance that any functionality like this could get > implementation reports sufficient to qualify for DS within three IETFs > let alone within a couple of days or weeks. >=20 > This work doesn't belong in this specification. It may not belong > anywhere because of the issues cited by Perry. >=20 >=20 >=20 > Tim Hartrick > Mentat Inc. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 03:58:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04766 for ; Fri, 29 Oct 2004 03:58:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRsc-0008Nh-EW for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 04:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRHu-00014q-LJ; Fri, 29 Oct 2004 03:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1eS-0006Ah-68 for ipv6@megatron.ietf.org; Fri, 22 Oct 2004 11:48:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15435 for ; Fri, 22 Oct 2004 11:48:20 -0400 (EDT) Received: from portal.hamachi.org ([69.25.196.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1rF-0000re-Hw for ipv6@ietf.org; Fri, 22 Oct 2004 12:01:38 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id CA4D717985; Fri, 22 Oct 2004 11:48:17 -0400 (EDT) From: BIll Sommerfeld To: Suresh Krishnan In-Reply-To: References: Content-Type: text/plain Message-Id: <1098460022.4555.68.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 22 Oct 2004 11:47:04 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Oct 2004 03:35:01 -0400 Cc: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit On Fri, 2004-10-22 at 11:04, Suresh Krishnan wrote: > Can you give me more details or a pointer to such an attack? I will add > add some text and a reference to it. There's a wealth of information about traffic analysis capabilities in many books about WW-II-era codebreaking. As a more modern example: By observing the timing and size of a sequence of packets in and out of a system acting as a traditional SMTP mail relay, one can most likely identify probable SMTP flows (3-way handshake of tinygrams, SMTP banner, HELO, MAIL FROM, one or more RCPT TO, DATA+message, QUIT, tcp termination tinygrams). This gives you message size, recipient count, and length of each email address in the envelope. You can now correlate messages in with messages out (message out will be larger by the typical size of a received: header), and may let you identify messages and possible replies in 1:1 email conversations by matching the sender and recipient address lengths... With sufficient data you could also probably also pick out behavioral quirks such as which correspondents habitually fail to trim quoted material in replied-to messages. You may also want to reference the new traffic-flow-security extensions (extended padding, dummy traffic discards) in the current drafts of IPsec ESP. - Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 04:11:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06146 for ; Fri, 29 Oct 2004 04:11:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNS5r-0000L8-Qr for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 04:26:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRlm-00031Z-DK; Fri, 29 Oct 2004 04:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRS9-0008Uv-PU for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 03:45:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03581 for ; Fri, 29 Oct 2004 03:45:40 -0400 (EDT) Received: from cp.64translator.com ([202.214.123.2] helo=senegal.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRgN-0007ss-B1 for ipv6@ietf.org; Fri, 29 Oct 2004 04:00:24 -0400 Received: from localhost (localhost [IPv6:::1]) by senegal.64translator.com (8.12.11/8.12.11) with SMTP id i9T7j2CS001064 for ; Fri, 29 Oct 2004 16:45:02 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Date: Fri, 29 Oct 2004 16:45:02 +0900 From: Nobumichi Ozoe To: ipv6@ietf.org Message-Id: <20041029164502.675eadd5.Nobumichi.Ozoe@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: 6th TAHI IPv6 Interoperability Test Event - 24 - 28 January 2005, Chiba, Japan 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Dear All, TAHI Projcet is organizing its 6th TAHI IPv6 Interoperability Test Event. The event will be held from 24th - 28th January 2005 at the Makuhari messe of Chiba Japan. Registration will be avairable from 17 November 2004 at: http://www.tahi.org/inop/6thinterop.html Deadline to register is 31 December 2004 This time we will provide the following tests: o Conformance test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, IKE for IPv6, SNMP for IPv6 SIP, IPv6 Core Protocol, IPsec, MLDv1, Default Address Selection, Default Router Preference .... o Interoperability test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, NEMO SIP, IPv6 Core Protocol, IPsec, IKE, Prefix Delegation, MLDv2 .... For more details, please visit our web site. * TAHI Project Home Page http://www.tahi.org/ * 6th TAHI IPv6 Interoperability Test Event Announce Page http://www.tahi.org/inop/6thinterop.html #I'm sorry if you have already received this mail. Regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 04:28:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07319 for ; Fri, 29 Oct 2004 04:28:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSLw-0000gA-Mz for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 04:43:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRrB-0008Px-1D; Fri, 29 Oct 2004 04:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNRkh-0002MX-LQ for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 04:04:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05395 for ; Fri, 29 Oct 2004 04:04:47 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRyt-00007O-TX for ipv6@ietf.org; Fri, 29 Oct 2004 04:19:33 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6C004D36F4S1@mailout3.samsung.com> for ipv6@ietf.org; Fri, 29 Oct 2004 17:04:16 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6C00A3W698QV@mailout3.samsung.com> for ipv6@ietf.org; Fri, 29 Oct 2004 17:00:44 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6C006GL698XE@mmp2.samsung.com> for ipv6@ietf.org; Fri, 29 Oct 2004 17:00:44 +0900 (KST) Date: Fri, 29 Oct 2004 17:02:14 +0900 From: Soohong Daniel Park In-reply-to: To: Pekka Savola , Brian Haberman Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7BIT Cc: IPv6 WG Subject: RE: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7BIT Hi > If M-Policy is 1, the host SHOULD invoke Host Configuration Behaviour > for address and other configuration information, regardless of the > change of the state variables. The host SHOULD NOT invoke > Information Configuration Behaviour regardless of O-Policy. Note, > however, that if the available DHCPv6 servers only provide the > service for the Information Configuration Behaviour, the host will > even not be able to configure other configuration parameters than > addresses. Thus, it is generally inadvisable to set M-Policy to 1, > unless there is a particular reason to do so. > > ==> is it really true that if a full DHCPv6 client is initiated, and > the server is 'stateless', the DHCPv6 client doesn't get back the > stateless information? > > That would seem to be a big problem for DHCPv6 deployment if servers > are stateless, and I think someone has claimed that this shouldn't be > a problem. > > If the text you wrote is correct, that would mean that to get robust > behaviour, the host would have to either rely that the capabilities of > the DHCPv6 servers match those that are advertised in the route > advertisements, or to always just "prepare for the worst" by firing > off a parallel information-request as well. > > And then it would seem to make sense for prudent DHCPv6 implementers > to do everything they can to ensure they'll receive information-reply > from stateful servers as well.. because that's better than nothing, > and better than relying on how the bits in RAs have been configured! A node that performs Information Configuration Behaviour (is newly defined in this document instead of stateless DHCPv6) MUST have obtained its IPv6 addresses through some other mechanism. So if the node is supposed to perform Information Configuration Behaviour without IPv6 addresses, it is a problematic situation (further, IMO, it is a rare environment). That is why we said *inadvisable* in this document. IMO, it does not occur severe problems since RFC3736 is just a subset of the full DHCPv6 service, thus a full DHCPv6 client (as you said) can do both or either Host Configuration Behaviour for configuring the IPv6 address and Information Configuration Behaviour for the other information. > - minor issue wrt inconsistent M/O information: > > If the host frequently receives inconsistent M and O flags of Router > Advertisement (e.g., in a mobile environment for supporting fast > movement detection), it may need complex consideration on an > erroneous case. However, this case is not closely related to this > document; rather, it is a general issue on the inconsistent Router > Advertisement parameters from multiple routers. In fact, other > configuration parameters such as the MTU size and the hop limit are > also possible to be inconsistent in different Router Advertisements. > > ==> actually M/O is IMHO a bit worse than these two, because these are > just internal variables, typically implemented in the kernel, and > toggling back and forth between them is not a problem. > > Presumably, initiating DHCPv6 requires running a non-trivial user-land > process. Hence, I'd dare to say that the transitions are a bigger > problem with M/O flags, as has already been discussed a bit in > security considerations. > > Thus I'd like to see some further text, e.g. 1-2 sentences, describing > why M/O transitions are a bigger problem than other inconsistent > information. If required, your concern will appear in the revision. Thanks. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 05:45:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12285 for ; Fri, 29 Oct 2004 05:45:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNTYD-00028V-0S for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 06:00:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNT1c-0007bq-IR; Fri, 29 Oct 2004 05:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSbR-0007zD-QC for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 04:59:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09421 for ; Fri, 29 Oct 2004 04:59:19 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSpg-0001Go-OG for ipv6@ietf.org; Fri, 29 Oct 2004 05:14:05 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9T8wTs10360; Fri, 29 Oct 2004 11:58:33 +0300 Date: Fri, 29 Oct 2004 11:58:29 +0300 (EEST) From: Pekka Savola To: Soohong Daniel Park In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Brian Haberman , IPv6 WG Subject: RE: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 On Fri, 29 Oct 2004, Soohong Daniel Park wrote: >> If M-Policy is 1, the host SHOULD invoke Host Configuration Behaviour >> for address and other configuration information, regardless of the >> change of the state variables. The host SHOULD NOT invoke >> Information Configuration Behaviour regardless of O-Policy. Note, >> however, that if the available DHCPv6 servers only provide the >> service for the Information Configuration Behaviour, the host will >> even not be able to configure other configuration parameters than >> addresses. Thus, it is generally inadvisable to set M-Policy to 1, >> unless there is a particular reason to do so. >> >> ==> is it really true that if a full DHCPv6 client is initiated, and >> the server is 'stateless', the DHCPv6 client doesn't get back the >> stateless information? >> >> That would seem to be a big problem for DHCPv6 deployment if servers >> are stateless, and I think someone has claimed that this shouldn't be >> a problem. >> >> If the text you wrote is correct, that would mean that to get robust >> behaviour, the host would have to either rely that the capabilities of >> the DHCPv6 servers match those that are advertised in the route >> advertisements, or to always just "prepare for the worst" by firing >> off a parallel information-request as well. >> >> And then it would seem to make sense for prudent DHCPv6 implementers >> to do everything they can to ensure they'll receive information-reply >> from stateful servers as well.. because that's better than nothing, >> and better than relying on how the bits in RAs have been configured! > > A node that performs Information Configuration Behaviour (is newly defined > in this document instead of stateless DHCPv6) MUST have obtained > its IPv6 addresses through some other mechanism. So if the node > is supposed to perform Information Configuration Behaviour without > IPv6 addresses, it is a problematic situation (further, IMO, it is a rare > environment). That is why we said *inadvisable* in this document. > IMO, it does not occur severe problems since RFC3736 is just a subset > of the full DHCPv6 service, thus a full DHCPv6 client (as you said) can do > both or either Host Configuration Behaviour for configuring the IPv6 address > and Information Configuration Behaviour for the other information. I think this missed the point; maybe I didn't articulate it well enough. I'm not concerned about how nodes configure addresses, but rather how nodes get the other information. The text above could be read so that a full DHCPv6 client would not get addresses (obviously!) and neither other information (that would be surprising, but I could imagine why this could happen) from a stateless DHCPV6 server. The question is, does it really not get 'other information', and if so, this calls for several other actions. If not, the draft needs to be revised for clarity. -- 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 Oct 29 08:41:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24850 for ; Fri, 29 Oct 2004 08:41:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWJ6-0005z3-Oh for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 08:56:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNW2M-0007OI-5z; Fri, 29 Oct 2004 08:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVih-0004Ot-C3 for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 08:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23180 for ; Fri, 29 Oct 2004 08:19:01 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNVwy-0005Tk-A5 for ipv6@ietf.org; Fri, 29 Oct 2004 08:33:48 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9TCIUkT014174 for ; Fri, 29 Oct 2004 07:18:30 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 29 Oct 2004 08:18:30 -0400 Message-ID: From: "Brzozowski, John Jason (John)" To: "'ipv6@ietf.org'" Date: Fri, 29 Oct 2004 08:18:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: RE: DHCPv6 Server 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Lucent Technologies currently has a DHCPv6 Server and Client. BETA testing for the same will begin later this year. If anyone is interested please contact me directly. Regards, ============================================ John Jason Brzozowski Lucent Technologies 610.722.7979 jjbrzozowski@lucent.com ============================================ [JJB] -----Original Message----- [JJB] From: ipv6-bounces@ietf.org [JJB] [mailto:ipv6-bounces@ietf.org]On Behalf Of [JJB] Suresh Krishnan [JJB] Sent: Monday, October 18, 2004 9:04 PM [JJB] To: Hansen Chan [JJB] Cc: ipv6@ietf.org [JJB] Subject: Re: DHCPv6 Server [JJB] [JJB] [JJB] Hi Hansen, [JJB] I remember seeing two of them. One is from HP and is [JJB] included in HP-UX [JJB] 11i v1. The other one is from NEC. There is also an open source [JJB] implementation at http://dhcpv6.sourceforge.net [JJB] [JJB] Regards [JJB] Suresh [JJB] [JJB] On Mon, 18 Oct 2004, Hansen Chan wrote: [JJB] [JJB] >Hello all, [JJB] > [JJB] >Don't know whether this is the right mailing list to [JJB] pose this question. [JJB] >I am looking for commercial DHCPv6 server. Can someone [JJB] recommend some [JJB] >names to me? [JJB] > [JJB] >Thanks, [JJB] >Hansen [JJB] > [JJB] >> [JJB] > [JJB] > [JJB] >--------------------------------------------------------- [JJB] ----------- [JJB] >IETF IPv6 working group mailing list [JJB] >ipv6@ietf.org [JJB] >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 Oct 29 16:15:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02847 for ; Fri, 29 Oct 2004 16:15:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdOA-00080I-IQ for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 16:30:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNclV-0004yK-Gh; Fri, 29 Oct 2004 15:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcOp-0002vK-Jc for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 15:26:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28158 for ; Fri, 29 Oct 2004 15:26:57 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcdA-0006hB-FS for ipv6@ietf.org; Fri, 29 Oct 2004 15:41:48 -0400 Received: from [10.0.0.75] (account margaret HELO [10.0.0.75]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 183054 for ipv6@ietf.org; Fri, 29 Oct 2004 15:21:21 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Fri, 29 Oct 2004 15:26:48 -0400 To: ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi All, We're having a discussion on URIs and IRIs in the IESG that has led me to realize that the URL literal IPv6 address format described in RFC 2732 does not contain any provision for including a zone ID. I don't think that we could simply add a "%zone-id" to the end of the IP address, because % is a special character in URLs. Thoughts? Is this something we should update? Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 16:36:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07382 for ; Fri, 29 Oct 2004 16:36:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdiR-0000p1-8N for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 16:51:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNclr-0005Gh-Ke; Fri, 29 Oct 2004 15:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcYK-0000b2-Je; Fri, 29 Oct 2004 15:36:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28839; Fri, 29 Oct 2004 15:36:46 -0400 (EDT) Message-Id: <200410291936.PAA28839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 29 Oct 2004 15:36:46 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-2461bis-01.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-2461bis-01.txt Pages : 86 Date : 2004-10-29 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-01.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-ipv6-2461bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-2461bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-29155928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-2461bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-2461bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-29155928.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Oct 29 17:19:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13825 for ; Fri, 29 Oct 2004 17:19:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNeNw-0002Yz-VK for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 17:34:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdhy-0003fL-Bq; Fri, 29 Oct 2004 16:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNd1d-0002v1-8z for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 16:07:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01738 for ; Fri, 29 Oct 2004 16:07:02 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdFy-0007fd-0V for ipv6@ietf.org; Fri, 29 Oct 2004 16:21:54 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Oct 2004 16:06:17 -0400 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, 29 Oct 2004 16:06:31 -0400 Message-ID: Thread-Topic: Link MTU restriction in 2461 Thread-Index: AcS6WdIWvcHS6dn6RnedrKV6aCxumwAjYcQAAMLUdQA= From: "Soliman, Hesham" To: "Soliman, Hesham" , X-OriginalArrivalTime: 29 Oct 2004 20:06:17.0095 (UTC) FILETIME=[BFCEC170:01C4BDF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Subject: RE: 2461bis update 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable The draft is now available at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-01.txt > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > Behalf Of > Soliman, Hesham > Sent: Monday, October 25, 2004 7:10 PM > To: ipv6@ietf.org > Subject: 2461bis update >=20 >=20 > Folks,=20 >=20 > Last night I submitted an updated 2461bis draft.=20 > I believe all issues raised were addressed in this update. > Please have a look at the draft when it appears on the=20 > web and look for comments you might have raised and=20 > were either not responded to, or agreed to be updated > but were not. If I missed any of those please let me=20 > know and send comments to the list. >=20 > I think the draft is now ready for WG LC. >=20 > Hesham >=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=20 > for the sole use > of the intended recipient. Any review or distribution by=20 > others is strictly > prohibited. If you are not the intended recipient please=20 > 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 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Oct 29 17:31:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15418 for ; Fri, 29 Oct 2004 17:31:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNeZU-000327-Hx for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 17:46:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNe3V-0008BG-EA; Fri, 29 Oct 2004 17:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdMr-0003H4-UI for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 16:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05385 for ; Fri, 29 Oct 2004 16:28:59 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdbD-0000DC-7N for ipv6@ietf.org; Fri, 29 Oct 2004 16:43:51 -0400 Received: from [192.168.1.176] ([196.40.10.138]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000541397.msg for ; Fri, 29 Oct 2004 22:33:39 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 29 Oct 2004 14:28:09 -0600 From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Fri, 29 Oct 2004 22:33:39 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 196.40.10.138 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-MDAV-Processed: consulintel.es, Fri, 29 Oct 2004 22:33:43 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: Re: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi Margaret, Why not ? We are using the [] to enclose the IPv6 address, so then the % will be also inside the square brackets, right ? Regards, Jordi > De: Margaret Wasserman > Responder a: ipv6-bounces@ietf.org > Fecha: Fri, 29 Oct 2004 15:26:48 -0400 > Para: ipv6@ietf.org > Asunto: RFC 2732 and Zone IDs > > > Hi All, > > We're having a discussion on URIs and IRIs in the IESG that has led > me to realize that the URL literal IPv6 address format described in > RFC 2732 does not contain any provision for including a zone ID. I > don't think that we could simply add a "%zone-id" to the end of the > IP address, because % is a special character in URLs. > > Thoughts? Is this something we should update? > > Margaret > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line 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 Fri Oct 29 18:36:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22160 for ; Fri, 29 Oct 2004 18:36:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNfaD-0004WA-FZ for ipv6-web-archive@ietf.org; Fri, 29 Oct 2004 18:50:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNf9Z-0005Sx-Uq; Fri, 29 Oct 2004 18:23:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNf3d-0008VZ-D5 for ipv6@megatron.ietf.org; Fri, 29 Oct 2004 18:17:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20663 for ; Fri, 29 Oct 2004 18:17:14 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNfI0-00049e-0P for ipv6@ietf.org; Fri, 29 Oct 2004 18:32:08 -0400 Received: from [10.0.0.75] (account margaret HELO [10.0.0.75]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 183243; Fri, 29 Oct 2004 18:11:37 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Fri, 29 Oct 2004 18:16:56 -0400 To: jordi.palet@consulintel.es, From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Re: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 I don't know... I am far from a URL expert, but in discussions about how to encode IPv6 literals in URIs and IRIs, the square brackets don't seem to be enough. The percent sign also has to be encoded as a %25 and/or changed to another character. Does this apply to URLs, too? Margaret At 2:28 PM -0600 10/29/04, JORDI PALET MARTINEZ wrote: >Hi Margaret, > >Why not ? We are using the [] to enclose the IPv6 address, so then the % >will be also inside the square brackets, right ? > >Regards, >Jordi > > >> De: Margaret Wasserman >> Responder a: ipv6-bounces@ietf.org >> Fecha: Fri, 29 Oct 2004 15:26:48 -0400 >> Para: ipv6@ietf.org >> Asunto: RFC 2732 and Zone IDs >> >> >> Hi All, >> >> We're having a discussion on URIs and IRIs in the IESG that has led >> me to realize that the URL literal IPv6 address format described in >> RFC 2732 does not contain any provision for including a zone ID. I >> don't think that we could simply add a "%zone-id" to the end of the >> IP address, because % is a special character in URLs. >> >> Thoughts? Is this something we should update? >> >> Margaret >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > >********************************** >Madrid 2003 Global IPv6 Summit >Presentations and videos on line 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Oct 30 02:32:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02733 for ; Sat, 30 Oct 2004 02:32:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNn1l-0003l5-L8 for ipv6-web-archive@ietf.org; Sat, 30 Oct 2004 02:47:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNmdt-00034r-BM; Sat, 30 Oct 2004 02:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNmWR-0005vZ-IS for ipv6@megatron.ietf.org; Sat, 30 Oct 2004 02:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01431 for ; Sat, 30 Oct 2004 02:15:29 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNmkr-0003Vi-Qq for ipv6@ietf.org; Sat, 30 Oct 2004 02:30:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9U6Eo506695; Sat, 30 Oct 2004 09:14:50 +0300 Date: Sat, 30 Oct 2004 09:14:50 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Fri, 29 Oct 2004, Margaret Wasserman wrote: > We're having a discussion on URIs and IRIs in the IESG that has led > me to realize that the URL literal IPv6 address format described in > RFC 2732 does not contain any provision for including a zone ID. I > don't think that we could simply add a "%zone-id" to the end of the > IP address, because % is a special character in URLs. > > Thoughts? Is this something we should update? Yes, I believe this is a problem. Possibly the best solution is specifying a BCP that limited scope addresses should not be used in URLs or in applications like that. People trying to use link-local addresses for "normal" applications is just causing grief. Perhaps that needs to be stopped. -- 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 Sat Oct 30 07:27:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16221 for ; Sat, 30 Oct 2004 07:27:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNrcl-0008QI-Jy for ipv6-web-archive@ietf.org; Sat, 30 Oct 2004 07:42:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNrKh-0003Rw-W1; Sat, 30 Oct 2004 07:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNrAj-0007qB-EL for ipv6@megatron.ietf.org; Sat, 30 Oct 2004 07:13:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15663 for ; Sat, 30 Oct 2004 07:13:22 -0400 (EDT) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNrPC-0008EN-FE for ipv6@ietf.org; Sat, 30 Oct 2004 07:28:23 -0400 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9UBCqBU096930 for ; Sat, 30 Oct 2004 11:12:52 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9UBCqlw150136 for ; Sat, 30 Oct 2004 12:12:52 +0100 Received: from zurich.ibm.com (sig-9-145-133-119.de.ibm.com [9.145.133.119]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA82434 for ; Sat, 30 Oct 2004 13:12:51 +0200 Message-ID: <41837732.9010408@zurich.ibm.com> Date: Sat, 30 Oct 2004 13:12:50 +0200 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: IPv6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Subject: Re: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit We discussed this with respect to the scoped address document a while back (message attached below). Here's my view (clipped from some off-line dialogue) about why we didn't go into panic mode to get this fixed in the URI syntax (2396bis, already approved as full Standard, which obsoletes 2732) at that time: > Because it has no *reasonable* use? Is it reasonable to use HTTP this way? > It doesn't really bother me that it isn't covered by the latest URI syntax > (and therefore not by IRI syntax). I must say I have largely ignored > the whole scoped address debate, so I missed this when we did the original > work on RFC 2732. In any case this is a dead duck, unless the IESG wants to recall 2396bis from the RFC Editor, which seems absolutely unjustified to me. Brian -------- Original Message -------- Subject: Re: I-D ACTION:draft-ietf-ipv6-scoping-arch-02.txt Date: Wed, 01 Sep 2004 10:11:59 +0200 From: Brian E Carpenter Organization: IBM To: IPv6 References: <200408271440.KAA04170@ietf.org> <41343098.5070709@zurich.ibm.com> <4134314D.7010702@zurich.ibm.com> Your suggested changes seem fine to me. I certainly don't think we should recall the draft from the RFC Editor. If the changes can be made as editorial updates, that's fine. If not, they can simply be kept for the next version. I'm really sorry I didn't spot this during the Last Call. Brian JINMEI Tatuya wrote: >>>>>>On Tue, 31 Aug 2004 10:05:33 +0200, >>>>>>Brian E Carpenter said: > > >>P.S. I'm quite aware that this has already passed the IESG, >>but it will obviously have to be updated one day, so please >>keep these comments in a safe place. > > > I interpret this to mean that you are not requiring to revise the > draft addressing your comments. But it seems we can reflect some of > your points during the editorial work with the RFC editor. > > If my understanding is NOT correct, please say so explicitly. > > Now going to the comments: > > >>>>However, the typed URL is often sent on the wire, and it would cause >>>>confusion if an application did not strip the portion >>>>before sending. Note that the applications should not need to care >>>>about which kind of addresses they're using, much less parse or strip >>>>out the portion of the address. Also, the format for >>>>non-global addresses might conflict with the URI syntax [13], since >>>>the syntax defines the delimiter character (`%') as the escape >>>>character. >>> >>>[13] is RFC 2396, which will be obsoleted by draft-fielding-uri-rfc2396bis >>> >>>Actually there is no problem with the conflict, except that in a URI, >>>a percent sign has to be percent-encoded as %25. So zone_id 1 would >>>be represented in a URI as %251. > > > Yes, but the point is that the escaped format would not be able to be > passed to, e.g., getaddrinfo() directly. It would decrease the > benefit of the extended format with the "%" delimiter. Also, we > then could not simply copy-n-paste a literal IPv6 address with a zone > identifier from output of some other command. It would also decrease > the benefit of the format. > > So, for example, does it help to revise this paragraph as follows? > (i.e., adding several sentences at the end of the paragraph) > > However, the typed URL is often sent on the wire, and it would cause > confusion if an application did not strip the portion > before sending. Note that the applications should not need to care > about which kind of addresses they're using, much less parse or strip > out the portion of the address. Also, the format for > non-global addresses might conflict with the URI syntax [13], since > the syntax defines the delimiter character (`%') as the escape > character. This conflict would require, for example, that the > part for zone 1 with the delimiter be represented as > '%251'. But it also means that we could not simply copy a > non-escaped format from other sources as input to the URI parser. > Additionally, if the URI parser does not convert the escaped format > before passing it to a name-to-address library, the conversion will > fail. All these issues would decrease the benefit of the textual > representation described in this section. > > >>>>Hence, this document does not specify how the format for non-global >>>>addresses should be combined with the preferred format for literal >>>>IPv6 addresses. > > >>>I'd want a URI syntax expert to check, but I'm not sure that >>>there is any problem with %251, %252, etc. It's ugly, but using >>>literal addresses is always ugly. The real question is whether there >>>would ever be any *need* to specify a zone_id in a URI. > > > Regarding %251 or %252, see above. > > Regarding the "real question", I'd say it should at least be rare, so > we could simply remove the URI issues if it can be a blocking problem. > But I can imagine some usage similar to the example shown in Section > 11.4, considering many today's leaf routers have web interface, and > thus I believe providing some notes might help. > > >>>>As for the conflict issue with the URI format, it >>>>would be better to wait until the relationship between the preferred >>>>format and the URI syntax is clarified. >>> >>>It is clarified by draft-fielding-uri-rfc2396bis. >>> >>> >>>>...In fact, the preferred >>>>format for IPv6 literal addresses itself has the same kind of >>>>conflict. >>> >>>No, it's a very different conflict. % is a global escape character >>>in URIs, which is why it has to be escaped itself as %25. The colons >>>in IPv6 addresses are simply delimiters. I think this sentence is >>>unnecessary. > > > I would say those were the same problem before the clarification of > rfc2396bis. But I understand that the conflict with colons is not an > issue any more with rfc2396bis. > > So, perhaps we can just simply this paragraph to: > > Hence, this document does not specify how the format for non-global > addresses should be combined with the preferred format for literal > IPv6 addresses. In any case, it is recommended to use an FQDN > instead of a literal IPv6 address in a URL, whenever an FQDN is > available. > > Does this make sense to you? > > 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 > -------------------------------------------------------------------- > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Oct 30 12:27:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02860 for ; Sat, 30 Oct 2004 12:27:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNwJ8-00056R-Vh for ipv6-web-archive@ietf.org; Sat, 30 Oct 2004 12:42:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNvlO-0002Xk-FT; Sat, 30 Oct 2004 12:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNvYt-0007VD-OJ for ipv6@megatron.ietf.org; Sat, 30 Oct 2004 11:54:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01443 for ; Sat, 30 Oct 2004 11:54:36 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNvnL-0004c8-RE for ipv6@ietf.org; Sat, 30 Oct 2004 12:09:40 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.75]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 183497; Sat, 30 Oct 2004 11:48:56 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <41837732.9010408@zurich.ibm.com> References: <41837732.9010408@zurich.ibm.com> Date: Sat, 30 Oct 2004 11:54:26 -0400 To: Brian E Carpenter , IPv6 From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: Re: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe At 1:12 PM +0200 10/30/04, Brian E Carpenter wrote: >> Because it has no *reasonable* use? Is it reasonable to use HTTP this way? >> It doesn't really bother me that it isn't covered by the latest URI syntax >> (and therefore not by IRI syntax). I must say I have largely ignored >> the whole scoped address debate, so I missed this when we did the original >> work on RFC 2732. Brian originally made this statement in an exchange with some URI/IRI authors/experts and the IESG regarding my "discuss" position on draft-duerst-iri-10.txt. My response was: "I don't know. A year ago, I would have said "no", but with documents on the IESG agenda like draft-black-snmp-uri-08.txt, I am taking a new view of URIs. This document defines a URI syntax that can be used for access to SNMP objects, and one of the use cases includes having a local SNMP manager that is accessed through a URI -- the URI then being translated into an SNMP request that is sent to the agent via SNMP. So, URIs can, effectively, be used as a programmatic interface to other applications running on the local system. In that sort of case, I think we very well might need to include scoped addresses in URIs. And, IMO, it would be better to have a standard way to do this than to live in a world where folks just insert an unencoded % and some parsers pass it through cleanly, others escape it for you and still others return an error -- which is how the current behaviour of URI parsers has been described in this thread." BTW, I don't think it was a mistake to omit this when RFC 2732 was published, as the IPv6 Scoped Address Architecture (which defines zone IDs) was only recently approved by the IESG for publication at PS. >In any case this is a dead duck, unless the IESG wants to recall 2396bis >from the RFC Editor, which seems absolutely unjustified to me. The discussion with the URI/IRI authors doesn't seem to be moving in the direction of recalling 2396bis. It seems preferable to write a new document that defines an IPv6 address encoding that includes a zone ID. This could be done under the IPvFuture mechanism described in 2396bis. I'm certainly willing to let the URI/IRI folks figure out the best way to fix this problem, but I don't understand how the fact that 2396bis is in the RFC editor queue makes this problem a "dead duck". In fact, I'm not sure I understand what "this" is referring to in the sentence above. I don't know exactly where this will end up, but given the fact that 2396bis will obsolete RFC 2732 when it is published (which I didn't realize when I started this thread), I agree that an update to RFC 2732 doesn't make sense. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Oct 30 17:49:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20440 for ; Sat, 30 Oct 2004 17:49:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO1Ky-0002NG-T9 for ipv6-web-archive@ietf.org; Sat, 30 Oct 2004 18:04:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO0qb-00049o-RZ; Sat, 30 Oct 2004 17:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO0jG-0002jv-NA; Sat, 30 Oct 2004 17:25:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19188; Sat, 30 Oct 2004 17:25:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO0xp-0001wK-VU; Sat, 30 Oct 2004 17:40:46 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CO0Xr-00014j-Ko; Sat, 30 Oct 2004 17:13:55 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Sat, 30 Oct 2004 17:13:55 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'Link Scoped IPv6 Multicast Addresses ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-11-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-06.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 31 00:13:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11575 for ; Sun, 31 Oct 2004 00:13:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO7Ke-000054-Dq for ipv6-web-archive@ietf.org; Sun, 31 Oct 2004 00:28:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO6yY-0001IU-IV; Sun, 31 Oct 2004 00:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO6u7-0000cr-2m for ipv6@megatron.ietf.org; Sun, 31 Oct 2004 00:01:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10872 for ; Sun, 31 Oct 2004 00:01:15 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO78j-0008Mc-EF for ipv6@ietf.org; Sun, 31 Oct 2004 00:16:25 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 52A14694 for ; Sun, 31 Oct 2004 00:00:36 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 31 Oct 2004 00:00:36 -0400 Message-Id: <20041031040036.52A14694@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.28% | 7 | 21.76% | 77458 | h.soliman@flarion.com 12.28% | 7 | 17.04% | 60657 | elwynd@nortelnetworks.com 14.04% | 8 | 10.02% | 35660 | pekkas@netcore.fi 7.02% | 4 | 7.49% | 26647 | osprey67@yahoo.com 5.26% | 3 | 6.15% | 21895 | brian@innovationslab.net 7.02% | 4 | 4.03% | 14343 | rt+ipv6-2461bis@rt.psg.com 5.26% | 3 | 5.05% | 17985 | internet-drafts@ietf.org 5.26% | 3 | 3.75% | 13353 | margaret@thingmagic.com 3.51% | 2 | 3.24% | 11519 | jinmei@isl.rdc.toshiba.co.jp 3.51% | 2 | 3.13% | 11157 | mukesh.k.gupta@nokia.com 3.51% | 2 | 2.23% | 7949 | nobumichi.ozoe@jp.yokogawa.com 1.75% | 1 | 2.82% | 10025 | brc@zurich.ibm.com 1.75% | 1 | 2.01% | 7155 | soohong.park@samsung.com 1.75% | 1 | 1.34% | 4782 | kitamura@da.jp.nec.com 1.75% | 1 | 1.29% | 4592 | jjbrzozowski@lucent.com 1.75% | 1 | 1.27% | 4510 | jordi.palet@consulintel.es 1.75% | 1 | 1.17% | 4181 | perry@coders.net 1.75% | 1 | 1.16% | 4131 | erik.nordmark@sun.com 1.75% | 1 | 1.14% | 4067 | tim@mentat.com 1.75% | 1 | 1.12% | 3983 | sra+ipng@hactrn.net 1.75% | 1 | 1.05% | 3723 | itojun@itojun.org 1.75% | 1 | 0.87% | 3100 | brian.haberman@jhuapl.edu 1.75% | 1 | 0.85% | 3042 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 57 |100.00% | 355914 | 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 Oct 31 10:55:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08524 for ; Sun, 31 Oct 2004 10:55:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COII8-0007Ju-IV for ipv6-web-archive@ietf.org; Sun, 31 Oct 2004 11:10:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COHvn-0002zU-3x; Sun, 31 Oct 2004 10:47:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COHpu-0002Cx-7y for ipv6@megatron.ietf.org; Sun, 31 Oct 2004 10:41:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07399 for ; Sun, 31 Oct 2004 10:41:40 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COI4c-00074W-Ku for ipv6@ietf.org; Sun, 31 Oct 2004 10:56:55 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9VCOuN3172400; Sun, 31 Oct 2004 12:24:56 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9VCOt6j078508; Sun, 31 Oct 2004 12:24:56 GMT Received: from zurich.ibm.com (sig-9-145-249-116.de.ibm.com [9.145.249.116]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA66000; Sun, 31 Oct 2004 13:24:51 +0100 Message-ID: <4184D995.3070005@zurich.ibm.com> Date: Sun, 31 Oct 2004 13:24:53 +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: Margaret Wasserman References: <41837732.9010408@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Just to explain my "dead duck" comment, indeed I meant it only in the context of the documents currently in the publication queue. If a real requirement appears then it is pretty obvious what to do - extend the URI syntax appropriately and modify every URI parser. Brian Margaret Wasserman wrote: > At 1:12 PM +0200 10/30/04, Brian E Carpenter wrote: > >>> Because it has no *reasonable* use? Is it reasonable to use HTTP >>> this way? >>> It doesn't really bother me that it isn't covered by the latest URI >>> syntax >>> (and therefore not by IRI syntax). I must say I have largely ignored >>> the whole scoped address debate, so I missed this when we did the >>> original >>> work on RFC 2732. > > > Brian originally made this statement in an exchange with some URI/IRI > authors/experts and the IESG regarding my "discuss" position on > draft-duerst-iri-10.txt. My response was: > > "I don't know. A year ago, I would have said "no", but with documents > on the IESG agenda like draft-black-snmp-uri-08.txt, I am taking a new > view of URIs. This document defines a URI syntax that can be used for > access to SNMP objects, and one of the use cases includes having a local > SNMP manager that is accessed through a URI -- the URI then being > translated into an SNMP request that is sent to the agent via SNMP. > > So, URIs can, effectively, be used as a programmatic interface to other > applications running on the local system. In that sort of case, I think > we very well might need to include scoped addresses in URIs. And, IMO, > it would be better to have a standard way to do this than to live in a > world where folks just insert an unencoded % and some parsers pass it > through cleanly, others escape it for you and still others return an > error -- which is how the current behaviour of URI parsers has been > described in this thread." > > BTW, I don't think it was a mistake to omit this when RFC 2732 was > published, as the IPv6 Scoped Address Architecture (which defines zone > IDs) was only recently approved by the IESG for publication at PS. > >> In any case this is a dead duck, unless the IESG wants to recall 2396bis >> from the RFC Editor, which seems absolutely unjustified to me. > > > The discussion with the URI/IRI authors doesn't seem to be moving in the > direction of recalling 2396bis. It seems preferable to write a new > document that defines an IPv6 address encoding that includes a zone ID. > This could be done under the IPvFuture mechanism described in 2396bis. > > I'm certainly willing to let the URI/IRI folks figure out the best way > to fix this problem, but I don't understand how the fact that 2396bis is > in the RFC editor queue makes this problem a "dead duck". In fact, I'm > not sure I understand what "this" is referring to in the sentence above. > > I don't know exactly where this will end up, but given the fact that > 2396bis will obsolete RFC 2732 when it is published (which I didn't > realize when I started this thread), I agree that an update to RFC 2732 > doesn't make sense. > > Margaret > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Oct 31 18:41:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15567 for ; Sun, 31 Oct 2004 18:41:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COPZ5-0008Bh-Sm for ipv6-web-archive@ietf.org; Sun, 31 Oct 2004 18:56:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COPFb-0002jM-Ts; Sun, 31 Oct 2004 18:36:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COPDy-0002XJ-Cs for ipv6@megatron.ietf.org; Sun, 31 Oct 2004 18:35:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15207 for ; Sun, 31 Oct 2004 18:34:59 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COPSa-00083s-IS for ipv6@ietf.org; Sun, 31 Oct 2004 18:50:19 -0500 Received: from [192.168.1.200] ([196.40.10.211]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000542735.msg for ; Mon, 01 Nov 2004 00:39:33 +0100 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 31 Oct 2004 17:32:33 -0600 From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Mon, 01 Nov 2004 00:39:33 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 196.40.10.211 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-MDAV-Processed: consulintel.es, Mon, 01 Nov 2004 00:39:35 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Subject: Re: RFC 2732 and Zone IDs 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Ok. I was referring to "addresses" only, not names. In that case, I still think that [2001::DEAD%1] still should work, but not www.mydomain.com%1. Not sure either if this kind of scope option in an http request has some use, but probably I'm missing a lot of options for that ! Regards, Jordi > De: Pekka Savola > Responder a: ipv6-bounces@ietf.org > Fecha: Sat, 30 Oct 2004 09:14:50 +0300 (EEST) > Para: Margaret Wasserman > CC: ipv6@ietf.org > Asunto: Re: RFC 2732 and Zone IDs > > On Fri, 29 Oct 2004, Margaret Wasserman wrote: >> We're having a discussion on URIs and IRIs in the IESG that has led >> me to realize that the URL literal IPv6 address format described in >> RFC 2732 does not contain any provision for including a zone ID. I >> don't think that we could simply add a "%zone-id" to the end of the >> IP address, because % is a special character in URLs. >> >> Thoughts? Is this something we should update? > > Yes, I believe this is a problem. > > Possibly the best solution is specifying a BCP that limited scope > addresses should not be used in URLs or in applications like that. > > People trying to use link-local addresses for "normal" applications is > just causing grief. Perhaps that needs to be stopped. > > -- > 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 > -------------------------------------------------------------------- > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line 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 --------------------------------------------------------------------