From ipv6-bounces@ietf.org Thu Dec 01 11:22:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrCc-0001XT-4E; Thu, 01 Dec 2005 11:22:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrCZ-0001U3-C4 for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 11:22:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11894 for ; Thu, 1 Dec 2005 11:21:45 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhrX2-0003gZ-Cw for ipv6@ietf.org; Thu, 01 Dec 2005 11:43:43 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Dec 2005 11:22:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 11:22:18 -0500 Message-ID: Thread-Topic: 2461bis and host-load-sharing Thread-Index: AcX2E8IQQFk9JKBZSiOxJp+gAchBegAf2cEA From: "Soliman, Hesham" To: "Bob Hinden" X-OriginalArrivalTime: 01 Dec 2005 16:22:18.0359 (UTC) FILETIME=[661AE070:01C5F693] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Dave Thaler Subject: RE: 2461bis and host-load-sharing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Bob, > > Dave, > > > > I think we can handle this during IESG last call. Does anyone =20 > > oppose Dave's suggestion > > below to update this statement according to RFC 4311 ? >=20 > Before answering the question, what would the exact change be to =20 > draft-ietf-ipv6-2461bis-05.txt? =3D> Sorry, I think I assumed too much. I was proposing the removal of=20 that sentence and replacing it with a reference to RFC 4311. I can send exact text to the list.=20 Hesham >=20 > One consideration is that the update to 2661 is being submitted at =20 > Draft standard and we need to be carefull to not make incompatible =20 > changes. This probably not the case here, but I would like to see =20 > the proposed text. >=20 > Thanks, > Bob >=20 >=20 > > Thx, > > Hesham > > > > -----Original Message----- > > From: ipv6-bounces@ietf.org=20 [mailto:ipv6-bounces@ietf.org]On Behalf =20 > Of Dave Thaler > Sent: Wednesday, November 23, 2005 1:37 PM > To: JINMEI Tatuya / ???? > Cc: margaret@thingmagic.com; ipv6@ietf.org > Subject: 2461bis and host-load-sharing > > draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: > > An implementation may choose to always return the same router or > > cycle through the router list in a round-robin fashion as long > > as it always returns a reachable or a probably reachable router > > when one is available. > > However RFC 4311 (draft-ietf-ipv6-host-load-sharing-04.txt) updates > > RFC 2461, is a Proposed Standard, and says: > > [ND] ... > > specifies that an implementation may always choose the same router > > (e.g., the first in the list) or may cycle through the routers in > > a round-robin manner. Both of these suggestions are problematic. > > [...] > > If 2461bis is intended to obsolete RFC 2461, then I think the =20 > statement > > in 6.3.6 should be updated to be in accordance with RFC 4311. =20 > Otherwise > > RFC 4311 will have to be republished to update 2461bis. > > -Dave > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 =20 > 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 > > -------------------------------------------------------------------- > 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 Dec 01 13:04:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehsmo-0000jY-Lf; Thu, 01 Dec 2005 13:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehsmm-0000jQ-E0 for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 13:04:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25759 for ; Thu, 1 Dec 2005 13:03:13 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eht7G-0007dG-64 for ipv6@ietf.org; Thu, 01 Dec 2005 13:25:13 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Dec 2005 10:03:47 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 10:03:47 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 10:03:46 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 10:03:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 10:03:45 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC114A5FB67@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: 2461bis and host-load-sharing thread-index: AcX2E8IQQFk9JKBZSiOxJp+gAchBegAf2cEAAAIkOeA= From: "Dave Thaler" To: "Soliman, Hesham" , "Bob Hinden" X-OriginalArrivalTime: 01 Dec 2005 18:03:46.0165 (UTC) FILETIME=[92B85A50:01C5F6A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis and host-load-sharing 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 A draft standard can't have a normative reference to a proposed standard. I believe the options are: a) remove the problematic text from 2461bis and don't replace it with anything (i.e., be silent on the issue). I'm not sure what the state of 4311 changes to then, since it's updating an obsoleted RFC. b) replace the text with a note that is classified as an=20 informative reference to 4311. c) replace the text with the 2 paragraphs from 4311, and have 2461bis also obsolete 4311. This doesn't yet qualify per Draft Standard rules so I don't think this option is really viable without delaying 2461bis.=20 I believe Hesham is suggesting (b), and if appropriate text can be constructed I would support this. -Dave > -----Original Message----- > From: Soliman, Hesham [mailto:H.Soliman@flarion.com] > Sent: Thursday, December 01, 2005 8:22 AM > To: Bob Hinden > Cc: Dave Thaler; ipv6@ietf.org > Subject: RE: 2461bis and host-load-sharing >=20 > Hi Bob, >=20 > > > Dave, > > > > > > I think we can handle this during IESG last call. Does anyone > > > oppose Dave's suggestion > > > below to update this statement according to RFC 4311 ? > > > > Before answering the question, what would the exact change be to > > draft-ietf-ipv6-2461bis-05.txt? >=20 > =3D> Sorry, I think I assumed too much. I was proposing the removal of > that sentence and replacing it with a reference to RFC 4311. I can > send exact text to the list. >=20 > Hesham >=20 > > > > One consideration is that the update to 2661 is being submitted at > > Draft standard and we need to be carefull to not make incompatible > > changes. This probably not the case here, but I would like to see > > the proposed text. > > > > Thanks, > > Bob > > > > > > > Thx, > > > Hesham > > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org > [mailto:ipv6-bounces@ietf.org]On Behalf > > Of Dave Thaler > > Sent: Wednesday, November 23, 2005 1:37 PM > > To: JINMEI Tatuya / ???? > > Cc: margaret@thingmagic.com; ipv6@ietf.org > > Subject: 2461bis and host-load-sharing > > > > draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: > > > > An implementation may choose to always return the same router or > > > > cycle through the router list in a round-robin fashion as long > > > > as it always returns a reachable or a probably reachable router > > > > when one is available. > > > > However RFC 4311 (draft-ietf-ipv6-host-load-sharing-04.txt) updates > > > > RFC 2461, is a Proposed Standard, and says: > > > > [ND] ... > > > > specifies that an implementation may always choose the same router > > > > (e.g., the first in the list) or may cycle through the routers in > > > > a round-robin manner. Both of these suggestions are problematic. > > > > [...] > > > > If 2461bis is intended to obsolete RFC 2461, then I think the > > statement > > > > in 6.3.6 should be updated to be in accordance with RFC 4311. > > Otherwise > > > > RFC 4311 will have to be republished to update 2461bis. > > > > -Dave > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 > > > > -------------------------------------------------------------------- > > 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 Dec 01 13:06:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhspT-0003n5-VM; Thu, 01 Dec 2005 13:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhspS-0003n0-VJ for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 13:06:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26177 for ; Thu, 1 Dec 2005 13:05:59 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eht9y-0007kN-TG for ipv6@ietf.org; Thu, 01 Dec 2005 13:27:59 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Dec 2005 13:06:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 13:06:36 -0500 Message-ID: Thread-Topic: 2461bis and host-load-sharing Thread-Index: AcX2E8IQQFk9JKBZSiOxJp+gAchBegAf2cEAAAIkOeAAAYgtQA== From: "Soliman, Hesham" To: "Dave Thaler" , "Bob Hinden" X-OriginalArrivalTime: 01 Dec 2005 18:06:36.0671 (UTC) FILETIME=[F85980F0:01C5F6A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis and host-load-sharing 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 > A draft standard can't have a normative reference to a proposed > standard. >=20 > I believe the options are: > a) remove the problematic text from 2461bis and don't replace it with > anything (i.e., be silent on the issue). I'm not sure what the state > of 4311 changes to then, since it's updating an obsoleted RFC. > b) replace the text with a note that is classified as an=20 > informative reference to 4311. > c) replace the text with the 2 paragraphs from 4311, and have 2461bis > also obsolete 4311. This doesn't yet qualify per Draft=20 > Standard rules > so I don't think this option is really viable without=20 > delaying 2461bis.=20 >=20 > I believe Hesham is suggesting (b), and if appropriate text can be > constructed I would support this. =3D> Thanks for the detailed description. Yes I was suggesting (b) = above. Hesham >=20 > -Dave >=20 > > -----Original Message----- > > From: Soliman, Hesham [mailto:H.Soliman@flarion.com] > > Sent: Thursday, December 01, 2005 8:22 AM > > To: Bob Hinden > > Cc: Dave Thaler; ipv6@ietf.org > > Subject: RE: 2461bis and host-load-sharing > >=20 > > Hi Bob, > >=20 > > > > Dave, > > > > > > > > I think we can handle this during IESG last call. Does anyone > > > > oppose Dave's suggestion > > > > below to update this statement according to RFC 4311 ? > > > > > > Before answering the question, what would the exact change be to > > > draft-ietf-ipv6-2461bis-05.txt? > >=20 > > =3D> Sorry, I think I assumed too much. I was proposing the=20 > removal of > > that sentence and replacing it with a reference to RFC 4311. I can > > send exact text to the list. > >=20 > > Hesham > >=20 > > > > > > One consideration is that the update to 2661 is being=20 > submitted at > > > Draft standard and we need to be carefull to not make=20 > incompatible > > > changes. This probably not the case here, but I would=20 > like to see > > > the proposed text. > > > > > > Thanks, > > > Bob > > > > > > > > > > Thx, > > > > Hesham > > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org > > [mailto:ipv6-bounces@ietf.org]On Behalf > > > Of Dave Thaler > > > Sent: Wednesday, November 23, 2005 1:37 PM > > > To: JINMEI Tatuya / ???? > > > Cc: margaret@thingmagic.com; ipv6@ietf.org > > > Subject: 2461bis and host-load-sharing > > > > > > draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: > > > > > > An implementation may choose to always return the=20 > same router or > > > > > > cycle through the router list in a round-robin=20 > fashion as long > > > > > > as it always returns a reachable or a probably=20 > reachable router > > > > > > when one is available. > > > > > > However RFC 4311=20 > (draft-ietf-ipv6-host-load-sharing-04.txt) updates > > > > > > RFC 2461, is a Proposed Standard, and says: > > > > > > [ND] ... > > > > > > specifies that an implementation may always choose the same > router > > > > > > (e.g., the first in the list) or may cycle through=20 > the routers > in > > > > > > a round-robin manner. Both of these suggestions are > problematic. > > > > > > [...] > > > > > > If 2461bis is intended to obsolete RFC 2461, then I think the > > > statement > > > > > > in 6.3.6 should be updated to be in accordance with RFC 4311. > > > Otherwise > > > > > > RFC 4311 will have to be republished to update 2461bis. > > > > > > -Dave > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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=20 > material for the > > > sole > > > use of the intended recipient. Any review or distribution by > > > others is > > > strictly prohibited. If you are not the intended=20 > 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 > > > > > >=20 > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests:=20 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 Dec 01 14:20:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtzD-00085o-Me; Thu, 01 Dec 2005 14:20:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtzA-000844-W1 for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 14:20:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04448 for ; Thu, 1 Dec 2005 14:20:05 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhuJi-0001jN-8C for ipv6@ietf.org; Thu, 01 Dec 2005 14:42:06 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA29046; Thu, 1 Dec 2005 11:20:41 -0800 (PST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jB1JKeC24202; Thu, 1 Dec 2005 13:20:40 -0600 (CST) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Dec 2005 14:20:12 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 14:20:12 -0500 Message-ID: Thread-Topic: 2461bis and host-load-sharing Thread-Index: AcX2E8IQQFk9JKBZSiOxJp+gAchBegAf2cEAAAIkOeAAA5VhUA== From: "Manfredi, Albert E" To: "Dave Thaler" , "Soliman, Hesham" , "Bob Hinden" X-OriginalArrivalTime: 01 Dec 2005 19:20:12.0446 (UTC) FILETIME=[405B4BE0:01C5F6AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis and host-load-sharing 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 It seems to me that it would be easier to obsolete RFC 4311 rather than trying to keep it and 2461bis in sync? And what's in 4311 seems straightforward and flexible enough to be easy to incorporate in 2461bis, no? If it weren't for the delay that option c might cause, wouldn't it be the simplest solution in the long run? Bert > -----Original Message----- > From: Dave Thaler [mailto:dthaler@windows.microsoft.com]=20 > Sent: Thursday, December 01, 2005 1:04 PM > To: Soliman, Hesham; Bob Hinden > Cc: ipv6@ietf.org > Subject: RE: 2461bis and host-load-sharing >=20 > A draft standard can't have a normative reference to a proposed > standard. >=20 > I believe the options are: > a) remove the problematic text from 2461bis and don't replace it with > anything (i.e., be silent on the issue). I'm not sure what the state > of 4311 changes to then, since it's updating an obsoleted RFC. > b) replace the text with a note that is classified as an=20 > informative reference to 4311. > c) replace the text with the 2 paragraphs from 4311, and have 2461bis > also obsolete 4311. This doesn't yet qualify per Draft Standard rules > so I don't think this option is really viable without=20 > delaying 2461bis.=20 >=20 > I believe Hesham is suggesting (b), and if appropriate text can be > constructed I would support this. >=20 > -Dave >=20 > > -----Original Message----- > > From: Soliman, Hesham [mailto:H.Soliman@flarion.com] > > Sent: Thursday, December 01, 2005 8:22 AM > > To: Bob Hinden > > Cc: Dave Thaler; ipv6@ietf.org > > Subject: RE: 2461bis and host-load-sharing > >=20 > > Hi Bob, > >=20 > > > > Dave, > > > > > > > > I think we can handle this during IESG last call. Does anyone > > > > oppose Dave's suggestion > > > > below to update this statement according to RFC 4311 ? > > > > > > Before answering the question, what would the exact change be to > > > draft-ietf-ipv6-2461bis-05.txt? > >=20 > > =3D> Sorry, I think I assumed too much. I was proposing the removal = of > > that sentence and replacing it with a reference to RFC 4311. I can > > send exact text to the list. > >=20 > > Hesham > >=20 > > > > > > One consideration is that the update to 2661 is being=20 > submitted at > > > Draft standard and we need to be carefull to not make=20 > incompatible > > > changes. This probably not the case here, but I would=20 > like to see > > > the proposed text. > > > > > > Thanks, > > > Bob > > > > > > > > > > Thx, > > > > Hesham > > > > > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org > > [mailto:ipv6-bounces@ietf.org]On Behalf > > > Of Dave Thaler > > > Sent: Wednesday, November 23, 2005 1:37 PM > > > To: JINMEI Tatuya / ???? > > > Cc: margaret@thingmagic.com; ipv6@ietf.org > > > Subject: 2461bis and host-load-sharing > > > > > > draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: > > > > > > An implementation may choose to always return the=20 > same router or > > > > > > cycle through the router list in a round-robin fashion as long > > > > > > as it always returns a reachable or a probably=20 > reachable router > > > > > > when one is available. > > > > > > However RFC 4311=20 > (draft-ietf-ipv6-host-load-sharing-04.txt) updates > > > > > > RFC 2461, is a Proposed Standard, and says: > > > > > > [ND] ... > > > > > > specifies that an implementation may always choose the same > router > > > > > > (e.g., the first in the list) or may cycle through the routers > in > > > > > > a round-robin manner. Both of these suggestions are > problematic. > > > > > > [...] > > > > > > If 2461bis is intended to obsolete RFC 2461, then I think the > > > statement > > > > > > in 6.3.6 should be updated to be in accordance with RFC 4311. > > > Otherwise > > > > > > RFC 4311 will have to be republished to update 2461bis. > > > > > > -Dave > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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=20 > 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 > > > > > >=20 > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests:=20 > https://www1.ietf.org/mailman/listinfo/ipv6 > > >=20 > -------------------------------------------------------------------- >=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 Thu Dec 01 14:22:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehu0k-0000fB-63; Thu, 01 Dec 2005 14:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehu0i-0000cy-V5 for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 14:22:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04540 for ; Thu, 1 Dec 2005 14:21:41 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhuLF-0001mg-7I for ipv6@ietf.org; Thu, 01 Dec 2005 14:43:42 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB1JMKcv011851; Thu, 1 Dec 2005 21:22:21 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 21:22:22 +0200 Received: from [172.19.69.50] ([172.19.69.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Dec 2005 21:22:22 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Thu, 1 Dec 2005 11:22:41 -0800 To: "ext Soliman, Hesham" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 01 Dec 2005 19:22:22.0937 (UTC) FILETIME=[8E22A490:01C5F6AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dave Thaler Subject: Re: 2461bis and host-load-sharing 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 Hesham, Dave, >> A draft standard can't have a normative reference to a proposed >> standard. >> >> I believe the options are: >> a) remove the problematic text from 2461bis and don't replace it with >> anything (i.e., be silent on the issue). I'm not sure what the state >> of 4311 changes to then, since it's updating an obsoleted RFC. >> b) replace the text with a note that is classified as an >> informative reference to 4311. >> c) replace the text with the 2 paragraphs from 4311, and have 2461bis >> also obsolete 4311. This doesn't yet qualify per Draft >> Standard rules >> so I don't think this option is really viable without >> delaying 2461bis. >> >> I believe Hesham is suggesting (b), and if appropriate text can be >> constructed I would support this. > > => Thanks for the detailed description. Yes I was suggesting (b) > above. I think that is fine, but please send the proposed text to the list. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 01 14:24:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehu2O-0001sX-Ax; Thu, 01 Dec 2005 14:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehu2L-0001qw-Fp for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 14:24:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04678 for ; Thu, 1 Dec 2005 14:23:22 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhuMq-0001qk-Jx for ipv6@ietf.org; Thu, 01 Dec 2005 14:45:23 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Dec 2005 11:23:56 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 11:23:56 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 11:23:55 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 11:23:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 11:23:44 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC114A5FCDD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: 2461bis and host-load-sharing thread-index: AcX2E8IQQFk9JKBZSiOxJp+gAchBegAf2cEAAAIkOeAAA5VhUAAAmO+Q From: "Dave Thaler" To: "Manfredi, Albert E" , "Soliman, Hesham" , "Bob Hinden" X-OriginalArrivalTime: 01 Dec 2005 19:23:55.0322 (UTC) FILETIME=[C53379A0:01C5F6AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis and host-load-sharing 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 Yes it is straightforward to incorporate and would be the simplest solution in the long run. The issue with c is the Draft Standard requirements in RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. [...] The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. -Dave > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Thursday, December 01, 2005 11:20 AM > To: Dave Thaler; Soliman, Hesham; Bob Hinden > Cc: ipv6@ietf.org > Subject: RE: 2461bis and host-load-sharing >=20 > It seems to me that it would be easier to obsolete RFC 4311 rather than > trying to keep it and 2461bis in sync? And what's in 4311 seems > straightforward and flexible enough to be easy to incorporate in > 2461bis, no? >=20 > If it weren't for the delay that option c might cause, wouldn't it be > the simplest solution in the long run? >=20 > Bert >=20 >=20 > > -----Original Message----- > > From: Dave Thaler [mailto:dthaler@windows.microsoft.com] > > Sent: Thursday, December 01, 2005 1:04 PM > > To: Soliman, Hesham; Bob Hinden > > Cc: ipv6@ietf.org > > Subject: RE: 2461bis and host-load-sharing > > > > A draft standard can't have a normative reference to a proposed > > standard. > > > > I believe the options are: > > a) remove the problematic text from 2461bis and don't replace it with > > anything (i.e., be silent on the issue). I'm not sure what the state > > of 4311 changes to then, since it's updating an obsoleted RFC. > > b) replace the text with a note that is classified as an > > informative reference to 4311. > > c) replace the text with the 2 paragraphs from 4311, and have 2461bis > > also obsolete 4311. This doesn't yet qualify per Draft Standard rules > > so I don't think this option is really viable without > > delaying 2461bis. > > > > I believe Hesham is suggesting (b), and if appropriate text can be > > constructed I would support this. > > > > -Dave > > > > > -----Original Message----- > > > From: Soliman, Hesham [mailto:H.Soliman@flarion.com] > > > Sent: Thursday, December 01, 2005 8:22 AM > > > To: Bob Hinden > > > Cc: Dave Thaler; ipv6@ietf.org > > > Subject: RE: 2461bis and host-load-sharing > > > > > > Hi Bob, > > > > > > > > Dave, > > > > > > > > > > I think we can handle this during IESG last call. Does anyone > > > > > oppose Dave's suggestion > > > > > below to update this statement according to RFC 4311 ? > > > > > > > > Before answering the question, what would the exact change be to > > > > draft-ietf-ipv6-2461bis-05.txt? > > > > > > =3D> Sorry, I think I assumed too much. I was proposing the = removal of > > > that sentence and replacing it with a reference to RFC 4311. I can > > > send exact text to the list. > > > > > > Hesham > > > > > > > > > > > One consideration is that the update to 2661 is being > > submitted at > > > > Draft standard and we need to be carefull to not make > > incompatible > > > > changes. This probably not the case here, but I would > > like to see > > > > the proposed text. > > > > > > > > Thanks, > > > > Bob > > > > > > > > > > > > > Thx, > > > > > Hesham > > > > > > > > > > -----Original Message----- > > > > > From: ipv6-bounces@ietf.org > > > [mailto:ipv6-bounces@ietf.org]On Behalf > > > > Of Dave Thaler > > > > Sent: Wednesday, November 23, 2005 1:37 PM > > > > To: JINMEI Tatuya / ???? > > > > Cc: margaret@thingmagic.com; ipv6@ietf.org > > > > Subject: 2461bis and host-load-sharing > > > > > > > > draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: > > > > > > > > An implementation may choose to always return the > > same router or > > > > > > > > cycle through the router list in a round-robin fashion as long > > > > > > > > as it always returns a reachable or a probably > > reachable router > > > > > > > > when one is available. > > > > > > > > However RFC 4311 > > (draft-ietf-ipv6-host-load-sharing-04.txt) updates > > > > > > > > RFC 2461, is a Proposed Standard, and says: > > > > > > > > [ND] ... > > > > > > > > specifies that an implementation may always choose the same > > router > > > > > > > > (e.g., the first in the list) or may cycle through the routers > > in > > > > > > > > a round-robin manner. Both of these suggestions are > > problematic. > > > > > > > > [...] > > > > > > > > If 2461bis is intended to obsolete RFC 2461, then I think the > > > > statement > > > > > > > > in 6.3.6 should be updated to be in accordance with RFC 4311. > > > > Otherwise > > > > > > > > RFC 4311 will have to be republished to update 2461bis. > > > > > > > > -Dave > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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 > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: > > https://www1.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 01 15:43:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvGf-0005H9-Hi; Thu, 01 Dec 2005 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvGd-0005GX-UK for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 15:43:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24885 for ; Thu, 1 Dec 2005 15:42:12 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhvbB-0007ln-Sf for ipv6@ietf.org; Thu, 01 Dec 2005 16:04:14 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Dec 2005 15:42:50 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 15:42:49 -0500 Message-ID: Thread-Topic: 2461bis and host-load-sharing Thread-Index: AcX2rJAS5iuVJByvRt2s2g73Vz1w4gACkspg From: "Soliman, Hesham" To: "Bob Hinden" X-OriginalArrivalTime: 01 Dec 2005 20:42:50.0031 (UTC) FILETIME=[CB4EBBF0:01C5F6B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Dave Thaler Subject: Suggested text for 2461bis and host-load-sharing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Here is the suggested text. The current version of this=20 section is at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-05.txt I believe Dave's comment only applies to point 1) in the=20 current draft. So I only changed that point. The rest doesn't seem to contradict 4311.=20 Comments? Hesham 6.3.6. Default Router Selection The algorithm for selecting a router depends in part on whether or not a router is known to be reachable. The exact details of how a node keeps track of a neighbor's reachability state are covered in Section 7.3. The algorithm for selecting a default router is invoked during next-hop determination when no Destination Cache entry exists for an off-link destination or when communication through an existing router appears to be failing. Under normal conditions, a router would be selected the first time traffic is sent to a destination, with subsequent traffic for that destination using the same router as indicated in the Destination Cache modulo any changes to the Destination Cache caused by Redirect messages. The policy for selecting routers from the Default Router List is as follows: 1) Routers that are reachable or probably reachable (i.e., in any state other than INCOMPLETE) SHOULD be preferred over routers whose reachability is unknown or suspect (i.e., in the INCOMPLETE state, or for which no Neighbor Cache entry exists). Further implementation hints on default router selection when multiple equivalent routers are available are discussed in=20 [LD-SHRE]. 2) When no routers on the list are known to be reachable or probably reachable, routers SHOULD be selected in a round-robin fashion, so that subsequent requests for a default router do not return the same router until all other routers have been selected. Cycling through the router list in this case ensures that all available routers are actively probed by the Neighbor Unreachability Detection algorithm. A request for a default router is made in conjunction with the sending of a packet to a router, and the selected router will be probed for reachability as a side effect. [LD-SHRE] RFC 4311. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 01 18:17:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxgM-0002oF-80; Thu, 01 Dec 2005 18:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxgK-0002o5-En for ipv6@megatron.ietf.org; Thu, 01 Dec 2005 18:17:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00080 for ; Thu, 1 Dec 2005 18:16:53 -0500 (EST) Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehy0s-0002d8-Th for ipv6@ietf.org; Thu, 01 Dec 2005 18:38:56 -0500 Received: from [84.90.29.195] (account aamaral@av.it.pt) by av.it.pt (CommuniGate Pro WebUser 4.3.7) with HTTP id 3649975; Thu, 01 Dec 2005 23:15:50 +0000 From: "=?ISO-8859-1?Q?Ant=F3nio?= Amaral" To: "IPng" , "M6bone" X-Mailer: CommuniGate Pro WebUser Interface v.4.3.7 Date: Thu, 01 Dec 2005 23:15:50 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA00080 Cc: Subject: Bootsrap mecanism new PIM Neighbor 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 Dear All, After draft-ietf-pim-sm-bsr-05.txt there is a section ---- 3.5. Unicasting Bootstrap Messages to New and Rebooting=20 Routers To allow new or rebooting routers to learn the RP-Set=20 quickly, when a Hello message is received from a new neighbor, or a Hello=20 message with a new GenID is received from an existing neighbor, one=20 router on the LAN unicasts a stored copy of the Bootstrap message for each=20 admin scope zone to the new or rebooting router. (....) -------- What is the motivation for this behaviour? With a common=20 bootstrap message new router also learn the RP-Set=20 quickly, am I right? In my opinion when a new router placed on the LAN sends a=20 PIM Hello message, one router on the LAN could simply send=20 a bootstrap message and new router also learn the RP-Set=20 quickly. Thanks in advance Best Regards AA -------------------------------------------------------- Ant=F3nio Manuel Nunes C. Amaral Instituto de Telecomunica=E7=F5es - P=F3lo de Aveiro Campus Universit=E1rio 3810-193 AVEIRO - PORTUGAL Telef. 234 - 377900 Fax. 234 - 377901 e-mail: aamaral@av.it.pt Telef. directo. 234 - 377906 --------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 01 21:16:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0Te-0003zZ-TN; Thu, 01 Dec 2005 21:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0Td-0003zM-OD; Thu, 01 Dec 2005 21:16:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19617; Thu, 1 Dec 2005 21:15:58 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0oE-0001Cm-NZ; Thu, 01 Dec 2005 21:38:03 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB22FCE26983; Thu, 1 Dec 2005 18:15:12 -0800 (PST) Message-Id: <200512020215.jB22FCE26983@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 01 Dec 2005 18:15:12 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4311 on IPv6 Host-to-Router Load Sharing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4311 Title: IPv6 Host-to-Router Load Sharing Author(s): R. Hinden, D. Thaler Status: Standards Track Date: November 2005 Mailbox: bob.hinden@nokia.com, dthaler@microsoft.com Pages: 5 Characters: 10156 Updates: 2461 I-D Tag: draft-ietf-ipv6-host-load-sharing-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4311.txt The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051201181352.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4311 --OtherAccess Content-Type: Message/External-body; name="rfc4311.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051201181352.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Thu Dec 01 21:17:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0U0-00046j-9w; Thu, 01 Dec 2005 21:17:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0Ty-00046a-VI; Thu, 01 Dec 2005 21:17:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19703; Thu, 1 Dec 2005 21:16:19 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0oa-0001Ez-2B; Thu, 01 Dec 2005 21:38:24 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB22FAE26976; Thu, 1 Dec 2005 18:15:10 -0800 (PST) Message-Id: <200512020215.jB22FAE26976@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 01 Dec 2005 18:15:10 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4311 on IPv6 Host-to-Router Load Sharing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4311 Title: IPv6 Host-to-Router Load Sharing Author(s): R. Hinden, D. Thaler Status: Standards Track Date: November 2005 Mailbox: bob.hinden@nokia.com, dthaler@microsoft.com Pages: 5 Characters: 10156 Updates: 2461 I-D Tag: draft-ietf-ipv6-host-load-sharing-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4311.txt The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051201181352.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4311 --OtherAccess Content-Type: Message/External-body; name="rfc4311.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051201181352.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Dec 02 06:01:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei8fp-0003H1-CN; Fri, 02 Dec 2005 06:01:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei8fn-0003En-3L for ipv6@megatron.ietf.org; Fri, 02 Dec 2005 06:01:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06787 for ; Fri, 2 Dec 2005 06:01:02 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei90Q-0001w8-Jz for ipv6@ietf.org; Fri, 02 Dec 2005 06:23:11 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5991D842EA for ; Fri, 2 Dec 2005 12:01:39 +0100 (CET) Received: from [163.117.139.65] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.65]) by smtp02.uc3m.es (Postfix) with ESMTP id 3F148841E3 for ; Fri, 2 Dec 2005 12:01:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <6400a911d7bd8a2b8b3504e60943db67@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ipv6@ietf.org From: marcelo bagnulo braun Date: Fri, 2 Dec 2005 12:01:57 +0100 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Subject: Fwd: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-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 Hi, we would like to submit this draft for the consideration of the IPv6 wg. This draft identifies limitations in RFC3484 in multihomed configurations. The conclusion is that some changes are needed to properly support such cases. The goal of the draft is to foster discussion and try to determine if we need to generate a rfc3484bis to overcome the identified problems Comments? Regards, marcelo Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 1 de diciembre de 2005 21:50:02 GMT+01:00 > Para: i-d-announce@ietf.org > Asunto: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Updating RFC 3484 for multihoming support > Author(s) : M. Bagnulo > Filename : draft-bagnulo-ipv6-rfc3484-update-00.txt > Pages : 12 > Date : 2005-12-1 > > This note describes the limitations of RFC 3484 in multihomed > environments and proposes possible updates to the default address > selection mechanisms in order to cope with the identified > limitations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-ipv6-rfc3484-update > -00.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-bagnulo-ipv6-rfc3484-update-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bagnulo-ipv6-rfc3484-update-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-12-1145325.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 02 08:36:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiB5s-0004p3-GT; Fri, 02 Dec 2005 08:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiB5q-0004nm-CQ for ipv6@megatron.ietf.org; Fri, 02 Dec 2005 08:36:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23579 for ; Fri, 2 Dec 2005 08:36:06 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiBQS-0007Zs-Dg for ipv6@ietf.org; Fri, 02 Dec 2005 08:58:17 -0500 Received: from impact.jinmei.org (PPP409.air-4x8x.dti.ne.jp [210.170.213.195]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 326981521A; Fri, 2 Dec 2005 22:36:20 +0900 (JST) Date: Fri, 02 Dec 2005 22:36:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: margaret@thingmagic.com, Brian Haberman , IPv6 WG Subject: Re: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (Sorry for the delayed response...I hope you still remember the context) >>>>> On Thu, 17 Nov 2005 13:06:20 -0500, >>>>> "Soliman, Hesham" said: > Sending in hibernate mode. >> I'm not sure if this one is correctly addressed: >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05107.html >> (BTW: msg05107 is a comment on version 03, and I could not get a 04 >> version. Has that version been issued, or is the version number >> bumped?) >> >> I've compared the difference of the state machine in Appendix C >> between the 03 and 05 versions (attached below). At least it doesn't >> seem to cover the case where the neighbor cache entry does not exist. > => This is not the issue you are pointing to above. This issue above was about receiving > a message without SLLAO. Whether a Neighbor cache entry existed or not doesn't > seem to affect this. Please re-read the thread starting at: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04329.html I thought this discussion was the trigger of the change to APPENDIX C in version 05. If not, please specify a pointer of the source of this particular set of change (e.g., ML archive). Assuming the above discussion is the source, the essential point at that time was that the spec is unclear on the case where - an unsolicited ND message does not contain source/target LLAO - the receiving node does not have a neighbor cache entry for the source/target (see one of my comments in the thread: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04387.html and the follow-ups to this message) while the very original message of msg04329.html specifically mentioned RS, it is essentially common to all 'unsolicited' messages (RA, NS, and redirects in addition to RS). If my memory correct, the consensus at that time was that it would be good to clarify this point in the general form. So, the change to APPENDIX C should cover the case of - an unsolicited ND message does not contain source/target LLAO - the receiving node does not have a neighbor cache entry for the source/target for RA, RS, NS and redirect. That's why I made this comment. Again, if the source of the change to 05 is different than this discussion, please specify a pointer to the real source. >> It also does not cover the case where a Redirect message (w/o target >> link-layer address option) caused the situation in question. In > => This might be something to discuss. Could you elaborate? Are you saying there > is a Redirect message without the LLAO (that itself is not a problem AFAIK) ? See above. >> addition, I don't understand the following entry (added in 05): >> >> + INCOMPLETE NA, Solicited=any, Send ICMP error >> unchanged >> + Override=any, No (if router) or >> + Link-layer address log error (if host) >> + >> >> Which ICMP error is expected to be sent in this case? > => Destination unreachable. > Why do we >> separate the case for router and host? > => Because a host can't send it to anyone. A router would send it to the off-link node > trying to reach the router's neighbo (e.g. when this happens during address resolution). Hmm..., this sounds strange to me in a couple of points. First of all, which part of the main text specifies this behavior? As far as I can see, the only text that explicitly mentions ICMPv6 destination unreachable error to be sent is in Section 7.2.2, where the error is sent upon retransmit timeout for NS messages (which is clearly a different scenario than this one). Secondly, if we separate the case for routers and for hosts here, why don't we do the same thing in this case? INCOMPLETE Retransmit timeout, Discard entry - N or more Send ICMP error retransmissions. (this one corresponds to the above 'retransmission timeout' case). In my understanding, the general sense of RFC2461 about the ICMPv6 destination unreachable is that this 'error' is a conceptual one as described in Section 2.1: ICMP destination unreachable indication - an error indication returned to the original sender of a packet that cannot be delivered for the reasons outlined in [ICMPv6]. If the error occurs on a node other than the node originating the packet, an ICMP error message is generated. If the error occurs on the originating node, an implementation is not required to actually create and send an ICMP error packet to the source, as long as the upper-layer sender is notified through an appropriate mechanism (e.g., return value from a procedure call). Note, however, that an implementation may find it convenient in some cases to return errors to the sender by taking the offending packet, generating an ICMP error message, and then delivering it (locally) through the generic error handling routines. and the main text does not differentiate between the router case and the host case. If you really want to treat the two cases separately in APPENDIX C, I don't necessarily object to that particular decision. However, the decision should at least be consistent throughout the appendix. 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 Fri Dec 02 10:42:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiD3G-0002Wu-Ps; Fri, 02 Dec 2005 10:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiD3C-0002Vf-FC for ipv6@megatron.ietf.org; Fri, 02 Dec 2005 10:42:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08347 for ; Fri, 2 Dec 2005 10:41:30 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiDNs-0003Wl-Fz for ipv6@ietf.org; Fri, 02 Dec 2005 11:03:42 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Dec 2005 10:42:03 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Dec 2005 10:42:02 -0500 Message-ID: Thread-Topic: Fwd: Request To Advance: Thread-Index: AcX3RWRtq6qYIjviTf6baq1t3hQfoQAD5DMA From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 02 Dec 2005 15:42:03.0175 (UTC) FILETIME=[F0F4CB70:01C5F756] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: margaret@thingmagic.com, Brian Haberman , IPv6 WG Subject: RE: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >=20 > (Sorry for the delayed response...I hope you still remember the > context) =3D> No probs, I remember it clearly. > >> I've compared the difference of the state machine in Appendix C > >> between the 03 and 05 versions (attached below). At=20 > least it doesn't > >> seem to cover the case where the neighbor cache entry=20 > does not exist. >=20 > > =3D> This is not the issue you are pointing to above. This=20 > issue above was about receiving > > a message without SLLAO. Whether a Neighbor cache entry=20 > existed or not doesn't > > seem to affect this. >=20 > Please re-read the thread starting at: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04329.html >=20 > I thought this discussion was the trigger of the change to APPENDIX C > in version 05. If not, please specify a pointer of the=20 > source of this > particular set of change (e.g., ML archive). =3D> Sure, this is what triggered the issue. >=20 > Assuming the above discussion is the source, the essential point at > that time was that the spec is unclear on the case where >=20 > - an unsolicited ND message does not contain source/target LLAO > - the receiving node does not have a neighbor cache entry for the > source/target =3D> Correct. >=20 > (see one of my comments in the thread: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04387.html > and the follow-ups to this message) >=20 > while the very original message of msg04329.html specifically > mentioned RS, it is essentially common to all 'unsolicited' messages > (RA, NS, and redirects in addition to RS). If my memory correct, the > consensus at that time was that it would be good to clarify=20 > this point > in the general form. =20 =3D> Agreed. In addition to Appendix C, we also agreed on the list to = add a paragraph to section 7.2 (text from Greg Daley) to clarify the general handling. This = was also added. So, the change to APPENDIX C should cover the > case of >=20 > - an unsolicited ND message does not contain source/target LLAO > - the receiving node does not have a neighbor cache entry for the > source/target >=20 > for RA, RS, NS and redirect. >=20 > That's why I made this comment. Again, if the source of the=20 > change to > 05 is different than this discussion, please specify a pointer to the > real source. =3D> Your comment seemed to indicate that the non-existence of the cache = entry was a separate issue, but I don't think it is. The reception of an ND = message without the SLLAO is only a problem if no entry existed. In other words, we = wouldn't have registered this issue from the beginning if it were related to cases = where the receiving node already had an entry.=20 I might have misunderstood your comment but you also seemed to indicate = that there=20 was a difference between the following two cases: - Receiving an NS without SLLAO, which was triggered by the reception = of a REDIRECT (at the sending node) - Receiving an NS without SLLAO for other reasons.=20 As far as the spec is concerned both cases are the same, do you = disagree? If you only mean: "Add the case for REDIRECT received without SLLAO" = that's ok with me. I can add that but I don't see any other distinction.=20 >=20 > > =3D> Because a host can't send it to anyone. A router would=20 > send it to the off-link node > > trying to reach the router's neighbo (e.g. when this=20 > happens during address resolution).=20 >=20 > Hmm..., this sounds strange to me in a couple of points. >=20 > First of all, which part of the main text specifies this=20 > behavior? As > far as I can see, the only text that explicitly mentions ICMPv6 > destination unreachable error to be sent is in Section 7.2.2, where > the error is sent upon retransmit timeout for NS messages (which is > clearly a different scenario than this one). >=20 > Secondly, if we separate the case for routers and for hosts here, why > don't we do the same thing in this case? >=20 > INCOMPLETE Retransmit timeout, Discard entry - > N or more Send ICMP error > retransmissions. >=20 > (this one corresponds to the above 'retransmission timeout' case). >=20 > In my understanding, the general sense of RFC2461 about the ICMPv6 > destination unreachable is that this 'error' is a conceptual one as > described in Section 2.1: >=20 > ICMP destination unreachable indication > - an error indication returned to the original sender > of a packet that cannot be delivered for the reasons > outlined in [ICMPv6]. If the error occurs on a node > other than the node originating the packet, an ICMP > error message is generated. If the error occurs on > the originating node, an implementation is not > required to actually create and send an ICMP error > packet to the source, as long as the upper-layer > sender is notified through an appropriate mechanism > (e.g., return value from a procedure call). Note, > however, that an implementation may find it > convenient in some cases to return errors to the > sender by taking the offending packet, generating an > ICMP error message, and then delivering it (locally) > through the generic error handling routines. >=20 > and the main text does not differentiate between the router case and > the host case. >=20 > If you really want to treat the two cases separately in APPENDIX C, I > don't necessarily object to that particular decision. However, the > decision should at least be consistent throughout the appendix. =3D> Good points. I agree with that. So to keep it consistent, I'll = remove this distinction between host and router.=20 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 Fri Dec 02 21:58:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiNbT-0001QS-N1; Fri, 02 Dec 2005 21:58:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiNbR-0001QF-D0 for ipv6@megatron.ietf.org; Fri, 02 Dec 2005 21:58:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04653 for ; Fri, 2 Dec 2005 21:57:33 -0500 (EST) Message-Id: <200512030257.VAA04653@ietf.org> Received: from [202.205.253.249] (helo=sammy.buptnet.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiNw4-0006dy-0J for ipv6@ietf.org; Fri, 02 Dec 2005 22:19:51 -0500 Received: (qmail 32283 invoked by uid 89); 3 Dec 2005 02:57:59 -0000 Received: by simscan 1.1.0 ppid: 32275, pid: 32278, t: 0.4147s scanners: attach: 1.1.0 clamav: 0.85.1/m:31/d:897 spam: 3.0.2 Received: from unknown (HELO WANGY) (wangy@210.25.132.96) by 0 with SMTP; 3 Dec 2005 02:57:58 -0000 From: "??" To: Date: Sat, 3 Dec 2005 10:58:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcX3tWBMJyN0Rc9FTK6ZoynVoxp+BQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sammy X-Spam-Status: No, score=-100.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit Subject: unsubcribe 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 03 16:57:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EifNX-0004Yx-2J; Sat, 03 Dec 2005 16:57:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EifNV-0004Ys-1r for ipv6@megatron.ietf.org; Sat, 03 Dec 2005 16:57:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07327 for ; Sat, 3 Dec 2005 16:56:19 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EifiR-0004yF-Hp for ipv6@ietf.org; Sat, 03 Dec 2005 17:18:49 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jB3Luuji020716; Sat, 3 Dec 2005 22:56:56 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jB3LuumL013216; Sat, 3 Dec 2005 22:56:56 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jB3LutwV013215; Sat, 3 Dec 2005 22:56:55 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Sat, 3 Dec 2005 22:56:55 +0100 From: Stig Venaas To: =?iso-8859-1?Q?Ant=F3nio?= Amaral Message-ID: <20051203215655.GD12857@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tyholt.uninett.no id jB3Luuji020716 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: IPng , M6bone Subject: Re: [m6bone] Bootsrap mecanism new PIM Neighbor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Dec 01, 2005 at 11:15:50PM +0000, Ant=F3nio Amaral wrote: > Dear All, >=20 > After draft-ietf-pim-sm-bsr-05.txt there is a section >=20 > ---- > 3.5. Unicasting Bootstrap Messages to New and Rebooting=20 > Routers >=20 > To allow new or rebooting routers to learn the RP-Set=20 > quickly, when a > Hello message is received from a new neighbor, or a Hello=20 > message with a > new GenID is received from an existing neighbor, one=20 > router on the LAN > unicasts a stored copy of the Bootstrap message for each=20 > admin scope > zone to the new or rebooting router. > (....) > -------- >=20 > What is the motivation for this behaviour? With a common=20 > bootstrap message new router also learn the RP-Set=20 > quickly, am I right? > In my opinion when a new router placed on the LAN sends a=20 > PIM Hello message, one router on the LAN could simply send=20 > a bootstrap message and new router also learn the RP-Set=20 > quickly. That's what happens. The text in bsr spec, does exactly what you write above. When a new router send a PIM hello, an existing router may unicast a BSM to it. Stig >=20 > Thanks in advance > Best Regards >=20 > AA > -------------------------------------------------------- > Ant=F3nio Manuel Nunes C. Amaral > Instituto de Telecomunica=E7=F5es - P=F3lo de Aveiro > Campus Universit=E1rio > 3810-193 AVEIRO - PORTUGAL > Telef. 234 - 377900 > Fax. 234 - 377901 > e-mail: aamaral@av.it.pt > Telef. directo. 234 - 377906 > --------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 04 00:00:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EilzN-0001Ni-M3; Sun, 04 Dec 2005 00:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EilzM-0001Lz-2D for ipv6@megatron.ietf.org; Sun, 04 Dec 2005 00:00:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04875 for ; Sat, 3 Dec 2005 23:59:50 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EimKM-0006r2-La for ipv6@ietf.org; Sun, 04 Dec 2005 00:22:24 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id CD845331 for ; Sun, 4 Dec 2005 00:00:13 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 04 Dec 2005 00:00:13 -0500 Message-Id: <20051204050013.CD845331@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.15% | 5 | 19.80% | 42534 | h.soliman@flarion.com 12.12% | 4 | 15.72% | 33765 | vishwas@sinett.com 12.12% | 4 | 9.55% | 20523 | stig.venaas@uninett.no 9.09% | 3 | 6.86% | 14735 | bob.hinden@nokia.com 6.06% | 2 | 8.32% | 17869 | dthaler@windows.microsoft.com 6.06% | 2 | 6.17% | 13258 | rfc-editor@rfc-editor.org 3.03% | 1 | 4.11% | 8839 | jinmei@isl.rdc.toshiba.co.jp 3.03% | 1 | 4.04% | 8680 | albert.e.manfredi@boeing.com 3.03% | 1 | 3.97% | 8524 | radhakrishnan@zazunetworks.com 3.03% | 1 | 3.23% | 6949 | obaidasyed@gmail.com 3.03% | 1 | 2.83% | 6077 | marcelo@it.uc3m.es 3.03% | 1 | 2.56% | 5506 | srisuresh@yahoo.com 3.03% | 1 | 2.10% | 4518 | sra+ipng@hactrn.net 3.03% | 1 | 2.10% | 4509 | aamaral@av.it.pt 3.03% | 1 | 1.95% | 4179 | ot@cisco.com 3.03% | 1 | 1.89% | 4063 | pekkas@netcore.fi 3.03% | 1 | 1.78% | 3819 | mailman-owner@ietf.org 3.03% | 1 | 1.63% | 3504 | 77cronux.leed0621@huawei.com 3.03% | 1 | 1.39% | 2982 | wangy@buptnet.edu.cn --------+------+--------+----------+------------------------ 100.00% | 33 |100.00% | 214833 | 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 Dec 05 02:55:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjBC3-0002Xh-Mp; Mon, 05 Dec 2005 02:55:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjBC1-0002Xb-10 for ipv6@megatron.ietf.org; Mon, 05 Dec 2005 02:55:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12596 for ; Mon, 5 Dec 2005 02:54:33 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjBXC-0006Gi-H5 for ipv6@ietf.org; Mon, 05 Dec 2005 03:17:22 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:d839:6d12:1633:3eb2]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2F6F51521A; Mon, 5 Dec 2005 16:54:55 +0900 (JST) Date: Mon, 05 Dec 2005 16:54:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IPv6 WG Subject: Re: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 2 Dec 2005 10:42:02 -0500, >>>>> "Soliman, Hesham" said: > => Agreed. In addition to Appendix C, we also agreed on the list to add a paragraph to > section 7.2 (text from Greg Daley) to clarify the general > handling. This was also added. OK so far. > So, the change to APPENDIX C should cover the >> case of >> >> - an unsolicited ND message does not contain source/target LLAO >> - the receiving node does not have a neighbor cache entry for the >> source/target >> >> for RA, RS, NS and redirect. >> >> That's why I made this comment. Again, if the source of the >> change to >> 05 is different than this discussion, please specify a pointer to the >> real source. > => Your comment seemed to indicate that the non-existence of the cache entry > was a separate issue, but I don't think it is. The reception of an ND message without > the SLLAO is only a problem if no entry existed. In other words, we wouldn't have > registered this issue from the beginning if it were related to cases where the receiving > node already had an entry. Yes, that's correct. Perhaps I was not clear in my previous message, but I actually meant: the change to APPENDIX C should cover the case of an unsolicited ND message does not contain source/target LLAO, AND the receiving node does not have a neighbor cache entry for the source/target (there are two conditions for a single 'case') Is this now clear and does that match your (our) understanding? Then, let's revisit the change to APPENDIX C in 2461bis-05. My point of the first message of this thread is that the change does not cover cases where a neighbor cache entry does not exist when the unsolicited message arrives (see the diff I attached to a previous message http://www1.ietf.org/mail-archive/web/ipv6/current/msg05861.html). More specifically, I'd like to see new entries like: State Event Action New state - RS, no link-layer - - address ...hmm..., perhaps your intent was that such cases should be covered new entries like this one: INCOMPLETE NS, RS No link-layer - unchanged address If so, I see your position, but I don't think this is 100% correct, because the 'non-existent' entry cannot be in any state (INCOMPLETE in this case). I believe using '-' for the 'State' field in these cases should make more sense. > If you only mean: "Add the case for REDIRECT received without SLLAO" that's ok with me. Yes, that's my point. >> If you really want to treat the two cases separately in APPENDIX C, I >> don't necessarily object to that particular decision. However, the >> decision should at least be consistent throughout the appendix. > => Good points. I agree with that. So to keep it consistent, I'll remove this distinction > between host and router. Okay, but please clarify my first question, too: >> First of all, which part of the main text specifies this behavior? As >> far as I can see, the only text that explicitly mentions ICMPv6 >> destination unreachable error to be sent is in Section 7.2.2, where >> the error is sent upon retransmit timeout for NS messages (which is >> clearly a different scenario than this one). 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 Mon Dec 05 04:34:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjCjZ-00075M-63; Mon, 05 Dec 2005 04:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjCjX-00075C-OR for ipv6@megatron.ietf.org; Mon, 05 Dec 2005 04:34:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21843 for ; Mon, 5 Dec 2005 04:33:18 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjD4n-0001QZ-64 for ipv6@ietf.org; Mon, 05 Dec 2005 04:56:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Dec 2005 01:38:30 -0800 Message-ID: Thread-Topic: Fragment Header Thread-Index: AcXw8lxBeAfl+TOPRgGsitXQwZXcvgIjJpzg From: "Vishwas Manral" To: "Radhakrishnan.S" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Fragment Header X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Radhakrishnan, I think that having a fragment header does not mean that it is a = fragment. The document for SIIT RFC2765, in Section 3 states that: - "Also, when the IPv4 sender does not perform path MTU discovery the = translator MUST always include an IPv6 fragment header to indicate that = the sender allows fragmentation. That is needed should the packet pass = through an IPv6-to-IPv4 translator." That is why I think that having a fragment header does not mean that it = is a fragment. It just signals the equivalent of the DF bit in case the = packet is translated to IPv4. Thanks, Vishwas ________________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Radhakrishnan.S Sent: Friday, November 25, 2005 7:32 AM To: ipv6@ietf.org Subject: Re: Fragment Header That said; how should the case where we have the fragment header and = both the Fragment Offset and the M flag is 0 be treated? =3D> The one and only fragment.=A0 :-) Doesnt make sense unless u want = to test the reassembling capability of the receiver of the fragments. = The presence of a fragment header is used in NAT-PT IPv4->IPv6 to = indicate that the packet is fragmentable. (case where DF bit is NOT set = in IPv4 header). Why do we need the M flag in the "fragment header" at all for IPv6? = Having the fragment header itself would tell it's a fragment and would = distinguish between the first fragment and a non-fragment. =3D> M flag is used to distinguish last frag from others!!!! Its used = for identifying the last frag when computing the length during = reassembly.=20 Vishwas Manral wrote:=20 Hi folks, =A0 I have a doubt regarding the fragment header. Why do we need the M flag = in the "fragment header" at all for IPv6? Having the fragment header = itself would tell it's a fragment and would distinguish between the = first fragment and a non-fragment. =A0 In IPv4 we did not have a fragment header, so the M flag was logical to = have for distinguishing the first and a non fragment. =A0 That said; how should the case where we have the fragment header and = both the Fragment Offset and the M flag is 0 be treated? =A0 Thanks, Vishwas =A0 =A0=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 05 04:41:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjCqI-0000Vh-Pf; Mon, 05 Dec 2005 04:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjCqH-0000Vc-1b for ipv6@megatron.ietf.org; Mon, 05 Dec 2005 04:41:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22711 for ; Mon, 5 Dec 2005 04:40:13 -0500 (EST) Received: from web61116.mail.yahoo.com ([209.73.179.30]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjDBM-0001gJ-2f for ipv6@ietf.org; Mon, 05 Dec 2005 05:03:01 -0500 Received: (qmail 80477 invoked by uid 60001); 5 Dec 2005 09:40:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ie; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qQTeicjVqZtjWVrF4r9bZX13YOrsYjR1YOuYvXwo9lb0bD+gPrz66yZlrqU0EBgVF0tAYmlIi9fuOhcOC9wxVGZHerUQf5DUvQpoPWV5yAZmpj/PFnezPnZlRKlm696A3Dj2Tep+5Rde9NhE71T+iBjx0K/uQSmu4X7rkdI9ByA= ; Message-ID: <20051205094038.80475.qmail@web61116.mail.yahoo.com> Received: from [195.166.243.186] by web61116.mail.yahoo.com via HTTP; Mon, 05 Dec 2005 09:40:38 GMT Date: Mon, 5 Dec 2005 09:40:38 +0000 (GMT) From: Doo Timbir To: Vishwas Manral , "Radhakrishnan.S" , ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: RE: Fragment Header 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="===============0666426230==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0666426230== Content-Type: multipart/alternative; boundary="0-1279347547-1133775638=:59686" Content-Transfer-Encoding: 8bit --0-1279347547-1133775638=:59686 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Vishwas, It appears our reasoning is in the same direction.I definitely think likewise too! Sincerely, Doo Timbir. Vishwas Manral wrote: Hi Radhakrishnan, I think that having a fragment header does not mean that it is a fragment. The document for SIIT RFC2765, in Section 3 states that: - "Also, when the IPv4 sender does not perform path MTU discovery the translator MUST always include an IPv6 fragment header to indicate that the sender allows fragmentation. That is needed should the packet pass through an IPv6-to-IPv4 translator." That is why I think that having a fragment header does not mean that it is a fragment. It just signals the equivalent of the DF bit in case the packet is translated to IPv4. Thanks, Vishwas ________________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Radhakrishnan.S Sent: Friday, November 25, 2005 7:32 AM To: ipv6@ietf.org Subject: Re: Fragment Header That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated? => The one and only fragment. :-) Doesnt make sense unless u want to test the reassembling capability of the receiver of the fragments. The presence of a fragment header is used in NAT-PT IPv4->IPv6 to indicate that the packet is fragmentable. (case where DF bit is NOT set in IPv4 header). Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment. => M flag is used to distinguish last frag from others!!!! Its used for identifying the last frag when computing the length during reassembly. Vishwas Manral wrote: Hi folks, I have a doubt regarding the fragment header. Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment. In IPv4 we did not have a fragment header, so the M flag was logical to have for distinguishing the first and a non fragment. That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated? Thanks, Vishwas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------------------------- Win a Yahoo! Vespa NEW - Yahoo! Cars has 3 Vespa LX125s to be won Enter Now! --0-1279347547-1133775638=:59686 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Vishwas,
 
