From owner-v6ops@ops.ietf.org Wed Mar 01 03:59:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENBU-00013K-1T for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 03:59:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FENBR-0003yn-C1 for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 03:59:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEN7r-000LUS-Gz for v6ops-data@psg.com; Wed, 01 Mar 2006 08:56:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEN7n-000LTk-6E for v6ops@ops.ietf.org; Wed, 01 Mar 2006 08:56:00 +0000 Received: from [169.223.253.24] ([169.223.253.24]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001653626.msg for ; Wed, 01 Mar 2006 09:55:52 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Mar 2006 16:55:41 +0800 Subject: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9DerPKaGezqkBEdqMzAANky3PwA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 169.223.253.24 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 01 Mar 2006 09:55:55 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi all, We have submitted before yesterday a new draft, it seems is still not available at the IETF repository, but meanwhile, the document can be reached at: http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-00.txt Comments welcome ! Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Mar 01 04:06:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENIN-000170-JB for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:06:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FENIL-0004I5-2A for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:06:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENHa-000MCv-Re for v6ops-data@psg.com; Wed, 01 Mar 2006 09:06:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENHX-000MCY-CM for v6ops@ops.ietf.org; Wed, 01 Mar 2006 09:06:03 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k2196Cnn014089 for ; Wed, 1 Mar 2006 09:06:12 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k2195tM22027 for v6ops@ops.ietf.org; Wed, 1 Mar 2006 09:05:55 GMT Date: Wed, 1 Mar 2006 09:05:55 +0000 From: Tim Chown To: "v6ops@ops.ietf.org" Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060301090555.GC20809@login.ecs.soton.ac.uk> Mail-Followup-To: "v6ops@ops.ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Jordi, I think this draft is covered as one section of the Address Assignment Considerations draft that Gunter submitted last week? http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-addcon-00.txt Tim On Wed, Mar 01, 2006 at 04:55:41PM +0800, JORDI PALET MARTINEZ wrote: > Hi all, > > We have submitted before yesterday a new draft, it seems is still not > available at the IETF repository, but meanwhile, the document can be reached > at: > http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-00.txt > > Comments welcome ! > > Regards, > Jordi > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Mar 01 04:30:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENer-0008JY-EC for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:30:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FENeq-0005QT-55 for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:30:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENdr-000NzB-3n for v6ops-data@psg.com; Wed, 01 Mar 2006 09:29:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENdq-000Nyy-8A for v6ops@ops.ietf.org; Wed, 01 Mar 2006 09:29:06 +0000 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.17313521; Wed, 01 Mar 2006 04:28:53 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 04:28:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 04:28:51 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730498139C@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9DerPKaGezqkBEdqMzAANky3PwAABG5aA From: "Durand, Alain" To: , X-OriginalArrivalTime: 01 Mar 2006 09:28:53.0727 (UTC) FILETIME=[8E91E6F0:01C63D12] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Jordi, This draft makes the assumption that all point-to-point links are connecting ISP to Customer. This is obviously not true. - Alain. > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ > Sent: Wednesday, March 01, 2006 3:56 AM > To: v6ops@ops.ietf.org > Subject: Guidelines for Numbering IPv6 Point-to-Point Links=20 > and Easing the Addressing Plans >=20 > Hi all, >=20 > We have submitted before yesterday a new draft, it seems is=20 > still not available at the IETF repository, but meanwhile,=20 > the document can be reached > at: > http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-poin t2point-00.txt >=20 > Comments welcome ! >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be=20 > privileged or confidential. The information is intended to be=20 > for the use of the individual(s) named above. If you are not=20 > the intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information,=20 > including attached files, is prohibited. >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Mar 01 04:32:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENhE-0001K4-N6 for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:32:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FENhD-0005Wk-CH for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:32:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENgj-000OHV-RL for v6ops-data@psg.com; Wed, 01 Mar 2006 09:32:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENgi-000OHC-Rq for v6ops@ops.ietf.org; Wed, 01 Mar 2006 09:32:05 +0000 Received: from [169.223.253.24] ([169.223.253.24]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001653761.msg for ; Wed, 01 Mar 2006 10:31:57 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Mar 2006 17:31:49 +0800 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9EvcKNXet2KkGEdqMzAANky3PwA== In-Reply-To: <20060301090555.GC20809@login.ecs.soton.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 169.223.253.24 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 01 Mar 2006 10:32:02 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hi Tim, Not sure if it is the same, to be honest didn't saw it before. I will take a look. I've prepared this in December, when working with a customer, but didn't wanted to submit it until we had the time to try with different routing protocols, which we did only last week. Regards, Jordi > De: Tim Chown > Responder a: > Fecha: Wed, 1 Mar 2006 09:05:55 +0000 > Para: "v6ops@ops.ietf.org" > Asunto: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans > > Hi Jordi, > > I think this draft is covered as one section of the Address Assignment > Considerations draft that Gunter submitted last week? > > http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-addcon-00.txt > > Tim > > On Wed, Mar 01, 2006 at 04:55:41PM +0800, JORDI PALET MARTINEZ wrote: >> Hi all, >> >> We have submitted before yesterday a new draft, it seems is still not >> available at the IETF repository, but meanwhile, the document can be reached >> at: >> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-00.txt >> >> Comments welcome ! >> >> Regards, >> Jordi >> >> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> > > -- > Tim/::1 > > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Mar 01 04:53:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEO10-0005mS-Sk for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:53:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEO0z-0006FA-FE for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:53:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENzv-000Psm-9t for v6ops-data@psg.com; Wed, 01 Mar 2006 09:51:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENzu-000PsY-8q for v6ops@ops.ietf.org; Wed, 01 Mar 2006 09:51:54 +0000 Received: from [169.223.253.24] ([169.223.253.24]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001653838.msg for ; Wed, 01 Mar 2006 10:51:49 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Mar 2006 17:50:41 +0800 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9DerPKaGezqkBEdqMzAANky3PwAABG5aAAADQJ5w= In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730498139C@PACDCEXCMB01.cable.comcast.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 169.223.253.24 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 01 Mar 2006 10:51:51 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi Alain, May be some text need to be fixed, but the idea behind the document is still correct, and will work the same regardless of being ISP-customer or something different. I will take care about this clarification in a new version. Thanks ! Regards, Jordi > De: "Durand, Alain" > Responder a: > Fecha: Wed, 1 Mar 2006 04:28:51 -0500 > Para: , > Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point Links and Easing > the Addressing Plans > Asunto: RE: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans >=20 > Jordi, >=20 > This draft makes the assumption that all point-to-point links are > connecting > ISP to Customer. >=20 > This is obviously not true. >=20 > - Alain. >=20 >=20 >=20 >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ >> Sent: Wednesday, March 01, 2006 3:56 AM >> To: v6ops@ops.ietf.org >> Subject: Guidelines for Numbering IPv6 Point-to-Point Links >> and Easing the Addressing Plans >>=20 >> Hi all, >>=20 >> We have submitted before yesterday a new draft, it seems is >> still not available at the IETF repository, but meanwhile, >> the document can be reached >> at: >> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-poin > t2point-00.txt >>=20 >> Comments welcome ! >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >>=20 >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be >> for the use of the individual(s) named above. If you are not >> the intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, >> including attached files, is prohibited. >>=20 >>=20 >>=20 >>=20 >>=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Mar 01 04:57:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEO4s-0007Xl-2U for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:57:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEO4q-0006JZ-Qc for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 04:57:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEO44-0000Dm-EY for v6ops-data@psg.com; Wed, 01 Mar 2006 09:56:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEO43-0000DZ-Gi for v6ops@ops.ietf.org; Wed, 01 Mar 2006 09:56:11 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k219uMGI027897 for ; Wed, 1 Mar 2006 09:56:22 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k219u5x23477 for v6ops@ops.ietf.org; Wed, 1 Mar 2006 09:56:05 GMT Date: Wed, 1 Mar 2006 09:56:05 +0000 From: Tim Chown To: "v6ops@ops.ietf.org" Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060301095605.GA23369@login.ecs.soton.ac.uk> Mail-Followup-To: "v6ops@ops.ietf.org" References: <20060301090555.GC20809@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Wed, Mar 01, 2006 at 05:31:49PM +0800, JORDI PALET MARTINEZ wrote: > Hi Tim, > > Not sure if it is the same, to be honest didn't saw it before. I will take a > look. > > I've prepared this in December, when working with a customer, but didn't > wanted to submit it until we had the time to try with different routing > protocols, which we did only last week. The aim of Gunter's draft is to give guidance for one of the most common questions that seems to come up at the moment, i.e. 'OK, I'm deploying IPv6, but what addressing plan should I use and what addressing gotchas are there that I need to avoid?' What we've done in the first draft of that is to create a strawman text for discussion in Dallas. Point to point discussion is one facet of the draft, but there are many others. I've not yet formed an opinion on the idea in your draft, but it seems it could be captured as one part of this bigger 'considerations' draft. Tim From owner-v6ops@ops.ietf.org Wed Mar 01 05:30:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEObi-0004gl-7y for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:30:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEOSM-0007d0-VC for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:21:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEOS5-0002HQ-8l for v6ops-data@psg.com; Wed, 01 Mar 2006 10:21:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,RCVD_IN_WHOIS_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [208.17.35.58] (helo=cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEOS4-0002HC-HN for v6ops@ops.ietf.org; Wed, 01 Mar 2006 10:21:00 +0000 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.17411767; Wed, 01 Mar 2006 05:20:11 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 05:20:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 05:20:38 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730405F189@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9DerPKaGezqkBEdqMzAANky3PwAABG5aAAADQJ5wAAQvZ/g== From: "Durand, Alain" To: , X-OriginalArrivalTime: 01 Mar 2006 10:20:39.0760 (UTC) FILETIME=[C9E8ED00:01C63D19] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 VGhlIHBhcnQgYWJvdXQgcGlja2luZyBhIHdlbGwga25vdyAvNjQgb3V0IGEgdGhlIC80OCBjZXJ0 YWlubHkgd29uJ3Qgd29yayBpbiB0aGUgZ2VuZXJhbCBjYXNlLi4uDQpOZWl0aGVyIHdpbGwgdGhl IGlkZWEgdGhhdCB0aGUgSVNQIGhhcyBJSUQ9MSBhbmQgdGhlIGN1c3RvbWVyIGhhZCBJSUQ9Mi4u Lg0KDQpUaGVyZSB3b24ndCBiZSBtdWNoIGxlZnQgZXhjZXB0IHRoZSByZWNvbW1lbmRhdGlvbiB0 byB1c2UgLzY0Lg0KDQogICAtIEFsYWluLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IG93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZw0KVG86IHY2b3BzQG9wcy5pZXRmLm9y Zw0KU2VudDogV2VkIE1hciAwMSAwNDo1MDo0MSAyMDA2DQpTdWJqZWN0OiBSZTogR3VpZGVsaW5l cyBmb3IgTnVtYmVyaW5nIElQdjYgUG9pbnQtdG8tUG9pbnQgTGlua3MgYW5kIEVhc2luZyB0aGUg QWRkcmVzc2luZyBQbGFucw0KDQpIaSBBbGFpbiwNCg0KTWF5IGJlIHNvbWUgdGV4dCBuZWVkIHRv IGJlIGZpeGVkLCBidXQgdGhlIGlkZWEgYmVoaW5kIHRoZSBkb2N1bWVudCBpcyBzdGlsbA0KY29y cmVjdCwgYW5kIHdpbGwgd29yayB0aGUgc2FtZSByZWdhcmRsZXNzIG9mIGJlaW5nIElTUC1jdXN0 b21lciBvcg0Kc29tZXRoaW5nIGRpZmZlcmVudC4NCg0KSSB3aWxsIHRha2UgY2FyZSBhYm91dCB0 aGlzIGNsYXJpZmljYXRpb24gaW4gYSBuZXcgdmVyc2lvbi4gVGhhbmtzICENCg0KUmVnYXJkcywN CkpvcmRpDQoNCg0KDQoNCj4gRGU6ICJEdXJhbmQsIEFsYWluIiA8QWxhaW5fRHVyYW5kQGNhYmxl LmNvbWNhc3QuY29tPg0KPiBSZXNwb25kZXIgYTogPG93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZz4N Cj4gRmVjaGE6IFdlZCwgMSBNYXIgMjAwNiAwNDoyODo1MSAtMDUwMA0KPiBQYXJhOiA8am9yZGku cGFsZXRAY29uc3VsaW50ZWwuZXM+LCA8djZvcHNAb3BzLmlldGYub3JnPg0KPiBDb252ZXJzYWNp w7NuOiBHdWlkZWxpbmVzIGZvciBOdW1iZXJpbmcgSVB2NiBQb2ludC10by1Qb2ludCBMaW5rcyBh bmQgRWFzaW5nDQo+IHRoZSBBZGRyZXNzaW5nIFBsYW5zDQo+IEFzdW50bzogUkU6IEd1aWRlbGlu ZXMgZm9yIE51bWJlcmluZyBJUHY2IFBvaW50LXRvLVBvaW50IExpbmtzIGFuZCBFYXNpbmcgdGhl DQo+IEFkZHJlc3NpbmcgUGxhbnMNCj4gDQo+IEpvcmRpLA0KPiANCj4gVGhpcyBkcmFmdCBtYWtl cyB0aGUgYXNzdW1wdGlvbiB0aGF0IGFsbCBwb2ludC10by1wb2ludCBsaW5rcyBhcmUNCj4gY29u bmVjdGluZw0KPiBJU1AgdG8gQ3VzdG9tZXIuDQo+IA0KPiBUaGlzIGlzIG9idmlvdXNseSBub3Qg dHJ1ZS4NCj4gDQo+ICAgIC0gQWxhaW4uDQo+IA0KPiANCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogb3duZXItdjZvcHNAb3BzLmlldGYub3JnDQo+PiBbbWFpbHRv Om93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpPUkRJIFBBTEVUIE1BUlRJ TkVaDQo+PiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAxLCAyMDA2IDM6NTYgQU0NCj4+IFRvOiB2 Nm9wc0BvcHMuaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IEd1aWRlbGluZXMgZm9yIE51bWJlcmluZyBJ UHY2IFBvaW50LXRvLVBvaW50IExpbmtzDQo+PiBhbmQgRWFzaW5nIHRoZSBBZGRyZXNzaW5nIFBs YW5zDQo+PiANCj4+IEhpIGFsbCwNCj4+IA0KPj4gV2UgaGF2ZSBzdWJtaXR0ZWQgYmVmb3JlIHll c3RlcmRheSBhIG5ldyBkcmFmdCwgaXQgc2VlbXMgaXMNCj4+IHN0aWxsIG5vdCBhdmFpbGFibGUg YXQgdGhlIElFVEYgcmVwb3NpdG9yeSwgYnV0IG1lYW53aGlsZSwNCj4+IHRoZSBkb2N1bWVudCBj YW4gYmUgcmVhY2hlZA0KPj4gYXQ6DQo+PiBodHRwOi8vd3d3LmNvbnN1bGludGVsLmV1cm82aXgu b3JnL2lldGYvZHJhZnQtcGFsZXQtdjZvcHMtcG9pbg0KPiB0MnBvaW50LTAwLnR4dA0KPj4gDQo+ PiBDb21tZW50cyB3ZWxjb21lICENCj4+IA0KPj4gUmVnYXJkcywNCj4+IEpvcmRpDQo+PiANCj4+ IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+PiBUaGUgSVB2NiBQb3J0YWw6IGh0dHA6Ly93d3cuaXB2NnRmLm9y Zw0KPj4gDQo+PiBCYXJjZWxvbmEgMjAwNSBHbG9iYWwgSVB2NiBTdW1taXQNCj4+IFNsaWRlcyBh dmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vd3d3LmlwdjYtZXMuY29tDQo+PiANCj4+IFRoaXMgZWxl Y3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZQ0KPj4gcHJp dmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBi ZQ0KPj4gZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlv dSBhcmUgbm90DQo+PiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRp c2Nsb3N1cmUsIGNvcHlpbmcsDQo+PiBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLA0KPj4gaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBw cm9oaWJpdGVkLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4gDQoNCg0KDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoZSBJUHY2IFBvcnRhbDog aHR0cDovL3d3dy5pcHY2dGYub3JnDQoNCkJhcmNlbG9uYSAyMDA1IEdsb2JhbCBJUHY2IFN1bW1p dA0KU2xpZGVzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaXB2Ni1lcy5jb20NCg0KVGhpcyBl bGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZp bGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwg Y29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZv cm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9oaWJpdGVkLg0KDQoNCg0K DQo= From owner-v6ops@ops.ietf.org Wed Mar 01 05:31:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEOcS-0004qq-Ty for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:31:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEOcR-00088s-0j for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:31:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEObZ-00039u-A6 for v6ops-data@psg.com; Wed, 01 Mar 2006 10:30:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [84.14.106.33] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEObX-00039e-VA for v6ops@ops.ietf.org; Wed, 01 Mar 2006 10:30:48 +0000 Received: from [222.106.174.241] (unknown [222.106.174.241]) by proxy.6wind.com (Postfix) with ESMTP id A4644525F8F; Wed, 1 Mar 2006 11:30:45 +0100 (CET) Message-ID: <440577CE.7090404@6wind.com> Date: Wed, 01 Mar 2006 11:30:38 +0100 From: Vincent Jardin Organization: http://www.ipv6.6WIND.com/ User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jordi.palet@consulintel.es Cc: v6ops@ops.ietf.org Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans References: <6EEEACD9D7F52940BEE26F5467C02C730498139C@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730498139C@PACDCEXCMB01.cable.comcast.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi, Please, this draft should metion: - the cases when there are only link-local addresses - because it is mainly focus on ISPs cases, it should describe too how it fits with Prefix Delegation: my recommandation would be not to put any addresses ont the point to point interface (there is already link-local addresses which are enough for routing protocols). - there are some drawbacks of putting an IPv6 /64 on the provider side, + because you will create loops if redirection is not properly implemented on point to point interfaces (I mean a good implementation and configuration should never send redirect packets) + because you will loose the support of the anycast address sub-network. It means that the LNS or BAS will answer instead of the CPE. - what's about the support of the anycast address sub-network ? - what's about multi-links to a same site ? For instance, we know some cases where you have 2 point to point links with ECMPv6 for load balancing. Section 4 cannot be applied in that case. FYI and from my experience, for ISPs, it is useless to number the IPv6 links. Only link local is enough. From an implementation point of view, you just need to add a reject (or blackhole) /48 route for each users through each interface. Because you have a same route through many interfaces, you will have the benefit of ECMPv6 support. Maybe, it could be useful (and I do doubt), to number only the IPv6 point to point links that are more used for infrasturcture (GRE, 6in6, L2TP/VPN, etc.). Regards, Vincent >>Hi all, >> >>We have submitted before yesterday a new draft, it seems is >>still not available at the IETF repository, but meanwhile, >>the document can be reached >>at: >>http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-poin >> >> >t2point-00.txt > > >>Comments welcome ! >> >> >> From owner-v6ops@ops.ietf.org Wed Mar 01 05:40:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEObj-0004eh-9f for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:30:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEOQ4-0007TP-76 for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:18:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEON2-0001of-Qw for v6ops-data@psg.com; Wed, 01 Mar 2006 10:15:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEON2-0001oT-2l for v6ops@ops.ietf.org; Wed, 01 Mar 2006 10:15:48 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2006 02:15:47 -0800 X-IronPort-AV: i="4.02,155,1139212800"; d="scan'208"; a="310654405:sNHT32583938" Received: from jdc-xdm1.cisco.com (jdc-xdm1.cisco.com [10.70.237.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k21AFktD028051; Wed, 1 Mar 2006 02:15:47 -0800 (PST) Received: (otroan@localhost) by jdc-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id k21AFkn12552; Wed, 1 Mar 2006 19:15:46 +0900 (JST) X-Authentication-Warning: jdc-xdm1.cisco.com: otroan set sender to ot@cisco.com using -f From: Ole Troan To: jordi.palet@consulintel.es Cc: "v6ops@ops.ietf.org" Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans References: Date: Wed, 01 Mar 2006 19:15:45 +0900 In-Reply-To: (JORDI PALET MARTINEZ's message of "Wed, 01 Mar 2006 16:55:41 +0800") Message-ID: <7t564my4gj2.fsf@jdc-xdm1.cisco.com> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 > We have submitted before yesterday a new draft, it seems is still not > available at the IETF repository, but meanwhile, the document can be reached > at: > http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-00.txt > > Comments welcome ! 3. Numbering Interfaces Often, in point-to-point links, hardware tokens are not available, so frequently they are manually numbered sequentially with most of the bits cleared to zero. This also match the need to keep certain bits (u, g) cleared. This numbering makes as well easier to remember the interfaces, which typically will become numbered as 1 (with 63 point to point links, even though they don't have L2 addresses, do have link-local addresses. I don't know of any implementation which requires you to manually configure these. typically the implementation reuses a link-local from an interface with a L2 address. 4. Routing Aggregation of the Point-to-Point Links Following this approach and assuming that a shorter prefix is typically delegated to a customer, in general a /48 [4], it is possible to simplify the routing aggregation of the point-to-point links. Towards this, the point-to-point link may be numbered using the first /64 of a given /48. using the first (or any) subnet of a larger prefix, breaks the conceptual model of DHCP prefix delegation. the prefix is delegated to the requesting router and cannot be used to number the link between the delegating and requesting router. cheers, Ole From owner-v6ops@ops.ietf.org Wed Mar 01 05:42:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEOnF-00073y-4V for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:42:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEOnD-00008x-OG for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 05:42:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEOmT-0004IB-SH for v6ops-data@psg.com; Wed, 01 Mar 2006 10:42:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.6.95.236] (helo=tcmail22.telekom.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEOmS-0004Hw-NV for v6ops@ops.ietf.org; Wed, 01 Mar 2006 10:42:05 +0000 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 1 Mar 2006 11:42:02 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Mar 2006 11:42:02 +0100 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F3353C8F@S4DE9JSAAIG.ost.t-com.de> From: "Bonness, Olaf" To: ot@cisco.com, jordi.palet@consulintel.es Cc: v6ops@ops.ietf.org Subject: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 11:41:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > 4. Routing Aggregation of the Point-to-Point Links > > Following this approach and assuming that a shorter prefix is > typically delegated to a customer, in general a /48 [4], it is > possible to simplify the routing aggregation of the point-to-point > links. Towards this, the point-to-point link may be numbered using > the first /64 of a given /48. > > using the first (or any) subnet of a larger prefix, breaks the > conceptual model of DHCP prefix delegation. the prefix is delegated to > the requesting router and cannot be used to number the link between > the delegating and requesting router. My assumption from a service provider point of view would be to use a dedicated sub-preaefix (e.g. /48)of my own aggregate to address the point-to-point links (e.g. /64) to the custumers (in the case I have to do this). cu Olaf From owner-v6ops@ops.ietf.org Wed Mar 01 06:03:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEP6q-0002es-1t for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:03:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEP6o-0000g4-PW for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:03:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEP62-000698-IX for v6ops-data@psg.com; Wed, 01 Mar 2006 11:02:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEP61-00068s-Iz for v6ops@ops.ietf.org; Wed, 01 Mar 2006 11:02:17 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k21B2RGm015745 for ; Wed, 1 Mar 2006 11:02:27 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k21B2AE25513 for v6ops@ops.ietf.org; Wed, 1 Mar 2006 11:02:10 GMT Date: Wed, 1 Mar 2006 11:02:10 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060301110210.GF23369@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1E4CCB2441C5C0409AD8A929482A09F3353C8F@S4DE9JSAAIG.ost.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F3353C8F@S4DE9JSAAIG.ost.t-com.de> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: > > > > 4. Routing Aggregation of the Point-to-Point Links > > > > Following this approach and assuming that a shorter prefix is > > typically delegated to a customer, in general a /48 [4], it is > > possible to simplify the routing aggregation of the point-to-point > > links. Towards this, the point-to-point link may be numbered using > > the first /64 of a given /48. > > > > using the first (or any) subnet of a larger prefix, breaks the > > conceptual model of DHCP prefix delegation. the prefix is delegated to > > the requesting router and cannot be used to number the link between > > the delegating and requesting router. > > My assumption from a service provider point of view would be to use a dedicated sub-preaefix (e.g. /48)of my own aggregate to address the point-to-point links (e.g. /64) to the custumers (in the case I have to do this). And if the customer prefix being 'easy' to relate to the point-to-point link address is important (though one assumes this is all tucked away nicely in some db :) you could presumably look at doing something like using the 16 bits assigned for the customer /48 as the 16 bits used to identify the /64 under your carved out /48 for point-to-point links? -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Mar 01 06:22:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEPPn-0001p6-Ie for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:22:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEPPn-0001Yy-9v for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:22:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEPOX-0007iG-R5 for v6ops-data@psg.com; Wed, 01 Mar 2006 11:21:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.6.95.236] (helo=tcmail22.telekom.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEPOW-0007i3-LV for v6ops@ops.ietf.org; Wed, 01 Mar 2006 11:21:25 +0000 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 1 Mar 2006 12:21:23 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Mar 2006 12:21:23 +0100 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F3353C92@S4DE9JSAAIG.ost.t-com.de> From: "Bonness, Olaf" To: tjc@ecs.soton.ac.uk, v6ops@ops.ietf.org Subject: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 12:21:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Yes, this could be one nice approach - but is normally not necessary since the operation and maintenance procedures are mostly automated and db based. Olaf > -----Ursprungliche Nachricht----- > Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im > Auftrag von Tim Chown > Gesendet: Mittwoch, 1. Marz 2006 12:02 > An: v6ops@ops.ietf.org > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and > Easing the Addressing Plans > > > On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: > > > > > > 4. Routing Aggregation of the Point-to-Point Links > > > > > > Following this approach and assuming that a shorter prefix is > > > typically delegated to a customer, in general a /48 [4], it is > > > possible to simplify the routing aggregation of the > point-to-point > > > links. Towards this, the point-to-point link may be > numbered using > > > the first /64 of a given /48. > > > > > > using the first (or any) subnet of a larger prefix, breaks the > > > conceptual model of DHCP prefix delegation. the prefix is > delegated to > > > the requesting router and cannot be used to number the > link between > > > the delegating and requesting router. > > > > My assumption from a service provider point of view would > be to use a dedicated sub-preaefix (e.g. /48)of my own > aggregate to address the point-to-point links (e.g. /64) to > the custumers (in the case I have to do this). > > And if the customer prefix being 'easy' to relate to the > point-to-point > link address is important (though one assumes this is all tucked away > nicely in some db :) you could presumably look at doing something like > using the 16 bits assigned for the customer /48 as the 16 bits used > to identify the /64 under your carved out /48 for > point-to-point links? > > -- > Tim/::1 > > > From owner-v6ops@ops.ietf.org Wed Mar 01 06:32:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEPZV-0007sx-7o for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:32:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEPZT-0001jW-Uw for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:32:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEPYr-0008dv-8T for v6ops-data@psg.com; Wed, 01 Mar 2006 11:32:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEPYq-0008dk-JY for v6ops@ops.ietf.org; Wed, 01 Mar 2006 11:32:04 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k21BVsIV013713; Wed, 1 Mar 2006 11:31:54 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k21BVsCm013712; Wed, 1 Mar 2006 11:31:54 GMT Date: Wed, 1 Mar 2006 11:31:54 +0000 From: bmanning@vacation.karoshi.com To: "Bonness, Olaf" Cc: tjc@ecs.soton.ac.uk, v6ops@ops.ietf.org Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060301113154.GD13404@vacation.karoshi.com.> References: <1E4CCB2441C5C0409AD8A929482A09F3353C92@S4DE9JSAAIG.ost.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F3353C92@S4DE9JSAAIG.ost.t-com.de> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 so, the presumption is that unless you automate the process and put a db behind the assignments, that other processes are superfuluous? not everyone has or wants to have yet another dependency in the loop. (... sorry, can't get routing to work since the db is down... and its behind a router ... er... sorry...) --bill On Wed, Mar 01, 2006 at 12:21:16PM +0100, Bonness, Olaf wrote: > Yes, this could be one nice approach - but is normally not necessary since the operation and maintenance procedures are mostly automated and db based. > > Olaf > > > -----Ursprungliche Nachricht----- > > Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im > > Auftrag von Tim Chown > > Gesendet: Mittwoch, 1. Marz 2006 12:02 > > An: v6ops@ops.ietf.org > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and > > Easing the Addressing Plans > > > > > > On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: > > > > > > > > 4. Routing Aggregation of the Point-to-Point Links > > > > > > > > Following this approach and assuming that a shorter prefix is > > > > typically delegated to a customer, in general a /48 [4], it is > > > > possible to simplify the routing aggregation of the > > point-to-point > > > > links. Towards this, the point-to-point link may be > > numbered using > > > > the first /64 of a given /48. > > > > > > > > using the first (or any) subnet of a larger prefix, breaks the > > > > conceptual model of DHCP prefix delegation. the prefix is > > delegated to > > > > the requesting router and cannot be used to number the > > link between > > > > the delegating and requesting router. > > > > > > My assumption from a service provider point of view would > > be to use a dedicated sub-preaefix (e.g. /48)of my own > > aggregate to address the point-to-point links (e.g. /64) to > > the custumers (in the case I have to do this). > > > > And if the customer prefix being 'easy' to relate to the > > point-to-point > > link address is important (though one assumes this is all tucked away > > nicely in some db :) you could presumably look at doing something like > > using the 16 bits assigned for the customer /48 as the 16 bits used > > to identify the /64 under your carved out /48 for > > point-to-point links? > > > > -- > > Tim/::1 > > > > > > From owner-v6ops@ops.ietf.org Wed Mar 01 06:59:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEPzK-0005ge-Bm for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:59:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEPzI-0002Pw-VU for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 06:59:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEPyH-000Atx-Rf for v6ops-data@psg.com; Wed, 01 Mar 2006 11:58:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.6.95.236] (helo=tcmail22.telekom.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEPyG-000Atj-L1 for v6ops@ops.ietf.org; Wed, 01 Mar 2006 11:58:20 +0000 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 1 Mar 2006 12:58:18 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Mar 2006 12:58:18 +0100 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F3353C94@S4DE9JSAAIG.ost.t-com.de> From: "Bonness, Olaf" To: bmanning@vacation.karoshi.com Cc: tjc@ecs.soton.ac.uk, v6ops@ops.ietf.org Subject: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 12:58:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Sorry, if I was a little bit unclear. My assumption is, that large ISPs/access providers with millions of customers will simply have automated processes (and hence data bases) for their network operation. Otherwise it is not possible to react successful and in time if any errors occure. And this db's bring additional complexity to the process, thats right. (But if you are not able to make your db working than you should not act as ISP :-), or am I wrong at this point?) Of course this is a decission that every ISP has to made by its own ... Olaf > -----Ursprungliche Nachricht----- > Von: bmanning@vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Gesendet: Mittwoch, 1. Marz 2006 12:32 > An: Bonne?, Olaf > Cc: tjc@ecs.soton.ac.uk; v6ops@ops.ietf.org > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and > Easing the Addressing Plans > > > > so, the presumption is that unless you automate the process and > put a db behind the assignments, that other processes are > superfuluous? > not everyone has or wants to have yet another dependency in the loop. > (... sorry, can't get routing to work since the db is down... > and its behind > a router ... er... sorry...) > > --bill > > > On Wed, Mar 01, 2006 at 12:21:16PM +0100, Bonness, Olaf wrote: > > Yes, this could be one nice approach - but is normally not > necessary since the operation and maintenance procedures are > mostly automated and db based. > > > > Olaf > > > > > -----Ursprungliche Nachricht----- > > > Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im > > > Auftrag von Tim Chown > > > Gesendet: Mittwoch, 1. Marz 2006 12:02 > > > An: v6ops@ops.ietf.org > > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point > Links and > > > Easing the Addressing Plans > > > > > > > > > On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: > > > > > > > > > > 4. Routing Aggregation of the Point-to-Point Links > > > > > > > > > > Following this approach and assuming that a > shorter prefix is > > > > > typically delegated to a customer, in general a > /48 [4], it is > > > > > possible to simplify the routing aggregation of the > > > point-to-point > > > > > links. Towards this, the point-to-point link may be > > > numbered using > > > > > the first /64 of a given /48. > > > > > > > > > > using the first (or any) subnet of a larger prefix, breaks the > > > > > conceptual model of DHCP prefix delegation. the prefix is > > > delegated to > > > > > the requesting router and cannot be used to number the > > > link between > > > > > the delegating and requesting router. > > > > > > > > My assumption from a service provider point of view would > > > be to use a dedicated sub-preaefix (e.g. /48)of my own > > > aggregate to address the point-to-point links (e.g. /64) to > > > the custumers (in the case I have to do this). > > > > > > And if the customer prefix being 'easy' to relate to the > > > point-to-point > > > link address is important (though one assumes this is all > tucked away > > > nicely in some db :) you could presumably look at doing > something like > > > using the 16 bits assigned for the customer /48 as the 16 > bits used > > > to identify the /64 under your carved out /48 for > > > point-to-point links? > > > > > > -- > > > Tim/::1 > > > > > > > > > > From owner-v6ops@ops.ietf.org Wed Mar 01 07:12:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQC2-000314-Mg for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 07:12:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEQC2-0002x9-A2 for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 07:12:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEQBU-000C7c-N5 for v6ops-data@psg.com; Wed, 01 Mar 2006 12:12:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEQBU-000C7R-4H for v6ops@ops.ietf.org; Wed, 01 Mar 2006 12:12:00 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k21CBsIV013846; Wed, 1 Mar 2006 12:11:54 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k21CBsi2013845; Wed, 1 Mar 2006 12:11:54 GMT Date: Wed, 1 Mar 2006 12:11:54 +0000 From: bmanning@vacation.karoshi.com To: "Bonness, Olaf" Cc: bmanning@vacation.karoshi.com, tjc@ecs.soton.ac.uk, v6ops@ops.ietf.org Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060301121154.GA13786@vacation.karoshi.com.> References: <1E4CCB2441C5C0409AD8A929482A09F3353C94@S4DE9JSAAIG.ost.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F3353C94@S4DE9JSAAIG.ost.t-com.de> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e ah, i see. existing "mega" ISP/access providers, which emerged primarily from the merger/sale of the many smaller, local ISPs of the 1980/1990 era are: a) given permanent "first mover" advantage in address delegations because of their size, (and requirement to have automated systems in play) over smaller, nimble, startup ISPs who have no such requirement. b) have protocol and operational recommendations formed that bias address assignments and delegation options to those who can't operate without a "working db"... there are whole countries who do not have the capital or expertise to run such back-end systems. i remain sceptical of the presumption of a minimal capability set that involves excessive (for most) support structures. YMMV. --bill On Wed, Mar 01, 2006 at 12:58:09PM +0100, Bonness, Olaf wrote: > Sorry, if I was a little bit unclear. My assumption is, that large ISPs/access providers with millions of customers will simply have automated processes (and hence data bases) for their network operation. Otherwise it is not possible to react successful and in time if any errors occure. > And this db's bring additional complexity to the process, thats right. > (But if you are not able to make your db working than you should not act as ISP :-), or am I wrong at this point?) > > Of course this is a decission that every ISP has to made by its own ... > > Olaf > > > -----Ursprungliche Nachricht----- > > Von: bmanning@vacation.karoshi.com > > [mailto:bmanning@vacation.karoshi.com] > > Gesendet: Mittwoch, 1. Marz 2006 12:32 > > An: Bonne?, Olaf > > Cc: tjc@ecs.soton.ac.uk; v6ops@ops.ietf.org > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and > > Easing the Addressing Plans > > > > > > > > so, the presumption is that unless you automate the process and > > put a db behind the assignments, that other processes are > > superfuluous? > > not everyone has or wants to have yet another dependency in the loop. > > (... sorry, can't get routing to work since the db is down... > > and its behind > > a router ... er... sorry...) > > > > --bill > > > > > > On Wed, Mar 01, 2006 at 12:21:16PM +0100, Bonness, Olaf wrote: > > > Yes, this could be one nice approach - but is normally not > > necessary since the operation and maintenance procedures are > > mostly automated and db based. > > > > > > Olaf > > > > > > > -----Ursprungliche Nachricht----- > > > > Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im > > > > Auftrag von Tim Chown > > > > Gesendet: Mittwoch, 1. Marz 2006 12:02 > > > > An: v6ops@ops.ietf.org > > > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point > > Links and > > > > Easing the Addressing Plans > > > > > > > > > > > > On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: > > > > > > > > > > > > 4. Routing Aggregation of the Point-to-Point Links > > > > > > > > > > > > Following this approach and assuming that a > > shorter prefix is > > > > > > typically delegated to a customer, in general a > > /48 [4], it is > > > > > > possible to simplify the routing aggregation of the > > > > point-to-point > > > > > > links. Towards this, the point-to-point link may be > > > > numbered using > > > > > > the first /64 of a given /48. > > > > > > > > > > > > using the first (or any) subnet of a larger prefix, breaks the > > > > > > conceptual model of DHCP prefix delegation. the prefix is > > > > delegated to > > > > > > the requesting router and cannot be used to number the > > > > link between > > > > > > the delegating and requesting router. > > > > > > > > > > My assumption from a service provider point of view would > > > > be to use a dedicated sub-preaefix (e.g. /48)of my own > > > > aggregate to address the point-to-point links (e.g. /64) to > > > > the custumers (in the case I have to do this). > > > > > > > > And if the customer prefix being 'easy' to relate to the > > > > point-to-point > > > > link address is important (though one assumes this is all > > tucked away > > > > nicely in some db :) you could presumably look at doing > > something like > > > > using the 16 bits assigned for the customer /48 as the 16 > > bits used > > > > to identify the /64 under your carved out /48 for > > > > point-to-point links? > > > > > > > > -- > > > > Tim/::1 > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Wed Mar 01 09:05:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERxO-0001lG-3A for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 09:05:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERxN-0006sB-La for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 09:05:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FERuy-000LWm-Fu for v6ops-data@psg.com; Wed, 01 Mar 2006 14:03:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.6.95.236] (helo=tcmail22.telekom.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FERux-000LWZ-0B for v6ops@ops.ietf.org; Wed, 01 Mar 2006 14:03:03 +0000 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 1 Mar 2006 15:02:47 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Mar 2006 15:02:47 +0100 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F3353C95@S4DE9JSAAIG.ost.t-com.de> From: "Bonness, Olaf" To: bmanning@vacation.karoshi.com Cc: tjc@ecs.soton.ac.uk, v6ops@ops.ietf.org Subject: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 15:02:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb I'm not sure if I understand your problem/behaviour here. I do not argue for or against using db in process automation for operation and maintenance. This is definitely not a topic for the standardization work inside this wg and every ISP should make its choice itself. (My opinion is only that large ISPs will most likely use such instruments - nevertheless it is not a requirement.) Thats all I want to say and please do'not interprete my emails in other directions. Tnx and best regards Olaf > -----Ursprungliche Nachricht----- > Von: bmanning@vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Gesendet: Mittwoch, 1. Marz 2006 13:12 > An: Bonne?, Olaf > Cc: bmanning@vacation.karoshi.com; tjc@ecs.soton.ac.uk; > v6ops@ops.ietf.org > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and > Easing the Addressing Plans > > > ah, i see. existing "mega" ISP/access providers, which > emerged primarily from the > merger/sale of the many smaller, local ISPs of the 1980/1990 era are: > > a) given permanent "first mover" advantage in address > delegations > because of their size, (and requirement to have > automated systems > in play) over smaller, nimble, startup ISPs who have no such > requirement. > b) have protocol and operational recommendations formed > that bias > address assignments and delegation options to those > who can't operate > without a "working db"... > > there are whole countries who do not have the capital or > expertise to run such > back-end systems. i remain sceptical of the presumption of a > minimal capability > set that involves excessive (for most) support structures. YMMV. > > --bill > > > On Wed, Mar 01, 2006 at 12:58:09PM +0100, Bonness, Olaf wrote: > > Sorry, if I was a little bit unclear. My assumption is, > that large ISPs/access providers with millions of customers > will simply have automated processes (and hence data bases) > for their network operation. Otherwise it is not possible to > react successful and in time if any errors occure. > > And this db's bring additional complexity to the process, > thats right. > > (But if you are not able to make your db working than you > should not act as ISP :-), or am I wrong at this point?) > > > > Of course this is a decission that every ISP has to made by > its own ... > > > > Olaf > > > > > -----Ursprungliche Nachricht----- > > > Von: bmanning@vacation.karoshi.com > > > [mailto:bmanning@vacation.karoshi.com] > > > Gesendet: Mittwoch, 1. Marz 2006 12:32 > > > An: Bonne?, Olaf > > > Cc: tjc@ecs.soton.ac.uk; v6ops@ops.ietf.org > > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point > Links and > > > Easing the Addressing Plans > > > > > > > > > > > > so, the presumption is that unless you automate the process and > > > put a db behind the assignments, that other processes are > > > superfuluous? > > > not everyone has or wants to have yet another dependency > in the loop. > > > (... sorry, can't get routing to work since the db is down... > > > and its behind > > > a router ... er... sorry...) > > > > > > --bill > > > > > > > > > On Wed, Mar 01, 2006 at 12:21:16PM +0100, Bonness, Olaf wrote: > > > > Yes, this could be one nice approach - but is normally not > > > necessary since the operation and maintenance procedures are > > > mostly automated and db based. > > > > > > > > Olaf > > > > > > > > > -----Ursprungliche Nachricht----- > > > > > Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im > > > > Auftrag von Tim Chown > > > > Gesendet: Mittwoch, 1. Marz 2006 12:02 > > > > An: v6ops@ops.ietf.org > > > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point > > Links and > > > > Easing the Addressing Plans > > > > > > > > > > > > On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: > > > > > > > > > > > > 4. Routing Aggregation of the Point-to-Point Links > > > > > > > > > > > > Following this approach and assuming that a > > shorter prefix is > > > > > > typically delegated to a customer, in general a > > /48 [4], it is > > > > > > possible to simplify the routing aggregation of the > > > > point-to-point > > > > > > links. Towards this, the point-to-point link may be > > > > numbered using > > > > > > the first /64 of a given /48. > > > > > > > > > > > > using the first (or any) subnet of a larger prefix, breaks the > > > > > > conceptual model of DHCP prefix delegation. the prefix is > > > > delegated to > > > > > > the requesting router and cannot be used to number the > > > > link between > > > > > > the delegating and requesting router. > > > > > > > > > > My assumption from a service provider point of view would > > > > be to use a dedicated sub-preaefix (e.g. /48)of my own > > > > aggregate to address the point-to-point links (e.g. /64) to > > > > the custumers (in the case I have to do this). > > > > > > > > And if the customer prefix being 'easy' to relate to the > > > > point-to-point > > > > link address is important (though one assumes this is all > > tucked away > > > > nicely in some db :) you could presumably look at doing > > something like > > > > using the 16 bits assigned for the customer /48 as the 16 > > bits used > > > > to identify the /64 under your carved out /48 for > > > > point-to-point links? > > > > > > > > -- > > > > Tim/::1 > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Wed Mar 01 15:39:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEY6S-00021e-Sp for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 15:39:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEY6R-0007cn-JY for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 15:39:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEY3o-0003Uc-MQ for v6ops-data@psg.com; Wed, 01 Mar 2006 20:36:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEY3m-0003UL-5z for v6ops@ops.ietf.org; Wed, 01 Mar 2006 20:36:34 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 01 Mar 2006 12:36:33 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k21KaXw1027403; Wed, 1 Mar 2006 12:36:33 -0800 (PST) Received: from [10.242.8.68] (sjc-vpn6-401.cisco.com [10.21.121.145]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k21Kcfuj021178; Wed, 1 Mar 2006 12:38:46 -0800 In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F3353C8F@S4DE9JSAAIG.ost.t-com.de> References: <1E4CCB2441C5C0409AD8A929482A09F3353C8F@S4DE9JSAAIG.ost.t-com.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D1D54F5-EE9E-4DA4-AFD6-59C61590A99F@cisco.com> Cc: ot@cisco.com, jordi.palet@consulintel.es, v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 11:30:09 -0500 To: "Bonness, Olaf" X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1471; t=1141245528; x=1141677728; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20AW=3A=20Guidelines=20for=20Numbering=20IPv6=20Point-to-Point=20L inks=20and=20Easing=20the=20Addressing=20Plans |To:=22Bonness,=20Olaf=22=20; X=v=3Dmtcc.com=3B=20h=3DSd58CcD/5IERcslLdtmafwDHvwo=3D; b=Oqqu7AijYRSzCmVenr1/ADiAA1U8dp8QoV6dA7wWYaZQgGKsk+GID+Ifs2I8DCde7I4gQx0z O8FAMmiYT8rV5OgExKJU4oR0jCeAsd3hGkOukjzs+eL6jbBDi7YiauYU4CMDmuGia0pi6wUxTlO 7Vf1vOqKa1VG5wunSLwbDlN0=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 My assumption as a routing geek is that the only reasonable use of a numbered point to point link is to address an end station; it needs an address to be useful in the network. But any router/router point- to-point interface should be supportable using link-local addresses. A router needs one address reachable by its administration (eg non- link-local), to be a member of any prefix on a LAN that it is serving, and to be able to reach p/p-connected end stations it serves. On Mar 1, 2006, at 5:41 AM, Bonness, Olaf wrote: >> >> 4. Routing Aggregation of the Point-to-Point Links >> >> Following this approach and assuming that a shorter prefix is >> typically delegated to a customer, in general a /48 [4], it is >> possible to simplify the routing aggregation of the point-to-point >> links. Towards this, the point-to-point link may be numbered >> using >> the first /64 of a given /48. >> >> using the first (or any) subnet of a larger prefix, breaks the >> conceptual model of DHCP prefix delegation. the prefix is >> delegated to >> the requesting router and cannot be used to number the link between >> the delegating and requesting router. > > My assumption from a service provider point of view would be to use > a dedicated sub-preaefix (e.g. /48)of my own aggregate to address > the point-to-point links (e.g. /64) to the custumers (in the case > I have to do this). > > cu > Olaf From owner-v6ops@ops.ietf.org Wed Mar 01 16:41:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZ4q-0000Ys-T3 for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 16:41:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEZ4q-0007Oy-Fv for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 16:41:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEZ2r-0008f8-TM for v6ops-data@psg.com; Wed, 01 Mar 2006 21:39:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEZ2p-0008eU-EW for v6ops@ops.ietf.org; Wed, 01 Mar 2006 21:39:39 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2006 13:39:39 -0800 X-IronPort-AV: i="4.02,157,1139212800"; d="scan'208"; a="1781050111:sNHT47603120" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k21Ld51p025033; Wed, 1 Mar 2006 13:39:38 -0800 (PST) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 16:39:31 -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 Subject: RE: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Wed, 1 Mar 2006 16:39:30 -0500 Message-ID: <3D1C81E7AA3CD64FA20B04D269FEF7F4013E6CF5@xmb-rtp-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9cE69Vn+vw+xSTNy3OUqYmVDj9wABtIQA From: "Chip Popoviciu \(cpopovic\)" To: "Fred Baker \(fred\)" , "Bonness, Olaf" Cc: "Ole Troan \(otroan\)" , , X-OriginalArrivalTime: 01 Mar 2006 21:39:31.0247 (UTC) FILETIME=[9FC49BF0:01C63D78] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Along these lines there are two other aspects that are worth considering: 1. A single address with scope larger than link-local would indeed be sufficient for a router as long as the network management policies and tools do not need to reach specific interfaces for troubleshooting purposes for example. 2. In the case of a Service Provider that offers VPN services, an address with a scope larger than link-local is necessary for each VRF for things such as PMTU discovery. In that case, it might be easier to simply assign that address to the PE-CE link rather than create for example a loopback for each VRF.=20 In principle link-locals are sufficient for the PE-CE link however in practice, all little details considered, people might end up assigning more than that to the link. And in that sense, it will be better to use a prefix set aside by the SP for its own infrastructure rather than what is delegated to the customer (as Ole mentioned). Regards, Chip -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker (fred) Sent: Wednesday, March 01, 2006 11:30 AM To: Bonness, Olaf Cc: Ole Troan (otroan); jordi.palet@consulintel.es; v6ops@ops.ietf.org Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans My assumption as a routing geek is that the only reasonable use of a numbered point to point link is to address an end station; it needs an address to be useful in the network. But any router/router point- to-point interface should be supportable using link-local addresses. =20 A router needs one address reachable by its administration (eg non- link-local), to be a member of any prefix on a LAN that it is serving, and to be able to reach p/p-connected end stations it serves. On Mar 1, 2006, at 5:41 AM, Bonness, Olaf wrote: >> >> 4. Routing Aggregation of the Point-to-Point Links >> >> Following this approach and assuming that a shorter prefix is >> typically delegated to a customer, in general a /48 [4], it is >> possible to simplify the routing aggregation of the point-to-point >> links. Towards this, the point-to-point link may be numbered=20 >> using >> the first /64 of a given /48. >> >> using the first (or any) subnet of a larger prefix, breaks the=20 >> conceptual model of DHCP prefix delegation. the prefix is delegated=20 >> to the requesting router and cannot be used to number the link=20 >> between the delegating and requesting router. > > My assumption from a service provider point of view would be to use a=20 > dedicated sub-preaefix (e.g. /48)of my own aggregate to address the=20 > point-to-point links (e.g. /64) to the custumers (in the case I have=20 > to do this). > > cu > Olaf From owner-v6ops@ops.ietf.org Wed Mar 01 20:12:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEcMo-0003GP-Dg for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 20:12:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEcMk-0001Mi-VO for v6ops-archive@lists.ietf.org; Wed, 01 Mar 2006 20:12:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEcJG-000Oyu-Jv for v6ops-data@psg.com; Thu, 02 Mar 2006 01:08:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEcJF-000Oyf-Nf for v6ops@ops.ietf.org; Thu, 02 Mar 2006 01:08:49 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k2218gIV017819; Thu, 2 Mar 2006 01:08:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k2218bMr017818; Thu, 2 Mar 2006 01:08:37 GMT Date: Thu, 2 Mar 2006 01:08:37 +0000 From: bmanning@vacation.karoshi.com To: "Bonness, Olaf" Cc: bmanning@vacation.karoshi.com, tjc@ecs.soton.ac.uk, v6ops@ops.ietf.org Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060302010837.GB17777@vacation.karoshi.com.> References: <1E4CCB2441C5C0409AD8A929482A09F3353C95@S4DE9JSAAIG.ost.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F3353C95@S4DE9JSAAIG.ost.t-com.de> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 On Wed, Mar 01, 2006 at 03:02:39PM +0100, Bonness, Olaf wrote: > I'm not sure if I understand your problem/behaviour here. its ok... i question your assumptions, you clarify them and life is good. my bias is pretty clear. > I do not argue for or against using db in process automation for operation and maintenance. This is definitely not a topic for the standardization work inside this wg and every ISP should make its choice itself. > (My opinion is only that large ISPs will most likely use such instruments - nevertheless it is not a requirement.) > > Thats all I want to say and please do'not interprete my emails in other directions. > Tnx and best regards > Olaf > > > > > -----Ursprungliche Nachricht----- > > Von: bmanning@vacation.karoshi.com > > [mailto:bmanning@vacation.karoshi.com] > > Gesendet: Mittwoch, 1. Marz 2006 13:12 > > An: Bonne?, Olaf > > Cc: bmanning@vacation.karoshi.com; tjc@ecs.soton.ac.uk; > > v6ops@ops.ietf.org > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and > > Easing the Addressing Plans > > > > > > ah, i see. existing "mega" ISP/access providers, which > > emerged primarily from the > > merger/sale of the many smaller, local ISPs of the 1980/1990 era are: > > > > a) given permanent "first mover" advantage in address > > delegations > > because of their size, (and requirement to have > > automated systems > > in play) over smaller, nimble, startup ISPs who have no such > > requirement. > > b) have protocol and operational recommendations formed > > that bias > > address assignments and delegation options to those > > who can't operate > > without a "working db"... > > > > there are whole countries who do not have the capital or > > expertise to run such > > back-end systems. i remain sceptical of the presumption of a > > minimal capability > > set that involves excessive (for most) support structures. YMMV. > > > > --bill > > > > > > On Wed, Mar 01, 2006 at 12:58:09PM +0100, Bonness, Olaf wrote: > > > Sorry, if I was a little bit unclear. My assumption is, > > that large ISPs/access providers with millions of customers > > will simply have automated processes (and hence data bases) > > for their network operation. Otherwise it is not possible to > > react successful and in time if any errors occure. > > > And this db's bring additional complexity to the process, > > thats right. > > > (But if you are not able to make your db working than you > > should not act as ISP :-), or am I wrong at this point?) > > > > > > Of course this is a decission that every ISP has to made by > > its own ... > > > > > > Olaf > > > > > > > -----Ursprungliche Nachricht----- > > > > Von: bmanning@vacation.karoshi.com > > > > [mailto:bmanning@vacation.karoshi.com] > > > > Gesendet: Mittwoch, 1. Marz 2006 12:32 > > > > An: Bonne?, Olaf > > > > Cc: tjc@ecs.soton.ac.uk; v6ops@ops.ietf.org > > > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point > > Links and > > > > Easing the Addressing Plans > > > > > > > > > > > > > > > > so, the presumption is that unless you automate the process and > > > > put a db behind the assignments, that other processes are > > > > superfuluous? > > > > not everyone has or wants to have yet another dependency > > in the loop. > > > > (... sorry, can't get routing to work since the db is down... > > > > and its behind > > > > a router ... er... sorry...) > > > > > > > > --bill > > > > > > > > > > > > On Wed, Mar 01, 2006 at 12:21:16PM +0100, Bonness, Olaf wrote: > > > > > Yes, this could be one nice approach - but is normally not > > > > necessary since the operation and maintenance procedures are > > > > mostly automated and db based. > > > > > > > > > > Olaf > > > > > > > > > > > -----Ursprungliche Nachricht----- > > > > > > Von: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org]Im > > > > > Auftrag von Tim Chown > > > > > Gesendet: Mittwoch, 1. Marz 2006 12:02 > > > > > An: v6ops@ops.ietf.org > > > > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point > > > Links and > > > > > Easing the Addressing Plans > > > > > > > > > > > > > > > On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: > > > > > > > > > > > > > > 4. Routing Aggregation of the Point-to-Point Links > > > > > > > > > > > > > > Following this approach and assuming that a > > > shorter prefix is > > > > > > > typically delegated to a customer, in general a > > > /48 [4], it is > > > > > > > possible to simplify the routing aggregation of the > > > > > point-to-point > > > > > > > links. Towards this, the point-to-point link may be > > > > > numbered using > > > > > > > the first /64 of a given /48. > > > > > > > > > > > > > > using the first (or any) subnet of a larger prefix, breaks the > > > > > > > conceptual model of DHCP prefix delegation. the prefix is > > > > > delegated to > > > > > > > the requesting router and cannot be used to number the > > > > > link between > > > > > > > the delegating and requesting router. > > > > > > > > > > > > My assumption from a service provider point of view would > > > > > be to use a dedicated sub-preaefix (e.g. /48)of my own > > > > > aggregate to address the point-to-point links (e.g. /64) to > > > > > the custumers (in the case I have to do this). > > > > > > > > > > And if the customer prefix being 'easy' to relate to the > > > > > point-to-point > > > > > link address is important (though one assumes this is all > > > tucked away > > > > > nicely in some db :) you could presumably look at doing > > > something like > > > > > using the 16 bits assigned for the customer /48 as the 16 > > > bits used > > > > > to identify the /64 under your carved out /48 for > > > > > point-to-point links? > > > > > > > > > > -- > > > > > Tim/::1 > > > > > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Thu Mar 02 03:56:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEjcH-0001gI-8G for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 03:56:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEjcG-0003aq-Uh for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 03:56:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEjYq-000EyF-Aw for v6ops-data@psg.com; Thu, 02 Mar 2006 08:53:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEjYn-000Exo-2F for v6ops@ops.ietf.org; Thu, 02 Mar 2006 08:53:21 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k228rXSK029139 for ; Thu, 2 Mar 2006 08:53:33 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k228rCn29498 for v6ops@ops.ietf.org; Thu, 2 Mar 2006 08:53:12 GMT Date: Thu, 2 Mar 2006 08:53:12 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060302085311.GC28111@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <3D1C81E7AA3CD64FA20B04D269FEF7F4013E6CF5@xmb-rtp-213.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D1C81E7AA3CD64FA20B04D269FEF7F4013E6CF5@xmb-rtp-213.amer.cisco.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Are there also possibily PIM issues? Would using only link locals cause problems for PIM-SM where the Register messages are sent to the RP from a link-local interface on a CPE acting as the DR? For example, with the Register Stop messages? We ran into this a while ago, but I can't remember the specifics right now :) I agree with Fred; from a management point of view, the less explicit numbering required the better, as that implies the least renumbering at a later date... Tim On Wed, Mar 01, 2006 at 04:39:30PM -0500, Chip Popoviciu (cpopovic) wrote: > > Along these lines there are two other aspects that are worth > considering: > > 1. A single address with scope larger than link-local would indeed be > sufficient for a router as long as the network management policies and > tools do not need to reach specific interfaces for troubleshooting > purposes for example. > > 2. In the case of a Service Provider that offers VPN services, an > address with a scope larger than link-local is necessary for each VRF > for things such as PMTU discovery. In that case, it might be easier to > simply assign that address to the PE-CE link rather than create for > example a loopback for each VRF. > > In principle link-locals are sufficient for the PE-CE link however in > practice, all little details considered, people might end up assigning > more than that to the link. And in that sense, it will be better to use > a prefix set aside by the SP for its own infrastructure rather than what > is delegated to the customer (as Ole mentioned). > > Regards, > Chip > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Fred Baker (fred) > Sent: Wednesday, March 01, 2006 11:30 AM > To: Bonness, Olaf > Cc: Ole Troan (otroan); jordi.palet@consulintel.es; v6ops@ops.ietf.org > Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and > Easing the Addressing Plans > > My assumption as a routing geek is that the only reasonable use of a > numbered point to point link is to address an end station; it needs an > address to be useful in the network. But any router/router point- > to-point interface should be supportable using link-local addresses. > A router needs one address reachable by its administration (eg non- > link-local), to be a member of any prefix on a LAN that it is serving, > and to be able to reach p/p-connected end stations it serves. > > On Mar 1, 2006, at 5:41 AM, Bonness, Olaf wrote: > > >> > >> 4. Routing Aggregation of the Point-to-Point Links > >> > >> Following this approach and assuming that a shorter prefix is > >> typically delegated to a customer, in general a /48 [4], it is > >> possible to simplify the routing aggregation of the point-to-point > >> links. Towards this, the point-to-point link may be numbered > >> using > >> the first /64 of a given /48. > >> > >> using the first (or any) subnet of a larger prefix, breaks the > >> conceptual model of DHCP prefix delegation. the prefix is delegated > >> to the requesting router and cannot be used to number the link > >> between the delegating and requesting router. > > > > My assumption from a service provider point of view would be to use a > > dedicated sub-preaefix (e.g. /48)of my own aggregate to address the > > point-to-point links (e.g. /64) to the custumers (in the case I have > > to do this). > > > > cu > > Olaf > -- Tim/::1 From owner-v6ops@ops.ietf.org Thu Mar 02 12:42:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEroh-000895-Ea for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErof-0008Hs-O4 for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErka-00013K-Ip for v6ops-data@psg.com; Thu, 02 Mar 2006 17:38:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErkZ-000132-Tr for v6ops@ops.ietf.org; Thu, 02 Mar 2006 17:38:04 +0000 Received: from [169.223.253.163] ([169.223.253.163]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658242.msg for ; Thu, 02 Mar 2006 18:37:57 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 01:28:18 +0800 Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY+HrHT8KmmwqoREdqSigANky3PwA== In-Reply-To: <3D1D54F5-EE9E-4DA4-AFD6-59C61590A99F@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 169.223.253.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 02 Mar 2006 18:38:00 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Yes, but then we are creating a kind of non-reachability to the router from outside the network by using only link-local. If I'm an user and I want to address my router from outside my network, this is an easy way. Same for the ISP, if he need to address this router and is outside his network. Regards, Jordi > De: Fred Baker > Responder a: > Fecha: Wed, 1 Mar 2006 11:30:09 -0500 > Para: "Bonness, Olaf" > CC: , , "v6ops@ops.ietf.org" > > Asunto: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing > the Addressing Plans > > My assumption as a routing geek is that the only reasonable use of a > numbered point to point link is to address an end station; it needs > an address to be useful in the network. But any router/router point- > to-point interface should be supportable using link-local addresses. > A router needs one address reachable by its administration (eg non- > link-local), to be a member of any prefix on a LAN that it is > serving, and to be able to reach p/p-connected end stations it serves. > > On Mar 1, 2006, at 5:41 AM, Bonness, Olaf wrote: > >>> >>> 4. Routing Aggregation of the Point-to-Point Links >>> >>> Following this approach and assuming that a shorter prefix is >>> typically delegated to a customer, in general a /48 [4], it is >>> possible to simplify the routing aggregation of the point-to-point >>> links. Towards this, the point-to-point link may be numbered >>> using >>> the first /64 of a given /48. >>> >>> using the first (or any) subnet of a larger prefix, breaks the >>> conceptual model of DHCP prefix delegation. the prefix is >>> delegated to >>> the requesting router and cannot be used to number the link between >>> the delegating and requesting router. >> >> My assumption from a service provider point of view would be to use >> a dedicated sub-preaefix (e.g. /48)of my own aggregate to address >> the point-to-point links (e.g. /64) to the custumers (in the case >> I have to do this). >> >> cu >> Olaf > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 02 12:42:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErop-0008CM-Dt for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEron-0008I0-Pm for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErk9-00011i-7A for v6ops-data@psg.com; Thu, 02 Mar 2006 17:37:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [217.126.187.160] (helo=consulintel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErk7-00011W-Dc for v6ops@ops.ietf.org; Thu, 02 Mar 2006 17:37:36 +0000 Received: from consulintel.es ([213.172.48.142]) by consulintel.com (consulintel.com) (MDaemon.PRO.v8.0.1.R) with ESMTP id md50000010303.msg for ; Thu, 02 Mar 2006 18:37:51 +0100 Received: from [169.223.253.163] ([169.223.253.163]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658235.msg for ; Thu, 02 Mar 2006 18:36:59 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 01:19:13 +0800 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY+HWz6q1ZK6qoQEdqSigANky3PwA== In-Reply-To: <440577CE.7090404@6wind.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 02 Mar 2006 18:37:08 +0100 X-MDRemoteIP: 213.172.48.142 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.com, Thu, 02 Mar 2006 18:37:53 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Hi Vincent, See below, in-line. Regards, Jordi > De: Vincent Jardin > Organizaci=F3n: http://www.ipv6.6WIND.com/ > Responder a: > Fecha: Wed, 01 Mar 2006 11:30:38 +0100 > Para: > CC: "v6ops@ops.ietf.org" > Asunto: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans >=20 > Hi, >=20 > Please, this draft should metion: > - the cases when there are only link-local addresses >=20 > - because it is mainly focus on ISPs cases, it should describe too how > it fits with Prefix Delegation: my recommandation would be not to put > any addresses ont the point to point interface (there is already > link-local addresses which are enough for routing protocols). I disagree regarding using link-local addresses, is very confusing when you do a traceroute and you can even see the same addresses in different customers in different links (if de ISP decides to use a fix IID for each side). This has been also the feedback that we got from different ISPs. >=20 > - there are some drawbacks of putting an IPv6 /64 on the provider side, > + because you will create loops if redirection is not properly > implemented on point to point interfaces (I mean a good implementation > and configuration should never send redirect packets) > + because you will loose the support of the anycast address > sub-network. It means that the LNS or BAS will answer instead of the CPE. >=20 > - what's about the support of the anycast address sub-network ? The /64 is in the customer side, not the provider one, which uses /48. >=20 > - what's about multi-links to a same site ? For instance, we know some > cases where you have 2 point to point links with ECMPv6 for load > balancing. Section 4 cannot be applied in that case. Not sure what do you mean with ECMPv6. I will check it out tomorrow, I'm off line now. >=20 > FYI and from my experience, for ISPs, it is useless to number the IPv6 > links. Only link local is enough. From an implementation point of view, > you just need to add a reject (or blackhole) /48 route for each users > through each interface. Because you have a same route through many > interfaces, you will have the benefit of ECMPv6 support. I think this is what actually I'm proposing then ;-) >=20 > Maybe, it could be useful (and I do doubt), to number only the IPv6 > point to point links that are more used for infrasturcture (GRE, 6in6, > L2TP/VPN, etc.). >=20 > Regards, > Vincent >=20 >>> Hi all, >>>=20 >>> We have submitted before yesterday a new draft, it seems is >>> still not available at the IETF repository, but meanwhile, >>> the document can be reached >>> at: >>> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-poin >>> =20 >>>=20 >> t2point-00.txt >> =20 >>=20 >>> Comments welcome ! >>>=20 >>> =20 >>>=20 >=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 02 12:42:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErow-0008I5-51 for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErov-0008IB-I0 for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErk4-00011Q-7C for v6ops-data@psg.com; Thu, 02 Mar 2006 17:37:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErk2-00011D-Uh for v6ops@ops.ietf.org; Thu, 02 Mar 2006 17:37:31 +0000 Received: from [169.223.253.163] ([169.223.253.163]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658240.msg for ; Thu, 02 Mar 2006 18:37:19 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 01:23:52 +0800 Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY+HhNHUZDGMKoREdqSigANky3PwA== In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F3353C92@S4DE9JSAAIG.ost.t-com.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 169.223.253.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 02 Mar 2006 18:37:20 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 I will much prefer "keep it simple and stupid", no database, if you don't need it for it, no unnecessary calculations of the IID, etc. Regards, Jordi > De: "Bonness, Olaf" > Responder a: > Fecha: Wed, 1 Mar 2006 12:21:16 +0100 > Para: , "v6ops@ops.ietf.org" > Asunto: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans > > Yes, this could be one nice approach - but is normally not necessary since > the operation and maintenance procedures are mostly automated and db based. > > Olaf > >> -----Ursprungliche Nachricht----- >> Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im >> Auftrag von Tim Chown >> Gesendet: Mittwoch, 1. Marz 2006 12:02 >> An: v6ops@ops.ietf.org >> Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and >> Easing the Addressing Plans >> >> >> On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote: >>>> >>>> 4. Routing Aggregation of the Point-to-Point Links >>>> >>>> Following this approach and assuming that a shorter prefix is >>>> typically delegated to a customer, in general a /48 [4], it is >>>> possible to simplify the routing aggregation of the >> point-to-point >>>> links. Towards this, the point-to-point link may be >> numbered using >>>> the first /64 of a given /48. >>>> >>>> using the first (or any) subnet of a larger prefix, breaks the >>>> conceptual model of DHCP prefix delegation. the prefix is >> delegated to >>>> the requesting router and cannot be used to number the >> link between >>>> the delegating and requesting router. >>> >>> My assumption from a service provider point of view would >> be to use a dedicated sub-preaefix (e.g. /48)of my own >> aggregate to address the point-to-point links (e.g. /64) to >> the custumers (in the case I have to do this). >> >> And if the customer prefix being 'easy' to relate to the >> point-to-point >> link address is important (though one assumes this is all tucked away >> nicely in some db :) you could presumably look at doing something like >> using the 16 bits assigned for the customer /48 as the 16 bits used >> to identify the /64 under your carved out /48 for >> point-to-point links? >> >> -- >> Tim/::1 >> >> >> > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 02 12:42:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErp4-0008SW-5y for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErp3-0008IH-OU for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErjj-0000zp-KY for v6ops-data@psg.com; Thu, 02 Mar 2006 17:37:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErjh-0000yi-BU for v6ops@ops.ietf.org; Thu, 02 Mar 2006 17:37:11 +0000 Received: from [169.223.253.163] ([169.223.253.163]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658230.msg for ; Thu, 02 Mar 2006 18:36:59 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 01:10:42 +0800 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9DerPKaGezqkBEdqMzAANky3PwAABG5aAAADQJ5wAAQvZ/gBAnM+s In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730405F189@PACDCEXCMB01.cable.comcast.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 169.223.253.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 02 Mar 2006 18:37:06 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd I'm not sure if you got the idea about the text being a must, which is not the case. I'm proposing a model which has operational advantages, based in real field positive experience and feedback from ISPs. Then you have an example using the 1st /64 and IID=3D1 and IID=3D2, but is only one example, you can choose something different for your case. The example shows the easier way. Regards, Jordi > De: "Durand, Alain" > Responder a: > Fecha: Wed, 1 Mar 2006 05:20:38 -0500 > Para: , > Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point Links and Easing > the Addressing Plans > Asunto: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans >=20 > The part about picking a well know /64 out a the /48 certainly won't work in > the general case... > Neither will the idea that the ISP has IID=3D1 and the customer had IID=3D2... >=20 > There won't be much left except the recommendation to use /64. >=20 > - Alain. >=20 >=20 >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org > To: v6ops@ops.ietf.org > Sent: Wed Mar 01 04:50:41 2006 > Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans >=20 > Hi Alain, >=20 > May be some text need to be fixed, but the idea behind the document is still > correct, and will work the same regardless of being ISP-customer or > something different. >=20 > I will take care about this clarification in a new version. Thanks ! >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >> De: "Durand, Alain" >> Responder a: >> Fecha: Wed, 1 Mar 2006 04:28:51 -0500 >> Para: , >> Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point Links and Easing >> the Addressing Plans >> Asunto: RE: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the >> Addressing Plans >>=20 >> Jordi, >>=20 >> This draft makes the assumption that all point-to-point links are >> connecting >> ISP to Customer. >>=20 >> This is obviously not true. >>=20 >> - Alain. >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: owner-v6ops@ops.ietf.org >>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ >>> Sent: Wednesday, March 01, 2006 3:56 AM >>> To: v6ops@ops.ietf.org >>> Subject: Guidelines for Numbering IPv6 Point-to-Point Links >>> and Easing the Addressing Plans >>>=20 >>> Hi all, >>>=20 >>> We have submitted before yesterday a new draft, it seems is >>> still not available at the IETF repository, but meanwhile, >>> the document can be reached >>> at: >>> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-poin >> t2point-00.txt >>>=20 >>> Comments welcome ! >>>=20 >>> Regards, >>> Jordi >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ********************************************** >>> The IPv6 Portal: http://www.ipv6tf.org >>>=20 >>> Barcelona 2005 Global IPv6 Summit >>> Slides available at: >>> http://www.ipv6-es.com >>>=20 >>> This electronic message contains information which may be >>> privileged or confidential. The information is intended to be >>> for the use of the individual(s) named above. If you are not >>> the intended recipient be aware that any disclosure, copying, >>> distribution or use of the contents of this information, >>> including attached files, is prohibited. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. >=20 >=20 >=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 02 12:42:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErpC-0000M5-2T for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErpB-0008IO-Lw for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErjZ-0000vw-IS for v6ops-data@psg.com; Thu, 02 Mar 2006 17:37:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErjU-0000vY-BZ for v6ops@ops.ietf.org; Thu, 02 Mar 2006 17:37:00 +0000 Received: from [169.223.253.163] ([169.223.253.163]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658228.msg for ; Thu, 02 Mar 2006 18:36:23 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 01:08:10 +0800 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY+G+HNIGhQhKoPEdqSigANky3PwA== In-Reply-To: <7t564my4gj2.fsf@jdc-xdm1.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 169.223.253.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 02 Mar 2006 18:36:54 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hi Ole, See below, in-line. Regards, Jordi > De: Ole Troan > Responder a: > Fecha: Wed, 01 Mar 2006 19:15:45 +0900 > Para: > CC: "v6ops@ops.ietf.org" > Asunto: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans > >> We have submitted before yesterday a new draft, it seems is still not >> available at the IETF repository, but meanwhile, the document can be reached >> at: >> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-00.txt >> >> Comments welcome ! > > 3. Numbering Interfaces > > Often, in point-to-point links, hardware tokens are not available, so > frequently they are manually numbered sequentially with most of the > bits cleared to zero. This also match the need to keep certain bits > (u, g) cleared. This numbering makes as well easier to remember the > interfaces, which typically will become numbered as 1 (with 63 > > point to point links, even though they don't have L2 addresses, do > have link-local addresses. I don't know of any implementation which > requires you to manually configure these. typically the implementation > reuses a link-local from an interface with a L2 address. I believe I taken most of this text from the IPv6 addressing document. Even if that's not correct (meaning that you have always L2 addresses), most of the providers that I worked with, prefer to use something like 1 and 2 for easy numbering the links. > > 4. Routing Aggregation of the Point-to-Point Links > > Following this approach and assuming that a shorter prefix is > typically delegated to a customer, in general a /48 [4], it is > possible to simplify the routing aggregation of the point-to-point > links. Towards this, the point-to-point link may be numbered using > the first /64 of a given /48. > > using the first (or any) subnet of a larger prefix, breaks the > conceptual model of DHCP prefix delegation. the prefix is delegated to > the requesting router and cannot be used to number the link between > the delegating and requesting router. I just re-read the DHCP-PD document, and is not so clear to me that this breaks the model (I mean strictly there is no any text that is against this usage). Also, we have actually tested this, even with Cisco, and it works ;-) If you mean that DHCP-PD concept is to delegate the complete prefix to the requesting router, well, the user owning the CPE will not complain having one less /64, but also is not so clear to me that we are stealing from them a /64 because this is actually used to connect it ;-) > > cheers, > Ole > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 02 12:42:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErpK-0000ZB-75 for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErpJ-0008J6-Ps for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:42:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErl3-00015o-4Y for v6ops-data@psg.com; Thu, 02 Mar 2006 17:38:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErl2-00015X-7G for v6ops@ops.ietf.org; Thu, 02 Mar 2006 17:38:32 +0000 Received: from [169.223.253.163] ([169.223.253.163]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658244.msg for ; Thu, 02 Mar 2006 18:38:27 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 01:31:16 +0800 Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9cE69Vn+vw+xSTNy3OUqYmVDj9wABtIQAACn+x88= In-Reply-To: <3D1C81E7AA3CD64FA20B04D269FEF7F4013E6CF5@xmb-rtp-213.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 169.223.253.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 02 Mar 2006 18:38:29 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 As said, question of taste ... Both a prefix aside, or the same prefix are good choices, and I'm not trying to describe the best practice, but a good one (or alternatively add the aside prefix description and each reader to choose). Regards, Jordi > De: "Chip Popoviciu (cpopovic)" > Responder a: > Fecha: Wed, 1 Mar 2006 16:39:30 -0500 > Para: "Fred Baker (fred)" , "Bonness, Olaf" > > CC: "Ole Troan (otroan)" , , > > Conversaci=F3n: AW: Guidelines for Numbering IPv6 Point-to-Point Links and > Easing the Addressing Plans > Asunto: RE: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing > the Addressing Plans >=20 >=20 > Along these lines there are two other aspects that are worth > considering: >=20 > 1. A single address with scope larger than link-local would indeed be > sufficient for a router as long as the network management policies and > tools do not need to reach specific interfaces for troubleshooting > purposes for example. >=20 > 2. In the case of a Service Provider that offers VPN services, an > address with a scope larger than link-local is necessary for each VRF > for things such as PMTU discovery. In that case, it might be easier to > simply assign that address to the PE-CE link rather than create for > example a loopback for each VRF. >=20 > In principle link-locals are sufficient for the PE-CE link however in > practice, all little details considered, people might end up assigning > more than that to the link. And in that sense, it will be better to use > a prefix set aside by the SP for its own infrastructure rather than what > is delegated to the customer (as Ole mentioned). >=20 > Regards, > Chip >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Fred Baker (fred) > Sent: Wednesday, March 01, 2006 11:30 AM > To: Bonness, Olaf > Cc: Ole Troan (otroan); jordi.palet@consulintel.es; v6ops@ops.ietf.org > Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and > Easing the Addressing Plans >=20 > My assumption as a routing geek is that the only reasonable use of a > numbered point to point link is to address an end station; it needs an > address to be useful in the network. But any router/router point- > to-point interface should be supportable using link-local addresses. > A router needs one address reachable by its administration (eg non- > link-local), to be a member of any prefix on a LAN that it is serving, > and to be able to reach p/p-connected end stations it serves. >=20 > On Mar 1, 2006, at 5:41 AM, Bonness, Olaf wrote: >=20 >>>=20 >>> 4. Routing Aggregation of the Point-to-Point Links >>>=20 >>> Following this approach and assuming that a shorter prefix is >>> typically delegated to a customer, in general a /48 [4], it is >>> possible to simplify the routing aggregation of the point-to-point >>> links. Towards this, the point-to-point link may be numbered >>> using >>> the first /64 of a given /48. >>>=20 >>> using the first (or any) subnet of a larger prefix, breaks the >>> conceptual model of DHCP prefix delegation. the prefix is delegated >>> to the requesting router and cannot be used to number the link >>> between the delegating and requesting router. >>=20 >> My assumption from a service provider point of view would be to use a >> dedicated sub-preaefix (e.g. /48)of my own aggregate to address the >> point-to-point links (e.g. /64) to the custumers (in the case I have >> to do this). >>=20 >> cu >> Olaf >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 02 12:43:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErpR-0000aq-Uq for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:43:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErpR-0008JB-LI for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 12:43:05 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErjz-000117-Ks for v6ops-data@psg.com; Thu, 02 Mar 2006 17:37:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FErjq-00010Y-J4 for v6ops@ops.ietf.org; Thu, 02 Mar 2006 17:37:27 +0000 Received: from [169.223.253.163] ([169.223.253.163]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658237.msg for ; Thu, 02 Mar 2006 18:37:04 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 01:21:10 +0800 Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY+HbK38Sfq4qoQEdqSigANky3PwA== In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F3353C8F@S4DE9JSAAIG.ost.t-com.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 169.223.253.163 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 02 Mar 2006 18:37:08 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi Olaf, I guess is a question of taste, I've seen this opinion from some ISPs, but also the contrary one from many others. Both models are valid. May be the document will be more complete describing both choices, and up to each one to decide which he/she prefers. Regards, Jordi > De: "Bonness, Olaf" > Responder a: > Fecha: Wed, 1 Mar 2006 11:41:59 +0100 > Para: , > CC: "v6ops@ops.ietf.org" > Asunto: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans > >> >> 4. Routing Aggregation of the Point-to-Point Links >> >> Following this approach and assuming that a shorter prefix is >> typically delegated to a customer, in general a /48 [4], it is >> possible to simplify the routing aggregation of the point-to-point >> links. Towards this, the point-to-point link may be numbered using >> the first /64 of a given /48. >> >> using the first (or any) subnet of a larger prefix, breaks the >> conceptual model of DHCP prefix delegation. the prefix is delegated to >> the requesting router and cannot be used to number the link between >> the delegating and requesting router. > > My assumption from a service provider point of view would be to use a > dedicated sub-preaefix (e.g. /48)of my own aggregate to address the > point-to-point links (e.g. /64) to the custumers (in the case I have to do > this). > > cu > Olaf > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 02 19:48:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyTP-0007xB-9t for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 19:48:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyTN-0001Nz-MM for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 19:48:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyQm-000BPV-5r for v6ops-data@psg.com; Fri, 03 Mar 2006 00:46:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [64.233.166.177] (helo=pproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyQl-000BPE-Ak for v6ops@ops.ietf.org; Fri, 03 Mar 2006 00:46:03 +0000 Received: by pproxy.gmail.com with SMTP id m51so150820pye for ; Thu, 02 Mar 2006 16:46:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:content-type; b=AQHAboWyB38enOhrE4EZ5TdFIr/1HGX3c9llXKnq6SjOZgmm/16MARz6I3QmfXADOHGQQGFidJnsYlXkTMIc4vYCycW4x+cr2uQktt5ZL9nkCxe70hRrEo1gHx7NGGvBPiG6w2VNnnZmOORoLpmyfyhBnLlWOmKwVt6p92I/CL0= Received: by 10.35.99.5 with SMTP id b5mr228653pym; Thu, 02 Mar 2006 16:46:02 -0800 (PST) Received: from ?192.168.2.7? ( [218.158.168.164]) by mx.gmail.com with ESMTP id k62sm1223136pyk.2006.03.02.16.46.01; Thu, 02 Mar 2006 16:46:02 -0800 (PST) Message-ID: <440791C5.4020802@gmail.com> Date: Fri, 03 Mar 2006 09:45:57 +0900 From: Myung-Ki Shin Reply-To: myungki.shin@gmail.com Organization: ETRI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: I-D ACTION:draft-shin-v6ops-802-16-deployment-scenarios-00.txt Content-Type: multipart/mixed; boundary="------------050909000300030901090803" Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. --------------050909000300030901090803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, We've posted a new draft - ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks. http://www.ietf.org/internet-drafts/draft-shin-v6ops-802-16-deployment-scenarios-00.txt This draft extends the work of [draft-ietf-v6ops-bb-deployment- scenarios] and re-uses the document layout. As the deployment of wireless broadband access network progresses, users will be connected to IPv6 networks. In this draft we will discuss main components of IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies using tunneling mechanisms and native IPv6. Its goal was to contribute to [draft-ietf-v6ops-bb-deployment- scenarios], but it is too late to add new material. So, authors think that it will be also useful for ISP who wants to adopt 802.16 access technologies, if it is published as a separate document. I would appreciate to hear your comments. Thansk, Myung-Ki, --------------050909000300030901090803 Content-Type: Message/External-body; name="draft-shin-v6ops-802-16-deployment-scenarios-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-shin-v6ops-802-16-deployment-scenarios-00.txt" Content-Type: text/plain Content-ID: <2006-3-2124909.I-D@ietf.org> --------------050909000300030901090803 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/MKSHIN/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/MKSHIN/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------050909000300030901090803-- From owner-v6ops@ops.ietf.org Thu Mar 02 21:54:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF0R5-0007z1-Ck for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 21:54:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF0R1-0006gW-UE for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 21:54:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF0OU-000M2Y-1w for v6ops-data@psg.com; Fri, 03 Mar 2006 02:51:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [208.17.33.58] (helo=pacdcoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF0OT-000M23-4Z for v6ops@ops.ietf.org; Fri, 03 Mar 2006 02:51:49 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Date: Thu, 2 Mar 2006 21:51:12 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7304B06264@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9DerPKaGezqkBEdqMzAANky3PwAABG5aAAADQJ5wAAQvZ/gBAnM+sABQ5PTA= From: "Durand, Alain" To: , X-OriginalArrivalTime: 03 Mar 2006 02:51:18.0085 (UTC) FILETIME=[58534F50:01C63E6D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Jordi, If you write a document saying: here is how we have done things and it = worked, this is all fine and good. If you write a document saying: those = are the IETF recommended guideline, it needs to be subject to more = scrutimy. - Alain.=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ > Sent: Thursday, March 02, 2006 12:11 PM > To: v6ops@ops.ietf.org > Subject: Re: Guidelines for Numbering IPv6 Point-to-Point=20 > Links and Easing the Addressing Plans >=20 > I'm not sure if you got the idea about the text being a must,=20 > which is not the case. I'm proposing a model which has=20 > operational advantages, based in real field positive=20 > experience and feedback from ISPs. Then you have an example=20 > using the 1st /64 and IID=3D1 and IID=3D2, but is only one=20 > example, you can choose something different for your case.=20 > The example shows the easier way. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > > De: "Durand, Alain" Responder a:=20 > > > > Fecha: Wed, 1 Mar 2006 05:20:38 -0500 > > Para: , > > Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point=20 > Links and=20 > > Easing the Addressing Plans > > Asunto: Re: Guidelines for Numbering IPv6 Point-to-Point Links and=20 > > Easing the Addressing Plans > >=20 > > The part about picking a well know /64 out a the /48=20 > certainly won't=20 > > work in the general case... > > Neither will the idea that the ISP has IID=3D1 and the=20 > customer had IID=3D2... > >=20 > > There won't be much left except the recommendation to use /64. > >=20 > > - Alain. > >=20 > >=20 > >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > To: v6ops@ops.ietf.org > > Sent: Wed Mar 01 04:50:41 2006 > > Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and=20 > > Easing the Addressing Plans > >=20 > > Hi Alain, > >=20 > > May be some text need to be fixed, but the idea behind the=20 > document is=20 > > still correct, and will work the same regardless of being=20 > ISP-customer=20 > > or something different. > >=20 > > I will take care about this clarification in a new version. Thanks ! > >=20 > > Regards, > > Jordi > >=20 > >=20 > >=20 > >=20 > >> De: "Durand, Alain" Responder a:=20 > >> > >> Fecha: Wed, 1 Mar 2006 04:28:51 -0500 > >> Para: , > >> Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point=20 > Links and=20 > >> Easing the Addressing Plans > >> Asunto: RE: Guidelines for Numbering IPv6 Point-to-Point Links and=20 > >> Easing the Addressing Plans > >>=20 > >> Jordi, > >>=20 > >> This draft makes the assumption that all point-to-point links are=20 > >> connecting ISP to Customer. > >>=20 > >> This is obviously not true. > >>=20 > >> - Alain. > >>=20 > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: owner-v6ops@ops.ietf.org > >>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI=20 > PALET MARTINEZ > >>> Sent: Wednesday, March 01, 2006 3:56 AM > >>> To: v6ops@ops.ietf.org > >>> Subject: Guidelines for Numbering IPv6 Point-to-Point Links and=20 > >>> Easing the Addressing Plans > >>>=20 > >>> Hi all, > >>>=20 > >>> We have submitted before yesterday a new draft, it seems is still=20 > >>> not available at the IETF repository, but meanwhile, the document=20 > >>> can be reached > >>> at: > >>> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-poin > >> t2point-00.txt > >>>=20 > >>> Comments welcome ! > >>>=20 > >>> Regards, > >>> Jordi > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> ********************************************** > >>> The IPv6 Portal: http://www.ipv6tf.org > >>>=20 > >>> Barcelona 2005 Global IPv6 Summit > >>> Slides available at: > >>> http://www.ipv6-es.com > >>>=20 > >>> This electronic message contains information which may be=20 > privileged=20 > >>> or confidential. The information is intended to be for the use of=20 > >>> the individual(s) named above. If you are not the=20 > intended recipient=20 > >>> be aware that any disclosure, copying, distribution or use of the=20 > >>> contents of this information, including attached files, is=20 > >>> prohibited. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>=20 > >=20 > >=20 > >=20 > >=20 > > ********************************************** > > The IPv6 Portal: http://www.ipv6tf.org > >=20 > > Barcelona 2005 Global IPv6 Summit > > Slides available at: > > http://www.ipv6-es.com > >=20 > > This electronic message contains information which may be=20 > privileged=20 > > or confidential. The information is intended to be for the=20 > use of the > > individual(s) named above. If you are not the intended recipient be=20 > > aware that any disclosure, copying, distribution or use of the=20 > > contents of this information, including attached files, is=20 > prohibited. > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be=20 > privileged or confidential. The information is intended to be=20 > for the use of the individual(s) named above. If you are not=20 > the intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information,=20 > including attached files, is prohibited. >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Mar 02 22:20:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF0qc-0005q9-JT for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 22:20:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF0qa-0007ho-K8 for v6ops-archive@lists.ietf.org; Thu, 02 Mar 2006 22:20:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF0pt-000Ogu-8w for v6ops-data@psg.com; Fri, 03 Mar 2006 03:20:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF0pp-000Odg-JS for v6ops@ops.ietf.org; Fri, 03 Mar 2006 03:20:06 +0000 Received: from [169.223.253.24] ([169.223.253.24]) by consulintel.es (consulintel.es) (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001658947.msg for ; Fri, 03 Mar 2006 04:20:00 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 03 Mar 2006 11:19:51 +0800 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcY9DerPKaGezqkBEdqMzAANky3PwAABG5aAAADQJ5wAAQvZ/gBAnM+sABQ5PTAAAQz9YQ== In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7304B06264@PACDCEXCMB01.cable.comcast.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 169.223.253.24 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Fri, 03 Mar 2006 04:20:03 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Hi Alain, From my reading of the document I'm not saying at all that this are THE IETF guidelines, just guidelines, with is fair to say I think, especially when there is an example that say "may". Regards, Jordi > De: "Durand, Alain" > Responder a: > Fecha: Thu, 2 Mar 2006 21:51:12 -0500 > Para: , > Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point Links and Easing > the Addressing Plans > Asunto: RE: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans >=20 > Jordi, >=20 > If you write a document saying: here is how we have done things and it worked, > this is all fine and good. If you write a document saying: those are the IETF > recommended guideline, it needs to be subject to more scrutimy. >=20 > - Alain.=20 >=20 >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ >> Sent: Thursday, March 02, 2006 12:11 PM >> To: v6ops@ops.ietf.org >> Subject: Re: Guidelines for Numbering IPv6 Point-to-Point >> Links and Easing the Addressing Plans >>=20 >> I'm not sure if you got the idea about the text being a must, >> which is not the case. I'm proposing a model which has >> operational advantages, based in real field positive >> experience and feedback from ISPs. Then you have an example >> using the 1st /64 and IID=3D1 and IID=3D2, but is only one >> example, you can choose something different for your case. >> The example shows the easier way. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >>> De: "Durand, Alain" Responder a: >>> >>> Fecha: Wed, 1 Mar 2006 05:20:38 -0500 >>> Para: , >>> Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point >> Links and=20 >>> Easing the Addressing Plans >>> Asunto: Re: Guidelines for Numbering IPv6 Point-to-Point Links and >>> Easing the Addressing Plans >>>=20 >>> The part about picking a well know /64 out a the /48 >> certainly won't=20 >>> work in the general case... >>> Neither will the idea that the ISP has IID=3D1 and the >> customer had IID=3D2... >>>=20 >>> There won't be much left except the recommendation to use /64. >>>=20 >>> - Alain. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: owner-v6ops@ops.ietf.org >>> To: v6ops@ops.ietf.org >>> Sent: Wed Mar 01 04:50:41 2006 >>> Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and >>> Easing the Addressing Plans >>>=20 >>> Hi Alain, >>>=20 >>> May be some text need to be fixed, but the idea behind the >> document is=20 >>> still correct, and will work the same regardless of being >> ISP-customer=20 >>> or something different. >>>=20 >>> I will take care about this clarification in a new version. Thanks ! >>>=20 >>> Regards, >>> Jordi >>>=20 >>>=20 >>>=20 >>>=20 >>>> De: "Durand, Alain" Responder a: >>>> >>>> Fecha: Wed, 1 Mar 2006 04:28:51 -0500 >>>> Para: , >>>> Conversaci=F3n: Guidelines for Numbering IPv6 Point-to-Point >> Links and=20 >>>> Easing the Addressing Plans >>>> Asunto: RE: Guidelines for Numbering IPv6 Point-to-Point Links and >>>> Easing the Addressing Plans >>>>=20 >>>> Jordi, >>>>=20 >>>> This draft makes the assumption that all point-to-point links are >>>> connecting ISP to Customer. >>>>=20 >>>> This is obviously not true. >>>>=20 >>>> - Alain. >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: owner-v6ops@ops.ietf.org >>>>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI >> PALET MARTINEZ >>>>> Sent: Wednesday, March 01, 2006 3:56 AM >>>>> To: v6ops@ops.ietf.org >>>>> Subject: Guidelines for Numbering IPv6 Point-to-Point Links and >>>>> Easing the Addressing Plans >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> We have submitted before yesterday a new draft, it seems is still >>>>> not available at the IETF repository, but meanwhile, the document >>>>> can be reached >>>>> at: >>>>> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-poin >>>> t2point-00.txt >>>>>=20 >>>>> Comments welcome ! >>>>>=20 >>>>> Regards, >>>>> Jordi >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ********************************************** >>>>> The IPv6 Portal: http://www.ipv6tf.org >>>>>=20 >>>>> Barcelona 2005 Global IPv6 Summit >>>>> Slides available at: >>>>> http://www.ipv6-es.com >>>>>=20 >>>>> This electronic message contains information which may be >> privileged=20 >>>>> or confidential. The information is intended to be for the use of >>>>> the individual(s) named above. If you are not the >> intended recipient >>>>> be aware that any disclosure, copying, distribution or use of the >>>>> contents of this information, including attached files, is >>>>> prohibited. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ********************************************** >>> The IPv6 Portal: http://www.ipv6tf.org >>>=20 >>> Barcelona 2005 Global IPv6 Summit >>> Slides available at: >>> http://www.ipv6-es.com >>>=20 >>> This electronic message contains information which may be >> privileged=20 >>> or confidential. The information is intended to be for the >> use of the >>> individual(s) named above. If you are not the intended recipient be >>> aware that any disclosure, copying, distribution or use of the >>> contents of this information, including attached files, is >> prohibited. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >>=20 >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be >> for the use of the individual(s) named above. If you are not >> the intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, >> including attached files, is prohibited. >>=20 >>=20 >>=20 >>=20 >>=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Mar 05 04:03:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFp8p-00020W-2I for v6ops-archive@lists.ietf.org; Sun, 05 Mar 2006 04:03:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFp8m-0001n0-Jw for v6ops-archive@lists.ietf.org; Sun, 05 Mar 2006 04:03:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFp4T-0000CW-GJ for v6ops-data@psg.com; Sun, 05 Mar 2006 08:58:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFp4Q-0000C9-4A for v6ops@ops.ietf.org; Sun, 05 Mar 2006 08:58:30 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k258wOX09435; Sun, 5 Mar 2006 09:58:24 +0100 (CET) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp112.cisco.com [10.61.64.112]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k258wMC06031; Sun, 5 Mar 2006 09:58:22 +0100 (CET) Message-Id: <4.3.2.7.2.20060305095545.03770588@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 05 Mar 2006 09:58:18 +0100 To: v6ops@ops.ietf.org From: "Gunter Van de Velde (gvandeve)" Subject: Fwd: IPv6 Unicast Address Assignment Considerations Cc: tjc@ecs.soton.ac.uk, cpopovic@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Resend of original message as i apparently did not reach the overall v6ops alias. G/ >Date: Tue, 21 Feb 2006 13:34:00 +0100 >To: v6ops@ietf.org >From: "Gunter Van de Velde (gvandeve)" >Subject: IPv6 Unicast Address Assignment Considerations >Cc: tjc@ecs.soton.ac.uk, cpopovic@cisco.com > >Dear all, > >The authors of the following draft would be interested in comments >on the draft > >http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-addcon-00.txt > >Kind Regards, >G/ From owner-v6ops@ops.ietf.org Sun Mar 05 05:12:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFqE1-000348-OC for v6ops-archive@lists.ietf.org; Sun, 05 Mar 2006 05:12:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFqE0-0000M2-BL for v6ops-archive@lists.ietf.org; Sun, 05 Mar 2006 05:12:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFqC9-0005vb-SX for v6ops-data@psg.com; Sun, 05 Mar 2006 10:10:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.117] (helo=test-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFqC9-0005vQ-9t for v6ops@ops.ietf.org; Sun, 05 Mar 2006 10:10:33 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 05 Mar 2006 02:10:33 -0800 Received: from jdc-xdm1.cisco.com (jdc-xdm1.cisco.com [10.70.237.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k25AAUGv017003; Sun, 5 Mar 2006 02:10:31 -0800 (PST) Received: (otroan@localhost) by jdc-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id k25AAUP13358; Sun, 5 Mar 2006 19:10:30 +0900 (JST) X-Authentication-Warning: jdc-xdm1.cisco.com: otroan set sender to ot@cisco.com using -f From: Ole Troan To: jordi.palet@consulintel.es Cc: "v6ops@ops.ietf.org" Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans References: Date: Sun, 05 Mar 2006 19:10:30 +0900 In-Reply-To: (JORDI PALET MARTINEZ's message of "Fri, 03 Mar 2006 01:08:10 +0800") Message-ID: <7t5psl1cicp.fsf@jdc-xdm1.cisco.com> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >> using the first (or any) subnet of a larger prefix, breaks the >> conceptual model of DHCP prefix delegation. the prefix is delegated to >> the requesting router and cannot be used to number the link between >> the delegating and requesting router. > > I just re-read the DHCP-PD document, and is not so clear to me that this > breaks the model (I mean strictly there is no any text that is against this > usage). Also, we have actually tested this, even with Cisco, and it works > ;-) > > If you mean that DHCP-PD concept is to delegate the complete prefix to the > requesting router, well, the user owning the CPE will not complain having > one less /64, but also is not so clear to me that we are stealing from them > a /64 because this is actually used to connect it ;-) how is the requesting router supposed to know that it can't use that prefix on a downstream link? cheers, Ole From owner-v6ops@ops.ietf.org Mon Mar 06 03:30:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGB57-0000DM-Vs for v6ops-archive@lists.ietf.org; Mon, 06 Mar 2006 03:28:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGB0J-00059R-3T for v6ops-archive@lists.ietf.org; Mon, 06 Mar 2006 03:23:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGAwY-000HZ0-33 for v6ops-data@psg.com; Mon, 06 Mar 2006 08:19:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGAwX-000HYo-2D for v6ops@ops.ietf.org; Mon, 06 Mar 2006 08:19:49 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id D13D8179EA; Mon, 6 Mar 2006 09:19:47 +0100 (CET) Date: Mon, 6 Mar 2006 09:19:47 +0100 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060306081947.GA12282@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <1E4CCB2441C5C0409AD8A929482A09F3353C8F@S4DE9JSAAIG.ost.t-com.de> <3D1D54F5-EE9E-4DA4-AFD6-59C61590A99F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D1D54F5-EE9E-4DA4-AFD6-59C61590A99F@cisco.com> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Wed, Mar 01, 2006 at 11:30:09AM -0500, Fred Baker wrote: > My assumption as a routing geek is that the only reasonable use of a > numbered point to point link is to address an end station; it needs > an address to be useful in the network. But any router/router point- > to-point interface should be supportable using link-local addresses. And my experience as a routing operator/geek says that traceroute must work. "unnumbered" links are a pain to no end in day-to-day ops. When I was last working for a large ISP we had one in-country sub-ISP in Sweden who used unnumbered p2p links to customer CPEs. No end of pain with monitoring and troubleshooting. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From owner-v6ops@ops.ietf.org Tue Mar 07 20:20:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnLg-0003qX-P4 for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 20:20:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGnAb-00067X-Di for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 20:08:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGn6M-0002Jk-6k for v6ops-data@psg.com; Wed, 08 Mar 2006 01:04:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.134.166.247] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGn6J-0002JX-Fa for v6ops@ops.ietf.org; Wed, 08 Mar 2006 01:04:27 +0000 Received: from [192.168.1.101] (modemcable027.128-130-66.mc.videotron.ca [66.130.128.27]) by jazz.viagenie.qc.ca (Postfix) with ESMTP id 8509C37AE04 for ; Tue, 7 Mar 2006 20:04:26 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2AA3A19F-15FD-41B9-9603-9BD3A0DE438E@viagenie.ca> Content-Transfer-Encoding: quoted-printable From: Marc Blanchet Subject: Fwd: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-01.txt Date: Tue, 7 Mar 2006 20:04:54 -0500 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi, I updated the draft based on the comments got last fall on the =20 first version. I think these guidelines are very useful for operators =20= and I'm proposing that this draft is a v6ops wg draft. Is there a =20 v6ops meeting in Dallas? I haven't seen an agenda circulating around. Marc. D=E9but du message r=E9exp=E9di=E9 : > De : Internet-Drafts@ietf.org > Date : 7 mars 2006 15:50:02 HNE > =C0 : i-d-announce@ietf.org > Objet : I-D ACTION:draft-blanchet-v6ops-routing-guidelines-01.txt > R=E9pondre =E0 : internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. > > > Title : IPv6 Routing Policies Guidelines > Author(s) : M. Blanchet > Filename : draft-blanchet-v6ops-routing-guidelines-01.txt > Pages : 8 > Date : 2006-3-7 > =09 > Guidelines on how to handle IPv6 routes are needed for operators of > networks, either providers or enterprises. This document is a > followup on RFC2772 work but for the production IPv6 Internet. > RFC2772 becomes historic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-routing-=20 > guidelines-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body =20= > 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 =20= > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-blanchet-v6ops-routing-guidelines-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-blanchet-v6ops-routing-=20 > guidelines-01.txt". > =09 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-3-7132712.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-v6ops@ops.ietf.org Tue Mar 07 20:35:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnaf-0001x7-A3 for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 20:35:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGnae-0007Eu-11 for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 20:35:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGnZv-0004ZK-EH for v6ops-data@psg.com; Wed, 08 Mar 2006 01:35:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGnZu-0004Y6-NH for v6ops@ops.ietf.org; Wed, 08 Mar 2006 01:35:02 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Mar 2006 17:35:01 -0800 X-IronPort-AV: i="4.02,173,1139212800"; d="scan'208"; a="413328192:sNHT31205060" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k281Z0Gv026938; Tue, 7 Mar 2006 17:35:01 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k281aq75007231; Tue, 7 Mar 2006 17:36:52 -0800 In-Reply-To: <2AA3A19F-15FD-41B9-9603-9BD3A0DE438E@viagenie.ca> References: <2AA3A19F-15FD-41B9-9603-9BD3A0DE438E@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <551A81E5-3318-49D8-A511-6FB865A41B6E@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-01.txt Date: Tue, 7 Mar 2006 17:34:56 -0800 To: Marc Blanchet X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=326; t=1141781812; x=1142214012; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20I-D=20ACTION=3Adraft-blanchet-v6ops-routing-guidelines-01.txt=20 |To:Marc=20Blanchet=20; X=v=3Dmtcc.com=3B=20h=3DLU3Abl6RL0C2LQMHfOuS3ea05mQ=3D; b=Xbw8eNChKofRvcV/EiFlf9BSMFs8J3dVjD3c52/Buou0re929Cvcd/8zP0ZjyZkqluLOPQZH cjPMeP8ste38g79qQ2JWROqt8CKcDOg9pjULJtrw2NApCbZVlKP5REoNtQBgWOIoxN/k4CfRSMT eNtBzwkk2sNI6X8AYuWwONQg=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 On Mar 7, 2006, at 5:04 PM, Marc Blanchet wrote: > Is there a v6ops meeting in Dallas? I haven't seen an agenda > circulating around. http://www.ietf.org/meetings/agenda_65.txt places v6ops in a two hour session early Thursday afternoon. The first agenda I saw had v6ops Tuesday afternoon, so it may move again. From owner-v6ops@ops.ietf.org Tue Mar 07 20:37:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnc1-0002iX-CK for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 20:37:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGnc1-0007HC-41 for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 20:37:13 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGnbs-0004kq-UY for v6ops-data@psg.com; Wed, 08 Mar 2006 01:37:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.134.166.247] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGnbr-0004kW-BN for v6ops@ops.ietf.org; Wed, 08 Mar 2006 01:37:03 +0000 Received: from [192.168.1.101] (modemcable027.128-130-66.mc.videotron.ca [66.130.128.27]) by jazz.viagenie.qc.ca (Postfix) with ESMTP id 9F9A237AE03; Tue, 7 Mar 2006 20:37:02 -0500 (EST) In-Reply-To: <551A81E5-3318-49D8-A511-6FB865A41B6E@cisco.com> References: <2AA3A19F-15FD-41B9-9603-9BD3A0DE438E@viagenie.ca> <551A81E5-3318-49D8-A511-6FB865A41B6E@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: Marc Blanchet Subject: Re: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-01.txt Date: Tue, 7 Mar 2006 20:37:12 -0500 To: Fred Baker X-Mailer: Apple Mail (2.746.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c I was referring to a v6ops meeting agenda. Marc. Le 06-03-07 =E0 20:34, Fred Baker a =E9crit : > On Mar 7, 2006, at 5:04 PM, Marc Blanchet wrote: >> Is there a v6ops meeting in Dallas? I haven't seen an agenda =20 >> circulating around. > > http://www.ietf.org/meetings/agenda_65.txt places v6ops in a two =20 > hour session early Thursday afternoon. The first agenda I saw had =20 > v6ops Tuesday afternoon, so it may move again. From owner-v6ops@ops.ietf.org Tue Mar 07 21:14:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGoC1-00010V-Ch for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 21:14:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGoBz-0000BC-KX for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 21:14:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGoAX-0007a1-3e for v6ops-data@psg.com; Wed, 08 Mar 2006 02:12:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.160.249.157] (helo=mail.zwtech.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGoAV-0007Za-Qc for v6ops@ops.ietf.org; Wed, 08 Mar 2006 02:12:51 +0000 Received: from [67.109.157.66] by mail.zwtech.net (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.9)); Sun, 9 Mar 2003 19:43:16 -0500 From: "John Spence" To: Subject: RE: IPv6 Unicast Address Assignment Considerations Date: Tue, 7 Mar 2006 18:12:40 -0800 Message-ID: <001401c64255$c8427610$90dc16ac@laptop220> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZANpPg/n2JUx7CQMCYXiPXXXkBXwCHp2kA In-Reply-To: <4.3.2.7.2.20060305095545.03770588@strange-brew> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Guys - nice IETF Draft. Lots of good considerations in there. I'd like to participate, so I've got some things to think about below. Clarifications, suggestions - hope they help move the discussion forward. Comments. *) In 1.0, you talk about Site-local and ULA. Not sure if this should go into the document, but during the transition this can be very tricky. Most implementations know about Site-local even though it is deprecated, and do not know about ULAs - even though they are to spec. I'm not sure, but my guess is that may confuse the address selection algorithm in the transition period. Since your document is implementation-oriented, this might be worth a mention. *) Also in 1.0, you know that ARIN is considering portable address to address the multihoming issue - right? Not done yet, but I'll bet it goes through. http://www.arin.net/policy/proposals/2006_4.html *) In 2.1, consider a sentence pointing out that scattering subnet /64 assignments, while still maintaining the ability to summarize routes, may make active subnets harder to find, or guess, for an outsider, but that it comes at the cost of complexity for the network operations team. *) Also in 2.1, I'm not sure if it is the right place to mention it, but today multihoming, with the aggregation model, pretty much means using Policy Based Routing - do you agree? If the source address will be chosen based on the destination address, some mechanism must be used to make sure the traffic egresses at the right interface through the right ISP. *) In 2.2, you mention that a ULA is a /48 prefix. You are correct per the spec. There was some traffic on the mailing list from before the RFC was published where I suggested it be better to be more flexible on the length. Suppose a site has a /47 because they are large enough to warrant it. They would probably like a /47 ULA to go with it, rather than using 2 /48s. The authors suggested that the spec was fine as is, but since these are internal addresses enterprises could do what they wanted about using a shorter prefix if that met their needs. So, again, not sure it should go in, but it is worth thinking about. *) In 2.2 you have the word "chgoose" when you mean "choose". *) In 2.4, you mention that multiple /48s in a single enterprise will be non-contiguous, and that is not good for summarization. I agree, but do you think that would be a problem in practice, since a whole /48 is still a large summary route. If you had a really big enterprise (say /40), if you have /48 summarization that is only 256 routes in the internal-enterprise backbone routers. Seems pretty good. Now if you had a lot of /62s, or /60s, that would be a problem. But I don't know if having to announce, say, 8 /48s when you might have been able to announce a single /45 would make a big difference, in practice. *) Man, it is hard to keep up. You reference RFC 3513 - 4219 is out now. ftp://ftp.rfc-editor.org/in-notes/rfc4291.txt *) In 3.3.1, the Subnet Anycast Address is where all the non-prefix bits are all zeros: ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt (2.6.1) http://www.iana.org/assignments/ipv6-anycast-addresses *) In 4.2, for "reverse DNS lookup", I suggest making it more clear that using privacy extensions for a host that needs to be in the DNS, if not using DDNS, is not recommended, as is practically impossible to maintain. I think some people might not get that from what you have. *) In 5.1, can you include an estimate of the number of subnets too? *) In 5.1.1, do not some people use site-local or ULA address for the infrastructure not because they are lacking addresses, but for security reasons, figuring that there need be no outside-the-enterprise communications with the control-plane, and so using ULAs improves security? If so, you might note that here as a practical consideration. *) In 5.1.2, does the allocation of a /56 to each school result in, essentially, smooth aggregation for the network? Or do you leave that behind, figuring that /56s are large enough summaries by themselves, because the convenience of having each school on a /56 yields other benefits (than full summarization)? *) In 5.1.4, do you really let hosts autoconfigure, then put their address manually in the DNS? Why not give them a simpler, manual address that would survive NIC swap-outs? -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Gunter Van de Velde (gvandeve) Sent: Sunday, March 05, 2006 12:58 AM To: v6ops@ops.ietf.org Cc: tjc@ecs.soton.ac.uk; cpopovic@cisco.com Subject: Fwd: IPv6 Unicast Address Assignment Considerations Resend of original message as i apparently did not reach the overall v6ops alias. G/ >Date: Tue, 21 Feb 2006 13:34:00 +0100 >To: v6ops@ietf.org >From: "Gunter Van de Velde (gvandeve)" >Subject: IPv6 Unicast Address Assignment Considerations >Cc: tjc@ecs.soton.ac.uk, cpopovic@cisco.com > >Dear all, > >The authors of the following draft would be interested in comments >on the draft > >http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-addcon-00.txt > >Kind Regards, >G/ From owner-v6ops@ops.ietf.org Tue Mar 07 21:40:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGoap-0006ia-Vb for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 21:40:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGoao-0000mQ-DX for v6ops-archive@lists.ietf.org; Tue, 07 Mar 2006 21:40:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGoZw-0009VK-9q for v6ops-data@psg.com; Wed, 08 Mar 2006 02:39:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [63.105.122.7] (helo=multicasttech.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGoZv-0009V7-4v for v6ops@ops.ietf.org; Wed, 08 Mar 2006 02:39:07 +0000 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4085925; Tue, 07 Mar 2006 21:37:41 -0500 In-Reply-To: <001401c64255$c8427610$90dc16ac@laptop220> References: <001401c64255$c8427610$90dc16ac@laptop220> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <635D1E77-19EA-43B0-B75E-DFC8743EFC34@multicasttech.com> Cc: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: IPv6 Unicast Address Assignment Considerations Date: Tue, 7 Mar 2006 21:39:03 -0500 To: "John Spence" X-Mailer: Apple Mail (2.746.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Hello; On Mar 7, 2006, at 9:12 PM, John Spence wrote: > > Guys - nice IETF Draft. Lots of good considerations in there. I'd > like to > participate, so I've got some things to think about below. > Clarifications, > suggestions - hope they help move the discussion forward. > > Comments. > > *) In 1.0, you talk about Site-local and ULA. Not sure if this > should go > into the document, but during the transition this can be very > tricky. Most > implementations know about Site-local even though it is deprecated, > and do > not know about ULAs - even though they are to spec. I'm not sure, > but my > guess is that may confuse the address selection algorithm in the > transition > period. Since your document is implementation-oriented, this might > be worth > a mention. > > *) Also in 1.0, you know that ARIN is considering portable address to > address the multihoming issue - right? Not done yet, but I'll bet > it goes > through. > > http://www.arin.net/policy/proposals/2006_4.html There is also http://www.arin.net/policy/proposals/2005_1.html , which is a competing proposal. I am confident that something along these lines will eventually go through. 2002-3 took quite a while too. Regards Marshall Eubanks > > > *) In 2.1, consider a sentence pointing out that scattering subnet /64 > assignments, while still maintaining the ability to summarize > routes, may > make active subnets harder to find, or guess, for an outsider, but > that it > comes at the cost of complexity for the network operations team. > > *) Also in 2.1, I'm not sure if it is the right place to mention > it, but > today multihoming, with the aggregation model, pretty much means using > Policy Based Routing - do you agree? If the source address will be > chosen > based on the destination address, some mechanism must be used to > make sure > the traffic egresses at the right interface through the right ISP. > > *) In 2.2, you mention that a ULA is a /48 prefix. You are correct > per the > spec. There was some traffic on the mailing list from before the > RFC was > published where I suggested it be better to be more flexible on the > length. > Suppose a site has a /47 because they are large enough to warrant > it. They > would probably like a /47 ULA to go with it, rather than using 2 / > 48s. The > authors suggested that the spec was fine as is, but since these are > internal > addresses enterprises could do what they wanted about using a > shorter prefix > if that met their needs. So, again, not sure it should go in, but > it is > worth thinking about. > > *) In 2.2 you have the word "chgoose" when you mean "choose". > > *) In 2.4, you mention that multiple /48s in a single enterprise > will be > non-contiguous, and that is not good for summarization. I agree, > but do you > think that would be a problem in practice, since a whole /48 is > still a > large summary route. If you had a really big enterprise (say /40), > if you > have /48 summarization that is only 256 routes in the internal- > enterprise > backbone routers. Seems pretty good. Now if you had a lot of / > 62s, or > /60s, that would be a problem. But I don't know if having to > announce, say, > 8 /48s when you might have been able to announce a single /45 would > make a > big difference, in practice. > > *) Man, it is hard to keep up. You reference RFC 3513 - 4219 is > out now. > > ftp://ftp.rfc-editor.org/in-notes/rfc4291.txt > > *) In 3.3.1, the Subnet Anycast Address is where all the non-prefix > bits are > all zeros: > > ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt (2.6.1) > > http://www.iana.org/assignments/ipv6-anycast-addresses > > *) In 4.2, for "reverse DNS lookup", I suggest making it more clear > that > using privacy extensions for a host that needs to be in the DNS, if > not > using DDNS, is not recommended, as is practically impossible to > maintain. I > think some people might not get that from what you have. > > *) In 5.1, can you include an estimate of the number of subnets too? > > *) In 5.1.1, do not some people use site-local or ULA address for the > infrastructure not because they are lacking addresses, but for > security > reasons, figuring that there need be no outside-the-enterprise > communications with the control-plane, and so using ULAs improves > security? > If so, you might note that here as a practical consideration. > > *) In 5.1.2, does the allocation of a /56 to each school result in, > essentially, smooth aggregation for the network? Or do you leave that > behind, figuring that /56s are large enough summaries by > themselves, because > the convenience of having each school on a /56 yields other > benefits (than > full summarization)? > > *) In 5.1.4, do you really let hosts autoconfigure, then put their > address > manually in the DNS? Why not give them a simpler, manual address > that would > survive NIC swap-outs? > > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf > Of Gunter Van de Velde (gvandeve) > Sent: Sunday, March 05, 2006 12:58 AM > To: v6ops@ops.ietf.org > Cc: tjc@ecs.soton.ac.uk; cpopovic@cisco.com > Subject: Fwd: IPv6 Unicast Address Assignment Considerations > > Resend of original message as i apparently did not reach the > overall v6ops > alias. > > G/ > >> Date: Tue, 21 Feb 2006 13:34:00 +0100 >> To: v6ops@ietf.org >> From: "Gunter Van de Velde (gvandeve)" >> Subject: IPv6 Unicast Address Assignment Considerations >> Cc: tjc@ecs.soton.ac.uk, cpopovic@cisco.com >> >> Dear all, >> >> The authors of the following draft would be interested in comments >> on the draft >> >> http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops- >> addcon-00.txt >> >> Kind Regards, >> G/ > > > > From owner-v6ops@ops.ietf.org Wed Mar 08 16:18:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH62o-0002SX-H2 for v6ops-archive@lists.ietf.org; Wed, 08 Mar 2006 16:18:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH62o-0006xj-55 for v6ops-archive@lists.ietf.org; Wed, 08 Mar 2006 16:18:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH5bj-000GI6-Gy for v6ops-data@psg.com; Wed, 08 Mar 2006 20:50:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH5bg-000GEb-Nn for v6ops@ops.ietf.org; Wed, 08 Mar 2006 20:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko30e006067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5bf-0002s2-4s; Wed, 08 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-security-overview-04.txt Message-Id: Date: Wed, 08 Mar 2006 15:50:03 -0500 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Transition/Co-existence Security Considerations Author(s) : E. Davies, et al. Filename : draft-ietf-v6ops-security-overview-04.txt Pages : 38 Date : 2006-3-8 The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-security-overview-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-security-overview-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-8142604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-security-overview-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-security-overview-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8142604.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Mar 08 16:55:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5eN-0003Nt-1N for v6ops-archive@lists.ietf.org; Wed, 08 Mar 2006 15:52:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5eL-0000dl-Lx for v6ops-archive@lists.ietf.org; Wed, 08 Mar 2006 15:52:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH5bq-000GJX-6X for v6ops-data@psg.com; Wed, 08 Mar 2006 20:50:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH5bp-000GJJ-IC for v6ops@ops.ietf.org; Wed, 08 Mar 2006 20:50:13 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko39W006329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5bf-0002sw-DX; Wed, 08 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-02.txt Message-Id: Date: Wed, 08 Mar 2006 15:50:03 -0500 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Using IPsec to Secure IPv6-in-IPv4 Tunnels Author(s) : P. Savola, et al. Filename : draft-ietf-v6ops-ipsec-tunnels-02.txt Pages : 21 Date : 2006-3-8 This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-02.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-v6ops-ipsec-tunnels-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipsec-tunnels-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-8144444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipsec-tunnels-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipsec-tunnels-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8144444.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Mar 08 19:19:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8sn-00065N-Vx for v6ops-archive@lists.ietf.org; Wed, 08 Mar 2006 19:19:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH8sm-00031i-Mt for v6ops-archive@lists.ietf.org; Wed, 08 Mar 2006 19:19:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH8pQ-0009rr-VB for v6ops-data@psg.com; Thu, 09 Mar 2006 00:16:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH8pQ-0009rg-GP for v6ops@ops.ietf.org; Thu, 09 Mar 2006 00:16:28 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2006 16:16:22 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k290GK7T000792; Wed, 8 Mar 2006 16:16:20 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k290I8le016263; Wed, 8 Mar 2006 16:18:08 -0800 In-Reply-To: <20060308234115.GA26884@nokia.com> References: <200603081545.k28FjlUJ016888@bright.research.att.com> <65C96E83-C9B6-4BC6-BA04-F6EAA73E9A2C@cisco.com> <20060308234115.GA26884@nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C5D0DC2-E540-48FB-845F-0B3F222688B9@cisco.com> Reply-To: idr@ietf.org, dirk@onesparrow.com, "Francois Le Faucheur (flefauch)" , jeremy.de_clercq@alcatel.be, stuart.prevost@bt.com Content-Transfer-Encoding: 7bit From: Fred Baker Subject: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Date: Wed, 8 Mar 2006 16:16:15 -0800 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=613; t=1141863489; x=1142295689; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:draft-ooms-v6ops-bgp-tunnel-06.txt=20and=20v6ops=20review |To:v6ops@ops.ietf.org; X=v=3Dmtcc.com=3B=20h=3Du4FA24Vbu239gGbsiN+C/K6JCHg=3D; b=LlywHsYykzVI9xcDAKg9R+REWdjWBMmelbbAOmyqp1JXEBlUnbskb902H/VQh33WIP0vPj/C 2qszl1QKq1q9dpczP06uWQ0A0lI0XuvuCBn78+OVvdxUjnG8STBOv01/vB8gC+rxGY2ZC4j7v/I NlV2gWbV06PiWZaG0NBjjNHY=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c We have been asked to read and comment on http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp- tunnel-06.txt "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", Jeremy De Clercq, 18-Jan-06, which is about to go into IESG review. As you will recall, this has been round the block, and deserves speedy review. May I suggest that you get your comments in by 17 March at the latest. Reply to the authors copying idr; if you are not on the list, the working group chairs will deal with the moderation issues. From owner-v6ops@ops.ietf.org Thu Mar 09 00:54:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHE6j-0004zx-DA for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 00:54:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHE6i-0004Lz-UV for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 00:54:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHE1G-000GaQ-24 for v6ops-data@psg.com; Thu, 09 Mar 2006 05:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [203.91.193.32] (helo=wip-ec-wd.wipro.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHE16-000GWa-NK for v6ops@ops.ietf.org; Thu, 09 Mar 2006 05:49:01 +0000 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 114A32065A for ; Thu, 9 Mar 2006 11:02:37 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id DBABC20652 for ; Thu, 9 Mar 2006 11:02:36 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.201.50.80]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 11:18:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6433D.0CF56DC3" Subject: RE: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Date: Thu, 9 Mar 2006 11:13:50 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Thread-Index: AcZDECakLHIqRK9nRXyE7KmvoNuoawALEr75 References: <200603081545.k28FjlUJ016888@bright.research.att.com> <65C96E83-C9B6-4BC6-BA04-F6EAA73E9A2C@cisco.com> <20060308234115.GA26884@nokia.com> <4C5D0DC2-E540-48FB-845F-0B3F222688B9@cisco.com> From: To: , , , , , X-OriginalArrivalTime: 09 Mar 2006 05:48:12.0307 (UTC) FILETIME=[0D5F8E30:01C6433D] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6433D.0CF56DC3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Just consider the scenario in which the CE also supports the IPv4. Then = how the IPv4 MPLS cloud will cater this specific IPv4 packet.=20 =20 BR, Dheeraj =20 ________________________________ From: owner-v6ops@ops.ietf.org on behalf of Fred Baker Sent: Thu 3/9/2006 5:46 AM To: v6ops@ops.ietf.org Subject: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review We have been asked to read and comment on http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp- tunnel-06.txt "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge=20 Routers (6PE)", Jeremy De Clercq, 18-Jan-06, which is about to go into IESG review. As you will recall, this has=20 been round the block, and deserves speedy review. May I suggest that=20 you get your comments in by 17 March at the latest. Reply to the=20 authors copying idr; if you are not on the list, the working group=20 chairs will deal with the moderation issues. ------_=_NextPart_001_01C6433D.0CF56DC3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review=0A= =0A= =0A=
=0A=
Hi,
=0A=
 
=0A=
Just consider =0A= the scenario in which the CE also supports the =0A= IPv4.  Then how the IPv4 MPLS cloud will cater this specific = IPv4 =0A= packet. 
=0A=
 
=0A=
BR,
=0A=
Dheeraj
=0A=
 
=0A=

=0A=
=0A= From: owner-v6ops@ops.ietf.org on = behalf of Fred =0A= Baker
Sent: Thu 3/9/2006 5:46 AM
To: =0A= v6ops@ops.ietf.org
Subject: draft-ooms-v6ops-bgp-tunnel-06.txt = and =0A= v6ops review

=0A=
=0A=

We have been asked to read and comment = on

   http:/= /www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-
tunnel-06.txt<= BR>   =0A= "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider =0A= Edge 
Routers
   (6PE)", Jeremy De Clercq, = 18-Jan-06, =0A= <draft-ooms-v6ops-bgp-
tunnel-06.txt>

which is about to = go into =0A= IESG review. As you will recall, this has 
been round the block, = and =0A= deserves speedy review. May I suggest that 
you get your = comments in by =0A= 17 March at the latest. Reply to the 
authors copying idr; if = you are =0A= not on the list, the working group 
chairs will deal with the = moderation =0A= issues.

=0A= =0A= =0A= ------_=_NextPart_001_01C6433D.0CF56DC3-- From owner-v6ops@ops.ietf.org Thu Mar 09 01:08:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHEK1-0000mt-QD for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 01:08:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHEJz-00054T-7y for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 01:08:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHEIs-0000u1-PB for v6ops-data@psg.com; Thu, 09 Mar 2006 06:07:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHEIr-0000ti-3D for v6ops@ops.ietf.org; Thu, 09 Mar 2006 06:07:13 +0000 Received: (qmail 7644 invoked by uid 417); 9 Mar 2006 06:00:32 -0000 Received: from tango-.softhome.net (HELO softhome.net) (172.16.2.14) by shunt-smtp-com-out-com-0 with SMTP; 9 Mar 2006 06:00:32 -0000 Received: from mehr ([132.70.222.125]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 08 Mar 2006 23:00:31 -0700 Message-ID: <033f01c6433e$ab575ae0$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <200603081545.k28FjlUJ016888@bright.research.att.com> <65C96E83-C9B6-4BC6-BA04-F6EAA73E9A2C@cisco.com> <20060308234115.GA26884@nokia.com> <4C5D0DC2-E540-48FB-845F-0B3F222688B9@cisco.com> Subject: Assistance with thesis requested Date: Thu, 9 Mar 2006 07:59:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi, As part of my thesis I am analyzing people's knowledge, perceptions, and plans regarding Internet Protocol version 6 (IPv6) in a survey. I would appreciate it if you could fill in the survey (no personal information is requested) and forward it to anyone that you feel appropriate. You should be aware that this survey leaves a tracking cookie on your computer to prevent duplicate responses. The survey is aimed at both non-technical and technical people and should only take you a few minutes to complete and would greatly help me in my studies. What is in it for you? In appreciation for taking the survey you will be redirected to a page with links to more information about IPv6 and several of my previously published articles. If you would like a copy of the final article please fill-in your e-mail address on the last page of the survey so I can send it to you. Your e-mail will not be used for anything other than responding with a copy of the article. A friend of mine at is hosting the Survey at: http://www.richgautier.com/survey/survey1.aspx Also, I apologize if you get more than one copy of this request; I am cross posting to several mailing lists and my personal mailing list. Thanks for your help, Eric Klein, MSc. Leon Recanati Graduate School of Business Administration and the Netvision Institute for Internet Studies, Tel Aviv University ericklei@post.tau.ac.il From owner-v6ops@ops.ietf.org Thu Mar 09 11:19:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNrV-0001t1-SW for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 11:19:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNrV-0007Jz-IJ for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 11:19:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHNoU-000NcR-Jw for v6ops-data@psg.com; Thu, 09 Mar 2006 16:16:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHNoT-000Nc6-6g for v6ops@ops.ietf.org; Thu, 09 Mar 2006 16:16:29 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2006 17:16:28 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k29GGP36008665; Thu, 9 Mar 2006 17:16:25 +0100 (MET) Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Mar 2006 17:16:24 +0100 Received: from [144.254.53.151] ([144.254.53.151]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:16:24 +0100 From: Eric Levy-Abegnoli To: Subject: Re: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Date: Thu, 9 Mar 2006 17:16:09 +0100 User-Agent: KMail/1.6.1 Cc: , , , , , References: <200603081545.k28FjlUJ016888@bright.research.att.com> <4C5D0DC2-E540-48FB-845F-0B3F222688B9@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200603091716.09776.elevyabe@cisco.com> X-OriginalArrivalTime: 09 Mar 2006 16:16:24.0588 (UTC) FILETIME=[CFB934C0:01C64394] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On jeudi 9 Mars 2006 06:43, dheeraj.singh@wipro.com wrote: > Hi, > > Just consider the scenario in which the CE also supports the IPv4. Then > how the IPv4 MPLS cloud will cater this specific IPv4 packet. What about it ? I don't see anything in the draft that will prevent such packet to be handled "as usual" by the PE and the MPLS cloud. Eric > > BR, > Dheeraj > > > ________________________________ > > From: owner-v6ops@ops.ietf.org on behalf of Fred Baker > Sent: Thu 3/9/2006 5:46 AM > To: v6ops@ops.ietf.org > Subject: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review > > > > We have been asked to read and comment on > > http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp- > tunnel-06.txt > "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge > Routers > (6PE)", Jeremy De Clercq, 18-Jan-06, tunnel-06.txt> > > which is about to go into IESG review. As you will recall, this has > been round the block, and deserves speedy review. May I suggest that > you get your comments in by 17 March at the latest. Reply to the > authors copying idr; if you are not on the list, the working group > chairs will deal with the moderation issues. From owner-v6ops@ops.ietf.org Thu Mar 09 14:04:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQRX-0000dm-FJ for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 14:04:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQRW-00049g-61 for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 14:04:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHQPA-000AUI-Ar for v6ops-data@psg.com; Thu, 09 Mar 2006 19:02:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHQP8-000AU2-9M for v6ops@ops.ietf.org; Thu, 09 Mar 2006 19:02:30 +0000 Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.0.5.R) with ESMTP id md50001675012.msg for ; Thu, 09 Mar 2006 20:02:25 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 09 Mar 2006 20:01:54 +0100 Subject: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Thread-Index: AcZDq+4dLJtiKK+fEdqUHQANky3PwA== In-Reply-To: <7t5psl1cicp.fsf@jdc-xdm1.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060309:v6ops@ops.ietf.org::c9k3G5dM/KXMtiLF:0000000000000000000000000000000000000000000065y X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 09 Mar 2006 20:02:25 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi Ole, See below, in-line. Regards, Jordi > De: Ole Troan > Responder a: > Fecha: Sun, 05 Mar 2006 19:10:30 +0900 > Para: > CC: "v6ops@ops.ietf.org" > Asunto: Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing Plans > >>> using the first (or any) subnet of a larger prefix, breaks the >>> conceptual model of DHCP prefix delegation. the prefix is delegated to >>> the requesting router and cannot be used to number the link between >>> the delegating and requesting router. >> >> I just re-read the DHCP-PD document, and is not so clear to me that this >> breaks the model (I mean strictly there is no any text that is against this >> usage). Also, we have actually tested this, even with Cisco, and it works >> ;-) >> >> If you mean that DHCP-PD concept is to delegate the complete prefix to the >> requesting router, well, the user owning the CPE will not complain having >> one less /64, but also is not so clear to me that we are stealing from them >> a /64 because this is actually used to connect it ;-) > > how is the requesting router supposed to know that it can't use that > prefix on a downstream link? This is not a "must" document, just info from operational experience. I'm not stating that this is the only way and that should be done like this. Also, it may depend on if the CPE is using the 1st /64 or something different. I don't see this is stated in the DHCP-PD document, so I guess is a decision of each implementation or I miss something ?. > > cheers, > Ole > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Mar 09 16:30:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS7r-0004nB-Jz for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 15:52:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS7o-0007rq-QD for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 15:52:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHS5F-000JDT-7e for v6ops-data@psg.com; Thu, 09 Mar 2006 20:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHS5E-000JCy-Ey for v6ops@ops.ietf.org; Thu, 09 Mar 2006 20:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko39W015559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5D-0000A3-6n; Thu, 09 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt Message-Id: Date: Thu, 09 Mar 2006 15:50:03 -0500 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Best Current Practice for Filtering ICMPv6 Messages in Firewalls Author(s) : E. Davies, J. Mohacsi Filename : draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt Pages : 34 Date : 2006-3-9 In networks supporting IPv6 the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-9142624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9142624.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Mar 09 17:18:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTSf-0005KD-Qb for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 17:18:21 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSLN-0001yR-Ov for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 16:06:45 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHS7h-0005Xv-3D for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 15:52:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHS5J-000JEP-Ap for v6ops-data@psg.com; Thu, 09 Mar 2006 20:50:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHS5I-000JEB-NH for v6ops@ops.ietf.org; Thu, 09 Mar 2006 20:50:08 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko20e020912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00005c-4b; Thu, 09 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-vlan-usage-01.txt Message-Id: Date: Thu, 09 Mar 2006 15:50:02 -0500 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks Author(s) : T. Chown Filename : draft-ietf-v6ops-vlan-usage-01.txt Pages : 13 Date : 2006-3-9 Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-vlan-usage-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-vlan-usage-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-vlan-usage-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-9114159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-vlan-usage-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-vlan-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9114159.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Mar 09 17:34:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTiZ-0000bf-5G for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 17:34:47 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSrY-0006Ie-Nx for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 16:40:00 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHSpJ-0000TK-Li for v6ops-archive@lists.ietf.org; Thu, 09 Mar 2006 16:37:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHSPS-000Ldg-3c for v6ops-data@psg.com; Thu, 09 Mar 2006 21:10:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHSPQ-000Lcq-EU for v6ops@ops.ietf.org; Thu, 09 Mar 2006 21:10:56 +0000 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 1FHSPN-0001x6-CO for v6ops@ops.ietf.org; Thu, 09 Mar 2006 21:10:53 +0000 Message-ID: <44109A6F.1070900@dial.pipex.com> Date: Thu, 09 Mar 2006 21:13:19 +0000 From: Elwyn Davies User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'v6ops@ops.ietf.org '" Subject: [Fwd: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt] Content-Type: multipart/mixed; boundary="------------070902080404030802020909" Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This is a multi-part message in MIME format. --------------070902080404030802020909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The main change in this update is the addition of Appendix B containing an example of the configuration needed for a Linux Netfilter packet filter engine (using ip6tables interface). It also contains a reference to draft-gont-tcpm-icmp-attacks-05 regarding icmp attacks on TCP. In the light of some recent discussions in the IESG, we may have to revisit the intended status of this document. It was intended for BCP but since there is little experience as yet, we may have to propose this as Informational until some experience accumulates. Regards, Elwyn -------- Original Message -------- Subject: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt Date: Thu, 09 Mar 2006 15:50:03 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: v6ops@ops.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Best Current Practice for Filtering ICMPv6 Messages in Firewalls Author(s) : E. Davies, J. Mohacsi Filename : draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt Pages : 34 Date : 2006-3-9 In networks supporting IPv6 the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070902080404030802020909 Content-Type: Message/External-body; name="draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt" Content-Type: text/plain Content-ID: <2006-3-9142624.I-D@ietf.org> --------------070902080404030802020909-- From owner-v6ops@ops.ietf.org Tue Mar 14 05:18:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ6bi-0008OO-GI for v6ops-archive@lists.ietf.org; Tue, 14 Mar 2006 05:18:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ6bi-0004a9-5u for v6ops-archive@lists.ietf.org; Tue, 14 Mar 2006 05:18:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ6XO-0004BX-7p for v6ops-data@psg.com; Tue, 14 Mar 2006 10:13:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ6XN-0004BA-3X for v6ops@ops.ietf.org; Tue, 14 Mar 2006 10:13:57 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2006 11:13:56 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2EADs36029411; Tue, 14 Mar 2006 11:13:54 +0100 (MET) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Mar 2006 11:13:54 +0100 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 Subject: RE: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Date: Tue, 14 Mar 2006 11:13:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Thread-Index: AcZDlM/bLSA1VmX/QJOfSkXV5TyengDua1mA From: "Francois Le Faucheur \(flefauch\)" To: Cc: , , , , , "Eric Levy- Abegnoli \(elevyabe\)" X-OriginalArrivalTime: 14 Mar 2006 10:13:54.0494 (UTC) FILETIME=[FFB8FDE0:01C6474F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hello Dheeraj, It seems that Eric's message didn't make it on the alias, so I am including it below. As pointed out by Eric, IPv4 packets from the CE can be handled by the PE as per existing IPv4 MPLS procedures. This doesn't interact in any way with the handling of IPv6 packets as described in the 6PE document. Can you confirm you are comfortable with this approach (or identify any remaining concerns)? Thanks Francois >> -----Original Message----- >> From: Eric Levy- Abegnoli (elevyabe)=20 >> Sent: jeudi 9 mars 2006 17:16 >> To: dheeraj.singh@wipro.com >> Cc: idr@ietf.org; dirk@onesparrow.com; Francois Le Faucheur=20 >> (flefauch); jeremy.de_clercq@alcatel.be;=20 >> stuart.prevost@bt.com; v6ops@ops.ietf.org >> Subject: Re: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review >>=20 >> On jeudi 9 Mars 2006 06:43, dheeraj.singh@wipro.com wrote: >> > Hi, >> > >> > Just consider the scenario in which the CE also supports=20 >> the IPv4. Then >> > how the IPv4 MPLS cloud will cater this specific IPv4 packet. >> >> What about it ? I don't see anything in the draft that will=20 >> prevent such=20 >> packet to be handled "as usual" by the PE and the MPLS cloud. >> Eric >> > >> > BR, >> > Dheeraj >> > >> > >> > ________________________________ >> > >> > From: owner-v6ops@ops.ietf.org on behalf of Fred Baker >> > Sent: Thu 3/9/2006 5:46 AM >> > To: v6ops@ops.ietf.org >> > Subject: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review >> > >> > >> > >> > We have been asked to read and comment on >> > >> > http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp- >> > tunnel-06.txt >> > "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge >> > Routers >> > (6PE)", Jeremy De Clercq, 18-Jan-06, > > tunnel-06.txt> >> > >> > which is about to go into IESG review. As you will recall, this has >> > been round the block, and deserves speedy review. May I=20 >> suggest that >> > you get your comments in by 17 March at the latest. Reply to the >> > authors copying idr; if you are not on the list, the working group >> > chairs will deal with the moderation issues. >>=20 From owner-v6ops@ops.ietf.org Tue Mar 14 06:26:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ7f8-00059s-1y for v6ops-archive@lists.ietf.org; Tue, 14 Mar 2006 06:26:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ7f7-000641-IY for v6ops-archive@lists.ietf.org; Tue, 14 Mar 2006 06:26:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ7dV-0007cJ-7W for v6ops-data@psg.com; Tue, 14 Mar 2006 11:24:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [203.91.193.32] (helo=wip-ec-wd.wipro.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ7d9-0007YX-5t for v6ops@ops.ietf.org; Tue, 14 Mar 2006 11:24:20 +0000 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 2E33D20630; Tue, 14 Mar 2006 16:37:53 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 10B25205DC; Tue, 14 Mar 2006 16:37:53 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 16:53:35 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64759.B8E1F68C" Subject: RE: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Date: Tue, 14 Mar 2006 16:51:33 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Thread-Index: AcZDlM/bLSA1VmX/QJOfSkXV5TyengDua1mAAAK9cgQ= References: From: To: Cc: , , , , , X-OriginalArrivalTime: 14 Mar 2006 11:23:35.0732 (UTC) FILETIME=[BBEF4740:01C64759] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 This is a multi-part message in MIME format. ------_=_NextPart_001_01C64759.B8E1F68C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Francois, =20 Thanks for the information. =20 This is exactly what I want to ask. It seems that I misunderstood, that the 6PE will also be responsible for = handling the IPv4 Traffic. =20 Best Regards, Dheeraj =20 ________________________________ From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: Tue 3/14/2006 3:43 PM To: Dheeraj Singh (WT01 - Broadband Networks) Cc: idr@ietf.org; dirk@onesparrow.com; jeremy.de_clercq@alcatel.be; = stuart.prevost@bt.com; v6ops@ops.ietf.org; Eric Levy- Abegnoli = (elevyabe) Subject: RE: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Hello Dheeraj, It seems that Eric's message didn't make it on the alias, so I am including it below. As pointed out by Eric, IPv4 packets from the CE can be handled by the PE as per existing IPv4 MPLS procedures. This doesn't interact in any way with the handling of IPv6 packets as described in the 6PE document. Can you confirm you are comfortable with this approach (or identify any remaining concerns)? Thanks Francois >> -----Original Message----- >> From: Eric Levy- Abegnoli (elevyabe) >> Sent: jeudi 9 mars 2006 17:16 >> To: dheeraj.singh@wipro.com >> Cc: idr@ietf.org; dirk@onesparrow.com; Francois Le Faucheur >> (flefauch); jeremy.de_clercq@alcatel.be; >> stuart.prevost@bt.com; v6ops@ops.ietf.org >> Subject: Re: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review >> >> On jeudi 9 Mars 2006 06:43, dheeraj.singh@wipro.com wrote: >> > Hi, >> > >> > Just consider the scenario in which the CE also supports >> the IPv4. Then >> > how the IPv4 MPLS cloud will cater this specific IPv4 packet. >> >> What about it ? I don't see anything in the draft that will >> prevent such >> packet to be handled "as usual" by the PE and the MPLS cloud. >> Eric >> > >> > BR, >> > Dheeraj >> > >> > >> > ________________________________ >> > >> > From: owner-v6ops@ops.ietf.org on behalf of Fred Baker >> > Sent: Thu 3/9/2006 5:46 AM >> > To: v6ops@ops.ietf.org >> > Subject: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review >> > >> > >> > >> > We have been asked to read and comment on >> > >> > http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp- >> > tunnel-06.txt >> > "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge >> > Routers >> > (6PE)", Jeremy De Clercq, 18-Jan-06, > > tunnel-06.txt> >> > >> > which is about to go into IESG review. As you will recall, this has >> > been round the block, and deserves speedy review. May I >> suggest that >> > you get your comments in by 17 March at the latest. Reply to the >> > authors copying idr; if you are not on the list, the working group >> > chairs will deal with the moderation issues. >> ------_=_NextPart_001_01C64759.B8E1F68C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review=0A= =0A= =0A=
=0A=
Hello = Francois,
=0A=
 
=0A=
Thanks for the information.
=0A=
 
=0A=
This is exactly what I want to = ask.
=0A=
It seems that I misunderstood, that the = 6PE will also =0A= be responsible for handling the IPv4 Traffic.
=0A=
 
=0A=
Best Regards,
=0A=
Dheeraj
=0A=
 
=0A=

=0A=
=0A= From: Francois Le Faucheur = (flefauch) =0A= [mailto:flefauch@cisco.com]
Sent: Tue 3/14/2006 3:43 = PM
To: =0A= Dheeraj Singh (WT01 - Broadband Networks)
Cc: idr@ietf.org; =0A= dirk@onesparrow.com; jeremy.de_clercq@alcatel.be; stuart.prevost@bt.com; =0A= v6ops@ops.ietf.org; Eric Levy- Abegnoli (elevyabe)
Subject: = RE: =0A= draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review

=0A=
=0A=

Hello Dheeraj,

It seems that Eric's message = didn't make =0A= it on the alias, so I am
including it below.

As pointed out by = Eric, =0A= IPv4 packets from the CE can be handled by the
PE as per existing = IPv4 MPLS =0A= procedures. This doesn't interact in any
way with the handling of = IPv6 =0A= packets as described in the 6PE document.

Can you confirm you are =0A= comfortable with this approach (or identify any
remaining =0A= concerns)?