It appears our reasoning is in the same direction.I definitely think likewise too!
 
Sincerely,
Doo Timbir.

Vishwas Manral <Vishwas@sinett.com> wrote:
Hi Radhakrishnan,

I think that having a fragment header does not mean that it is a fragment. The document for SIIT RFC2765, in Section 3 states that: -

"Also, when the IPv4 sender does not perform path MTU discovery the translator MUST always include an IPv6 fragment header to indicate that the sender allows fragmentation. That is needed should the packet pass through an IPv6-to-IPv4 translator."

That is why I think that having a fragment header does not mean that it is a fragment. It just signals the equivalent of the DF bit in case the packet is translated to IPv4.

Thanks,
Vishwas
________________________________________
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Radhakrishnan.S
Sent: Friday, November 25, 2005 7:32 AM
To: ipv6@ietf.org
Subject: Re: Fragment Header

That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated?
=> The one and only fragment.  :-) Doesnt make sense unless u want to test the reassembling capability of the receiver of the fragments. The presence of a fragment header is used in NAT-PT IPv4->IPv6 to indicate that the packet is fragmentable. (case where DF bit is NOT set in IPv4 header).

Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment.
=> M flag is used to distinguish last frag from others!!!! Its used for ide! ntifying the last frag when computing the length during reassembly.