Thanks

Francois

>> -----Original =0A= Message-----
>> From: Eric Levy- Abegnoli = (elevyabe)
>> Sent: =0A= jeudi 9 mars 2006 17:16
>> To: = dheeraj.singh@wipro.com
>> Cc: =0A= idr@ietf.org; dirk@onesparrow.com; Francois Le Faucheur
>> = (flefauch); =0A= jeremy.de_clercq@alcatel.be;
>> stuart.prevost@bt.com; =0A= v6ops@ops.ietf.org
>> Subject: Re: = draft-ooms-v6ops-bgp-tunnel-06.txt =0A= and v6ops review
>>
>> On jeudi 9 Mars 2006 06:43, =0A= dheeraj.singh@wipro.com wrote:
>> > Hi,
>> = >
>> =0A= > Just consider the scenario in which the CE also = supports
>> the =0A= IPv4.  Then
>> > how the IPv4 MPLS cloud will cater = this =0A= specific IPv4 packet.
>>
>> What about it ? I don't = see =0A= anything in the draft that will
>> prevent such
>> = packet to =0A= be handled "as usual" by the PE and the MPLS cloud.
>> = Eric
>> =0A= >
>> > BR,
>> > Dheeraj
>> = >
>> =0A= >
>> > ________________________________
>> =0A= >
>> > From: owner-v6ops@ops.ietf.org on behalf of Fred =0A= Baker
>> > Sent: Thu 3/9/2006 5:46 AM
>> > To: =0A= v6ops@ops.ietf.org
>> > Subject: = draft-ooms-v6ops-bgp-tunnel-06.txt =0A= and v6ops review
>> >
>> >
>> = >
>> =0A= > We have been asked to read and comment on
>> = >
>> =0A= >    http:/= /www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-
>> =0A= > tunnel-06.txt
>> >    "Connecting IPv6 = Islands =0A= over IPv4 MPLS using IPv6 Provider Edge
>> > = Routers
>> =0A= >    (6PE)", Jeremy De Clercq, 18-Jan-06, =0A= <draft-ooms-v6ops-bgp-
>> > tunnel-06.txt>
>> =0A= >
>> > which is about to go into IESG review. As you will = recall, =0A= this has
>> > been round the block, and deserves speedy = review. May =0A= I
>> suggest that
>> > you get your comments in by = 17 March =0A= at the latest. Reply to the
>> > authors copying idr; if you = are not =0A= on the list, the working group
>> > chairs will deal with = the =0A= moderation issues.
>>