Vishwas Manral wrote:
Hi folks,
 
I have a doubt regarding the fragment header. Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment.
 
In IPv4 we did not have a fragment header, so the M flag was logical to have for distinguishing the first and a non fragment.
 
That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated?
 
Thanks,
Vishwas
 
 


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

Win a Yahoo! Vespa NEW - Yahoo! Cars has 3 Vespa LX125s to be won Enter Now! --0-1279347547-1133775638=:59686-- --===============0666426230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0666426230==-- From ipv6-bounces@ietf.org Mon Dec 05 04:47:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjCwn-0002es-8v; Mon, 05 Dec 2005 04:47:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjCwg-0002eQ-Ju for ipv6@megatron.ietf.org; Mon, 05 Dec 2005 04:47:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23284 for ; Mon, 5 Dec 2005 04:46:52 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjDHv-0001vx-UB for ipv6@ietf.org; Mon, 05 Dec 2005 05:09:41 -0500 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 jB59ktk22831; Mon, 5 Dec 2005 10:46:55 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jB59ktrq065388; Mon, 5 Dec 2005 10:46:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512050946.jB59ktrq065388@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: marcelo bagnulo braun In-reply-to: Your message of Fri, 02 Dec 2005 12:01:57 +0100. <6400a911d7bd8a2b8b3504e60943db67@it.uc3m.es> Date: Mon, 05 Dec 2005 10:46:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ipv6@ietf.org Subject: Re: Fwd: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-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 In your previous mail you wrote: Comments? => I have some comments: - if the border router for X to A knows the outage it can deprecate the A prefix and propagate the information. Note this idea was described many time but as far as I know is *not* implemented (if such basic idea is not supported I am afraid we'll get no help from routers). Perhaps the document should say something about this, for instance explaining some outages can't be detected so easily... - the document should address as soon as possible the orders between destination and source addresses, i.e., it is S1-D1, S2-D1, S1-D2, S2-D2 or S1-D1, S1-D2, S2-D1, S2-D2? - note that many applications which specify source addresses in fact simply use source addresses returned by the selection mechanism (connect() then getsockname())... - the Rule 0 is not enough accurate: it assumes some state is kept (what state? how? lifetime? etc). IMHO the document has to provide guidelines! - in the Rule 0 the term "unreachable" is not the right one, IMHO it is more "not working for D"? - it is not true that RFC 3484 provides an ordered list of destination address, it only orders the list provided by DNS & co. BTW it should be useful to know when the tail of a list contains unusable addresses or to remove them. - IMHO it should be fine to get a support for address pairs because it is needed for any scheme which replaces the last "longest prefix match" rules by a better thing. I think about NAROS but there should be many similar ideas. - in 3.2.1 there are other transport protocols than TCP and UDP. I prefer connection oriented and connection less. - in 3.2.2 the amount of tried source addresses has to be controlled. IMHO a better mechanism for both TCP and UDP is a new setsockopt() which the N first elements of the source address list. The only issue is this hint can be obsolete when the list changes but when you look at the rules you can see they should give a stable ordering. Of course, it can be used to get the source address list for a destination... 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 Mon Dec 05 05:10:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjDIx-0007w0-F8; Mon, 05 Dec 2005 05:10:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjDIv-0007vI-KC for ipv6@megatron.ietf.org; Mon, 05 Dec 2005 05:10:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25438 for ; Mon, 5 Dec 2005 05:09:51 -0500 (EST) Received: from cpanel2.interactivedns.com ([67.15.58.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjDe5-0002bP-SS for ipv6@ietf.org; Mon, 05 Dec 2005 05:32:41 -0500 Received: from [61.95.198.15] (helo=[192.168.1.43]) by cpanel2.interactivedns.com with esmtpa (Exim 4.52) id 1EjDIF-00033a-M4; Mon, 05 Dec 2005 15:40:03 +0530 Message-ID: <43941202.9020704@zazunetworks.com> Date: Mon, 05 Dec 2005 15:40:10 +0530 From: "S.Radhakrishnan" Organization: ZAZU Networks User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishwas Manral References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel2.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - zazunetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Fragment Header 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 yes, right. thats what i meant too. :-) the purpose is only for indication. "the presence of a fragment header is used in NAT-PT IPv4->IPv6 to *indicate that the packet is fragmentable." *the error i made is "NAT-PT IPv4->IPv6" which should have been "NAT-PT IPv6->IPv4". error regretted! :-) regards radhakrishnan* * Vishwas Manral wrote: >Hi Radhakrishnan, > >I think that having a fragment header does not mean that it is a fragment. The document for SIIT RFC2765, in Section 3 states that: - > >"Also, when the IPv4 sender does not perform path MTU discovery the translator MUST always include an IPv6 fragment header to indicate that the sender allows fragmentation. That is needed should the packet pass through an IPv6-to-IPv4 translator." > >That is why I think that having a fragment header does not mean that it is a fragment. It just signals the equivalent of the DF bit in case the packet is translated to IPv4. > >Thanks, >Vishwas >________________________________________ >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Radhakrishnan.S >Sent: Friday, November 25, 2005 7:32 AM >To: ipv6@ietf.org >Subject: Re: Fragment Header > >That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated? >=> The one and only fragment. :-) Doesnt make sense unless u want to test the reassembling capability of the receiver of the fragments. The presence of a fragment header is used in NAT-PT IPv4->IPv6 to indicate that the packet is fragmentable. (case where DF bit is NOT set in IPv4 header). > >Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment. >=> M flag is used to distinguish last frag from others!!!! Its used for identifying the last frag when computing the length during reassembly. > > > > > >Vishwas Manral wrote: >Hi folks, > >I have a doubt regarding the fragment header. Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment. > >In IPv4 we did not have a fragment header, so the M flag was logical to have for distinguishing the first and a non fragment. > >That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated? > >Thanks, >Vishwas > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 05 08:37:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjGWw-0001yz-Kg; Mon, 05 Dec 2005 08:37:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjGWu-0001yX-SA for ipv6@megatron.ietf.org; Mon, 05 Dec 2005 08:37:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18979 for ; Mon, 5 Dec 2005 08:36:29 -0500 (EST) Received: from rockribhci590.ria.army.mil ([147.216.11.118] helo=ROCKRIBHCI590.nanw.ds.army.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjGsA-0001cK-GG for ipv6@ietf.org; Mon, 05 Dec 2005 08:59:21 -0500 Received: by rockribhci590.ria.army.mil with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Dec 2005 07:37:05 -0600 Message-ID: <7CD3A8FB1860D443A61E833FDC6E89B409826CAB@rockrib1bn045.ria.army.mil> From: "Martin, Jean K Ms TACOM-RI" To: "'ipv6@ietf.org'" Date: Mon, 5 Dec 2005 07:37:00 -0600 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Martin, Jean K Ms TACOM-RI" Subject: FW: unsubcribe 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 -----Original Message----- From: ?? [mailto:wangy@buptnet.edu.cn] Sent: Friday, December 02, 2005 8:58 PM To: ipv6@ietf.org Subject: unsubcribe -------------------------------------------------------------------- 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 Dec 05 08:49:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjGil-00058h-SE; Mon, 05 Dec 2005 08:49:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjGij-00058W-Ja for ipv6@megatron.ietf.org; Mon, 05 Dec 2005 08:49:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20162 for ; Mon, 5 Dec 2005 08:48:41 -0500 (EST) Received: from purgatory.unfix.org ([213.136.24.43] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjH40-000200-KZ for ipv6@ietf.org; Mon, 05 Dec 2005 09:11:34 -0500 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 9C71E7FAA for ; Mon, 5 Dec 2005 14:49:11 +0100 (CET) Message-ID: <43944544.6040007@unfix.org> Date: Mon, 05 Dec 2005 14:48:52 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "'ipv6@ietf.org'" References: <7CD3A8FB1860D443A61E833FDC6E89B409826CAB@rockrib1bn045.ria.army.mil> In-Reply-To: <7CD3A8FB1860D443A61E833FDC6E89B409826CAB@rockrib1bn045.ria.army.mil> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [administrative note] How to 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="===============0911208261==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0911208261== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6388D03FCD8278C6FBF17C03" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6388D03FCD8278C6FBF17C03 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, It's almost christmas again, autumn has already caused leaves to have fallen of the trees and people turn a bit crazy and want to unsubscribe. Apparently it is really hard to read the footer of every message send to the list, it contains: > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- If you would go to the above url you can use that to unsubscribe, which was the same page you used to subscribe to the list. Also note that the headers in the emails contain: 8<----------------------------------------------------------------- List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , ----------------------------------------------------------------->8 Which *also* describes how to unsubscribe from this list, mailing the above addresses unsubscribes you from the list. And when you are really unable to unsubscribe and need help then send them to the mail address at the bottom of: https://www1.ietf.org/mailman/listinfo/ipv6 or reply off-list to this message and I'll take a look into it for you. IMHO it is quite odd that in a technical community like the IETF reading is so difficult. Greets, Jeroen --------------enig6388D03FCD8278C6FBF17C03 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFDlEVEKaooUjM+fCMRAv7SAJ99sFuPB8ILOPD/eyGW1g055fPRrwCfTzEM mFYAbuKDSBbrkeJmhs03X/g= =lPYg -----END PGP SIGNATURE----- --------------enig6388D03FCD8278C6FBF17C03-- --===============0911208261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0911208261==-- From ipv6-bounces@ietf.org Tue Dec 06 14:51:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjiqE-0007Z7-92; Tue, 06 Dec 2005 14:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjiqC-0007Z1-K0 for ipv6@megatron.ietf.org; Tue, 06 Dec 2005 14:51:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14289 for ; Tue, 6 Dec 2005 14:50:16 -0500 (EST) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjjBk-0007Bq-16 for ipv6@ietf.org; Tue, 06 Dec 2005 15:13:24 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7719E9E171; Tue, 6 Dec 2005 20:50:57 +0100 (CET) Received: from [163.117.203.49] (unknown [163.117.203.49]) by smtp01.uc3m.es (Postfix) with ESMTP id 43D249E158; Tue, 6 Dec 2005 20:50:54 +0100 (CET) In-Reply-To: <200512050946.jB59ktrq065388@givry.rennes.enst-bretagne.fr> References: <200512050946.jB59ktrq065388@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <309b3c8cd3f23764d9c3dc5a11624d3f@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Tue, 6 Dec 2005 20:49:50 +0100 To: Francis Dupont X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-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 Hi Francis, thanks for your feedback comments below... El 05/12/2005, a las 10:46, Francis Dupont escribi=F3: > In your previous mail you wrote: > > Comments? > > =3D> I have some comments: > - if the border router for X to A knows the outage it can deprecate > the A prefix and propagate the information. Note this idea was > described many time but as far as I know is *not* implemented > (if such basic idea is not supported I am afraid we'll get > no help from routers). > Perhaps the document should say something about this, for instance > explaining some outages can't be detected so easily... > i agree this is a useful tool for multihomed environments (i have=20 included it in draft-bagnulo-shim6-addr-selection-00.txt) and i agree=20 that this should be detailed in a document related to initiating=20 communications in multihomed environments However, i am not sure if this would belong to a new version of RFC3484=20= which is the goal of this document... > - the document should address as soon as possible the orders between > destination and source addresses, i.e., it is S1-D1, S2-D1, S1-D2, > S2-D2 or S1-D1, S1-D2, S2-D1, S2-D2? > right, this would be the optimal approach, since it would provide an=20 order of address pairs (as opposed to an order of destiantion addresses=20= and for each deatiantion address, an ordered list of source addresses)=20= but the difficulty with this is that current functions do not return=20 address pairs, but destination addresses and source addresses=20 separately. I guess that one option would be to define new function=20 calls that return list of src,dst address pairs, but this wouldn't be=20 compatible with current apps, since they don't use these to-be-defined=20= functions I guess that an option would be to define the two approaches, on one=20 hand the approach to define the list of dest addresses and for each=20 dest address an ordered list of source addresses and the other approach=20= (for updated apps) the returns an ordered list of src,dst address pairs > - note that many applications which specify source addresses in > fact simply use source addresses returned by the selection > mechanism (connect() then getsockname())... > right the idea would be that the src addresses returned are ordered. The=20 difficulty is that this fucntion call does not refers to any specific=20 destiantion address and providing an order independent of the=20 destiantion is of little use imho so, the option would be to define a new function call that returns an=20 ordered list of source address available for a particular destiantion=20 address > - the Rule 0 is not enough accurate: it assumes some state is kept > (what state? how? lifetime? etc). IMHO the document has to > provide guidelines! > agree in draft-bagnulo-shim6-addr-selection-00.txt there is a proposal to use=20= information in incoming packets as hints to determine which address=20 pairs are working. This information is cached and can be used to=20 determine if an address pair is working > - in the Rule 0 the term "unreachable" is not the right one, IMHO > it is more "not working for D"? > agree an alternative would be to talk about working/non-working address pairs > - it is not true that RFC 3484 provides an ordered list of = destination > address, it only orders the list provided by DNS & co. I am not sure i understand the difference here... the rationale behind this is that a host wants to communicate with a=20 given host identified by a fqdn It then obtains the list of destiantion addresses for that fqdn from=20 the dns then rfc3484 orders the list provided by the dns so, i would say that rfc3484 returns an ordered list of destiantion=20 addresses... what is the aspect that i am missing here? > BTW it should > be useful to know when the tail of a list contains unusable > addresses or to remove them. > yes this could be an option otoh, an address pair working/non-working status may change over time=20 (and quite fast) so, possibly it may worth trying with address pairs that were not=20 working some minutes ago, if there are no other options (i.e. other=20 options have been tried later and they are not working) so including the addresses that were not working at the end of the list=20= may be of some use > - IMHO it should be fine to get a support for address pairs because > it is needed for any scheme which replaces the last "longest > prefix match" rules by a better thing. I think about NAROS but > there should be many similar ideas. i am not sure i understand this point... > > - in 3.2.1 there are other transport protocols than TCP and UDP. > I prefer connection oriented and connection less. > agree > - in 3.2.2 the amount of tried source addresses has to be controlled. > IMHO a better mechanism for both TCP and UDP is a new setsockopt() > which the N first elements of the source address list. in this case the application would be: - first obtaining the src address list for a given destiantion with a=20 new call setting, and then - it would be setting the list of source addresses to be tried by=20 TCP/UDP using this new option, passing the list (or part of) obtained=20 in the previous point right? This is an interesting middle ground option indeed, where the=20 application does not select a single address (as with bind()) nor it=20 leaves the src address unspecified (which is the actual scenario=20 considered in section 3.2.2) regards, marcelo > The only > issue is this hint can be obsolete when the list changes but > when you look at the rules you can see they should give a stable > ordering. Of course, it can be used to get the source address list > for a destination... > > 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 Tue Dec 06 21:09:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejokm-0002u2-T5; Tue, 06 Dec 2005 21:09:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejokl-0002tx-EK for ipv6@megatron.ietf.org; Tue, 06 Dec 2005 21:09:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22052 for ; Tue, 6 Dec 2005 21:09:03 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejp6N-0002lJ-6A for ipv6@ietf.org; Tue, 06 Dec 2005 21:32:15 -0500 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 jB729dP02182; Wed, 7 Dec 2005 03:09:39 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jB729dHY077351; Wed, 7 Dec 2005 03:09:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512070209.jB729dHY077351@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: marcelo bagnulo braun In-reply-to: Your message of Tue, 06 Dec 2005 20:49:50 +0100. <309b3c8cd3f23764d9c3dc5a11624d3f@it.uc3m.es> Date: Wed, 07 Dec 2005 03:09:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-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 In your previous mail you wrote: i agree this is a useful tool for multihomed environments (i have included it in draft-bagnulo-shim6-addr-selection-00.txt) and i agree that this should be detailed in a document related to initiating communications in multihomed environments However, i am not sure if this would belong to a new version of RFC3484 which is the goal of this document... => to be complete the document in its introduction should explain there are some cases without solutions so should list the possible solutions to find cases where none applies. This is the way I'll quickly explain the deprectation of prefixes from broken ISPs. > - the document should address as soon as possible the orders between > destination and source addresses, i.e., it is S1-D1, S2-D1, S1-D2, > S2-D2 or S1-D1, S1-D2, S2-D1, S2-D2? > right, this would be the optimal approach, since it would provide an => note I didn't ask for a solution but for the set out of the problem (it seems I was not clear enough, I apologize). order of address pairs (as opposed to an order of destiantion addresses and for each deatiantion address, an ordered list of source addresses) but the difficulty with this is that current functions do not return address pairs, but destination addresses and source addresses separately. I guess that one option would be to define new function calls that return list of src,dst address pairs, but this wouldn't be compatible with current apps, since they don't use these to-be-defined functions => this can be easily done by a middleware (aka bump in the API), including the very special one named the shim6 layer... I guess that an option would be to define the two approaches, on one hand the approach to define the list of dest addresses and for each dest address an ordered list of source addresses and the other approach (for updated apps) the returns an ordered list of src,dst address pairs => I don't believe in updated apps: we have to support this idea but we have more to never rely on it! > - note that many applications which specify source addresses in > fact simply use source addresses returned by the selection > mechanism (connect() then getsockname())... right the idea would be that the src addresses returned are ordered. The difficulty is that this fucntion call does not refers to any specific destiantion address => in the common mechanism I describe the destination is clearly taken into account (it is the argument of connect()). and providing an order independent of the destiantion is of little use imho so, the option would be to define a new function call that returns an ordered list of source address available for a particular destiantion address => a function or a simpler mechanism. > - the Rule 0 is not enough accurate: it assumes some state is kept > (what state? how? lifetime? etc). IMHO the document has to > provide guidelines! agree in draft-bagnulo-shim6-addr-selection-00.txt there is a proposal to use information in incoming packets as hints to determine which address pairs are working. This information is cached and can be used to determine if an address pair is working => so you have to cite this document and even to explain how to use its ideas outside the shim6 context. > - in the Rule 0 the term "unreachable" is not the right one, IMHO > it is more "not working for D"? > agree an alternative would be to talk about working/non-working address pairs => you can't talk about an address pair in a function about an argument: you have to find a better wording. > - it is not true that RFC 3484 provides an ordered list of destination > address, it only orders the list provided by DNS & co. I am not sure i understand the difference here... => it does not create the destination address list. BTW it is just a wording issue. the rationale behind this is that a host wants to communicate with a given host identified by a fqdn It then obtains the list of destiantion addresses for that fqdn from the dns then rfc3484 orders the list provided by the dns so, i would say that rfc3484 returns an ordered list of destiantion addresses... what is the aspect that i am missing here? => a function is not defined by its return value but by its return value in function of its arguments (this is why it is named "function"). Sorry but I began in functional programming and I do important differences for things which can be considered as details, like "(f x) y" is not the same than "f (x,y)" cf a previous comment. > BTW it should > be useful to know when the tail of a list contains unusable > addresses or to remove them. yes this could be an option otoh, an address pair working/non-working status may change over time (and quite fast) so, possibly it may worth trying with address pairs that were not working some minutes ago, if there are no other options (i.e. other options have been tried later and they are not working) so including the addresses that were not working at the end of the list may be of some use => a good alternative is to provide a reliability judgement so a clever implementation can adapt its strategy in looking for a working pair (I think about a sorting on address pairs). > - IMHO it should be fine to get a support for address pairs because > it is needed for any scheme which replaces the last "longest > prefix match" rules by a better thing. I think about NAROS but > there should be many similar ideas. i am not sure i understand this point... => look at draft-de-launois-multi6-naros-00.txt or read Cedric's PhD document. To apply this kind of ideas you both have to replace last rules and to give address pairs to the application. So to be able to handle address pairs is an important goal in a larger scope than this I-D. > - in 3.2.2 the amount of tried source addresses has to be controlled. > IMHO a better mechanism for both TCP and UDP is a new setsockopt() > which the N first elements of the source address list. in this case the application would be: - first obtaining the src address list for a given destiantion with a new call setting, and then => no, I don't see why this step is useful. Even the src address list length is not important. - it would be setting the list of source addresses to be tried by TCP/UDP using this new option, passing the list (or part of) obtained in the previous point right? => you didn't understand my idea. In place to handle in the application the source address list per destination you just specify the destination and the number of the item of the source address list. Of course you can get by connect() then getsockname() the source address but you don't need to do this. This is an interesting middle ground option indeed, where the application does not select a single address (as with bind()) nor it leaves the src address unspecified (which is the actual scenario considered in section 3.2.2) => the idea is to replace the bind() by a simpler setsockopt() with a counter. 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 Wed Dec 07 05:06:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjwCA-0002UF-9X; Wed, 07 Dec 2005 05:06:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjwC8-0002Tp-Or for ipv6@megatron.ietf.org; Wed, 07 Dec 2005 05:06:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10624 for ; Wed, 7 Dec 2005 05:05:47 -0500 (EST) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjwXl-0000tE-JH for ipv6@ietf.org; Wed, 07 Dec 2005 05:29:05 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EjwBi-00026n-2G; Wed, 07 Dec 2005 10:06:14 +0000 Message-ID: <4396B488.2050406@dial.pipex.com> Date: Wed, 07 Dec 2005 10:08:08 +0000 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman 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: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi. Sorry for the silence.. I have been on an extended holiday jaunt and am just catching up. As one of those who commented on the current version, just to say that I am happy with the proposed resolution, but it is probably appropriate to add a security note as proposed by Jeroen Massar as regards the tunnel endpoint enquiry. Regards, Elwyn Brian Haberman wrote: > All, > As promised during the IPv6 WG session in Vancouver, this is > my attempt to resolve the open issues with the ICMP Name Lookup > draft. From my review of my e-mail and the mailing list archive, there > are three open issues on the table. I will list each and propose a > resolution to each. > > I will accept comments on these changes until 5:00pm on 12/2/05. > After that, I will incorporate the changes and submit the draft. > > > Issue 1: Restrict operation of the protocol to link-local use. > > Resolution: > The consensus is to retain the more flexible multi-hop capability. > An additional sentence or two will be added to the Security > Considerations section recommending the filtering of these > messages at administrative boundaries. > > > Issue 2: Change multicast range used for Queries. > > Resolution: > This change will be made. There will not be a "compatibility" > knob for operation with older implementations. The addition > of such a knob will make operational use too complex. This > should simplify the use, but will require a code change. > > Issue 3: Discovery of tunnel endpoints. > > Resolution: > This change will be made and will be based on the text proposed > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html > > > Regards, > Brian > >------------------------------------------------------------------------ > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 07 13:18:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3sJ-0007Vm-UQ; Wed, 07 Dec 2005 13:18:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3sI-0007Vh-0g for ipv6@megatron.ietf.org; Wed, 07 Dec 2005 13:18:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08742 for ; Wed, 7 Dec 2005 13:17:50 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek4Dy-0001aW-DI for ipv6@ietf.org; Wed, 07 Dec 2005 13:41:07 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Dec 2005 13:18:27 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Date: Wed, 7 Dec 2005 13:18:28 -0500 Message-ID: Thread-Topic: Fwd: Request To Advance: Thread-Index: AcX5cS8rJtERXep6ScK2qdyLAZlWewB6GaPA From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 07 Dec 2005 18:18:27.0591 (UTC) FILETIME=[9E91C970:01C5FB5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > the change to APPENDIX C should cover the case of > an unsolicited ND message does not contain source/target LLAO, > AND the receiving node does not have a neighbor cache entry for > the source/target > (there are two conditions for a single 'case') >=20 > Is this now clear and does that match your (our) understanding? =3D> Yes. Except I didn't explicitly include the case where no entry = exists at all. >=20 > Then, let's revisit the change to APPENDIX C in 2461bis-05. My point > of the first message of this thread is that the change does not cover > cases where a neighbor cache entry does not exist when the=20 > unsolicited > message arrives (see the diff I attached to a previous message > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05861.html). >=20 > More specifically, I'd like to see new entries like: >=20 > State Event Action =20 > New state >=20 > - RS, no link-layer - - > address >=20 > ...hmm..., perhaps your intent was that such cases should be covered > new entries like this one: >=20 > INCOMPLETE NS, RS No link-layer - =20 > unchanged > address =3D> Exactly. >=20 > If so, I see your position, but I don't think this is 100% correct, > because the 'non-existent' entry cannot be in any state=20 > (INCOMPLETE in > this case). I believe using '-' for the 'State' field in these cases > should make more sense. =3D> Ok. This can be added.=20 > > =3D> Good points. I agree with that. So to keep it=20 > consistent, I'll remove this distinction > > between host and router.=20 >=20 > Okay, but please clarify my first question, too: >=20 > >> First of all, which part of the main text specifies this=20 > behavior? As > >> far as I can see, the only text that explicitly mentions ICMPv6 > >> destination unreachable error to be sent is in Section=20 > 7.2.2, where > >> the error is sent upon retransmit timeout for NS messages=20 > (which is > >> clearly a different scenario than this one). =3D> This can be added to the text at the beginning of 7.2., which = discusses this issues.=20 Hesham >=20 > Thanks, >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 08 16:17:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkT8X-0005TH-KJ; Thu, 08 Dec 2005 16:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkT8T-0005Rt-RL; Thu, 08 Dec 2005 16:17:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15161; Thu, 8 Dec 2005 16:16:12 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkT8W-0002sq-LM; Thu, 08 Dec 2005 16:17:08 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EkT8S-0004oW-6b; Thu, 08 Dec 2005 16:17:04 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 08 Dec 2005 16:17:04 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Last Call: 'Neighbor Discovery for IP version 6 (IPv6)' to Draft 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 The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'Neighbor Discovery for IP version 6 (IPv6) ' as a Draft 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 2005-12-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-05.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 08 16:17:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkT98-0005do-I6; Thu, 08 Dec 2005 16:17:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkT93-0005cC-B1; Thu, 08 Dec 2005 16:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15267; Thu, 8 Dec 2005 16:16:47 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkT96-0002vt-K0; Thu, 08 Dec 2005 16:17:44 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EkT92-000501-5o; Thu, 08 Dec 2005 16:17:40 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 08 Dec 2005 16:17:40 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Last Call: 'IP Version 6 over PPP' to Draft 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 The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'IP Version 6 over PPP ' as a Draft 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 2005-12-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 09 01:15:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkbXf-0004Q9-Eu; Fri, 09 Dec 2005 01:15:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkbXd-0004NA-PG; Fri, 09 Dec 2005 01:15:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14802; Fri, 9 Dec 2005 01:14:43 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkbXk-0005lQ-On; Fri, 09 Dec 2005 01:15:46 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jB96FIK13513; Fri, 9 Dec 2005 08:15:18 +0200 Date: Fri, 9 Dec 2005 08:15:18 +0200 (EET) From: Pekka Savola To: iesg@ietf.org 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org Subject: Re: Last Call: 'IP Version 6 over PPP' to Draft Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 8 Dec 2005, The IESG wrote: > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt > > Implementation Report can be accessed at > http://www.ietf.org/IESG/implementation.html I see only two implementation reports relating to PPP there, neither of which has anything to do with IPv6. Should it be up there yet? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 09 01:19:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekbbd-000517-Ab; Fri, 09 Dec 2005 01:19:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekbbc-00050q-50; Fri, 09 Dec 2005 01:19:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15137; Fri, 9 Dec 2005 01:18:50 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekbbk-0005tD-Ac; Fri, 09 Dec 2005 01:19:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jB96JYf13573; Fri, 9 Dec 2005 08:19:34 +0200 Date: Fri, 9 Dec 2005 08:19:34 +0200 (EET) From: Pekka Savola To: iesg@ietf.org 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: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: Last Call: 'Neighbor Discovery for IP version 6 (IPv6)' to Draft Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 8 Dec 2005, The IESG wrote: > 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 2005-12-22. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-05.txt > > Implementation Report can be accessed at > http://www.ietf.org/IESG/implementation.html The implementation report (http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt) seems outdated -- it seems to be from about 1997. I doubt any of the implementations listed there are even maintained anymore. The detail level of the implementation and interop report doesn't seem useful enough in deciding whether the full spec has been implemented and tested or not. -- 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 Dec 09 01:42:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkbxF-0005up-7O; Fri, 09 Dec 2005 01:42:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkbxD-0005uU-4m for ipv6@megatron.ietf.org; Fri, 09 Dec 2005 01:42:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18041 for ; Fri, 9 Dec 2005 01:40:59 -0500 (EST) From: Muthukumar_Lakshmanan@McAfee.com Received: from sncsmrelay2.nai.com ([67.97.80.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkbxB-0006k1-EA for ipv6@ietf.org; Fri, 09 Dec 2005 01:42:02 -0500 Received: from sncexwsout1.na.nai.com (sncexwsout1.na.nai.com [161.69.206.120]) by sncsmrelay2.nai.com (Switch-3.1.3/Switch-3.1.0) with SMTP id jB99OZl8011143 for ; Fri, 9 Dec 2005 01:24:35 -0800 Received: from (161.69.5.246) by sncexwsout1.na.nai.com via smtp id 348e_93a6d04c_6882_11da_9836_0002b3e6f1b3; Thu, 08 Dec 2005 23:08:19 -0800 (PST) Received: from banexmb1.corp.nai.org ([161.69.182.237]) by sncexbr1.corp.nai.org with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Dec 2005 22:41:43 -0800 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: Fri, 9 Dec 2005 12:11:39 +0530 Message-ID: Thread-Topic: Fragmented IPv6 packets Thread-Index: AcX8hdzELVT/ttFuSQeWU120tfP+Qw== To: X-OriginalArrivalTime: 09 Dec 2005 06:41:43.0593 (UTC) FILETIME=[9E456990:01C5FC8B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: Fragmented IPv6 packets X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I have a question on IPv6 fragments. Since IPv6 mandates a minimum MTU of 1280, IPv6 fragments (except the last fragment) should be of minimum 1280 bytes right? When an end host receives an IPv6 fragment which is lesser than 1280 bytes ( except the last fragment ) , should it treat it as invalid and drop it or should it still consider the fragment for reassembly. Are there any IPv6 implementations which reassemble them? Thanks, Muthu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 09 01:48:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekc3J-0007gS-IA; Fri, 09 Dec 2005 01:48:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekc3H-0007dn-Ss for ipv6@megatron.ietf.org; Fri, 09 Dec 2005 01:48:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18806 for ; Fri, 9 Dec 2005 01:47:24 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekc3O-0006w1-Fn for ipv6@ietf.org; Fri, 09 Dec 2005 01:48:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Dec 2005 22:52:44 -0800 Message-ID: Thread-Topic: Fragmented IPv6 packets Thread-Index: AcX8hdzELVT/ttFuSQeWU120tfP+QwABxCEQ From: "Vishwas Manral" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Fragmented IPv6 packets X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Muthu, You may want to shift the discussion to the v6ops list instead. Have a look at the draft http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny-fragments-is sues-00.txt in the meanwhile. Thanks, Vishwas -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Muthukumar_Lakshmanan@McAfee.com Sent: Friday, December 09, 2005 12:12 PM To: ipv6@ietf.org Subject: Fragmented IPv6 packets I have a question on IPv6 fragments. Since IPv6 mandates a minimum MTU of 1280, IPv6 fragments (except the last fragment) should be of minimum 1280 bytes right? When an end host receives an IPv6 fragment which is lesser than 1280 bytes ( except the last fragment ) , should it treat it as invalid and drop it or should it still consider the fragment for reassembly. Are there any IPv6 implementations which reassemble them? Thanks, Muthu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 09 12:53:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmRA-0000Xx-P8; Fri, 09 Dec 2005 12:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmR8-0000X2-L3 for ipv6@megatron.ietf.org; Fri, 09 Dec 2005 12:53:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07437 for ; Fri, 9 Dec 2005 12:52:37 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkmRE-0004ba-W3 for ipv6@ietf.org; Fri, 09 Dec 2005 12:53:46 -0500 Received: from impact.jinmei.org (PPP430.air-4x8x.dti.ne.jp [210.170.213.216]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2BA6C1521A for ; Sat, 10 Dec 2005 02:53:14 +0900 (JST) Date: Sat, 10 Dec 2005 02:53:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I believe this was discussed and clarified before, but I could not find any pointer, so let me ask here... It's regarding the "magic number" of 0xFFFE used in the modified EUI-64 format for the interface identifier of an IPv6 address. According to draft-ietf-ipv6-addr-arch-v4-04.txt (or already-published RFCs), we insert 0xFFFE in the middle of the interface identifier in order to convert an 48-bit MAC address to the modified EUI-64 format: [EUI64] defines a method to create a IEEE EUI-64 identifier from an IEEE 48bit MAC identifier. This is to insert two octets, with hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the company_id and vendor supplied id). (in APPENDIX A) However, according to [EUI64], we use 0xFFFF (not 0xFFFE) "to create an EUI-64 identifier from a 48bit MAC identifier" for network devices (i.e., MAC-48): To support encapsulation of EUI-48 and MAC-48 values within small subsets of the EUI-64 values, the first four digits of the manufacturer's extension identifier shall not be FFFF16 or FFFE16. Thus, the 64-bit values of the following form are never-assigned EUI-64 values: ccccccFFFEeeeeee(16) (an EUI-48 extension) ccccccFFFFeeeeee(16) (a MAC-48 extension) <==== this one (from http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) My question is whether there was any special reason why the IPv6 addr-arch document specified 0xFFFE. I googled and found a web page saying this is "an error": Confusingly IPv6 -- one of the most prominent standards that uses EUI-64 -- applies these rules inconsistenly. Due to an error in the appendix to the specification of IPv6 addressing, it is currently standard practice in IPv6 to extend MAC-48 addresses (such as IEEE 802 MAC address) to EUI-64 using 'FF-FE' rather than 'FF-FF'; it remains to be seen how this inconsistency will be resolved in the future. (http://www.kingj.com/articles/MAC_address) Is this true, or was there any particular reason for the "confusing" choice? I appreciate any clarification in advance, 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 Fri Dec 09 13:46:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknGg-0003bx-3U; Fri, 09 Dec 2005 13:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknGd-0003RX-1c for ipv6@megatron.ietf.org; Fri, 09 Dec 2005 13:46:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13749 for ; Fri, 9 Dec 2005 13:45:49 -0500 (EST) Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EknGh-0006fe-SK for ipv6@ietf.org; Fri, 09 Dec 2005 13:46:59 -0500 Received: from bcs-mail4.internal.cacheflow.com (bcs-mail4.internal.cacheflow.com [10.2.2.57]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id jB9IkBNj019457 for ; Fri, 9 Dec 2005 10:46:13 -0800 (PST) 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: Fri, 9 Dec 2005 10:46:07 -0800 Message-ID: <326DB2F7011D9347B156DA019416F3F702FB06E1@bcs-mail4.internal.cacheflow.com> Thread-Topic: Question on draft-ietf-ipv6-rfc2462bis-08.txt Thread-Index: AcX88NDjj64uC0owR1aTJGzUGF/aIw== From: "Li, Qing" To: X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Subject: Question on draft-ietf-ipv6-rfc2462bis-08.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 In Section 5.5.3, how is the 2-hour chosen as the magic number? -- Qing =09 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 09 21:23:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkuOO-0006Td-RX; Fri, 09 Dec 2005 21:23:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkuOK-0006T2-3q for ipv6@megatron.ietf.org; Fri, 09 Dec 2005 21:23:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27350 for ; Fri, 9 Dec 2005 21:22:14 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkuOU-0004Bd-1P for ipv6@ietf.org; Fri, 09 Dec 2005 21:23:27 -0500 Received: from impact.jinmei.org (unknown [2001:200:0:8002:6178:c2e8:a223:1214]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D71AD1525D; Sat, 10 Dec 2005 11:23:01 +0900 (JST) Date: Sat, 10 Dec 2005 11:23:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Li, Qing" In-Reply-To: <326DB2F7011D9347B156DA019416F3F702FB06E1@bcs-mail4.internal.cacheflow.com> References: <326DB2F7011D9347B156DA019416F3F702FB06E1@bcs-mail4.internal.cacheflow.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org Subject: Re: Question on draft-ietf-ipv6-rfc2462bis-08.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 9 Dec 2005 10:46:07 -0800, >>>>> "Li, Qing" said: > In Section 5.5.3, how is the 2-hour chosen as the magic > number? In case you're asking the main editor of this particular draft, I don't know. That 2-hour was alrady in the spec in RFC2462, so the authors of the original RFC may know the reason. 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 Sun Dec 11 00:00:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElJK9-0005K7-Vp; Sun, 11 Dec 2005 00:00:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElJK8-0005IR-AP for ipv6@megatron.ietf.org; Sun, 11 Dec 2005 00:00:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10526 for ; Sat, 10 Dec 2005 23:59:39 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElJKZ-0005Sg-RQ for ipv6@ietf.org; Sun, 11 Dec 2005 00:01:07 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id E8B4979C for ; Sun, 11 Dec 2005 00:00:10 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 11 Dec 2005 00:00:10 -0500 Message-Id: <20051211050010.E8B4979C@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 3 | 13.84% | 15532 | jinmei@isl.rdc.toshiba.co.jp 9.52% | 2 | 14.52% | 16298 | francis.dupont@enst-bretagne.fr 9.52% | 2 | 7.83% | 8787 | vishwas@sinett.com 9.52% | 2 | 6.38% | 7159 | pekkas@netcore.fi 9.52% | 2 | 5.91% | 6633 | iesg-secretary@ietf.org 4.76% | 1 | 9.42% | 10573 | doo090@yahoo.ie 4.76% | 1 | 8.02% | 8997 | marcelo@it.uc3m.es 4.76% | 1 | 5.58% | 6261 | jeroen@unfix.org 4.76% | 1 | 5.54% | 6221 | h.soliman@flarion.com 4.76% | 1 | 5.30% | 5951 | radhakrishnan@zazunetworks.com 4.76% | 1 | 4.60% | 5167 | elwynd@dial.pipex.com 4.76% | 1 | 3.87% | 4348 | sra+ipng@hactrn.net 4.76% | 1 | 3.39% | 3808 | muthukumar_lakshmanan@mcafee.com 4.76% | 1 | 2.96% | 3327 | jean.martin@us.army.mil 4.76% | 1 | 2.83% | 3176 | qing.li@bluecoat.com --------+------+--------+----------+------------------------ 100.00% | 21 |100.00% | 112238 | 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 Dec 12 03:28:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elj2h-0003KR-DC; Mon, 12 Dec 2005 03:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elj2d-0003Jv-TM for ipv6@megatron.ietf.org; Mon, 12 Dec 2005 03:28:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16147 for ; Mon, 12 Dec 2005 03:27:09 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elj3D-0001UQ-DO for ipv6@ietf.org; Mon, 12 Dec 2005 03:28:52 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id jBC8Rsec183090 for ; Mon, 12 Dec 2005 08:27:54 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBC8Rs1M181476 for ; Mon, 12 Dec 2005 09:27:54 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jBC8Rruc010579 for ; Mon, 12 Dec 2005 09:27:53 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jBC8RrGW010569; Mon, 12 Dec 2005 09:27:53 +0100 Received: from zurich.ibm.com (sig-9-145-135-204.de.ibm.com [9.145.135.204]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA17652; Mon, 12 Dec 2005 09:27:47 +0100 Message-ID: <439D347F.50707@zurich.ibm.com> Date: Mon, 12 Dec 2005 09:27:43 +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: ipv6@ietf.org References: <200512070209.jB729dHY077351@givry.rennes.enst-bretagne.fr> In-Reply-To: <200512070209.jB729dHY077351@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-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 A couple of minor comments. 1. I wonder if it would be better to use the shim6 terminology "ULP" (upper layer protocol) instead of "application." At least, I suggest referring to it. 2. In section 3.2, I think you also need to say something about SCTP. I presume that the interaction between 3484bis and SCTP will be quite complex. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Dec 13 03:05:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em5A2-0007Cs-0a; Tue, 13 Dec 2005 03:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em59z-0007B6-RY for ipv6@megatron.ietf.org; Tue, 13 Dec 2005 03:05:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15289 for ; Tue, 13 Dec 2005 03:04:20 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em5As-0005Hu-6N for ipv6@ietf.org; Tue, 13 Dec 2005 03:06:17 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:e579:e289:7d8a:fb6b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A138115263; Tue, 13 Dec 2005 17:04:50 +0900 (JST) Date: Tue, 13 Dec 2005 17:04:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IPv6 WG Subject: Re: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 7 Dec 2005 13:18:28 -0500, >>>>> "Soliman, Hesham" said: >> > => Good points. I agree with that. So to keep it >> consistent, I'll remove this distinction >> > between host and router. >> >> Okay, but please clarify my first question, too: >> >> >> First of all, which part of the main text specifies this >> behavior? As >> >> far as I can see, the only text that explicitly mentions ICMPv6 >> >> destination unreachable error to be sent is in Section >> 7.2.2, where >> >> the error is sent upon retransmit timeout for NS messages >> (which is >> >> clearly a different scenario than this one). > => This can be added to the text at the beginning of 7.2., which discusses this issues. Hmm, so the behavior corresponding to the following entry (shown again just to be accurate) is not currently described in the draft: INCOMPLETE NA, Solicited=any, Send ICMP error unchanged Override=any, No (if router) or Link-layer address log error (if host) then...we should discuss whether this behavior makes sense in the first place. Perhaps you added this entry based on a previous discussion, but I don't remember such consensus. So it would be great if you can provide a pointer to the discussion. In any case, I personally don't think this behavior makes sense. It at least violates a SHOULD requirement of Section 7.2.4 of draft-ietf-ipv6-2461bis-05.txt: If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received ^^^^^^^^^^^^^^^^^^^^^^^ advertisement. [...] Since the state is INCOMPLETE, this node should be doing link-layer address resolution by sending multicast NSs. In this case, the responder MUST include the target link-layer address option per Section 7.2.4: If the solicitation's IP Destination Address is a multicast address, the Target Link-Layer option MUST be included in the advertisement. So, the event of receiving an NS with no link-layer address in this state indicates the responder shows a non-compliant behavior. I believe it makes more sense to discard the bogus packets silently as described in the body of the draft (Section 7.2.4) rather than taking a specific action like sending an ICMPv6 error message. 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 Dec 14 18:48:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmgMW-0001Te-Ad; Wed, 14 Dec 2005 18:48:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmgMS-0001Sq-6s for ipv6@megatron.ietf.org; Wed, 14 Dec 2005 18:48:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14576 for ; Wed, 14 Dec 2005 18:47:33 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmgNb-00073N-Ll for ipv6@ietf.org; Wed, 14 Dec 2005 18:49:52 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id jBENmGeh021308; Wed, 14 Dec 2005 17:48:16 -0600 Received: from [142.133.72.115] (dhcp723-115.rnet.lmc.ericsson.se [142.133.72.115]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Y79M24XT; Wed, 14 Dec 2005 17:48:15 -0600 Message-ID: <43A0AF6C.1020907@ericsson.com> Date: Wed, 14 Dec 2005 18:49:00 -0500 X-Sybari-Trust: ab373321 5f038a5a 1a241f06 00000139 From: Suresh Krishnan User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Jinmei, I was confused by the same inconsistency couple of years ago and a thread resulting from my question failed to clarify the choice. I guess it is something we have to live with. You can look at this thread. http://www.atm.tut.fi/list-archive/ipng/msg10039.html Cheers Suresh JINMEI Tatuya / 神明達哉 wrote: > I believe this was discussed and clarified before, but I could not > find any pointer, so let me ask here... > > It's regarding the "magic number" of 0xFFFE used in the modified > EUI-64 format for the interface identifier of an IPv6 address. > > According to draft-ietf-ipv6-addr-arch-v4-04.txt (or already-published > RFCs), we insert 0xFFFE in the middle of the interface identifier in > order to convert an 48-bit MAC address to the modified EUI-64 format: > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > (between the company_id and vendor supplied id). > (in APPENDIX A) > > However, according to [EUI64], we use 0xFFFF (not 0xFFFE) "to create > an EUI-64 identifier from a 48bit MAC identifier" for network devices > (i.e., MAC-48): > > To support encapsulation of EUI-48 and MAC-48 values within small > subsets of the EUI-64 values, the first four digits of the > manufacturer's extension identifier shall not be FFFF16 or > FFFE16. Thus, the 64-bit values of the following form are > never-assigned EUI-64 values: > > ccccccFFFEeeeeee(16) (an EUI-48 extension) > > ccccccFFFFeeeeee(16) (a MAC-48 extension) <==== this one > (from http://standards.ieee.org/regauth/oui/tutorials/EUI64.html) > > My question is whether there was any special reason why the IPv6 > addr-arch document specified 0xFFFE. > > I googled and found a web page saying this is "an error": > > Confusingly IPv6 -- one of the most prominent standards that uses > EUI-64 -- applies these rules inconsistenly. Due to an error in the > appendix to the specification of IPv6 addressing, it is currently > standard practice in IPv6 to extend MAC-48 addresses (such as IEEE 802 > MAC address) to EUI-64 using 'FF-FE' rather than 'FF-FF'; it remains > to be seen how this inconsistency will be resolved in the future. > (http://www.kingj.com/articles/MAC_address) > > Is this true, or was there any particular reason for the "confusing" > choice? > > I appreciate any clarification in advance, > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 14 19:40:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmhB5-0008AV-0j; Wed, 14 Dec 2005 19:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmhB3-00089u-Kx for ipv6@megatron.ietf.org; Wed, 14 Dec 2005 19:40:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19881 for ; Wed, 14 Dec 2005 19:39:48 -0500 (EST) Received: from mail1.cluenet.de ([195.20.121.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmhCC-0000ZG-24 for ipv6@ietf.org; Wed, 14 Dec 2005 19:42:08 -0500 Received: by mail1.cluenet.de (Postfix, from userid 500) id D6C7F17A51; Thu, 15 Dec 2005 01:40:28 +0100 (CET) Date: Thu, 15 Dec 2005 01:40:28 +0100 From: Daniel Roesen To: ipv6@ietf.org Message-ID: <20051215004028.GA24527@srv01.cluenet.de> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Sat, Dec 10, 2005 at 02:53:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > According to draft-ietf-ipv6-addr-arch-v4-04.txt (or already-published > RFCs), we insert 0xFFFE in the middle of the interface identifier in > order to convert an 48-bit MAC address to the modified EUI-64 format: > > [EUI64] defines a method to create a IEEE EUI-64 identifier from an > IEEE 48bit MAC identifier. This is to insert two octets, with > hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC > (between the company_id and vendor supplied id). > (in APPENDIX A) > > However, according to [EUI64], we use 0xFFFF (not 0xFFFE) "to create > an EUI-64 identifier from a 48bit MAC identifier" for network devices > (i.e., MAC-48): "EUI-64" == "IEEE EUI-64" != "modified EUI-64". The modification is exactly the flipped bit. See 2.5.1: Modified EUI-64 format interface identifiers are formed by inverting the "u" bit (universal/local bit in IEEE EUI-64 terminology) when forming the interface identifier from IEEE EUI-64 identifiers. In the resulting Modified EUI-64 format the "u" bit is set to one (1) to indicate universal scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an IEEE EUI-64 identifier are as follows: and the rationale is right below that: The motivation for inverting the "u" bit when forming an interface identifier is to make it easy for system administrators to hand configure non-global identifiers when hardware tokens are not available. This is expected to be case for serial links, tunnel end- points, etc. The alternative would have been for these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 0:0:0:1, 0:0:0:2, etc. I wonder how well-known the special meaning of the upper 3 bits are to folks who work creativly with the 64 bit host ID space... and the consequences of having them != 000 are. :-) An IPv6 address (not derrived from a globally unique ID like ethernet MAC) with the the upper 3 host bits != 000 and u or g bit set to 1 would be wrong. :-) > I googled and found a web page saying this is "an error": > > Confusingly IPv6 -- one of the most prominent standards that uses > EUI-64 -- applies these rules inconsistenly. Due to an error in the > appendix to the specification of IPv6 addressing, it is currently > standard practice in IPv6 to extend MAC-48 addresses (such as IEEE 802 > MAC address) to EUI-64 using 'FF-FE' rather than 'FF-FF'; it remains > to be seen how this inconsistency will be resolved in the future. > (http://www.kingj.com/articles/MAC_address) > > Is this true, or was there any particular reason for the "confusing" > choice? The only confusion exists in the head of the author of above article. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 14 20:23:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmhqP-0002mN-53; Wed, 14 Dec 2005 20:23:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmhqO-0002m9-25 for ipv6@megatron.ietf.org; Wed, 14 Dec 2005 20:23:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23491 for ; Wed, 14 Dec 2005 20:22:36 -0500 (EST) Received: from mail1.cluenet.de ([195.20.121.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emhrb-00020b-Fw for ipv6@ietf.org; Wed, 14 Dec 2005 20:24:56 -0500 Received: by mail1.cluenet.de (Postfix, from userid 500) id B732F17A40; Thu, 15 Dec 2005 02:23:30 +0100 (CET) Date: Thu, 15 Dec 2005 02:23:30 +0100 From: Daniel Roesen To: ipv6@ietf.org Message-ID: <20051215012330.GB24527@srv01.cluenet.de> Mail-Followup-To: ipv6@ietf.org References: <20051215004028.GA24527@srv01.cluenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051215004028.GA24527@srv01.cluenet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Dec 15, 2005 at 01:40:28AM +0100, Daniel Roesen wrote: > An IPv6 address (not derrived from a globally unique ID like ethernet > MAC) with the the upper 3 host bits != 000 and u or g bit set to 1 > would be wrong. :-) s/upper 3 host bits/upper 3 bits 001 through 111 [except multicast 1111.1111 prefix]/ Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 14 20:36:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emi2n-0006c6-J9; Wed, 14 Dec 2005 20:36:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emi2l-0006bZ-TB for ipv6@megatron.ietf.org; Wed, 14 Dec 2005 20:36:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24531 for ; Wed, 14 Dec 2005 20:35:20 -0500 (EST) Received: from mail1.cluenet.de ([195.20.121.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emi3x-0002Ru-Do for ipv6@ietf.org; Wed, 14 Dec 2005 20:37:41 -0500 Received: by mail1.cluenet.de (Postfix, from userid 500) id 9B44E17A40; Thu, 15 Dec 2005 02:36:16 +0100 (CET) Date: Thu, 15 Dec 2005 02:36:16 +0100 From: Daniel Roesen To: ipv6@ietf.org Message-ID: <20051215013616.GA25136@srv01.cluenet.de> Mail-Followup-To: ipv6@ietf.org References: <20051215004028.GA24527@srv01.cluenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051215004028.GA24527@srv01.cluenet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Dec 15, 2005 at 01:40:28AM +0100, Daniel Roesen wrote: > "EUI-64" == "IEEE EUI-64" != "modified EUI-64". > > The modification is exactly the flipped bit. See 2.5.1: Please ignore my comment completely. I was thinking of the u/g bits, which are NOT relevant to the FF-FF and FF-FE thing, unless I also fail to count bits correctly. Nevertheless, the significance of bits #57 and #58 are not widely known to IPv6 operators out there. > The only confusion exists in the head of the author of above article. No, in my head. Looks like a mistake indeed, given that FF-FF is according to IEEE MAC-48, and FF-FE is EUI-48. Sorry for any confusion. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 14 20:54:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmiK0-000225-Ky; Wed, 14 Dec 2005 20:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmiJx-00020u-00 for ipv6@megatron.ietf.org; Wed, 14 Dec 2005 20:54:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26459 for ; Wed, 14 Dec 2005 20:53:05 -0500 (EST) Received: from mail1.cluenet.de ([195.20.121.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmiL6-00035j-Ok for ipv6@ietf.org; Wed, 14 Dec 2005 20:55:26 -0500 Received: by mail1.cluenet.de (Postfix, from userid 500) id 28A5A17A51; Thu, 15 Dec 2005 02:53:59 +0100 (CET) Date: Thu, 15 Dec 2005 02:53:59 +0100 From: Daniel Roesen To: ipv6@ietf.org Message-ID: <20051215015359.GA25390@srv01.cluenet.de> Mail-Followup-To: ipv6@ietf.org References: <20051215004028.GA24527@srv01.cluenet.de> <20051215013616.GA25136@srv01.cluenet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051215013616.GA25136@srv01.cluenet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Dec 15, 2005 at 02:36:16AM +0100, Daniel Roesen wrote: > Nevertheless, the significance of bits #57 and #58 are not widely > known to IPv6 operators out there. I cannot count. g-bit is bit #56, not #58. My only excuse for this mail flood is that it's almost 3am local time here. :-Z My apologies. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Dec 15 14:21:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmyfG-0007F6-Ef; Thu, 15 Dec 2005 14:21:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmyfA-00076Z-V6 for ipv6@megatron.ietf.org; Thu, 15 Dec 2005 14:21:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20704 for ; Thu, 15 Dec 2005 14:19:44 -0500 (EST) From: sasson_shuki@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmygA-0006TJ-46 for ipv6@ietf.org; Thu, 15 Dec 2005 14:22:15 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id jBFJK16Q012043; Thu, 15 Dec 2005 14:20:17 -0500 (EST) Received: from mercury.eng.emc.com (mercury.eng.emc.com [168.159.100.12]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id jBFJJtlq021075; Thu, 15 Dec 2005 14:19:56 -0500 (EST) Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2656.59) id ; Thu, 15 Dec 2005 14:19:52 -0500 Message-ID: <759A0BEC1CF75A43B72C9E94ACB19BEC01BE2F68@srgriese.eng.emc.com> To: Muthukumar_Lakshmanan@McAfee.com, ipv6@ietf.org Date: Thu, 15 Dec 2005 14:19:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.12.15.20 X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_00+ -3, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: RE: Fragmented IPv6 packets X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The mandate is on the fragmentation is on the transmitting side (the one that applies the fragmentation). The receiving side may reassemble these packets. From at least one implementation (Open BSD) there is no such check. Also the TAHI test doesn't test for this case. All of the above and the common sense says that the receiver should assemble these packets. Hope this helps! Shuki -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Muthukumar_Lakshmanan@McAfee.com Sent: Friday, December 09, 2005 1:42 AM To: ipv6@ietf.org Subject: Fragmented IPv6 packets I have a question on IPv6 fragments. Since IPv6 mandates a minimum MTU of 1280, IPv6 fragments (except the last fragment) should be of minimum 1280 bytes right? When an end host receives an IPv6 fragment which is lesser than 1280 bytes ( except the last fragment ) , should it treat it as invalid and drop it or should it still consider the fragment for reassembly. Are there any IPv6 implementations which reassemble them? Thanks, Muthu -------------------------------------------------------------------- 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 Dec 16 06:43:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnDzw-0007LZ-Jd; Fri, 16 Dec 2005 06:43:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnDzu-0007J9-Vg for ipv6@megatron.ietf.org; Fri, 16 Dec 2005 06:43:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06964 for ; Fri, 16 Dec 2005 06:42:39 -0500 (EST) Received: from relay-pt1.siemens.pt ([194.145.62.201] helo=relay1.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnE1U-00030C-7P for ipv6@ietf.org; Fri, 16 Dec 2005 06:45:18 -0500 Received: from fw-mta2.siemens.pt (fw-mta-pt1.siemens.pt [141.29.156.202]) by relay1.siemens.pt (8.13.1/8.13.1) with ESMTP id jBGBeVaB022768; Fri, 16 Dec 2005 11:40:31 GMT Received: from lisi053a.siemens.pt (lisi053a.siemens.pt [141.29.156.193]) by fw-mta2.siemens.pt (Hvm) with ESMTP id jBGBiQr22511; Fri, 16 Dec 2005 11:44:26 GMT 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, 16 Dec 2005 11:42:46 -0000 Message-ID: <0248B0F35AF7B8418CA72E88AC00BF1F8F2775@lisi053a.siemens.pt> Thread-Topic: Fragmented IPv6 packets Thread-Index: AcYBrhJTj7ahuwAETxOu5fM09Y3cTwAhPIew From: "Nuno Garcia" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Fragmented IPv6 packets X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi there: I believe the issue is not about fragmentation. The minimum Maximum Transmission Unit (MTU) of 1280 stated in RFC 2460 = does not stops IPv6 packets to be smaller that 1280 octets - what it = does say is that any link that is supposed to convey IPv6 packets must = accept packets that are at least as big as 1280 octets - what the RFC = says is that if an IPv6 node has a path MTU smaller that 1280 octets, = then the IPv6 packets must be fragmented/reassembled at a layer bellow = IPv6.=20 Actually, is kind of dumb to have a protocol that defines packets to be = as big as 64K and then mostly uses only 1500 bytes, but that another = story, and btw, this was already true for IPv4... Ethernet issue I = suppose... So, if a given payload is to conveyed over a network whose path MTU is = 1280 (but it can be bigger, as far as I know, there is no upper limit) = the sender fragments the payload and encapsulates it in IPv6 packets = whose size is 1280 octets. This does not mean that the last (or any) = packet cannot be 100 octets long, it only says that an IPv6 node, after = running Path MTU Discovery (RFC1981), must fragment its payloads as to = make the IPv6 packets as big as the discovered MTU. So here are my 2 cents, hope it helps, and I take this occasion to wish = you all a very Happy Season, and a wonderful 2006. Greetings! Nuno Garcia PhD Student=20 SIEMENS S.A. INFORMATION and COMMUNICATIONS * RESEARCH and DEVELOPMENT 1 * RESEARCH=20 Rua Irm=E3os Siemens, 1 Ed. 1, Piso 0 Alfragide 2720-093 Amadora Portugal=20 Phone: +351-21 416 7159 Fax: +351-21 424 2082=20 e-mail: Nuno.MGarcia@siemens.com=20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = sasson_shuki@emc.com Sent: quinta-feira, 15 de Dezembro de 2005 19:20 To: Muthukumar_Lakshmanan@McAfee.com; ipv6@ietf.org Subject: RE: Fragmented IPv6 packets The mandate is on the fragmentation is on the transmitting side (the one = that applies the fragmentation). The receiving side may reassemble these = packets. From at least one implementation (Open BSD) there is no such = check. Also the TAHI test doesn't test for this case. All of the above and the common sense says that the receiver should = assemble these packets. Hope this helps! Shuki -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Muthukumar_Lakshmanan@McAfee.com Sent: Friday, December 09, 2005 1:42 AM To: ipv6@ietf.org Subject: Fragmented IPv6 packets I have a question on IPv6 fragments. Since IPv6 mandates a minimum MTU = of 1280, IPv6 fragments (except the last fragment) should be of minimum = 1280 bytes right? When an end host receives an IPv6 fragment which is = lesser than 1280 bytes ( except the last fragment ) , should it treat it = as invalid and drop it or should it still consider the fragment for = reassembly. Are there any IPv6 implementations which reassemble them? Thanks, Muthu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Dec 16 14:45:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLVt-0004aa-1A; Fri, 16 Dec 2005 14:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLVn-0004YE-S5 for ipv6@megatron.ietf.org; Fri, 16 Dec 2005 14:45:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05628 for ; Fri, 16 Dec 2005 14:44:03 -0500 (EST) Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnLXS-0004KV-KZ for ipv6@ietf.org; Fri, 16 Dec 2005 14:46:47 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EnLVQ-0007P2-6W; Fri, 16 Dec 2005 19:44:40 +0000 Message-ID: <43A3199B.8090903@dial.pipex.com> Date: Fri, 16 Dec 2005 19:46:35 +0000 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nuno Garcia References: <0248B0F35AF7B8418CA72E88AC00BF1F8F2775@lisi053a.siemens.pt> In-Reply-To: <0248B0F35AF7B8418CA72E88AC00BF1F8F2775@lisi053a.siemens.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA05628 Cc: Muthukumar_Lakshmanan@McAfee.com, ipv6@ietf.org, sasson_shuki@emc.com Subject: Re: Fragmented IPv6 packets X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi. Related matters have been discussed in connection with potential=20 security problems mainly on the v6ops list. Some thoughts below... Regards, Elwyn Davies Nuno Garcia wrote: >Hi there: > >I believe the issue is not about fragmentation. > =20 > As RFC2460 stands at the moment, there is no constraint on how a packet=20 that needs to be fragmented should be split up. Clearly the last=20 fragment is generally going to be smaller than the path or link MTU (the=20 full packet is very unlikely to divide up evenly into MTU sized=20 pieces). This is not a problem because there is no minimum size=20 specified for an IPv6 payload (indeed you can send an IPv6 packet with=20 *no* payload). Currently, there is no requirement for the fragments before the last to=20 be any particular size and it is entirely up to the implementation how=20 an oversize packet should be broken up into fragments. This means that=20 at present an implementation has to accept fragments, however small. As was discovered with IPv4, allowing a packet to be divided into very=20 small fragments can be a security problem. Two hazards are that (1)=20 with large numbers of fragments the reconstruction buffers may be=20 overflowed and (2) the first fragment may not contain the information=20 needed by middleboxes that are looking at transport port numbers for=20 traffic classification. [A related problem, which has nothing to do with=20 size of packets, is that RFC2460 does not forbid overlapping fragments. =20 This can be a major security hazard but in practice many implementations=20 will reject overlapping fragments.] In my opinion, it would be desirable to at least recommend that all=20 fragments before the last are (say) 1024 octets or longer in length. =20 This would mean that even with a couple of tunnel headers added the=20 packet would not exceed the smallest possible MTU and so it would not be=20 necessary to mandate Path MTU discovery for fragmented packets. Of=20 course an implementation which does path MTU discovery on a path could=20 send larger fragments if it knows the MTU is larger than 1280 octets. =20 If this was recommended, receivers would be allowed to drop small=20 fragments and avoid the security problems. I have not researched what=20 the fragmentation policies are used by the various implementations=20 (which I ought to do) - this constrains to some extent what can be done=20 for backwards compatibility. >The minimum Maximum Transmission Unit (MTU) of 1280 stated in RFC 2460 d= oes not stops IPv6 packets to be smaller that 1280 octets - what it does = say is that any link that is supposed to convey IPv6 packets must accept = packets that are at least as big as 1280 octets - what the RFC says is th= at if an IPv6 node has a path MTU smaller that 1280 octets, then the IPv6= packets must be fragmented/reassembled at a layer bellow IPv6.=20 > >Actually, is kind of dumb to have a protocol that defines packets to be = as big as 64K and then mostly uses only 1500 bytes, but that another stor= y, and btw, this was already true for IPv4... Ethernet issue I suppose... > =20 > Indeed: Some higher speed versions of Ethernet can use larger frame=20 sizes, but Ethernet doesn't handle fragmentation so it is up to IP (v4=20 and v6) to fit its packets to the Ethenet frame size. In fact if you=20 look at IPv6 the default behaviour is closely fitted to using an=20 Ethernet L2 (things like the MTU and the use of link local multicast for=20 configuration). Other types of L2 just have to conform (or be adapted). >So, if a given payload is to conveyed over a network whose path MTU is 1= 280 (but it can be bigger, as far as I know, there is no upper limit) the= sender fragments the payload and encapsulates it in IPv6 packets whose s= ize is 1280 octets. This does not mean that the last (or any) packet cann= ot be 100 octets long, it only says that an IPv6 node, after running Path= MTU Discovery (RFC1981), must fragment its payloads as to make the IPv6 = packets as big as the discovered MTU. > =20 > As mentioned above, actually '.. make the IPv6 packets no larger than=20 the discovered MTU'. >So here are my 2 cents, hope it helps, and I take this occasion to wish = you all a very Happy Season, and a wonderful 2006. > >Greetings! > >Nuno Garcia >PhD Student=20 >SIEMENS S.A. >INFORMATION and COMMUNICATIONS * RESEARCH and DEVELOPMENT 1 * RESEARCH=20 > >Rua Irm=E3os Siemens, 1 >Ed. 1, Piso 0 >Alfragide >2720-093 Amadora >Portugal=20 > >Phone: +351-21 416 7159 >Fax: +351-21 424 2082=20 >e-mail: Nuno.MGarcia@siemens.com=20 > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = sasson_shuki@emc.com >Sent: quinta-feira, 15 de Dezembro de 2005 19:20 >To: Muthukumar_Lakshmanan@McAfee.com; ipv6@ietf.org >Subject: RE: Fragmented IPv6 packets > >The mandate is on the fragmentation is on the transmitting side (the one= that applies the fragmentation). The receiving side may reassemble these= packets. From at least one implementation (Open BSD) there is no such ch= eck. >Also the TAHI test doesn't test for this case. >All of the above and the common sense says that the receiver should asse= mble these packets. > >Hope this helps! >Shuki > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Muthukumar_Lakshmanan@McAfee.com >Sent: Friday, December 09, 2005 1:42 AM >To: ipv6@ietf.org >Subject: Fragmented IPv6 packets > > >I have a question on IPv6 fragments. Since IPv6 mandates a minimum MTU = of 1280, IPv6 fragments (except the last fragment) should be of minimum = 1280 bytes right? When an end host receives an IPv6 fragment which is les= ser than 1280 bytes ( except the last fragment ) , should it treat it as = invalid and drop it or should it still consider the fragment for reassemb= ly. Are there any IPv6 implementations which reassemble them? > >Thanks, >Muthu > >-------------------------------------------------------------------- >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 >-------------------------------------------------------------------- > =20 > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Dec 17 04:55:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnYmu-00026H-Ho; Sat, 17 Dec 2005 04:55:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnYms-00025H-C3 for ipv6@megatron.ietf.org; Sat, 17 Dec 2005 04:55:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03325 for ; Sat, 17 Dec 2005 04:54:33 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnYoc-0007ma-VF for ipv6@ietf.org; Sat, 17 Dec 2005 04:57:25 -0500 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 jBH9sqY06213 for ; Sat, 17 Dec 2005 10:54:52 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jBH9spHJ038447 for ; Sat, 17 Dec 2005 10:54:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512170954.jBH9spHJ038447@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipv6@ietf.org Date: Sat, 17 Dec 2005 10:54:51 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: two questions about SEND X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I have two questions about SEND: - is an "open source" or not implementation available? - in the RFC 3971 section 6.4.3 Trust Anchor Option page 35, an anchor name of type FQDN is "stored as a string, in the DNS wire format, as specified in RFC 1034" but obviously ^^^^ this name is a dNSName for SubjectAltName, i.e., the example trustanchor.example.com is encoded into 't' 'r' 'u' ... 'e' '.' 'c' 'o' 'm' and not 11 't' 'r' 'u' ... 'e' 3 'c' 'o' 'm' 0 which is the real format used on the wire but is useful only when names are directly given to DNS internal routines. BTW this wire format should be referenced by section 3.1 of RFC 1035 (not 1034), so I think the word "wire" is a typo, isn't it? 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 Sun Dec 18 00:00:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enqez-00056B-U8; Sun, 18 Dec 2005 00:00:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enqex-00055v-Tf for ipv6@megatron.ietf.org; Sun, 18 Dec 2005 00:00:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18676 for ; Sat, 17 Dec 2005 23:59:34 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Enqgt-0006tX-Jz for ipv6@ietf.org; Sun, 18 Dec 2005 00:02:37 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 66235A59 for ; Sun, 18 Dec 2005 00:00:09 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 18 Dec 2005 00:00:09 -0500 Message-Id: <20051218050009.66235A59@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 4 | 26.04% | 16183 | dr@cluenet.de 8.33% | 1 | 16.03% | 9962 | elwynd@dial.pipex.com 8.33% | 1 | 10.77% | 6693 | nuno.mgarcia@siemens.com 8.33% | 1 | 10.08% | 6264 | suresh.krishnan@ericsson.com 8.33% | 1 | 9.43% | 5863 | jinmei@isl.rdc.toshiba.co.jp 8.33% | 1 | 7.72% | 4799 | sasson_shuki@emc.com 8.33% | 1 | 6.91% | 4292 | brc@zurich.ibm.com 8.33% | 1 | 6.62% | 4115 | sra+ipng@hactrn.net 8.33% | 1 | 6.40% | 3978 | francis.dupont@enst-bretagne.fr --------+------+--------+----------+------------------------ 100.00% | 12 |100.00% | 62149 | 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 Dec 18 16:49:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo6Or-0001Eh-Te; Sun, 18 Dec 2005 16:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo6Op-0001EQ-JT for ipv6@megatron.ietf.org; Sun, 18 Dec 2005 16:48:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26896 for ; Sun, 18 Dec 2005 16:47:55 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eo6Qr-0006pV-FM for ipv6@ietf.org; Sun, 18 Dec 2005 16:51:06 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel10.hp.com (Postfix) with ESMTP id A669235DFF for ; Tue, 20 Dec 2005 04:15:16 -0800 (PST) Received: from [127.0.0.1] (mn000777.americas.hpqcorp.net [16.123.196.180]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id DAA16318 for ; Mon, 19 Dec 2005 03:12:53 +0530 (IST) Message-ID: <43A5D92D.1030507@india.hp.com> Date: Sun, 18 Dec 2005 13:48:29 -0800 From: Arun Thulasi User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: IPv6 Multicast filtering rules (version 01): comments sought X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: arunt@india.hp.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 Hello All, The next version (version 01) of IPv6 multicast filtering rules draft has been posted and it is available from http://www.ietf.org/internet-drafts/draft-arunt-ipv6-multicast-filtering-rules-01.txt. It addresses the issues and comments that were offered when version 0 was posted on this working group. The new version adds behavioral description in a SSM environment and also makes a few corrections in the terminologies as was suggested in earlier reviews. Do offer your comments, questions and suggestions on the new version of this draft. Thanks, Arun T -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Dec 19 01:58:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoEyg-0006zV-FY; Mon, 19 Dec 2005 01:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoEye-0006zA-VR for ipv6@megatron.ietf.org; Mon, 19 Dec 2005 01:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25634 for ; Mon, 19 Dec 2005 01:57:29 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoF0m-0007vU-Kj for ipv6@ietf.org; Mon, 19 Dec 2005 02:00:47 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:ddd9:9605:37b6:5576]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4E1F91521A; Mon, 19 Dec 2005 15:58:02 +0900 (JST) Date: Mon, 19 Dec 2005 15:58:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Suresh Krishnan In-Reply-To: <43A0AF6C.1020907@ericsson.com> References: <43A0AF6C.1020907@ericsson.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: why 0xFFFE is used in the modified EUI-64 format X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 14 Dec 2005 18:49:00 -0500, >>>>> Suresh Krishnan said: > I was confused by the same inconsistency couple of years ago and a > thread resulting from my question failed to clarify the choice. I guess > it is something we have to live with. You can look at this thread. > http://www.atm.tut.fi/list-archive/ipng/msg10039.html Thanks for the pointer. I now understand this was indeed discussed before. I agree we should live with the confusing choice as a "de-facto standard" rather than tweaking the specification once again. But...at the risk of causing unnecessary discussion, I wonder whether we can clarify this point in the RFC based on addr-arch-v4 just saying the method shown in appendix A actually is inconsistent with the IEEE standard but the IETF has decided to accept it. I personally think this can be done as a part of final editorial work with RFC editor before publication. What do others 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 Mon Dec 19 14:51:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoR2u-0004CI-T9; Mon, 19 Dec 2005 14:51:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoR2r-0004Ae-KV for ipv6@megatron.ietf.org; Mon, 19 Dec 2005 14:51:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03867 for ; Mon, 19 Dec 2005 14:50:37 -0500 (EST) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EoR56-0002Hq-JA for ipv6@ietf.org; Mon, 19 Dec 2005 14:54:01 -0500 Received: (qmail 8996 invoked by uid 417); 19 Dec 2005 19:51:27 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 19 Dec 2005 19:51:27 -0000 Received: from mehr ([132.70.219.60]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 19 Dec 2005 12:51:26 -0700 Message-ID: <012e01c604d5$37ed94e0$6b01a8c0@mtc.ki.se> From: "Eric Klein" To: ipv6@ietf.org Date: Mon, 19 Dec 2005 21:48:40 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: Trying to track down the ipng@sunroof.eng.sun.com mail archive 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="===============1845315848==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1845315848== Content-Type: multipart/alternative; boundary="----=_NextPart_000_012B_01C604E5.F95ECF80" This is a multi-part message in MIME format. ------=_NextPart_000_012B_01C604E5.F95ECF80 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am trying to track down the original archive of = ipng@sunroof.eng.sun.com that later became = http://atm.tut.fi/list-archive/ipng and then finally became = http://www1.ietf.org/mail-archive/web/ipv6/ in order to do some analysis = for my thesis. Can you tell me if this archive still exists anywhere, and if so how I = could access it. Thanks, Eric Klein, MSc ------=_NextPart_000_012B_01C604E5.F95ECF80 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
 
I am trying to track down the original = archive of=20 ipng@sunroof.eng.sun.com that=20 later became http://atm.tut.fi/list-archive/ipng and then finally became   http://www1.ietf.org/mail-archive/web/ipv6/ in order to do some analysis for my thesis.
 
Can you tell me if this archive still = exists=20 anywhere, and if so how I could access it.
 
Thanks,
Eric Klein, = MSc
 
------=_NextPart_000_012B_01C604E5.F95ECF80-- --===============1845315848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1845315848==-- From ipv6-bounces@ietf.org Mon Dec 19 22:24:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoY6k-0004ej-28; Mon, 19 Dec 2005 22:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoY6h-0004eK-Ie for ipv6@megatron.ietf.org; Mon, 19 Dec 2005 22:24:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29954 for ; Mon, 19 Dec 2005 22:23:03 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoY91-0002IF-Gh for ipv6@ietf.org; Mon, 19 Dec 2005 22:26:32 -0500 Received: from impact.jinmei.org (unknown [2001:200:0:8002:dced:b1df:5637:8594]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1B7601521A; Tue, 20 Dec 2005 12:24:01 +0900 (JST) Date: Tue, 20 Dec 2005 12:24:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Eric Klein" In-Reply-To: <012e01c604d5$37ed94e0$6b01a8c0@mtc.ki.se> References: <012e01c604d5$37ed94e0$6b01a8c0@mtc.ki.se> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: Trying to track down the ipng@sunroof.eng.sun.com mail archive X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 19 Dec 2005 21:48:40 +0200, >>>>> "Eric Klein" said: > I am trying to track down the original archive of ipng@sunroof.eng.sun.com that later became http://atm.tut.fi/list-archive/ipng and then finally became http://www1.ietf.org/mail-archive/web/ipv6/ in order to do some analysis for my thesis. > Can you tell me if this archive still exists anywhere, and if so how I could access it. See ftp://playground.sun.com/pub/ipng/ipng-mail-archive/ 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 Dec 20 10:31:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EojS9-0003cn-4P; Tue, 20 Dec 2005 10:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EojS7-0003cW-1Z for ipv6@megatron.ietf.org; Tue, 20 Dec 2005 10:30:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12548 for ; Tue, 20 Dec 2005 10:29:54 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EojUW-0008FE-Gx for ipv6@ietf.org; Tue, 20 Dec 2005 10:33:30 -0500 Received: from impact.jinmei.org (unknown [2001:200:0:8002:dced:b1df:5637:8594]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 24CCF15263; Wed, 21 Dec 2005 00:30:41 +0900 (JST) Date: Wed, 21 Dec 2005 00:30:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: brian@innovationslab.net User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: T flag for an IPv6 multicast address with permanent group ID X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I'm confused about the T flag for an IPv6 multicast address with a permanent group ID and would like to solicit clarification... According to Section 4.2 of RFC3307: Permanent group IDs are allocated on an Expert Review basis, in the range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant to be used in IPv6 multicast addresses, defined in [UNIMCAST]. (UNIMCAST=RFC3306) I interpret this as the corresponding IPv6 multicast address being based on a unicast network prefix as defined in RFC3306. Thus the P flag of the 4-bit flags field must be 1, and then the T flag must also be 1 as specified in RFC3306: o If P = 1, T MUST be set to 1, otherwise the setting of the T bit is defined in Section 2.7 of [ADDRARCH]. Meanwhile, Section 4.3 of RFC3307 reads: It should be noted that the high-order bit of the Group ID will be the same value as the T flag. Doesn't this contradict the relationship between the T flag and permanent group IDs? In fact, the high-order bit of a permanent group ID is 0 while the T flag must be 1 as I explained above. Or am I missing something? 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 Dec 20 11:34:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EokRz-0004Hx-Po; Tue, 20 Dec 2005 11:34:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EokRx-0004Hh-Uq for ipv6@megatron.ietf.org; Tue, 20 Dec 2005 11:34:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22610 for ; Tue, 20 Dec 2005 11:33:51 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EokUN-0002cu-RB for ipv6@ietf.org; Tue, 20 Dec 2005 11:37:26 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.9815673; Tue, 20 Dec 2005 11:34:08 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Date: Tue, 20 Dec 2005 11:34:09 -0500 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipv6@ietf.org Subject: Re: T flag for an IPv6 multicast address with permanent group ID 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="===============0790891150==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0790891150== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-22943509; protocol="application/pkcs7-signature" --Apple-Mail-2-22943509 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit On Dec 20, 2005, at 10:30, JINMEI Tatuya / 神明達哉 wrote: > I'm confused about the T flag for an IPv6 multicast address with a > permanent group ID and would like to solicit clarification... > > According to Section 4.2 of RFC3307: > > Permanent group IDs are allocated on an Expert Review basis, in the > range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant > to be used in IPv6 multicast addresses, defined in [UNIMCAST]. > (UNIMCAST=RFC3306) > > I interpret this as the corresponding IPv6 multicast address being > based on a unicast network prefix as defined in RFC3306. Thus the P > flag of the 4-bit flags field must be 1, and then the T flag must also > be 1 as specified in RFC3306: > > o If P = 1, T MUST be set to 1, otherwise the setting of the > T > bit is defined in Section 2.7 of [ADDRARCH]. > > Meanwhile, Section 4.3 of RFC3307 reads: > > It > should be noted that the high-order bit of the Group ID will be the > same value as the T flag. > > Doesn't this contradict the relationship between the T flag and > permanent group IDs? In fact, the high-order bit of a permanent group > ID is 0 while the T flag must be 1 as I explained above. > Section 4.3 only deals with multicast addresses allocated dynamically. That is, they are administered locally either by an allocation server (as described in Section 4.3.1) or by an end-host (Section 4.3.2). Are you considering the case where addresses with permanent group IDs are allocated by a server? We didn't consider that scenario. Multicast Addresses created using permanent group IDs (Section 4.2) does not mention the T flag mainly because addresses generated by RFC 3306 are not permanent. Rather, they only have a lifetime equivalent to the lifetime of the embedded prefix. Does that clarify things? Regards, Brian --Apple-Mail-2-22943509 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMjIwMTYzNDEwWjAjBgkqhkiG9w0B CQQxFgQU5ag4nSJ9t1mGuQzzsRVOvDdEXzIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAeduOR1mO5jXFxyWyylkdIWd4GJVNcVoLqNB4P5sANIn09YrpKdErrFFBMKi4QukuoG3l zlSv8pf6a0XAFMPOXXV/TIXtRzBHQm+MwUQPgkyv5ZvFEJKgbW6Vv4FFzyER7pTEm61OrAsiMoHy k2VVPBJ4QMu23SsUpUGgIlKGHUgiEQbq9/0cnOzQLAxu4l/kJcQvqgTPVIq8TgjE5J15INnqpvgI 53YrAE8j/wpKBsZQEnN8RUHbx3eetlL4qUKt4S+cO9VgDQQVZUbla+kagLSte1bvotxFBtBIfHAf /BbmYU6ixnlJIRgnjOn5TLqD6hWySy5fKn1pVZT4eNAYiQAAAAAAAA== --Apple-Mail-2-22943509-- --===============0790891150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0790891150==-- From ipv6-bounces@ietf.org Wed Dec 21 00:24:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EowSM-0000qz-72; Wed, 21 Dec 2005 00:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EowSJ-0000p3-8J for ipv6@megatron.ietf.org; Wed, 21 Dec 2005 00:24:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22989 for ; Wed, 21 Dec 2005 00:22:59 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EowUp-0005aQ-4Q for ipv6@ietf.org; Wed, 21 Dec 2005 00:26:41 -0500 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:dced:b1df:5637:8594]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 06CC81521A; Wed, 21 Dec 2005 14:23:54 +0900 (JST) Date: Wed, 21 Dec 2005 14:23:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: Re: T flag for an IPv6 multicast address with permanent group ID 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 Hello, thanks for the prompt response. >>>>> On Tue, 20 Dec 2005 11:34:09 -0500, >>>>> Brian Haberman said: > Section 4.3 only deals with multicast addresses allocated dynamically. > That is, they are administered locally either by an allocation server > (as described in Section 4.3.1) or by an end-host (Section 4.3.2). Hmm, so the following phrase of Section 4.3 the high-order bit of the Group ID will be the same value as the T flag just means "the high-order bit of the Group ID of a dynamic IPv6 multicast address will be the same value as the T flag of the dynamic IPv6 multicast address". I originally thought this is an 'if-and-only-if' relationship, that is, - if the high-order bit of the Group ID is 1, then the T flag is also 1, and - if the high-order bit of the Group ID is 0, then the T flag is also 0. But I understand that's not the intention of the RFC. (Then I personally wonder whether this really "should be noted", though...) Anyway, I think it's not clear. 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 Dec 21 04:21:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep0A3-0001c5-DW; Wed, 21 Dec 2005 04:21:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep0A1-0001bx-Sh for ipv6@megatron.ietf.org; Wed, 21 Dec 2005 04:21:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13997 for ; Wed, 21 Dec 2005 04:20:20 -0500 (EST) Received: from j069063.ppp.asahi-net.or.jp ([61.213.69.63] helo=z505.arifumi.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep0Cb-0004Jd-8m for ipv6@ietf.org; Wed, 21 Dec 2005 04:24:06 -0500 Received: from unknown (ietf.pflab.ecl.ntt.co.jp [129.60.16.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by z505.arifumi.net (Postfix) with ESMTP id 0EC1EF19F7 for ; Wed, 21 Dec 2005 18:19:57 +0900 (JST) Date: Wed, 21 Dec 2005 18:20:44 +0900 From: Arifumi Matsumoto To: ipv6@ietf.org Message-Id: <20051221182044.09381311.a@arifumi.net> In-Reply-To: <439D347F.50707@zurich.ibm.com> References: <200512070209.jB729dHY077351@givry.rennes.enst-bretagne.fr> <439D347F.50707@zurich.ibm.com> X-Mailer: Sylpheed version 2.1.8 (GTK+ 2.6.10; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-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 Hi all, Firstly, according to a minutes of the last shim6 meeting, http://www3.ietf.org/proceedings/05nov/minutes/shim6.html this issue of revising RFC3484 was passed to AD. I want to know if this proposal was arranged by AD. IMHO, these new functions look very effective and desirable to solve address selection problems. At the same time, however, inserting these rules into RFC3484 seems to involve such a tough modification to protocol stack. I suppose we should separate some already-raised issues about updating RFC3484 from these radical issues. -- Arifumi Matsumoto -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Dec 21 11:31:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6rk-0004Qq-2l; Wed, 21 Dec 2005 11:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6ri-0004Qd-8A for ipv6@megatron.ietf.org; Wed, 21 Dec 2005 11:30:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11258 for ; Wed, 21 Dec 2005 11:29:53 -0500 (EST) Received: from smail2.alcatel.fr ([64.208.49.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep6uL-0004E3-KN for ipv6@ietf.org; Wed, 21 Dec 2005 11:33:43 -0500 Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id jBLGUduR008570; Wed, 21 Dec 2005 17:30:40 +0100 Received: from alcatel.fr (jura [192.200.245.157]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA14555; Wed, 21 Dec 2005 17:30:39 +0100 (MET) Message-ID: <43A9832E.3090709@alcatel.fr> Date: Wed, 21 Dec 2005 17:30:38 +0100 From: =?ISO-8859-1?Q?laurent_cl=E9vy?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200512170954.jBH9spHJ038447@givry.rennes.enst-bretagne.fr> In-Reply-To: <200512170954.jBH9spHJ038447@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smail2.alcatel.fr id jBLGUduR008570 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: two questions about SEND X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, We have in Alcatel a partial implementation of SEND in our labs. By partial, I mean with CGA and RSA options only, and supposed compliant=20 to RFC 3972 and partially 3971. Kind regards, Laurent Cl=E9vy Francis Dupont wrote: >I have two questions about SEND: > - is an "open source" or not implementation available? > - in the RFC 3971 section 6.4.3 Trust Anchor Option page 35, > an anchor name of type FQDN is "stored as a string, in the > DNS wire format, as specified in RFC 1034" but obviously > ^^^^ > this name is a dNSName for SubjectAltName, i.e., the > example trustanchor.example.com is encoded into > 't' 'r' 'u' ... 'e' '.' 'c' 'o' 'm' > and not > 11 't' 'r' 'u' ... 'e' 3 'c' 'o' 'm' 0 > which is the real format used on the wire but is useful only > when names are directly given to DNS internal routines. > BTW this wire format should be referenced by section 3.1 of > RFC 1035 (not 1034), so I think the word "wire" is a typo, > isn't it? > >Francis.Dupont@enst-bretagne.fr > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > =20 > --=20 Alcatel CIT Route de Nozay 91460 Marcoussis Voice +33 (0)1 6963 1834 Fax +33 (0)1 6963 1767 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Dec 25 00:00:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqNzn-0001gR-Mj; Sun, 25 Dec 2005 00:00:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqNzl-0001gI-Fc for ipv6@megatron.ietf.org; Sun, 25 Dec 2005 00:00:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28981 for ; Sat, 24 Dec 2005 23:59:26 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EqO35-0005nB-2Q for ipv6@ietf.org; Sun, 25 Dec 2005 00:04:02 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 85B94A5B for ; Sun, 25 Dec 2005 00:00:11 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 25 Dec 2005 00:00:11 -0500 Message-Id: <20051225050011.85B94A5B@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 40.00% | 4 | 35.15% | 16690 | jinmei@isl.rdc.toshiba.co.jp 10.00% | 1 | 19.20% | 9115 | brian@innovationslab.net 10.00% | 1 | 12.11% | 5749 | ericlklein@softhome.net 10.00% | 1 | 10.06% | 4779 | laurent.clevy@alcatel.fr 10.00% | 1 | 7.91% | 3757 | sra+ipng@hactrn.net 10.00% | 1 | 7.79% | 3699 | arunt@india.hp.com 10.00% | 1 | 7.78% | 3694 | a@arifumi.net --------+------+--------+----------+------------------------ 100.00% | 10 |100.00% | 47483 | 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 Wed Dec 28 10:50:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdZl-0002wa-Kl; Wed, 28 Dec 2005 10:50:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdYz-0002j3-Gr; Wed, 28 Dec 2005 10:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20310; Wed, 28 Dec 2005 10:48:55 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erdd1-0003b3-Et; Wed, 28 Dec 2005 10:54:16 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ErdYw-0004Kf-58; Wed, 28 Dec 2005 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Dec 2005 10:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-optimistic-dad-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 --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 : Optimistic Duplicate Address Detection for IPv6 Author(s) : N. Moore Filename : draft-ietf-ipv6-optimistic-dad-07.txt Pages : 18 Date : 2005-12-28 Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case and to remain interoperable with unmodified hosts and routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-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-optimistic-dad-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-optimistic-dad-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: <2005-12-28102410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-optimistic-dad-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-28102410.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri Dec 30 10:49:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsMVH-0003l0-U0; Fri, 30 Dec 2005 10:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsMVG-0003kl-8F for ipv6@megatron.ietf.org; Fri, 30 Dec 2005 10:49:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04259 for ; Fri, 30 Dec 2005 10:48:01 -0500 (EST) Received: from ns.digi-data.com ([209.94.197.193] helo=odin.digi-data.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsMZi-0006dv-JN for ipv6@ietf.org; Fri, 30 Dec 2005 10:53:51 -0500 Received: from NEO.digi-data.com (mail.digi-data.com [10.1.1.16]) by odin.digi-data.com (Postfix) with ESMTP id 11495104A9 for ; Fri, 30 Dec 2005 11:42:37 -0400 (AST) Received: from [10.1.1.123] ([10.1.1.123]) by NEO.digi-data.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Dec 2005 11:48:55 -0400 Message-ID: <43B5574E.9070300@digi-data.com> Date: Fri, 30 Dec 2005 11:50:38 -0400 From: Robert Honore User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Dec 2005 15:48:55.0839 (UTC) FILETIME=[8A7D52F0:01C60D58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit Subject: Test Mesg. Pls Ignore 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 Mesg sent 2005 Dec 30 11:50 (GMT-4) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jan 01 00:00:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsvKk-0006sr-Q1; Sun, 01 Jan 2006 00:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsvKi-0006sS-DB for ipv6@megatron.ietf.org; Sun, 01 Jan 2006 00:00:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18296 for ; Sat, 31 Dec 2005 23:59:27 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsvPV-0004MO-9U for ipv6@ietf.org; Sun, 01 Jan 2006 00:05:38 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 0FB4C13E for ; Sun, 1 Jan 2006 00:00:13 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 01 Jan 2006 00:00:13 -0500 Message-Id: <20060101050013.0FB4C13E@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 1 | 42.12% | 6391 | internet-drafts@ietf.org 25.00% | 1 | 23.91% | 3628 | sra+ipng@hactrn.net 25.00% | 1 | 20.61% | 3127 | robert@digi-data.com 25.00% | 1 | 13.36% | 2028 | renxiang.yan@alcatel-sbell.com.cn --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 15174 | 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 --------------------------------------------------------------------