=0A= =0A= =0A= ------_=_NextPart_001_01C64759.B8E1F68C-- From owner-v6ops@ops.ietf.org Wed Mar 15 12:42:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJa0i-0004fe-6B for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 12:42:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJa0h-0000cc-T7 for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 12:42:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJZx4-0001VJ-SF for v6ops-data@psg.com; Wed, 15 Mar 2006 17:38:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJZx4-0001V0-BG for v6ops@ops.ietf.org; Wed, 15 Mar 2006 17:38:26 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 15 Mar 2006 09:38:25 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2FHcPYg006087 for ; Wed, 15 Mar 2006 09:38:25 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2FHdCit004294 for ; Wed, 15 Mar 2006 09:39:49 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DD30F67-F7D0-4477-B009-0FE4457554C8@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: Jabber service for IETF meetings Date: Wed, 15 Mar 2006 09:38:24 -0800 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1596; t=1142444389; x=1142876589; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Fwd=3A=20Jabber=20service=20for=20IETF=20meetings=20 |To:v6ops@ops.ietf.org; X=v=3Dmtcc.com=3B=20h=3D4yr0Slm9Ay+oty17xPiZtmzGrz4=3D; b=grS9N7MT5A31mKoOMi/8zzUA72X86ZX6aXkCLgXnlFCGNbI0/BbxCC/KEd4/kyhy4BtT1y/f SxTWgghMbodUTXCmbrdT36Lrh3EdsBYR/HCGMM1NqIBDYgQJpZED928FZjvfGtyXwvKIKe3ZY9T KUKkS5Wc6KqsRYUi+iox6j8E=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 We will be using the new jabber service in the meeting next week. Begin forwarded message: > From: IETF Secretariat > Date: March 14, 2006 8:26:27 PM PST > To: Working Group Chairs > Subject: Jabber service for IETF meetings > Reply-To: ietf-secretariat-reply@ietf.org > > Dear IETF WG Chairs, > > The Secretariat is pleased to announce a new Instant Messaging > service. This > service will provide jabber chat rooms to all IETF working groups > for their text > conferencing at IETF 65 and future meetings. > > The new jabber server is located at jabber.ietf.org and is currently > accessible. For those who are interested, please visit the above > location to > join any of the available chat rooms. > > Over the next few days, please take the time to test this new > service and > provide us with all questions, comments, and suggestions. Your > feedback is key > to our success! > > Please note: > > All traffic within the defined rooms (except "noc") is being logged > and updated > every 5 minutes to the ietf.org website. > > To view the log directories, point your browser to > http://www.ietf.org/meetings/ietf-logs/. > > If you click on a room directory, you will see one or more files named > "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you click on one of > those files, > you will see all logged traffic for that day. > > Please visit the IETF Text Conferencing Web page > (http://www.ietf.org/meetings/text_conf.html) for more information. > > The IETF Secretariat. From owner-v6ops@ops.ietf.org Wed Mar 15 13:16:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJaYN-0003r6-C4 for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 13:16:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJaYM-0002Hp-1t for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 13:16:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJaVD-0001na-24 for v6ops-data@psg.com; Wed, 15 Mar 2006 18:13:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJaVC-0001nN-Gc for v6ops@ops.ietf.org; Wed, 15 Mar 2006 18:13:42 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2006 09:58:27 -0800 X-IronPort-AV: i="4.02,195,1139212800"; d="scan'208"; a="314478466:sNHT15555890512" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2FHwQGv019903 for ; Wed, 15 Mar 2006 09:58:26 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2FHxn6p004491 for ; Wed, 15 Mar 2006 09:59:50 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <7DD30F67-F7D0-4477-B009-0FE4457554C8@cisco.com> References: <7DD30F67-F7D0-4477-B009-0FE4457554C8@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13B107F2-617F-4C46-9604-06D848118657@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Jabber service for IETF meetings Date: Wed, 15 Mar 2006 09:58:25 -0800 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1776; t=1142445590; x=1142877790; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Jabber=20service=20for=20IETF=20meetings=20 |To:v6ops@ops.ietf.org; X=v=3Dmtcc.com=3B=20h=3DaWnKNOlAZpzkihtqdGLw5ldhwAg=3D; b=n5cKQEPsXw3WXnQfpy4zKyNLyoqSGMAzBR9UgnB1zOL+3epEUDwxcG+KqFWdrR5X4FzJd1fF oQRrRTC8qEH+q6QzNp/NRf+tAtn5kmovJIIr5xa+2iA103tqyYX4CaB1SOvLAWzK1rolU4YaNqo 0PTpiFiBzxCo8Al3/uv2Grmw=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Looks like it is v6ops@rooms.jabber.ietf.org, not v6ops@jabber.ietf.org On Mar 15, 2006, at 9:38 AM, Fred Baker wrote: > We will be using the new jabber service in the meeting next week. > > Begin forwarded message: > >> From: IETF Secretariat >> Date: March 14, 2006 8:26:27 PM PST >> To: Working Group Chairs >> Subject: Jabber service for IETF meetings >> Reply-To: ietf-secretariat-reply@ietf.org >> >> Dear IETF WG Chairs, >> >> The Secretariat is pleased to announce a new Instant Messaging >> service. This >> service will provide jabber chat rooms to all IETF working groups >> for their text >> conferencing at IETF 65 and future meetings. >> >> The new jabber server is located at jabber.ietf.org and is currently >> accessible. For those who are interested, please visit the above >> location to >> join any of the available chat rooms. >> >> Over the next few days, please take the time to test this new >> service and >> provide us with all questions, comments, and suggestions. Your >> feedback is key >> to our success! >> >> Please note: >> >> All traffic within the defined rooms (except "noc") is being >> logged and updated >> every 5 minutes to the ietf.org website. >> >> To view the log directories, point your browser to >> http://www.ietf.org/meetings/ietf-logs/. >> >> If you click on a room directory, you will see one or more files >> named >> "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you click on one of >> those files, >> you will see all logged traffic for that day. >> >> Please visit the IETF Text Conferencing Web page >> (http://www.ietf.org/meetings/text_conf.html) for more information. >> >> The IETF Secretariat. From owner-v6ops@ops.ietf.org Wed Mar 15 13:44:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJazS-0000tl-Fy for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 13:44:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJazR-0002kf-5s for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 13:44:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJayq-0004EM-HS for v6ops-data@psg.com; Wed, 15 Mar 2006 18:44:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS, UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [128.182.66.106] (helo=mailer2.psc.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJayp-0004E7-LF for v6ops@ops.ietf.org; Wed, 15 Mar 2006 18:44:19 +0000 Received: from [128.182.160.59] (lassa.psc.edu [128.182.160.59]) (authenticated bits=0) by mailer2.psc.edu (8.13.4/8.13.3) with ESMTP id k2FIiI3R010718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2006 13:44:18 -0500 (EST) Message-ID: <4418608A.1050100@psc.edu> Date: Wed, 15 Mar 2006 13:44:26 -0500 From: Michael Lambert User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: Fwd: Jabber service for IETF meetings References: <7DD30F67-F7D0-4477-B009-0FE4457554C8@cisco.com> In-Reply-To: <7DD30F67-F7D0-4477-B009-0FE4457554C8@cisco.com> X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Fred Baker wrote: > We will be using the new jabber service in the meeting next week. Is it really there yet? % dig -t aaaa jabber.ietf.org ; <<>> DiG 9.2.2 <<>> -t aaaa jabber.ietf.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7212 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;jabber.ietf.org. IN AAAA ;; AUTHORITY SECTION: ietf.org. 572 IN SOA oak.neustar.com. sec_grp.neustar.biz. 1142370501 21600 3600 604800 86400 ;; Query time: 13 msec ;; SERVER: 128.182.58.3#53(128.182.58.3) ;; WHEN: Wed Mar 15 13:41:56 2006 ;; MSG SIZE rcvd: 103 Michael From owner-v6ops@ops.ietf.org Wed Mar 15 14:01:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbFH-0000mp-L8 for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 14:01:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbFG-0003Nh-BL for v6ops-archive@lists.ietf.org; Wed, 15 Mar 2006 14:01:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJbEh-0005Ty-3S for v6ops-data@psg.com; Wed, 15 Mar 2006 19:00:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJbEf-0005TZ-9b for v6ops@ops.ietf.org; Wed, 15 Mar 2006 19:00:41 +0000 Received: from [IPv6:2001:620:20:1000:202:55ff:fee6:21e8] (unknown [IPv6:2001:620:20:1000:202:55ff:fee6:21e8]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4BF738070; Wed, 15 Mar 2006 20:00:32 +0100 (CET) Subject: Re: Jabber service for IETF meetings From: Jeroen Massar To: Fred Baker Cc: v6ops@ops.ietf.org In-Reply-To: <13B107F2-617F-4C46-9604-06D848118657@cisco.com> References: <7DD30F67-F7D0-4477-B009-0FE4457554C8@cisco.com> <13B107F2-617F-4C46-9604-06D848118657@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dKgx+y3CDVfXWkSoLBz7" Organization: Unfix Date: Wed, 15 Mar 2006 20:00:25 +0100 Message-Id: <1142449225.4632.177.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 --=-dKgx+y3CDVfXWkSoLBz7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-03-15 at 09:58 -0800, Fred Baker wrote: > Looks like it is v6ops@rooms.jabber.ietf.org, not v6ops@jabber.ietf.org *pfew* I was not the only one making that mistake then ;) The http://www.ietf.org/meetings/text_conf.html describes this I found out after noticing that the other didn't work. On Wed, 2006-03-15 at 13:44 -0500, Michael Lambert wrote:=20 > Fred Baker wrote: > > We will be using the new jabber service in the meeting next week. >=20 > Is it really there yet? >=20 > % dig -t aaaa jabber.ietf.org I don't think that will come any time soon either. According to my little list at http://www.sixxs.net/tools/grh/dfp/arin/ Neustar doesn't have their own alloc yet, though they might of course get connectivity from some ISP to arrange this. Maybe a good question to ask the Neustar guys ? If they need it I can arrange connectivity most likely. _xmpp-client._tcp.jabber.ietf.org SRV 5 0 5222 jabber.ietf.org _xmpp-server._tcp.jabber.ietf.org SRV 5 0 5269 jabber.ietf.org _xmpp-server._tcp.rooms.jabber.ietf.org SRV 5 0 5269 jabber.ietf.org Is there but points to the same host. David did seem to have secured 2001:df8::/32 as a temporary allocation for the IETF65, thus IPv6 connectivity in Dallas should work at least, there is no transit available of course ;) Greets, Jeroen --=-dKgx+y3CDVfXWkSoLBz7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBEGGRJKaooUjM+fCMRAogXAJwOhShHNgNNxPOe4m2kX8Vrg+tnuACeLsn9 CKwicp50Bei+z3auW3OmQ+E= =38GH -----END PGP SIGNATURE----- --=-dKgx+y3CDVfXWkSoLBz7-- From owner-v6ops@ops.ietf.org Thu Mar 16 03:55:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoEy-0005bQ-Rz for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 03:53:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJo17-0000ma-Pj for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 03:39:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJnwV-0000PT-7X for v6ops-data@psg.com; Thu, 16 Mar 2006 08:34:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.62.9] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJnwT-0000PE-S0 for v6ops@ops.ietf.org; Thu, 16 Mar 2006 08:34:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id E29F589BBF; Thu, 16 Mar 2006 09:34:43 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31730-01-70; Thu, 16 Mar 2006 09:34:43 +0100 (CET) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 4C4FE89BBD; Thu, 16 Mar 2006 09:34:43 +0100 (CET) Message-ID: <44192323.3070505@uninett.no> Date: Thu, 16 Mar 2006 09:34:43 +0100 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" Cc: v6ops@ops.ietf.org, tjc@ecs.soton.ac.uk, cpopovic@cisco.com Subject: Re: Fwd: IPv6 Unicast Address Assignment Considerations References: <4.3.2.7.2.20060305095545.03770588@strange-brew> In-Reply-To: <4.3.2.7.2.20060305095545.03770588@strange-brew> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Some comments on 3.3.2. Addresses used by Embedded-RP (RFC3956) Embedded-RP [18] reflects the concept of integrating the Rendezvous Point (RP) IPv6 address into the IPv6 multicast group address. Due to this embedding and the fact that the length of the IPv6 address AND the IPv6 multicast address are 128 bits, it is not possible to have the complete IPv6 address of the multicast RP embedded as such. This limitation resulted in a restriction of 15 possible multicast addresses per subnet prefix. The space assigned for the embedded-RP The number of multicast addresses per prefix is huge, what you want to say, is that there are 15 possible RP addresses per prefix that can be used with embedded-RP. For each of those you have 32 bits for multicast addresses. is based on the 4 low order bits, while the remainder of the Interface ID is set to all '0'. [IPv6-prefix (64 bits)][60 bits all '0'][RIID] Where: [RIID] = 4 bit. This leads to the constraint that when creating subnet lengths longer than 64 bits, the bits between bit 65 and the subnet boundary should not be set to be all "0". I don't understand this constraint. If all 64 low order bits (apart from the lowest 4) are 0 it's possible to use embedded-RP even for prefixes longer than /64. This is perhaps not so good, but it would work just fine. If you choose subnets with prefixes longer than 64 where all those bits are non-zero, then you cannot use embedded-RP with an RP address belonging to that subnet. So while I don't understand your constraint as written in the draft, it might be worth pointing out what I wrote above. In general it might be good to say that when choosing addresses for routers, it might be worth considering whether the addresses work with embedded-RP. If you might want to use embedded-RP where that router is an RP, then it should have at least one "embeddable" address. I suppose in many cases (at least AFAIK) people would use an additional loopback address on a router as RP address. This makes it easy to move the RP to another router. Especially for embedded-RP this is useful, since you don't want to change the group addresses applications use just because you want to move the RP. This loopback addresses then need to be "embeddable". In this case, it doesn't matter what addresses the router uses on the physical interfaces. Stig From owner-v6ops@ops.ietf.org Thu Mar 16 03:58:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoJG-0008Pd-9m for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 03:58:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoJF-0001Bz-Rt for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 03:58:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoIP-0001tS-3i for v6ops-data@psg.com; Thu, 16 Mar 2006 08:57:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoIO-0001tG-6O for v6ops@ops.ietf.org; Thu, 16 Mar 2006 08:57:24 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2G8vGc01803; Thu, 16 Mar 2006 09:57:16 +0100 (CET) Received: from gvandeve-w2k01.cisco.com (rtp-vpn2-168.cisco.com [10.82.240.168]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2G8vFC03937; Thu, 16 Mar 2006 09:57:15 +0100 (CET) Message-Id: <4.3.2.7.2.20060316094459.05160f88@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Mar 2006 09:57:11 +0100 To: Stig Venaas From: "Gunter Van de Velde (gvandeve)" Subject: Re: Fwd: IPv6 Unicast Address Assignment Considerations Cc: v6ops@ops.ietf.org, tjc@ecs.soton.ac.uk, cpopovic@cisco.com In-Reply-To: <44192323.3070505@uninett.no> References: <4.3.2.7.2.20060305095545.03770588@strange-brew> <4.3.2.7.2.20060305095545.03770588@strange-brew> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Hi Stig, Thanks for the review and reading the document. Please see inline: At 09:34 16/03/2006 +0100, Stig Venaas wrote: >Some comments on 3.3.2. Addresses used by Embedded-RP (RFC3956) > > Embedded-RP [18] reflects the concept of integrating the Rendezvous > Point (RP) IPv6 address into the IPv6 multicast group address. Due > to this embedding and the fact that the length of the IPv6 address > AND the IPv6 multicast address are 128 bits, it is not possible to > have the complete IPv6 address of the multicast RP embedded as such. > > This limitation resulted in a restriction of 15 possible multicast > addresses per subnet prefix. The space assigned for the embedded-RP > >The number of multicast addresses per prefix is huge, what you want to >say, is that there are 15 possible RP addresses per prefix that can be >used with embedded-RP. For each of those you have 32 bits for multicast >addresses. That is exactly what we wanted to mention. We will revise the text. > is based on the 4 low order bits, while the remainder of the > Interface ID is set to all '0'. > > > [IPv6-prefix (64 bits)][60 bits all '0'][RIID] > > Where: [RIID] = 4 bit. > > > This leads to the constraint that when creating subnet lengths longer > than 64 bits, the bits between bit 65 and the subnet boundary should > not be set to be all "0". > >I don't understand this constraint. If all 64 low order bits (apart from >the lowest 4) are 0 it's possible to use embedded-RP even for prefixes >longer than /64. This is perhaps not so good, but it would work just fine. >If you choose subnets with prefixes longer than 64 where all those bits >are non-zero, then you cannot use embedded-RP with an RP address belonging >to that subnet. So while I don't understand your constraint as written in >the draft, it might be worth pointing out what I wrote above. The above text is pointing towards an awareness (maybe the word 'constraint' was too strong). If one makes a subnet longer as 64 bits, that the all '0' should/may be avoided as there is risk that one of the addresses could in that case overlap with an embedded-RP address. And yes, it will/should still work as unicast IPv6 address, but i think it is not very good practice to have addresses used that have may have double usage/meaning. I also see the point you are making and it makes a good addition to the draft. >In general it might be good to say that when choosing addresses for >routers, it might be worth considering whether the addresses work with >embedded-RP. If you might want to use embedded-RP where that router is an >RP, then it should have at least one "embeddable" address. > >I suppose in many cases (at least AFAIK) people would use an additional >loopback address on a router as RP address. This makes it easy to move the >RP to another router. Especially for embedded-RP this is useful, since you >don't want to change the group addresses applications use just because >you want to move the RP. This loopback addresses then need to be >"embeddable". In this case, it doesn't matter what addresses the router >uses on the physical interfaces. I agree. Although the above text is more a design recommendation which is not the main focus of this draft. Thanks again, G/ >Stig From owner-v6ops@ops.ietf.org Thu Mar 16 03:58:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoJO-0008Pp-OC for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 03:58:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoJO-0001C4-7O for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 03:58:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoIy-0001w2-56 for v6ops-data@psg.com; Thu, 16 Mar 2006 08:58:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.62.9] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoIx-0001vr-3o for v6ops@ops.ietf.org; Thu, 16 Mar 2006 08:57:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 3C38595B51; Thu, 16 Mar 2006 09:57:58 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06875-01-84; Thu, 16 Mar 2006 09:57:57 +0100 (CET) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 5BDAE8DB9B; Thu, 16 Mar 2006 09:57:57 +0100 (CET) Message-ID: <44192895.8020404@uninett.no> Date: Thu, 16 Mar 2006 09:57:57 +0100 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans References: <3D1C81E7AA3CD64FA20B04D269FEF7F4013E6CF5@xmb-rtp-213.amer.cisco.com> <20060302085311.GC28111@login.ecs.soton.ac.uk> In-Reply-To: <20060302085311.GC28111@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Tim Chown wrote: > Are there also possibily PIM issues? Would using only link locals cause > problems for PIM-SM where the Register messages are sent to the RP from > a link-local interface on a CPE acting as the DR? For example, with the > Register Stop messages? We ran into this a while ago, but I can't > remember the specifics right now :) The PIM-SM update, draft-ietf-pim-sm-v2-new-11.txt, points out that the source address of the PIM Register message must be reachable throughout the domain. I would assume that implementations would use a global address if the router has at least one global address. If you use only link-locals on the link, then the CPE hopefully has a global address on the customer side that can be used as source address (or perhaps a loopback address)... The problem you/we ran into, was that an RFC 1918 address was picked as source address... There might be similar issues with reachability of ULAs perhaps... Stig > > I agree with Fred; from a management point of view, the less explicit > numbering required the better, as that implies the least renumbering at > a later date... > > Tim > > On Wed, Mar 01, 2006 at 04:39:30PM -0500, Chip Popoviciu (cpopovic) wrote: > >>Along these lines there are two other aspects that are worth >>considering: >> >>1. A single address with scope larger than link-local would indeed be >>sufficient for a router as long as the network management policies and >>tools do not need to reach specific interfaces for troubleshooting >>purposes for example. >> >>2. In the case of a Service Provider that offers VPN services, an >>address with a scope larger than link-local is necessary for each VRF >>for things such as PMTU discovery. In that case, it might be easier to >>simply assign that address to the PE-CE link rather than create for >>example a loopback for each VRF. >> >>In principle link-locals are sufficient for the PE-CE link however in >>practice, all little details considered, people might end up assigning >>more than that to the link. And in that sense, it will be better to use >>a prefix set aside by the SP for its own infrastructure rather than what >>is delegated to the customer (as Ole mentioned). >> >>Regards, >>Chip >> >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >>Behalf Of Fred Baker (fred) >>Sent: Wednesday, March 01, 2006 11:30 AM >>To: Bonness, Olaf >>Cc: Ole Troan (otroan); jordi.palet@consulintel.es; v6ops@ops.ietf.org >>Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and >>Easing the Addressing Plans >> >>My assumption as a routing geek is that the only reasonable use of a >>numbered point to point link is to address an end station; it needs an >>address to be useful in the network. But any router/router point- >>to-point interface should be supportable using link-local addresses. >>A router needs one address reachable by its administration (eg non- >>link-local), to be a member of any prefix on a LAN that it is serving, >>and to be able to reach p/p-connected end stations it serves. >> >>On Mar 1, 2006, at 5:41 AM, Bonness, Olaf wrote: >> >> >>>> 4. Routing Aggregation of the Point-to-Point Links >>>> >>>> Following this approach and assuming that a shorter prefix is >>>> typically delegated to a customer, in general a /48 [4], it is >>>> possible to simplify the routing aggregation of the point-to-point >>>> links. Towards this, the point-to-point link may be numbered >>>>using >>>> the first /64 of a given /48. >>>> >>>>using the first (or any) subnet of a larger prefix, breaks the >>>>conceptual model of DHCP prefix delegation. the prefix is delegated >>>>to the requesting router and cannot be used to number the link >>>>between the delegating and requesting router. >>> >>>My assumption from a service provider point of view would be to use a >>>dedicated sub-preaefix (e.g. /48)of my own aggregate to address the >>>point-to-point links (e.g. /64) to the custumers (in the case I have >>>to do this). >>> >>>cu >>> Olaf >> > From owner-v6ops@ops.ietf.org Thu Mar 16 04:18:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJocW-0001zO-9t for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 04:18:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJocV-0002NE-O1 for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 04:18:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoay-0003Mk-FW for v6ops-data@psg.com; Thu, 16 Mar 2006 09:16:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoax-0003MX-CE for v6ops@ops.ietf.org; Thu, 16 Mar 2006 09:16:35 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2G9GYh03240; Thu, 16 Mar 2006 10:16:34 +0100 (CET) Received: from gvandeve-w2k01.cisco.com (rtp-vpn2-168.cisco.com [10.82.240.168]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2G9GWC22457; Thu, 16 Mar 2006 10:16:32 +0100 (CET) Message-Id: <4.3.2.7.2.20060316095750.051b14e0@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Mar 2006 10:16:26 +0100 To: "John Spence" From: "Gunter Van de Velde (gvandeve)" Subject: RE: IPv6 Unicast Address Assignment Considerations Cc: In-Reply-To: <001401c64255$c8427610$90dc16ac@laptop220> References: <4.3.2.7.2.20060305095545.03770588@strange-brew> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Hi John, Thanks for the review and reading the text. See inline At 18:12 7/03/2006 -0800, John Spence wrote: >Guys - nice IETF Draft. Lots of good considerations in there. I'd like to >participate, so I've got some things to think about below. Clarifications, >suggestions - hope they help move the discussion forward. > >Comments. > >*) In 1.0, you talk about Site-local and ULA. Not sure if this should go >into the document, but during the transition this can be very tricky. Most >implementations know about Site-local even though it is deprecated, and do >not know about ULAs - even though they are to spec. I'm not sure, but my >guess is that may confuse the address selection algorithm in the transition >period. Since your document is implementation-oriented, this might be worth >a mention. ok, will make a note of that in the text. >*) Also in 1.0, you know that ARIN is considering portable address to >address the multihoming issue - right? Not done yet, but I'll bet it goes >through. > >http://www.arin.net/policy/proposals/2006_4.html > Is there an indication when they will happen? I think the draft should follow as its implementation oriented, but not lead as long as the ARIN decision is not fallen. > >*) In 2.1, consider a sentence pointing out that scattering subnet /64 >assignments, while still maintaining the ability to summarize routes, may >make active subnets harder to find, or guess, for an outsider, but that it >comes at the cost of complexity for the network operations team. ok, will do. It fits inline with the IPv6 NAP concept >*) Also in 2.1, I'm not sure if it is the right place to mention it, but >today multihoming, with the aggregation model, pretty much means using >Policy Based Routing - do you agree? If the source address will be chosen >based on the destination address, some mechanism must be used to make sure >the traffic egresses at the right interface through the right ISP. If what one wants to achieve is that when sending packets that just those packets from a certain IPv6 source-address-range gets routed to/over the ISP responsible for that range. That is not always true as the network administrator may have a different policy of load-balancing. One item to keep in mind is the impact on RPF checks. IPv6 RPF check may very well break connectivity in IPv6 due to the aggregation principles. I'm not sure if this has been researched yet. >*) In 2.2, you mention that a ULA is a /48 prefix. You are correct per the >spec. There was some traffic on the mailing list from before the RFC was >published where I suggested it be better to be more flexible on the length. >Suppose a site has a /47 because they are large enough to warrant it. They >would probably like a /47 ULA to go with it, rather than using 2 /48s. The >authors suggested that the spec was fine as is, but since these are internal >addresses enterprises could do what they wanted about using a shorter prefix >if that met their needs. So, again, not sure it should go in, but it is >worth thinking about. i think as 'per spec' must be in the document. The /47 can be good to add as background context, but i'm not sure that is within the scope we intended. Maybe there are other opinions from people in the v6ops alias or from the co-authors? >*) In 2.2 you have the word "chgoose" when you mean "choose". oeps... thanks :-) >*) In 2.4, you mention that multiple /48s in a single enterprise will be >non-contiguous, and that is not good for summarization. I agree, but do you >think that would be a problem in practice, since a whole /48 is still a >large summary route. If you had a really big enterprise (say /40), if you >have /48 summarization that is only 256 routes in the internal-enterprise >backbone routers. Seems pretty good. Now if you had a lot of /62s, or >/60s, that would be a problem. But I don't know if having to announce, say, >8 /48s when you might have been able to announce a single /45 would make a >big difference, in practice. Thanks, i believe we can make a note of your observation in the text >*) Man, it is hard to keep up. You reference RFC 3513 - 4219 is out now. > >ftp://ftp.rfc-editor.org/in-notes/rfc4291.txt tx. will adjust >*) In 3.3.1, the Subnet Anycast Address is where all the non-prefix bits are >all zeros: > >ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt (2.6.1) > >http://www.iana.org/assignments/ipv6-anycast-addresses > >*) In 4.2, for "reverse DNS lookup", I suggest making it more clear that >using privacy extensions for a host that needs to be in the DNS, if not >using DDNS, is not recommended, as is practically impossible to maintain. I >think some people might not get that from what you have. ok, we can rewrite. I will leave the other sections for Tim as he edited the study. >*) In 5.1, can you include an estimate of the number of subnets too? >*) In 5.1.1, do not some people use site-local or ULA address for the >infrastructure not because they are lacking addresses, but for security >reasons, figuring that there need be no outside-the-enterprise >communications with the control-plane, and so using ULAs improves security? >If so, you might note that here as a practical consideration. > >*) In 5.1.2, does the allocation of a /56 to each school result in, >essentially, smooth aggregation for the network? Or do you leave that >behind, figuring that /56s are large enough summaries by themselves, because >the convenience of having each school on a /56 yields other benefits (than >full summarization)? > >*) In 5.1.4, do you really let hosts autoconfigure, then put their address >manually in the DNS? Why not give them a simpler, manual address that would >survive NIC swap-outs? > Many thanks again for your detailed review comments and observations, Groetjes, G/ >-----Original Message----- >From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf >Of Gunter Van de Velde (gvandeve) >Sent: Sunday, March 05, 2006 12:58 AM >To: v6ops@ops.ietf.org >Cc: tjc@ecs.soton.ac.uk; cpopovic@cisco.com >Subject: Fwd: IPv6 Unicast Address Assignment Considerations > >Resend of original message as i apparently did not reach the overall v6ops >alias. > >G/ > > >Date: Tue, 21 Feb 2006 13:34:00 +0100 > >To: v6ops@ietf.org > >From: "Gunter Van de Velde (gvandeve)" > >Subject: IPv6 Unicast Address Assignment Considerations > >Cc: tjc@ecs.soton.ac.uk, cpopovic@cisco.com > > > >Dear all, > > > >The authors of the following draft would be interested in comments > >on the draft > > > >http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-addcon-00.txt > > > >Kind Regards, > >G/ From owner-v6ops@ops.ietf.org Thu Mar 16 07:04:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJrD7-00018n-FK for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 07:04:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJrD6-0007AB-0S for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 07:04:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJrAY-000F7D-1o for v6ops-data@psg.com; Thu, 16 Mar 2006 12:01:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJrAU-000F6o-Fe for v6ops@ops.ietf.org; Thu, 16 Mar 2006 12:01:26 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k2GC2rHN026164 for ; Thu, 16 Mar 2006 12:02:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k2GC1Ko09427 for v6ops@ops.ietf.org; Thu, 16 Mar 2006 12:01:20 GMT Date: Thu, 16 Mar 2006 12:01:19 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: IPv6 Unicast Address Assignment Considerations Message-ID: <20060316120119.GN3585@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <4.3.2.7.2.20060305095545.03770588@strange-brew> <4.3.2.7.2.20060316095750.051b14e0@strange-brew> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20060316095750.051b14e0@strange-brew> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 On Thu, Mar 16, 2006 at 10:16:26AM +0100, Gunter Van de Velde (gvandeve) wrote: > > At 18:12 7/03/2006 -0800, John Spence wrote: > > >*) Also in 1.0, you know that ARIN is considering portable address to > >address the multihoming issue - right? Not done yet, but I'll bet it goes > >through. > > > >http://www.arin.net/policy/proposals/2006_4.html > > Is there an indication when they will happen? I think the draft should > follow > as its implementation oriented, but not lead as long as the ARIN decision > is not fallen. I've been following this through some Internet2 contacts, and it seems to have dragged for at least 12 months so far. So if it does happen, I wouldn't bet on it being soon. I think the draft can say no such process exists now for PI, but that some scheme may emerge over time. > >*) Also in 2.1, I'm not sure if it is the right place to mention it, but > >today multihoming, with the aggregation model, pretty much means using > >Policy Based Routing - do you agree? If the source address will be chosen > >based on the destination address, some mechanism must be used to make sure > >the traffic egresses at the right interface through the right ISP. > > If what one wants to achieve is that when sending packets that just those > packets > from a certain IPv6 source-address-range gets routed to/over the ISP > responsible > for that range. That is not always true as the network administrator may > have a different policy of load-balancing. One item to keep in mind is the > impact on RPF checks. IPv6 RPF check may very well break connectivity > in IPv6 due to the aggregation principles. I'm not sure if this has been > researched yet. I think a number of these issues in IPv6 space were investigated when Christian Huitema's 'what can we do today' multihoming proposal was discussed in the days of the multi6 WG. I think the problem is still outstanding. > >*) In 2.2, you mention that a ULA is a /48 prefix. You are correct per the > >spec. There was some traffic on the mailing list from before the RFC was > >published where I suggested it be better to be more flexible on the length. > >Suppose a site has a /47 because they are large enough to warrant it. > > i think as 'per spec' must be in the document. The /47 can be good to add > as background context, but i'm not sure that is within the scope we > intended. > Maybe there are other opinions from people in the v6ops alias or from the > co-authors? Ideally if I needed to use local addresses and needed more than a /48 I could use an aggregated prefix. But the ULA spec doesn't cater for that. The Centralised ULA spec could, but I think that one's dead in the water? > I will leave the other sections for Tim as he edited the study. OK, but you have the edit token :) > >*) In 5.1, can you include an estimate of the number of subnets too? There are around 1,500 hosts in around 20 IPv4 subnets ranging from /23 down to /28 size. Keeping IPv4 subnets shrinkwrapped to host counts is an IPv4-specific pain. > >*) In 5.1.1, do not some people use site-local or ULA address for the > >infrastructure not because they are lacking addresses, but for security > >reasons, figuring that there need be no outside-the-enterprise > >communications with the control-plane, and so using ULAs improves security? > >If so, you might note that here as a practical consideration. We follow the guidelines of the NAP draft, and thus consider all hosts to be globally addressed and use filtering at appropriate borders to constrain access. Modern campus switch-router equipment enables such filtering to be done very efficiently on an intranet basis too. I do appreciate it's a method some people use now in IPv4, but my understanding of the NAP ethos is to globally address all nodes. I wouldn't want the draft to be derailed by some religious aside though :) > >*) In 5.1.2, does the allocation of a /56 to each school result in, > >essentially, smooth aggregation for the network? Or do you leave that > >behind, figuring that /56s are large enough summaries by themselves, > >because > >the convenience of having each school on a /56 yields other benefits (than > >full summarization)? That was based on the organisational considerations of the university. Off hand there are I think around 20 schools; thus a /56 per school seemed appropriate. We felt that a common allocation size per school would also simplify management, and a /56 left lots of headroom for existing schools to grow. The other 'nice' options would have been a /52 or a /60, which seemed excessive or restrictive respectively. > >*) In 5.1.4, do you really let hosts autoconfigure, then put their address > >manually in the DNS? Why not give them a simpler, manual address that > >would > >survive NIC swap-outs? We do that for server systems, e.g. DNS servers on ::53 (because you can :), and in the longer run we plan to use DHCPv6, because our administrators like to be able to control address assignment, and it does simplify management (hosts running RFC3041 - currently by default all XP systems - are a pain from that perspective). We don't see much NIC swapout actually; most modern laptops have embedded NICs rather than PCMCIA ones, though maybe we'll see a mini resurgence of that with 802.11a cards. But yes, long term DHCPv6, and infrastructure servers manually assigned. Thanks again for the detailed review and good questions. Tim From owner-v6ops@ops.ietf.org Thu Mar 16 09:44:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJthy-0006Oi-6X for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 09:44:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJthw-0004BE-T5 for v6ops-archive@lists.ietf.org; Thu, 16 Mar 2006 09:44:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJtg9-0002Qp-Hg for v6ops-data@psg.com; Thu, 16 Mar 2006 14:42:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJtg7-0002QR-2B for v6ops@ops.ietf.org; Thu, 16 Mar 2006 14:42:15 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k2GEgEIV000458 for ; Thu, 16 Mar 2006 14:42:14 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k2GEgDD7000457 for v6ops@ops.ietf.org; Thu, 16 Mar 2006 14:42:13 GMT Date: Thu, 16 Mar 2006 14:42:13 +0000 From: bmanning@vacation.karoshi.com To: v6ops@ops.ietf.org Subject: Re: IPv6 Unicast Address Assignment Considerations Message-ID: <20060316144213.GB30857@vacation.karoshi.com.> References: <4.3.2.7.2.20060305095545.03770588@strange-brew> <4.3.2.7.2.20060316095750.051b14e0@strange-brew> <20060316120119.GN3585@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060316120119.GN3585@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Thu, Mar 16, 2006 at 12:01:19PM +0000, Tim Chown wrote: > On Thu, Mar 16, 2006 at 10:16:26AM +0100, Gunter Van de Velde (gvandeve) wrote: > > > > At 18:12 7/03/2006 -0800, John Spence wrote: > > > > >*) Also in 1.0, you know that ARIN is considering portable address to > > >address the multihoming issue - right? Not done yet, but I'll bet it goes > > >through. > > > > > >http://www.arin.net/policy/proposals/2006_4.html > > > > Is there an indication when they will happen? I think the draft should > > follow > > as its implementation oriented, but not lead as long as the ARIN decision > > is not fallen. > > I've been following this through some Internet2 contacts, and it seems > to have dragged for at least 12 months so far. So if it does happen, I > wouldn't bet on it being soon. I think the draft can say no such > process exists now for PI, but that some scheme may emerge over time. > the I2 folks are pretty good, but it is possible to get the information directly from ARIN, indeed, ARIN seeks for direct input. this issue is on the agenda for the next ARIN mtg (08-13apr2006) in Montreal. http://www.arin.net/announcements/20060313.html and one does not have to physically be present to participate: http://www.arin.net/announcements/20060310.html ... from my cursoury review of the mailing list discussion, there is strong member desire for PI space... and policies are set by the members. --bill From owner-v6ops@ops.ietf.org Sun Mar 19 09:47:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzBY-0002zi-2A for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 09:47:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzBW-0004wG-Pw for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 09:47:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKz7C-000Mgb-Bq for v6ops-data@psg.com; Sun, 19 Mar 2006 14:42:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKz7B-000MgH-91 for v6ops@ops.ietf.org; Sun, 19 Mar 2006 14:42:41 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k2JEgPHa027185; Sun, 19 Mar 2006 16:42:25 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k2JEgOct027182; Sun, 19 Mar 2006 16:42:25 +0200 Date: Sun, 19 Mar 2006 16:42:24 +0200 (EET) From: Pekka Savola To: "Gunter Van de Velde (gvandeve)" cc: v6ops@ops.ietf.org, tjc@ecs.soton.ac.uk, cpopovic@cisco.com Subject: Re: Fwd: IPv6 Unicast Address Assignment Considerations In-Reply-To: <4.3.2.7.2.20060305095545.03770588@strange-brew> Message-ID: References: <4.3.2.7.2.20060305095545.03770588@strange-brew> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1338/Sun Mar 19 02:04:12 2006 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Sun, 5 Mar 2006, Gunter Van de Velde (gvandeve) wrote: > Resend of original message as i apparently did not reach the overall v6ops > alias. .... Overall, I liked this doc. This would seem to be the logical place to put in the critical bits (if any) from Jordi's point-to-point doc, as well. A few small comments, - in section 2.1, "allocation" should be "assignment" - in secyion 2.4.1, the HD-ratio for v6 is for *sites* not addresses like in v4 - the embedded-RP part was already commented on. - in section 4.3, there's an uppercase SHOULD for CGA regeneration, but this kind of doc shouldn't use uppercase keywords - in section 4.3, CGA's aren't really indistinguishable, because if you know (or guess) the public key of the sender, you can verify who it belongs to.. but for many purposes, these have similar properties. - section 4.4, as above, you shouldn't need to mention embedded-RP reserved addresses. These are not reserved by default: it's the local admin's decition whether to put an RP at one of those interface-ID's, so they be used freely (though I'd advise that hosts still shouldn't use those). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 19 09:58:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzM4-0000Ll-Jg for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 09:58:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzM4-0005Na-Bq for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 09:58:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKzLb-000Nis-7K for v6ops-data@psg.com; Sun, 19 Mar 2006 14:57:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKzLa-000Nic-98 for v6ops@ops.ietf.org; Sun, 19 Mar 2006 14:57:34 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k2JEvVHa027453 for ; Sun, 19 Mar 2006 16:57:31 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k2JEvVuE027450 for ; Sun, 19 Mar 2006 16:57:31 +0200 Date: Sun, 19 Mar 2006 16:57:31 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans In-Reply-To: <44192895.8020404@uninett.no> Message-ID: References: <3D1C81E7AA3CD64FA20B04D269FEF7F4013E6CF5@xmb-rtp-213.amer.cisco.com> <20060302085311.GC28111@login.ecs.soton.ac.uk> <44192895.8020404@uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1338/Sun Mar 19 02:04:12 2006 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi, I read this short doc. I don't believe it's necessary, but if there's something important there, it could be added to the addcon draft. I believe the /48 assignment suggestion below is technically incorrect. The ISP router, when it gets a packet destined to anything except the first /64 will inccorrectly try to use Neighbor Discovery to find the address, instead of forwarding it to the customer router. This can't possibly work unless the customer router is using proxy-ND. ======= Moreover, it is possible to use the shorter prefix as the provider side numbering for the point-to-point link and keep the /64 for the customer side. In our example, it will become: o Point-to-point link at provider side: 2001:db8:aaaa::1/48 o Point-to-point link at customer side: 2001:db8:aaaa::2/64 ======== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 19 10:05:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzTQ-0001Um-6Z for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 10:05:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzTO-0005dy-OQ for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 10:05:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKzT1-000OML-Jj for v6ops-data@psg.com; Sun, 19 Mar 2006 15:05:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKzSz-000OLz-8h for v6ops@ops.ietf.org; Sun, 19 Mar 2006 15:05:13 +0000 Received: (qmail 74676 invoked by uid 1007); 19 Mar 2006 15:05:11 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=Ulr9UDF8CoSfMpb5MfPtouO50a9ApybUaVN8/OG6p3KxpdGmCZvESFXH/eVO5YHs ; Date: Sun, 19 Mar 2006 16:05:11 +0100 From: Gert Doering To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans Message-ID: <20060319150511.GE32178@Space.Net> References: <3D1C81E7AA3CD64FA20B04D269FEF7F4013E6CF5@xmb-rtp-213.amer.cisco.com> <20060302085311.GC28111@login.ecs.soton.ac.uk> <44192895.8020404@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi, On Sun, Mar 19, 2006 at 04:57:31PM +0200, Pekka Savola wrote: > I read this short doc. I don't believe it's necessary, but if there's > something important there, it could be added to the addcon draft. > > I believe the /48 assignment suggestion below is technically > incorrect. The ISP router, when it gets a packet destined to anything > except the first /64 will inccorrectly try to use Neighbor Discovery > to find the address, instead of forwarding it to the customer router. > This can't possibly work unless the customer router is using proxy-ND. Depending on the type of link. On "real" point-to-point links (PPP, HDLC serials), I doubt that anyone is doing ND - because there is no need to find out about the destination mac-level address. OTOH on things like "ATM bridged encapsulation", you're completely right. You need a peer IPv6 address to route the /48 to. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From owner-v6ops@ops.ietf.org Sun Mar 19 20:21:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL954-0000sd-9W for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 20:21:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL953-0002yV-06 for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 20:21:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FL92O-000Enl-Cp for v6ops-data@psg.com; Mon, 20 Mar 2006 01:18:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FL92N-000EnY-4f for v6ops@ops.ietf.org; Mon, 20 Mar 2006 01:18:23 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k2K1I2Ha008306; Mon, 20 Mar 2006 03:18:02 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k2K1I104008303; Mon, 20 Mar 2006 03:18:01 +0200 Date: Mon, 20 Mar 2006 03:18:01 +0200 (EET) From: Pekka Savola To: Mark Andrews cc: IETF DNSOP WG , v6ops@ops.ietf.org Subject: Re: WGLC for draft-huston-6to4-reverse-dns-04.txt In-Reply-To: <200603092252.k29MqIT4030354@drugs.dv.isc.org> Message-ID: References: <200603092252.k29MqIT4030354@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1338/Sun Mar 19 02:04:12 2006 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi, I'm adding v6ops to Cc: because it'd be useful to get some input on from the 6to4 operational experience here to gauge whether the mechanism addresses sufficiently large subset of the problem. Based on your note, which I agree with, I guess the questions we should be asking are: 1) "who are the target users of this spec?" 1.b) "is the mechanism good enough for _them_?" 2) "is there a sufficiently important subset of 6to4 users for which this is not an appropriate solution?" 2.b) "do we need to have a solution for them?" My answers to these would be, 1) 6to4 power users with static IPv4 address 1.b) yes 2) "regular" 6to4 users and/or 6to4 users w/ dynamic IPv4 address 2.b) unknown at the moment. Not sure if a scalable one could exist (and anyone would have enough steam to create one) Inline.. On Fri, 10 Mar 2006, Mark Andrews wrote: > While I am happy enough for draft-huston-6to4-reverse-dns-04.txt > to proceed it should be pointed out that this is a suboptimal > solution to the problem. > > 1. It requires rapid establishment of a the child zone on > multiple servers. There currently is no standardised method > for doing this. Yes, it's not clear whether this is considered a bug or feature: the mechanism is basically unusable (requiring a lot manual config) in all the sane authoritative server DNS configurations if you have a dynamic IP address (even if the dynamic IP address changed only infrequently) due to the manual overhead. But this may also discourage folks w/ dynamic IPs from participating, which might lessen the scalability concerns. > 2. It does not use DNS itself as the update mechanism. > > A all DNS solution would be to use a DNAME record rather > an NS RRSet to perform the delegation funtion in the method > described in RFC 2874. This remove the need for rapid > establishment of the child zone as it will already exist > and be populated. .... > This method was presented to the author several years ago > but was not listed in the alterative rejected. It would > be interesting to know why it was not listed as a alternative > and as to why it was rejected. I agree this could possibly be mentioned; the cause it has been omitted may be that that it wasn't listed in the original draft discussing the alternatives; did you send comment to Keith Moore while he still updated the document? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Mar 19 21:47:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAQC-0008PF-6G for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 21:47:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAQA-0005cx-P1 for v6ops-archive@lists.ietf.org; Sun, 19 Mar 2006 21:47:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLAOZ-000KVi-IG for v6ops-data@psg.com; Mon, 20 Mar 2006 02:45:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLAOY-000KVX-NK for v6ops@ops.ietf.org; Mon, 20 Mar 2006 02:45:22 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2006 18:45:23 -0800 X-IronPort-AV: i="4.03,109,1141632000"; d="scan'208"; a="1786293596:sNHT32403146" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2K2jM7T003962; Sun, 19 Mar 2006 18:45:22 -0800 (PST) Received: from [204.96.114.235] (sjc-vpn4-1139.cisco.com [10.21.84.114]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2K2kSSI006644; Sun, 19 Mar 2006 18:46:28 -0800 In-Reply-To: References: <200603092252.k29MqIT4030354@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Mark Andrews , Pekka Savola Reply-To: IETF DNSOP WG Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: WGLC for draft-huston-6to4-reverse-dns-04.txt Date: Sun, 19 Mar 2006 20:45:18 -0600 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.3) DKIM-Signature: a=rsa-sha1; q=dns; l=3003; t=1142822789; x=1143254989; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20WGLC=20for=20draft-huston-6to4-reverse-dns-04.txt=20 |To:v6ops@ops.ietf.org; X=v=3Dmtcc.com=3B=20h=3DY3SgEDVo26YfwfeTm45QgBgoBPY=3D; b=hJEcT1iMkO6NiPAwdNrt6jylZKNzGrH2hxbgZLasAWDpLKCan0PcNOZpxaiCeK/3Aq9K2eOD hYYxc3WYe86mQqjGDu+XJZIvKEK+1yn61ImEze/K4KxEb+5tzmj8/JQoLCq2FfYT6924cwcpSGH wNFQHbpEdteAMAaAiCj6RffM=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Please review the Huston draft and comment on it from the perspective of the 6to4 problem that this working group addressed over the past few years. Comments to DNS OPS. On Mar 19, 2006, at 7:18 PM, Pekka Savola wrote: > Hi, > > I'm adding v6ops to Cc: because it'd be useful to get some input on > from the 6to4 operational experience here to gauge whether the > mechanism addresses sufficiently large subset of the problem. > > Based on your note, which I agree with, I guess the questions we > should be asking are: > > 1) "who are the target users of this spec?" > 1.b) "is the mechanism good enough for _them_?" > > 2) "is there a sufficiently important subset of 6to4 users for which > this is not an appropriate solution?" > 2.b) "do we need to have a solution for them?" > > My answers to these would be, > 1) 6to4 power users with static IPv4 address > 1.b) yes > 2) "regular" 6to4 users and/or 6to4 users w/ dynamic IPv4 address > 2.b) unknown at the moment. Not sure if a scalable one could exist > (and anyone would have enough steam to create one) > > Inline.. > > On Fri, 10 Mar 2006, Mark Andrews wrote: >> While I am happy enough for draft-huston-6to4-reverse-dns-04.txt >> to proceed it should be pointed out that this is a suboptimal >> solution to the problem. >> >> 1. It requires rapid establishment of a the child zone on >> multiple servers. There currently is no standardised method >> for doing this. > > Yes, it's not clear whether this is considered a bug or feature: > the mechanism is basically unusable (requiring a lot manual config) > in all the sane authoritative server DNS configurations if you have > a dynamic IP address (even if the dynamic IP address changed only > infrequently) due to the manual overhead. > > But this may also discourage folks w/ dynamic IPs from > participating, which might lessen the scalability concerns. > >> 2. It does not use DNS itself as the update mechanism. >> >> A all DNS solution would be to use a DNAME record rather >> an NS RRSet to perform the delegation funtion in the method >> described in RFC 2874. This remove the need for rapid >> establishment of the child zone as it will already exist >> and be populated. > .... >> This method was presented to the author several years ago >> but was not listed in the alterative rejected. It would >> be interesting to know why it was not listed as a alternative >> and as to why it was rejected. > > I agree this could possibly be mentioned; the cause it has been > omitted may be that that it wasn't listed in the original draft > discussing the alternatives; did you send comment to Keith Moore > while he still updated the document? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Mar 21 11:03:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjKt-00025i-4v for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 11:03:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjKs-0005Uw-Sf for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 11:03:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLjI0-000OWw-Q4 for v6ops-data@psg.com; Tue, 21 Mar 2006 16:00:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLjHz-000OWj-VR for v6ops@ops.ietf.org; Tue, 21 Mar 2006 16:00:56 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2LG0oc20342; Tue, 21 Mar 2006 17:00:50 +0100 (CET) Received: from gvandeve-w2k01.cisco.com (syd-vpn-client-254-121.cisco.com [10.66.254.121]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2LG0iC00810; Tue, 21 Mar 2006 17:00:45 +0100 (CET) Message-Id: <4.3.2.7.2.20060321165830.04a87378@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Mar 2006 17:00:36 +0100 To: Pekka Savola From: "Gunter Van de Velde (gvandeve)" Subject: Re: Fwd: IPv6 Unicast Address Assignment Considerations Cc: v6ops@ops.ietf.org, tjc@ecs.soton.ac.uk, cpopovic@cisco.com In-Reply-To: References: <4.3.2.7.2.20060305095545.03770588@strange-brew> <4.3.2.7.2.20060305095545.03770588@strange-brew> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 At 16:42 19/03/2006 +0200, Pekka Savola wrote: >On Sun, 5 Mar 2006, Gunter Van de Velde (gvandeve) wrote: >>Resend of original message as i apparently did not reach the overall >>v6ops alias. >.... > >Overall, I liked this doc. That is always nice to hear :-) >This would seem to be the logical place to put in the critical bits (if >any) from Jordi's point-to-point doc, as well. > >A few small comments, > >- in section 2.1, "allocation" should be "assignment" ok >- in secyion 2.4.1, the HD-ratio for v6 is for *sites* not addresses like >in v4 ok >- the embedded-RP part was already commented on. >- in section 4.3, there's an uppercase SHOULD for CGA regeneration, but >this kind of doc shouldn't use uppercase keywords ok >- in section 4.3, CGA's aren't really indistinguishable, because if you >know (or guess) the public key of the sender, you can verify who it >belongs to.. but for many purposes, these have similar properties. > - section 4.4, as above, you shouldn't need to mention embedded-RP > reserved addresses. These are not reserved by default: it's the local > admin's decition whether to put an RP at one of those interface-ID's, so > they be used freely (though I'd advise that hosts still shouldn't use those). the last sentence between brackets is the awareness we wanted to achieve. Thanks again for the reading the document and for the review comments. Brgds, G/ >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Mar 21 15:08:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLn9D-0006Jn-HF for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 15:08:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLn9D-0006gC-5n for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 15:08:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLn64-0003le-9I for v6ops-data@psg.com; Tue, 21 Mar 2006 20:04:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLn63-0003lS-LX for v6ops@ops.ietf.org; Tue, 21 Mar 2006 20:04:51 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2006 12:04:51 -0800 X-IronPort-AV: i="4.03,115,1141632000"; d="scan'208"; a="418960236:sNHT25755500" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2LK4p7T015538 for ; Tue, 21 Mar 2006 12:04:51 -0800 (PST) Received: from [130.129.131.97] (sjc-vpn7-408.cisco.com [10.21.145.152]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2LK5omX022047 for ; Tue, 21 Mar 2006 12:05:50 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <7378B012-62ED-4422-BD21-A5D6D199983F@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Fred Baker Subject: v6ops Agenda Date: Tue, 21 Mar 2006 14:04:47 -0600 X-Mailer: Apple Mail (2.746.3) DKIM-Signature: a=rsa-sha1; q=dns; l=2462; t=1142971552; x=1143403752; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:v6ops=20Agenda |To:v6ops@ops.ietf.org; X=v=3Dmtcc.com=3B=20h=3DJ2QW5LyS2Vob9wYbTP5WI4s2Tok=3D; b=hqfq3MOqeVytkAUVWZn+RzOnEW2E7gjPePBDMbPLsxmIjCG2MfMCL6kkX2WzgPkqohzufvLD WuR+XB5HBA3UdvareNyn0nkuz4WZF4y1o3+locXQDYWRjpiIvGR5uXWf/VKL7+/CznvD/r/5/i+ EhBOF97UpaEy3MKtQrG+nBGA=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 So this is my agenda for Thursday. We have two hours, which with six items on the agenda means that each discussion should be limited to about 15-20 minutes. When I say "determine trajectory", I mean the answer to two basic questions: * is the working group interested in picking this up * if it is, where is it in that process. Are we ready for WGLC on the list, or are there comments that have to be addressed before? 1) IPv6 in CableLabs DOCSIS 3.0 Alain Durand Objective: Discussion of IPv6 in Docsis 3.0 & Cable network (Document not posted due to glitch between IETF and Cable Labs schedules; to be posted after IETF meeting) 2) discussion of "Best Current Practice for Filtering ICMPv6 Messages in Firewalls", Elwyn Davies, Janos Mohacsi, 9-Mar-06, Elwyn Davie Objective: initiate WGLC as either BCP or Informational This will depend on people having read this version of the document 3) Discussion of "IPv6 Routing Policies Guidelines", Marc Blanchet, 7- Mar-06, Marc Blanchet Objective: determine trajectory of this work 4) Discussion of point-to-point issue in the following two drafts: Tim Chown with comments from Jordi Palet Objective: determine trajectory of the combined work "IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, 13-Feb-06, "Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans", Jordi Palet, 1-Mar-06, 5) Discussion of "ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks", Myung-Ki Shin, Youn-Hee Han, 2-Mar-06, Myung-Ki Shu Objective: determine trajectory of document 6) Working group discussion of trajectory of the following two documents. they should be done if the prior WGLC comments have been addressed. I'm looking for a show of hands that people have read the latest update and consider them done. "IPv6 Enterprise Network Analysis", Jim Bound, 15-Feb-06, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", Pekka Savola, 8-Mar-06, From owner-v6ops@ops.ietf.org Tue Mar 21 15:37:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnbk-0007Kn-16 for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 15:37:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnbi-0007q2-P6 for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 15:37:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLnau-0005kV-5m for v6ops-data@psg.com; Tue, 21 Mar 2006 20:36:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLnat-0005jr-1v for v6ops@ops.ietf.org; Tue, 21 Mar 2006 20:36:43 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k2LKcao4014904 for ; Tue, 21 Mar 2006 20:38:36 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k2LKaZu21681 for v6ops@ops.ietf.org; Tue, 21 Mar 2006 20:36:35 GMT Date: Tue, 21 Mar 2006 20:36:35 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: v6ops Agenda Message-ID: <20060321203635.GR19153@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <7378B012-62ED-4422-BD21-A5D6D199983F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7378B012-62ED-4422-BD21-A5D6D199983F@cisco.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Tue, Mar 21, 2006 at 02:04:47PM -0600, Fred Baker wrote: > So this is my agenda for Thursday. We have two hours, which with six > items on the agenda means that each discussion should be limited to > about 15-20 minutes. > > 4) Discussion of point-to-point issue in the following two drafts: > Tim Chown with comments from Jordi Palet > Objective: determine trajectory of the combined work > "IPv6 Unicast Address Assignment Considerations", Gunter Van de > Velde, > 13-Feb-06, > > "Guidelines for Numbering IPv6 Point-to-Point Links and Easing the > Addressing > Plans", Jordi Palet, 1-Mar-06, Just to clarify here. Gunter can't make v6ops, but I'll present in his absence. We'd like to get feedback on the draft as a whole (there have been some good comments to the list already, for which we're grateful). The point-to-point issue is more on what the WG thinks of Jordi's proposal, and then whether that should be incorporated into the point-to-point section of addcon, if addcon is taken forward. There have also been some list comments on Jordi's draft, which people should review. -- Tim/::1 From owner-v6ops@ops.ietf.org Tue Mar 21 16:57:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLoqx-0006fa-M3 for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 16:57:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLoqw-0005Eo-D3 for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 16:57:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLopn-000AkG-Vu for v6ops-data@psg.com; Tue, 21 Mar 2006 21:56:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLopm-000Ajx-OT for v6ops@ops.ietf.org; Tue, 21 Mar 2006 21:56:11 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k2LLu8TJ021424 for ; Tue, 21 Mar 2006 21:56:08 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2LLuWgG209220 for ; Tue, 21 Mar 2006 21:56:32 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k2LLu8DY030628 for ; Tue, 21 Mar 2006 21:56:08 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k2LLu7QA030621; Tue, 21 Mar 2006 21:56:07 GMT Received: from zurich.ibm.com (sig-9-145-250-206.de.ibm.com [9.145.250.206]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA73560; Tue, 21 Mar 2006 22:56:06 +0100 Message-ID: <44207677.50007@zurich.ibm.com> Date: Tue, 21 Mar 2006 22:56:07 +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: Fred Baker CC: v6ops@ops.ietf.org Subject: Re: v6ops Agenda References: <7378B012-62ED-4422-BD21-A5D6D199983F@cisco.com> In-Reply-To: <7378B012-62ED-4422-BD21-A5D6D199983F@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Since you don't have a status of documents item, can you let us know where draft-ietf-v6ops-nap-02.txt is? It is some months since WGLC and resolution of the comments received. Brian (a co-author) From owner-v6ops@ops.ietf.org Tue Mar 21 17:07:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLp0S-0003lx-8g for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 17:07:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLp0R-00060p-0M for v6ops-archive@lists.ietf.org; Tue, 21 Mar 2006 17:07:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLp04-000BmX-Oh for v6ops-data@psg.com; Tue, 21 Mar 2006 22:06:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.117] (helo=test-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLp04-000Bm8-9h for v6ops@ops.ietf.org; Tue, 21 Mar 2006 22:06:48 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 21 Mar 2006 14:06:48 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2LM6jw1017280; Tue, 21 Mar 2006 14:06:47 -0800 (PST) Received: from [204.96.114.235] (sjc-vpn2-296.cisco.com [10.21.113.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2LM7j7N023414; Tue, 21 Mar 2006 14:07:45 -0800 In-Reply-To: <44207677.50007@zurich.ibm.com> References: <7378B012-62ED-4422-BD21-A5D6D199983F@cisco.com> <44207677.50007@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <677E84D2-582B-4A63-A817-58065C755F73@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: v6ops Agenda Date: Tue, 21 Mar 2006 16:06:44 -0600 To: Brian E Carpenter X-Mailer: Apple Mail (2.746.3) DKIM-Signature: a=rsa-sha1; q=dns; l=376; t=1142978866; x=1143411066; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20v6ops=20Agenda |To:Brian=20E=20Carpenter=20; X=v=3Dmtcc.com=3B=20h=3DnyuynQ8mOlhylfdNTpGwI4dMdTQ=3D; b=ZsVrIDZb5L2h6SRCj7CK96ourJRYFqjO/NvwMK+twHh468FFZSXLUg0d5Y7RSf7e6TiekR3n yd3a7vqIvaI/ndYKa4X32uxTocoE4W3iV44S1p8LFGbEaB0H16asypWvtMrGpWuuH7cUAjBrhhr xcV1293oM4c1Dn4funX1ezac=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 It is in the IESG queue. It and the -bb- draft were mailed in last week. Sorry for the delay. On Mar 21, 2006, at 3:56 PM, Brian E Carpenter wrote: > Since you don't have a status of documents item, > can you let us know where draft-ietf-v6ops-nap-02.txt > is? It is some months since WGLC and resolution of > the comments received. > > Brian (a co-author) From owner-v6ops@ops.ietf.org Wed Mar 22 12:17:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6xn-0007Al-0S for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 12:17:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6xl-0000Kz-LJ for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 12:17:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6ww-000EUp-2y for v6ops-data@psg.com; Wed, 22 Mar 2006 17:16:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6wv-000EUW-2r for v6ops@ops.ietf.org; Wed, 22 Mar 2006 17:16:45 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2MHGee26446; Wed, 22 Mar 2006 18:16:40 +0100 (CET) Received: from gvandeve-w2k01.cisco.com (syd-vpn-client-254-39.cisco.com [10.66.254.39]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2MHGYC09370; Wed, 22 Mar 2006 18:16:34 +0100 (CET) Message-Id: <4.3.2.7.2.20060322180455.02e85700@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Mar 2006 18:16:25 +0100 To: "Bonness, Olaf" From: "Gunter Van de Velde (gvandeve)" Subject: Re: IPv6 Routing Policies Guidelines - Draft Cc: v6ops@ops.ietf.org, marc.blanchet@viagenie.ca In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F38A49FC@S4DE9JSAAIG.ost.t-c om.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This document is a good read and is well to the point. Some notes: 1) Ch2.3. Link-scoped Unicast Depending how one looks at the definition of 'advertised' the reading may be confusing. (BGP could have two next-hops included, where-of one is the link-local address). It is not advertised as prefix, but is advertised as next-hop. A simple rewording may help here. 2) 2.6. Default Route I do not agree with the fact that :: may only be advertised in the core? Some networks do behave in the hot-potata manner and have the perception they are doing that for legitimate reasons. To add to these two comments it could be nice to have a look also at: http://www.space.net/~gert/RIPE/ipv6-filters.html it has now nice references on the bottom of the page for which some may have sufficient impact to have a note in the draft. (for example the Micro allocations from ARIN) Kind Regards, G/ At 17:27 22/03/2006 +0100, Bonness, Olaf wrote: >Hi Marc >I've recently read your draft and found it very helpful from a provider >point of view. I think this kind of documents help the ISPs to make their >homework and give them a good basis for their decission making and >operation. In this direction I would like to see your draft adopted as a >WG document. > >A minor remark to the 6to4 prefix. In our opinion a 6to4 prefix (that I've >received from another peer) could be advertised as well if I want to give >the peer 6to4 transit through my network. (The shortest path to the 6to4 >gateway will than be determined through the routing.) > >So far my 2 cents > Olaf From owner-v6ops@ops.ietf.org Wed Mar 22 13:18:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7uq-0007pP-Dv for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 13:18:40 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6Vi-0007ZE-01 for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 11:48:38 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FM6Gh-000449-A9 for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 11:33:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6Dg-000B7h-2q for v6ops-data@psg.com; Wed, 22 Mar 2006 16:30:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [217.6.95.236] (helo=tcmail22.telekom.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM6Dc-000B7M-OS for v6ops@ops.ietf.org; Wed, 22 Mar 2006 16:29:57 +0000 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP; Wed, 22 Mar 2006 17:29:47 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Mar 2006 17:29:46 +0100 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F38A49FC@S4DE9JSAAIG.ost.t-com.de> From: "Bonness, Olaf" To: v6ops@ops.ietf.org Cc: marc.blanchet@viagenie.ca Subject: IPv6 Routing Policies Guidelines - Draft Date: Wed, 22 Mar 2006 17:27:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Hi Marc I've recently read your draft and found it very helpful from a provider point of view. I think this kind of documents help the ISPs to make their homework and give them a good basis for their decission making and operation. In this direction I would like to see your draft adopted as a WG document. A minor remark to the 6to4 prefix. In our opinion a 6to4 prefix (that I've received from another peer) could be advertised as well if I want to give the peer 6to4 transit through my network. (The shortest path to the 6to4 gateway will than be determined through the routing.) So far my 2 cents Olaf From owner-v6ops@ops.ietf.org Wed Mar 22 19:07:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDMe-00084f-SG for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 19:07:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMDMe-0003IB-GO for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 19:07:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMDJT-000DWr-4I for v6ops-data@psg.com; Thu, 23 Mar 2006 00:04:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMDJR-000DWf-G0 for v6ops@ops.ietf.org; Thu, 23 Mar 2006 00:04:25 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2006 16:04:25 -0800 X-IronPort-AV: i="4.03,120,1141632000"; d="scan'208"; a="317070857:sNHT30722176" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2N04O7T028830; Wed, 22 Mar 2006 16:04:24 -0800 (PST) Received: from [130.129.131.97] (rtp-vpn3-343.cisco.com [10.82.217.89]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2N05JVE001553; Wed, 22 Mar 2006 16:05:20 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E559822-A5F2-4E8B-B520-5D4BFC3D3A2F@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Address Scanning Document comments Date: Wed, 22 Mar 2006 18:04:21 -0600 To: Tim Chown X-Mailer: Apple Mail (2.746.3) DKIM-Signature: a=rsa-sha1; q=dns; l=2361; t=1143072321; x=1143504521; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Address=20Scanning=20Document=20comments |To:Tim=20Chown=20; X=v=3Dmtcc.com=3B=20h=3DILBEPYSeLeZb0heXFtf0FhlyfIk=3D; b=gTJnqCOsPpCptaT372plQ1DFbwP9P7h0g+JKsEyBwV3ULY4SbbqdFm5yzOYGwDDnRwPSa9Ad 1kCHlkVRbHGgoWoWx+KoK9G72+aYwgK4uYpdpql1/XF/nEBL6RbEKu4Ka+MNm6iDnChPM+yn4Yw QwTBTUqH67+ZgrPo5aAkzDGc=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 > It is also worth noting that worms that spread by scanning target > networks for hosts to re-attack have become more common in recent > times. Thus a much more sparsely address-populated IPv6 network > will > have a more innate defense to such forms of worm infection, > although > there may still be significant scanning traffic generated. I hear this comment, taken from the draft, a lot, and I'm not as sure that it is true. Finding the hosts on a remote LAN will require the use of different techniques, but I'm not at all sure they will be hard to find. For example, when you receive this email, it will have a number of 'receive' lines. In case you have forgotten how to manage your email tool, they look something like this: > Received: from xbh-sjc-231.amer.cisco.com > ([128.107.191.100]) by xmb-sjc-225.amer.cisco.com with Microsoft > SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 15:21:53 -0800 > Received: from sj-iport-5.cisco.com ([171.68.10.87]) by > xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); > Wed, 22 Mar 2006 15:21:52 -0800 > Received: from sj-core-4.cisco.com ([171.68.223.138]) by > sj-iport-5.cisco.com with ESMTP; 22 Mar 2006 15:21:54 -0800 > Received: from xbh-sjc-211.amer.cisco.com > (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com > (8.12.10/8.12.6) with ESMTP id k2MNLnYg005591 for > ; Wed, 22 Mar 2006 15:21:49 -0800 (PST) > Received: from xfe-sjc-211.amer.cisco.com > ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft > SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 15:21:49 -0800 > Received: from cisco.com ([128.107.132.219]) by > xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); > Wed, 22 Mar 2006 15:21:48 -0800 As you can see, it contains the numeric address of the system. Any system that emits email is therefore known by any system that receives it, which is to say that IPv6 addresses of hosts on remote LANs are trivially easy to obtain. And if you can manage to infect one, the neighbor discovery protcool results in that system knowing all of its peers on said LAN even if they don't send mail. Hence, I doubt that there will be any address scans, and I also doubt that there will be less attacks. They will just come in a different way. From owner-v6ops@ops.ietf.org Wed Mar 22 20:12:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMENE-00040w-S9 for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 20:12:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMENA-0006Rm-Ig for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 20:12:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMELG-000HWw-Hn for v6ops-data@psg.com; Thu, 23 Mar 2006 01:10:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMELD-000HWe-Cs for v6ops@ops.ietf.org; Thu, 23 Mar 2006 01:10:19 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k2N1CHNU022201 for ; Thu, 23 Mar 2006 01:12:17 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k2N1AAL08397 for v6ops@ops.ietf.org; Thu, 23 Mar 2006 01:10:10 GMT Date: Thu, 23 Mar 2006 01:10:10 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Address Scanning Document comments Message-ID: <20060323011010.GI5716@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <7E559822-A5F2-4E8B-B520-5D4BFC3D3A2F@cisco.com> <4ADAFCC8-36D8-409C-9355-3349137DA17D@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADAFCC8-36D8-409C-9355-3349137DA17D@cisco.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Wed, Mar 22, 2006 at 04:28:23PM -0800, Roland Dobbins wrote: > > On Mar 22, 2006, at 4:04 PM, Fred Baker wrote: > > >> It is also worth noting that worms that spread by scanning target > >> networks for hosts to re-attack have become more common in recent > >> times. Thus a much more sparsely address-populated IPv6 > >>network will > >> have a more innate defense to such forms of worm infection, > >>although > >> there may still be significant scanning traffic generated. > > > >I hear this comment, taken from the draft, a lot, and I'm not as > >sure that it is true. Finding the hosts on a remote LAN will > >require the use of different techniques, but I'm not at all sure > >they will be hard to find. > > There's already a paper out which demonstrates this supposition to be > incorrect: > > http://www.cs.columbia.edu/~smb/papers/v6worms.pdf Yes, nice paper (which I think was posted here recently, well after the latest version of the scanning draft). Within an IPv4 site, a worm can propogate across all subnets, because the site's address space is probably dense due to the address conservation requirements; in contrast in IPv6 I suspect the resilience is inter-subnet, rather than intra-subnet. Once an attacker is on-link, you're in trouble. Of course while dual-stack is used, you're subjetc to the limitations of the 'weaker' of the protocols. -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Mar 22 20:33:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEhV-00032W-Gj for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 20:33:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMEhU-0007jS-7c for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 20:33:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMEgv-000IvS-DA for v6ops-data@psg.com; Thu, 23 Mar 2006 01:32:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMEgu-000IvC-Ev for v6ops@ops.ietf.org; Thu, 23 Mar 2006 01:32:44 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k2N1YjZf025381 for ; Thu, 23 Mar 2006 01:34:45 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k2N1Wc208746 for v6ops@ops.ietf.org; Thu, 23 Mar 2006 01:32:38 GMT Date: Thu, 23 Mar 2006 01:32:37 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Address Scanning Document comments Message-ID: <20060323013237.GJ5716@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <7E559822-A5F2-4E8B-B520-5D4BFC3D3A2F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E559822-A5F2-4E8B-B520-5D4BFC3D3A2F@cisco.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Wed, Mar 22, 2006 at 06:04:21PM -0600, Fred Baker wrote: > > For example, when you receive this email, it will have a number of > 'receive' lines. In case you have forgotten how to manage your email > tool, they look something like this: > > >Received: from xbh-sjc-231.amer.cisco.com > >([128.107.191.100]) by xmb-sjc-225.amer.cisco.com with Microsoft > >SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 15:21:53 -0800 > ... > >Received: from cisco.com ([128.107.132.219]) by > >xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); > >Wed, 22 Mar 2006 15:21:48 -0800 > > As you can see, it contains the numeric address of the system. Any > system that emits email is therefore known by any system that > receives it, which is to say that IPv6 addresses of hosts on remote > LANs are trivially easy to obtain. And if you can manage to infect > one, the neighbor discovery protcool results in that system knowing > all of its peers on said LAN even if they don't send mail. > > Hence, I doubt that there will be any address scans, and I also doubt > that there will be less attacks. They will just come in a different way. I agree, and I think Section 3 (Alternatives for Attackers) could add a list of examples of where to harvest addresses from. While MX's will be DNS listed anyway, mail headers are a good (or bad :) example since internal relays and sender IPs are invariably included. If RFC3041 addresses are used for senders (or for any application) at least that harvestable information has its value to the attacker time limited. -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Mar 22 20:35:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEk3-00070Z-Oh for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 20:35:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMEk2-0007ps-G6 for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 20:35:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMEjw-000JBa-Vt for v6ops-data@psg.com; Thu, 23 Mar 2006 01:35:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.117] (helo=test-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMEjw-000JBN-BL for v6ops@ops.ietf.org; Thu, 23 Mar 2006 01:35:52 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 22 Mar 2006 17:35:52 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2N1Zp7V018874; Wed, 22 Mar 2006 17:35:52 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 17:35:51 -0800 Received: from [204.96.114.235] ([10.21.82.173]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 17:35:50 -0800 In-Reply-To: <20060323013237.GJ5716@login.ecs.soton.ac.uk> References: <7E559822-A5F2-4E8B-B520-5D4BFC3D3A2F@cisco.com> <20060323013237.GJ5716@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8DFF994D-5C80-4785-92A6-F17594C1708A@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Address Scanning Document comments Date: Wed, 22 Mar 2006 19:35:49 -0600 To: Tim Chown X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 23 Mar 2006 01:35:51.0112 (UTC) FILETIME=[1E4D0C80:01C64E1A] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 RFC 3041 is a good thing... On Mar 22, 2006, at 7:32 PM, Tim Chown wrote: > If > RFC3041 addresses are used for senders (or for any application) at > least that harvestable information has its value to the attacker time > limited. From owner-v6ops@ops.ietf.org Wed Mar 22 23:38:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMHax-0000Q8-Ls for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 23:38:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMHaw-00068x-7R for v6ops-archive@lists.ietf.org; Wed, 22 Mar 2006 23:38:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMHXo-0008Lw-Ec for v6ops-data@psg.com; Thu, 23 Mar 2006 04:35:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.117] (helo=test-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMHXn-0008Lj-Dr for v6ops@ops.ietf.org; Thu, 23 Mar 2006 04:35:31 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by test-iport-1.cisco.com with ESMTP; 22 Mar 2006 20:35:31 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2N4ZUYg010003; Wed, 22 Mar 2006 20:35:31 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 20:35:30 -0800 Received: from [204.96.114.235] ([10.21.82.173]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 20:35:29 -0800 In-Reply-To: <20060323011010.GI5716@login.ecs.soton.ac.uk> References: <7E559822-A5F2-4E8B-B520-5D4BFC3D3A2F@cisco.com> <4ADAFCC8-36D8-409C-9355-3349137DA17D@cisco.com> <20060323011010.GI5716@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FDDEA08-86AB-4A80-B63D-32ED5736A3FD@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Address Scanning Document comments Date: Wed, 22 Mar 2006 22:35:27 -0600 To: Tim Chown X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 23 Mar 2006 04:35:30.0158 (UTC) FILETIME=[371CF0E0:01C64E33] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 If I may give you a healthy caution... In industry, we have a saying that one should not "believe one's own hype", or "breathe one's exhaust". John Chambers, Cisco's CEO, once asked Carly Fiorina, then CEO HP, to give a keynote at a Cisco corporate conference for the senior management and technical staff. At the end, he did a little interview with her, and asked her what she saw as the greatest danger there was to his company. The look on her face suggested that she was thinking on her feet - she hadn't been prepped for the question. She nonetheless replied, politely but without hesitation: "don't believe your own hype". It is managements' job to tell the troops and marketing's to tell the world "we're the greatest, and our products are the greatest". Every company, regardless of where it stands in reality, finds something to say about itself to allow it to say "we're the greatest, and the world is emulating us." And when you're in Cisco's position, it's pretty easy to believe it is true. Juniper exists because at a certain point Cisco believed its own hype. The industry is better for it - the competition keeps us both at the top of our game, and our customers benefit. But there have been some hard lessons. IPv6 is a great thing in a number of ways. The marketing story greatly exceeds its wonder, though. Make no mistake, IPv6 has as many vulnerabilities as IPv4. One just attacks them in a different way. If you want to leave IPv6 exposed and vulnerable, tell the world how invulnerable it is, how great a security solution and QoS solution and whatever else it is. It gives us a lot more addresses, and we need them, and having the addresses there are some very interesting things we can do, like the mobility stuff. That doesn't mean that it solves world hunger. Don't tell me how hard it will be to attack IPv6 using IPv4 techniques, or how IPv6 is more vulnerable if IPv4 is running in the same machine. Tell me how attackers will attack an IPv6 network, and how to defend against them. Make no mistake: they will. Don't believe your own hype. On Mar 22, 2006, at 7:10 PM, Tim Chown wrote: > On Wed, Mar 22, 2006 at 04:28:23PM -0800, Roland Dobbins wrote: >> >> On Mar 22, 2006, at 4:04 PM, Fred Baker wrote: >> >>>> It is also worth noting that worms that spread by scanning target >>>> networks for hosts to re-attack have become more common in recent >>>> times. Thus a much more sparsely address-populated IPv6 >>>> network will >>>> have a more innate defense to such forms of worm infection, >>>> although >>>> there may still be significant scanning traffic generated. >>> >>> I hear this comment, taken from the draft, a lot, and I'm not as >>> sure that it is true. Finding the hosts on a remote LAN will >>> require the use of different techniques, but I'm not at all sure >>> they will be hard to find. >> >> There's already a paper out which demonstrates this supposition to be >> incorrect: >> >> http://www.cs.columbia.edu/~smb/papers/v6worms.pdf > > Yes, nice paper (which I think was posted here recently, well after > the > latest version of the scanning draft). > > Within an IPv4 site, a worm can propogate across all subnets, because > the site's address space is probably dense due to the address > conservation > requirements; in contrast in IPv6 I suspect the resilience is inter- > subnet, > rather than intra-subnet. Once an attacker is on-link, you're in > trouble. > > Of course while dual-stack is used, you're subjetc to the > limitations of > the 'weaker' of the protocols. > > -- > Tim/::1 From owner-v6ops@ops.ietf.org Thu Mar 23 09:14:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQaO-0008J3-5v for v6ops-archive@lists.ietf.org; Thu, 23 Mar 2006 09:14:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQaM-0004Vh-TU for v6ops-archive@lists.ietf.org; Thu, 23 Mar 2006 09:14:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMQX8-0009Mr-IB for v6ops-data@psg.com; Thu, 23 Mar 2006 14:11:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMQX7-0009M8-Cd for v6ops@ops.ietf.org; Thu, 23 Mar 2006 14:11:25 +0000 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k2NEDRc6027346 for ; Thu, 23 Mar 2006 14:13:27 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k2NEBHP28938 for v6ops@ops.ietf.org; Thu, 23 Mar 2006 14:11:17 GMT Date: Thu, 23 Mar 2006 14:11:17 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Address Scanning Document comments Message-ID: <20060323141117.GB28000@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <7E559822-A5F2-4E8B-B520-5D4BFC3D3A2F@cisco.com> <4ADAFCC8-36D8-409C-9355-3349137DA17D@cisco.com> <20060323011010.GI5716@login.ecs.soton.ac.uk> <6FDDEA08-86AB-4A80-B63D-32ED5736A3FD@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6FDDEA08-86AB-4A80-B63D-32ED5736A3FD@cisco.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Wed, Mar 22, 2006 at 10:35:27PM -0600, Fred Baker wrote: > If I may give you a healthy caution... > > ... > > Don't tell me how hard it will be to attack IPv6 using IPv4 > techniques, or how IPv6 is more vulnerable if IPv4 is running in the > same machine. Tell me how attackers will attack an IPv6 network, and > how to defend against them. Make no mistake: they will. Good points, and I agree. It is harder for 'worms' to propogate between IPv6 subnets, but still possible. It is less likely to be by current typical ping sweeps. If there's time today, lets see a) if the WG thinks this doc should be pushed forward b) what the tone/conclusion of the doc should be (it currently lacks a conclusion) Bellovin's paper says that understanding what attackers may do is still work in progress. I think Section 3 can expand on these sources, and offer some advice on what attack vectors we may see. Thus I feel the document can highlight practical steps an administrator can take (and steps they should not). But of course the doc should not claim any magic invulnerability. Tim From owner-v6ops@ops.ietf.org Thu Mar 23 15:10:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW8r-0003t4-NP for v6ops-archive@lists.ietf.org; Thu, 23 Mar 2006 15:10:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMW8q-0003Xg-En for v6ops-archive@lists.ietf.org; Thu, 23 Mar 2006 15:10:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMW5R-000NPK-NX for v6ops-data@psg.com; Thu, 23 Mar 2006 20:07:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_WHOIS_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMW5R-000NP8-1g for v6ops@ops.ietf.org; Thu, 23 Mar 2006 20:07:13 +0000 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.17898823; Thu, 23 Mar 2006 15:06:45 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 15:06:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64EB5.4EE52D7D" Subject: DNSop doccument related to routing guidelines Date: Thu, 23 Mar 2006 15:06:44 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730507246A@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNSop doccument related to routing guidelines Thread-Index: AcZOtSzLyDS+x3eZTLSHfbbJIsRYzQ== From: "Durand, Alain" To: "Fred Baker" , Cc: "Marc Blanchet" X-OriginalArrivalTime: 23 Mar 2006 20:06:45.0192 (UTC) FILETIME=[4F3A8480:01C64EB5] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 1.5 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 This is a multi-part message in MIME format. ------_=_NextPart_001_01C64EB5.4EE52D7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-andrews-full-service-resolvers -02.txt ------_=_NextPart_001_01C64EB5.4EE52D7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
http://www.ietf.org/internet-drafts/draft-andrews-full-se= rvice-resolvers-02.txt
------_=_NextPart_001_01C64EB5.4EE52D7D--