From owner-v6ops@ops.ietf.org Mon Apr 03 17:06:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWFY-0005MS-KK for v6ops-archive@lists.ietf.org; Mon, 03 Apr 2006 17:06:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWFY-0005i1-3X for v6ops-archive@lists.ietf.org; Mon, 03 Apr 2006 17:06:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWCB-000FWw-EN for v6ops-data@psg.com; Mon, 03 Apr 2006 21:02:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWC9-000FWZ-Nm for v6ops@ops.ietf.org; Mon, 03 Apr 2006 21:02:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k33L2dkJ026106 for ; Mon, 3 Apr 2006 23:02:39 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k33L2ZS6026098 for ; Mon, 3 Apr 2006 23:02:35 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k33L2Zv7003946 for ; Mon, 3 Apr 2006 23:02:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604032102.k33L2Zv7003946@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-ipsec-tunnels-02.txt review (resent) Date: Mon, 03 Apr 2006 23:02:35 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 (This never reached the mailing-list so I resend it) Here is my review of draft-ietf-v6ops-ipsec-tunnels-02.txt: - perhaps the Abstract is too narrow in scope because the document is applicable to any IPv6-in-IPv4 tunnels secured by IPsec? IMHO the problem comes from the term "manually" which is more "controlled", i.e., we'd like to exclude 6to4 but not L2TP. - Introduction (and further): PAD (Peer Authorization Database) is important too. BTW SAD is not because it is supposed to be filled automatically. - section 2 (explanation/introduction comment). From an IPsec point of view, the main difference between a tunnel mode and a transport mode applied to a tunnel is over which addresses traffic selectors apply: for tunnel mode they are the inner addresses, so you get the (2) with a filter from the points 4/5 of RFC 4301 inbound processing, for transport mode they are the outer (and only visible) addresses. BTW what is valuable and provided by IPsec is the data origin authentication (origin here is the peer tunnel end-point). - section 4: IMHO we should not pay too much attention to IPsec v2 (RFC 2401) which is known to be not consitent with IKEv1 or the reality. - section 4: the remark about RFC 4301 bound to IKEv2 is important! - section 5.1: even I know some GSPD implementations SSPD is far more common. More important, we *should not* rely on one of the two models if we want credible interoperability. GSPD is not consistent with strict RFC 2401 because we can't apply a per interface SPD to select the interface... This is why RFC 3776 gives SPD entries only as example (:-), and why 5.3.1 assumption doesn't make sense (but remember the issue is from RFC 2401). - section 5.2: I really prefer the RFC 4301 style: * SPD IN / OUT -> SPD-S with bidirectional entries * SRC -> local, DST -> remote for selectors * IDci -> TSi, IDcr -> TSr * no phase 2 BTW please postpone the SPD per interface issue (i.e., we have to talk about it but not here) - section 5.3.1: the outbound processing assumption doesn't work with RFC 2401, this is not really a problem because RFC 2401 is basically flawn so nothing can be really correct... More critical, RFC 4301 was fixed and the forwarding box in the outbound processing is in the unprotected side so not only the assumption is wrong but the crossing of the IPsec boundary between the red and black space is something the security area directors will inflexibility and deeply review. I am really afraid that fixing this will just give the same than transport mode but in a very complex way... - section 7 (explanation/introduction comment). IKE manages two pairs of addresses, the addresses it runs over, called the peer addresses, which are the outer addresses too in our context. And addresses in traffic selectors. There are three ways to "update" the peer addresses but none without re-establishing SAs to update traffic selectors (and a proposal to recharter mobike to do that was rejected with a 12 vs 10 majority some days ago). The first way is NAT traversal where the used peer address is simply the last seen address in a valid (== checked by IPsec) packet. This is the implicit update and it was designed to keep IPsec alive through a NAT changing its mapping, but it works perfectly well in our context as described in the document. The second way is MOBIKE which provides an explicit (i.e., controlled by the peer) update mechanism for peer addresses. The protocol spec is in the RFC editor queue (so the document should be updated). This is a common misconception about MOBIKE: even if transport mode is not in the charter it is not true MOBIKE can't be used with transport mode: we should only be in a case where the traffic selectors don't need to be updated. Our context is one of theses cases when a SPD is attached to the tunnel interface and traffic selectors contain "any" for addresses: i.e., the interface selection is enough so there is no need to look at the outer addresses because they are enforced by the interface. Note the peer addresses still need to be managed, at least because they are critical parameters of the IKE SA we'd like to keep alive. The last way is to update directly (i.e., outside IPsec/IKE) the SA and SPD entries and to warn IKE to update its internal state, including the IKE SA. This is the Mobile IPv6 solution, the warning mechanism is the (in)famous K flag and there is a proposed API (PF_KEY extension) to implement it (and even working code for IKEv1 and IKEv2 :-). - section 8: this is a place where the IPsec WG never really proposed something and IMHO as there are many vendor based solutions it won't) - section 8: I'd like to get a good DNS SRV RR example for the DNS option. - section 9: needs update according to previous points. - section 11: BTW only IKEv2 maintains IPsec SAs. - section 11: if we can't find a better place, this is where to add some words about the PAD. - appendix A.x: please keep source and dest for the action description (i.e., the end-point addresses of the SAs) when SRC and DST are replaced by local and remote. Regards Francis.Dupont@point6.net From owner-v6ops@ops.ietf.org Fri Apr 07 09:16:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqoq-0000gt-Ed for v6ops-archive@lists.ietf.org; Fri, 07 Apr 2006 09:16:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqoo-0003yZ-16 for v6ops-archive@lists.ietf.org; Fri, 07 Apr 2006 09:16:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRqkm-0008Ds-DY for v6ops-data@psg.com; Fri, 07 Apr 2006 13:11:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [207.134.166.247] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRqkj-0008Da-Jc for v6ops@ops.ietf.org; Fri, 07 Apr 2006 13:11:53 +0000 Received: from [192.168.1.100] (modemcable027.128-130-66.mc.videotron.ca [66.130.128.27]) by jazz.viagenie.qc.ca (Postfix) with ESMTP id 4317E37AE00; Fri, 7 Apr 2006 09:11:50 -0400 (EDT) In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730507246A@PACDCEXCMB01.cable.comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C730507246A@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0D766EAA-EBCA-49D4-BDA2-F677E799350C@viagenie.ca> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: Marc Blanchet Subject: Re: DNSop doccument related to routing guidelines Date: Fri, 7 Apr 2006 09:08:47 -0400 To: "Durand, Alain" X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Alain, I understand that the document you are referring to does list some =20 IPv6 addresses and the need to setup sacrificial name servers to =20 manage the load. However, while somewhat related, I don't see the =20 need to either reference or use this document in the routing =20 guidelines document. Unless you suggest me something specific. Marc. Le 06-03-23 =E0 15:06, Durand, Alain a =E9crit : > http://www.ietf.org/internet-drafts/draft-andrews-full-service-=20 > resolvers-02.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca From owner-v6ops@ops.ietf.org Tue Apr 11 22:38:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTVFJ-0003Wr-HG for v6ops-archive@lists.ietf.org; Tue, 11 Apr 2006 22:38:17 -0400 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 1FTVFJ-0000eF-FF for v6ops-archive@lists.ietf.org; Tue, 11 Apr 2006 22:38:17 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTVFE-0006Y2-RY for v6ops-archive@lists.ietf.org; Tue, 11 Apr 2006 22:38:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTVBh-000CkN-94 for v6ops-data@psg.com; Wed, 12 Apr 2006 02:34:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [64.233.162.196] (helo=zproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTVBd-000CkA-Nb for v6ops@ops.ietf.org; Wed, 12 Apr 2006 02:34:29 +0000 Received: by zproxy.gmail.com with SMTP id 12so1317984nzp for ; Tue, 11 Apr 2006 19:34:29 -0700 (PDT) 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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MOdl6Pry/7KQFM5zb0eg0mDIKP+qWStChUDBiq/Pe+GSKRuVacQgHyCg3m6mZIKpf94RSl6Cj8EVxQbC6CSgo4WjVFsJLUaIPP48izCbxT6ZoYjV5xRSVgGuMXBmrgHu+lEa1CnB6wDc8OXQiQLzA2/7MVNykfffZ7sadgikWiY= Received: by 10.36.227.54 with SMTP id z54mr81393nzg; Tue, 11 Apr 2006 19:34:29 -0700 (PDT) Received: from ?129.254.112.125? ( [129.254.112.125]) by mx.gmail.com with ESMTP id 15sm532379nzo.2006.04.11.19.34.27; Tue, 11 Apr 2006 19:34:28 -0700 (PDT) Message-ID: <443C672D.3040706@gmail.com> Date: Wed, 12 Apr 2006 11:34:21 +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: Soohong Daniel Park CC: 16ng@eeca16.sogang.ac.kr, v6ops@ops.ietf.org Subject: Re: [16ng] Charter discussion - IP deployment over IEEE 802.16(e) Networks References: <00c501c65dcc$217fc110$6dc6dba8@daniellaptop> In-Reply-To: <00c501c65dcc$217fc110$6dc6dba8@daniellaptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hi, Daniel, (I'm ccing v6ops@ops.ietf.org) Actually, I don't think that the goal of two drafts are the same. V6ops draft [2] covers the issues on IPv6 deployment and integration methods and scenarios in 802.16 broadband access networks in coexistence with deployed IPv4 services. It extends works of . This is also one of goals and scope of v6ops WG. In this draft, authors do not try to define any new network models or protocols. But, in my view, 16ng should focus on network and IP link models (e.g, WiMAX and WiBro), not IPv6 deployment and scenarios, etc. So, I think the 16ng deliverable [1] should be published as a separate document, focusing on network and IP link models (IPv4 and IPv6, both). Any thoughts ? Thanks, Myung-Ki, -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Myung-Ki Shin, Ph.D.| myungki.shin@gmail.com ETRI/PEC | 161 Gajeong-dong Yuseong-gu Tel:+82-42-860-4847 | Daejeon, 305-350 Korea Soohong Daniel Park wrote: > I would call for comments on the "16ng deliverable as IP deployment > over IEEE 802.16(e) Networks". It aims to guage 16ng consensus > whether we might take this item or not (leave it as v6ops task). > I heard the relavant draft [2] below was officially accepted as v6ops > WG item at Dallas. That is why I try to clarify this item at this time. > > > [1] 16ng deliverable (none of draft) > - Produce "IP deployment over IEEE 802.16(e) Networks" to illustrate the IP > deployment scenarios and considerations over IEEE 802.16(e) networks based on > the WiMAX and WiBro. [Informational RFC] > > [2] v6ops individual submission regarding 802.16 deployment scenario > http://www.watersprings.org/pub/id/draft-shin-v6ops-802-16-deployment-scenarios-00.txt > > > To me, both are for the same goal. But [2] just mention IPv6, not IPv4 > ([1] will figure out both IPv4 and IPv6). Further, 16ng does not have a > chance to go through [2] as much as we satisfy. [2] seems a bit general > document as one of v6ops broadband deployment (WLAN, PLC, Cable, > and WMAN). Also, v6ops broadband deployment draft is under IESG > evaluation after WGLC. So, [2] will may be ready to the WGLC quickly > as far as I am concern. > > > CALL FOR COMMENTS: > > - Working on 16ng deliverable regardless of [2] ? > - Sending 16ng comments on [2], then published by v6ops ? > (In that case, we should consider how to deal with IPv4) > - Considering [2] as a candidate of 16ng deployment deliverable ? > > > Any comments are highly welcome. > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > _______________________________________________ > 16ng mailing list > 16ng@eeca16.sogang.ac.kr > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng > From owner-v6ops@ops.ietf.org Thu Apr 13 15:58:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7xO-0008GY-5I for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 15:58:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7xM-0001Bm-Oq for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 15:58:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FU7u3-0004ka-9W for v6ops-data@psg.com; Thu, 13 Apr 2006 19:54:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [32.97.110.150] (helo=e32.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FU7u2-0004kK-9P for v6ops@ops.ietf.org; Thu, 13 Apr 2006 19:54:54 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3DJsrqH015875 for ; Thu, 13 Apr 2006 15:54:53 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3DJwCVw186220 for ; Thu, 13 Apr 2006 13:58:12 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k3DJsqWv014437 for ; Thu, 13 Apr 2006 13:54:53 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-227-99.mts.ibm.com [9.65.227.99]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k3DJsqOa014402 for ; Thu, 13 Apr 2006 13:54:52 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k3DJsqeU008611 for ; Thu, 13 Apr 2006 15:54:52 -0400 Message-Id: <200604131954.k3DJsqeU008611@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: PI addressing in IPv6 advances in ARIN Date: Thu, 13 Apr 2006 15:54:52 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 FYI, at this week's ARIN meeting, there was agreement to move forward with a (slightly modified) version of http://www.arin.net/policy/proposals/2005_1.html, "Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites". Process wise, I believe there will be an updated proposal and formal last call. But there was clear support in the meeting to move forward on this policy. This is a significant step, as no PI addresses had previously been available for end sites in IPv6. Thomas From owner-v6ops@ops.ietf.org Thu Apr 13 17:00:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8vP-00082E-Aa for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 17:00:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU8vO-0003Uu-0j for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 17:00:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FU8tr-0008WW-Jv for v6ops-data@psg.com; Thu, 13 Apr 2006 20:58:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FU8tq-0008WJ-FD for v6ops@ops.ietf.org; Thu, 13 Apr 2006 20:58:46 +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 k3DKwjf06038; Thu, 13 Apr 2006 22:58:45 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (rtp-vpn4-34.cisco.com [10.82.208.34]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k3DKwhC15059; Thu, 13 Apr 2006 22:58:43 +0200 (CEST) Message-Id: <4.3.2.7.2.20060413225444.03640d58@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Apr 2006 22:58:39 +0200 To: Thomas Narten From: "Gunter Van de Velde (gvandeve)" Subject: Re: PI addressing in IPv6 advances in ARIN Cc: v6ops@ops.ietf.org In-Reply-To: <200604131954.k3DJsqeU008611@cichlid.raleigh.ibm.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: 9182cfff02fae4f1b6e9349e01d62f32 What would be the prefix allocation per organization? (Me being in Europe and not attending ARIN sessions) Has there been study on the # of organizations going for this and if the impact will be more significant then more's law on technology enhancement? G/ At 15:54 13/04/2006 -0400, Thomas Narten wrote: >FYI, at this week's ARIN meeting, there was agreement to move forward >with a (slightly modified) version of >http://www.arin.net/policy/proposals/2005_1.html, "Policy Proposal >2005-1: Provider-independent IPv6 Assignments for End Sites". > >Process wise, I believe there will be an updated proposal and formal >last call. But there was clear support in the meeting to move forward >on this policy. > >This is a significant step, as no PI addresses had previously been >available for end sites in IPv6. > >Thomas From owner-v6ops@ops.ietf.org Thu Apr 13 17:15:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9AO-0003VF-Dk for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 17:15:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU9AN-00041z-4g for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 17:15:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FU99V-0009OO-Jb for v6ops-data@psg.com; Thu, 13 Apr 2006 21:14:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FU99U-0009OD-Ow for v6ops@ops.ietf.org; Thu, 13 Apr 2006 21:14:56 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3DLEt0r004505 for ; Thu, 13 Apr 2006 17:14:55 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3DLEtWw225116 for ; Thu, 13 Apr 2006 17:14:55 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k3DLEtgM021406 for ; Thu, 13 Apr 2006 17:14:55 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-227-99.mts.ibm.com [9.65.227.99]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k3DLEsLP021384; Thu, 13 Apr 2006 17:14:55 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k3DLEsYA010205; Thu, 13 Apr 2006 17:14:54 -0400 Message-Id: <200604132114.k3DLEsYA010205@cichlid.raleigh.ibm.com> To: "Gunter Van de Velde (gvandeve)" cc: v6ops@ops.ietf.org Subject: Re: PI addressing in IPv6 advances in ARIN In-Reply-To: Message from "Gunter Van de Velde (gvandeve)" of "Thu, 13 Apr 2006 22:58:39 +0200." <4.3.2.7.2.20060413225444.03640d58@strange-brew> Date: Thu, 13 Apr 2006 17:14:54 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > What would be the prefix allocation per organization? /48, though can be larger in some cases. Watch for the revised proposal that gets last called for details. > (Me being in Europe and not attending ARIN sessions) Note: none of the other RIRs have such a policy in place today, though I wouldn't be surprised if they now followup with proposals of their own (though someone has to do it). > Has there been study on the # of organizations going for this > and if the impact will be more significant then more's law > on technology enhancement? Mostly just hand waving, with a lot of "IPv4 hasn't melted today," "looking at the impact of the current IPv4 policies, the number of PI assignments is only on the 100s per year", and "we can update the policy if things get problematical". Thomas From owner-v6ops@ops.ietf.org Thu Apr 13 17:29:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9N8-0007yN-3k for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 17:29:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU9N4-0004TI-F2 for v6ops-archive@lists.ietf.org; Thu, 13 Apr 2006 17:29:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FU9Md-000ABl-CD for v6ops-data@psg.com; Thu, 13 Apr 2006 21:28:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 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 1FU9Ma-000AB7-QX for v6ops@ops.ietf.org; Thu, 13 Apr 2006 21:28:29 +0000 Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001741976.msg for ; Thu, 13 Apr 2006 23:28:03 +0200 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 13 Apr 2006 23:28:20 +0200 Subject: Re: PI addressing in IPv6 advances in ARIN From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwA== In-Reply-To: <200604132114.k3DLEsYA010205@cichlid.raleigh.ibm.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:060413:v6ops@ops.ietf.org::Y9m84SgsqZSuKYAp:00000000000000000000000000000000000000000003Are 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, 13 Apr 2006 23:28:04 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi Thomas, all, During my fly-back from Montreal, I've worked in a proposal and I'm talking to folks in each RIR/region, with the idea to submit it to all them as a kind of (if possible), global policy. The idea is based on the comments that I did at the mic during the ARIN meeting. I will try to get this submitted next Monday/Tuesday and get ready for a formal presentation during the next RIPE meeting at Istanbul (following week). Regards, Jordi > De: Thomas Narten > Responder a: > Fecha: Thu, 13 Apr 2006 17:14:54 -0400 > Para: "Gunter Van de Velde (gvandeve)" > CC: "v6ops@ops.ietf.org" > Asunto: Re: PI addressing in IPv6 advances in ARIN > >> What would be the prefix allocation per organization? > > /48, though can be larger in some cases. Watch for the revised > proposal that gets last called for details. > >> (Me being in Europe and not attending ARIN sessions) > > Note: none of the other RIRs have such a policy in place today, > though I wouldn't be surprised if they now followup with proposals of > their own (though someone has to do it). > >> Has there been study on the # of organizations going for this >> and if the impact will be more significant then more's law >> on technology enhancement? > > Mostly just hand waving, with a lot of "IPv4 hasn't melted today," > "looking at the impact of the current IPv4 policies, the number of PI > assignments is only on the 100s per year", and "we can update the > policy if things get problematical". > > Thomas > ********************************************** 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 Fri Apr 14 03:14:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIVf-0006Cd-2J for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 03:14:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUIVa-0006nj-D8 for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 03:14:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUITP-000EJ2-Cg for v6ops-data@psg.com; Fri, 14 Apr 2006 07:12:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUITL-000EIX-5x for v6ops@ops.ietf.org; Fri, 14 Apr 2006 07:12:03 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 387F5340B0; Fri, 14 Apr 2006 03:12:02 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 03:12:01 -0400 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: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 03:11:58 -0400 Message-ID: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSA From: "Bound, Jim" To: , X-OriginalArrivalTime: 14 Apr 2006 07:12:01.0818 (UTC) FILETIME=[BA1107A0:01C65F92] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Jordi, why this will work as is for now? /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ > Sent: Thursday, April 13, 2006 5:28 PM > To: v6ops@ops.ietf.org > Subject: Re: PI addressing in IPv6 advances in ARIN >=20 > Hi Thomas, all, >=20 > During my fly-back from Montreal, I've worked in a proposal=20 > and I'm talking to folks in each RIR/region, with the idea to=20 > submit it to all them as a kind of (if possible), global policy. >=20 > The idea is based on the comments that I did at the mic=20 > during the ARIN meeting. >=20 > I will try to get this submitted next Monday/Tuesday and get=20 > ready for a formal presentation during the next RIPE meeting=20 > at Istanbul (following week). >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > > De: Thomas Narten > > Responder a: > > Fecha: Thu, 13 Apr 2006 17:14:54 -0400 > > Para: "Gunter Van de Velde (gvandeve)" > > CC: "v6ops@ops.ietf.org" > > Asunto: Re: PI addressing in IPv6 advances in ARIN > >=20 > >> What would be the prefix allocation per organization? > >=20 > > /48, though can be larger in some cases. Watch for the revised=20 > > proposal that gets last called for details. > >=20 > >> (Me being in Europe and not attending ARIN sessions) > >=20 > > Note: none of the other RIRs have such a policy in place=20 > today, though=20 > > I wouldn't be surprised if they now followup with proposals=20 > of their=20 > > own (though someone has to do it). > >=20 > >> Has there been study on the # of organizations going for=20 > this and if=20 > >> the impact will be more significant then more's law on technology=20 > >> enhancement? > >=20 > > Mostly just hand waving, with a lot of "IPv4 hasn't melted today," > > "looking at the impact of the current IPv4 policies, the=20 > number of PI=20 > > assignments is only on the 100s per year", and "we can update the=20 > > policy if things get problematical". > >=20 > > Thomas > >=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 Fri Apr 14 04:46:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJxB-00020Q-BR for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 04:46:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUJxA-0001CZ-UH for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 04:46:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUJvg-000J9v-Ms for v6ops-data@psg.com; Fri, 14 Apr 2006 08:45:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUJvc-000J9f-Df for v6ops@ops.ietf.org; Fri, 14 Apr 2006 08:45:20 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2006 10:45:19 +0200 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 k3E8jIUE002971; Fri, 14 Apr 2006 10:45:18 +0200 (MEST) 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); Fri, 14 Apr 2006 10:45:18 +0200 Received: from [144.254.53.139] ([144.254.53.139]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 10:45:17 +0200 From: Eric Levy-Abegnoli To: idr@ietf.org, dirk@onesparrow.com, "Francois Le Faucheur (flefauch)" , jeremy.de_clercq@alcatel.be, stuart.prevost@bt.com Subject: Re: draft-ooms-v6ops-bgp-tunnel-06.txt and v6ops review Date: Fri, 14 Apr 2006 09:45:13 +0200 User-Agent: KMail/1.6.1 Cc: v6ops@ops.ietf.org References: <200603081545.k28FjlUJ016888@bright.research.att.com> <20060308234115.GA26884@nokia.com> <4C5D0DC2-E540-48FB-845F-0B3F222688B9@cisco.com> In-Reply-To: <4C5D0DC2-E540-48FB-845F-0B3F222688B9@cisco.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200604140945.13967.elevyabe@cisco.com> X-OriginalArrivalTime: 14 Apr 2006 08:45:18.0120 (UTC) FILETIME=[C1B8F280:01C65F9F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, MTU is not discussed in the draft, and I think MPLS carries some specific issues that are worth describing. Basically, if the MTU in the MPLS core is smaller than 1280, IPv6 packets greater than 1280 bytes are likely to be dropped silently. Any chance (if this not too late) to add a small section/text on MTU handling in the MPLS core ? (at lean the first sentence) Here is a proposed text: MTU consideration -------------------------- [IPv6] requires that every link in the internet have an MTU of 1280 octets or greater. On MPLS links where no link-specific fragmentation and reassembly is provided, MTU must be configured to have an MTU of at least 1280 octets plus the encapsulation overhead in order for 6PE traffic to be forwarded. (Add optionnaly the following text) Some IPv6 hosts might be sending packets greater than the MTU available in the IPv4 MPLS core and rely on Path MTU discovery to learn about those links. Core routers are typically not IPv6 nodes and cannot build an IPv6 ICMP "packet Too Big" message. Even if they can, they may not have knowledge of the destination of the ICMP message and would be forwarding this message to the egress PE, using mechaninsm described in [RFC3032]. According to [RFC2463], the ICMP "Packet too Big" message can be filled with the invoking packet up to 1280 bytes. If any links on the path to the egress PE has an MTU smaller than 1280, the ICMP message won't reach its destination, preventing the originator of the traffic to be notified about the MTU too small. This may cause significant operational problems; the originator of the packets will notice that his data is not getting through, without knowing why and where packets are discarded. To minimize problems, it is advised to engineer the MTU on the ingress 6PE to core interface, consistent with the core MTU, so that ICMP 'Packet too big" can be sent by this router without these packets or the ICMP messages entering the core MPLS. Thank you Eric Levy-Abegnoli On jeudi 9 Mars 2006 01:16, Fred Baker wrote: > 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 Fri Apr 14 06:22:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FULRi-0005BW-JR for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 06:22:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FULRg-0004Cs-S8 for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 06:22:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FULPl-000OOZ-1G for v6ops-data@psg.com; Fri, 14 Apr 2006 10:20:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 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 1FULPk-000OOF-9u for v6ops@ops.ietf.org; Fri, 14 Apr 2006 10:20:32 +0000 Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001742291.msg for ; Fri, 14 Apr 2006 12:19:53 +0200 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 14 Apr 2006 12:20:06 +0200 Subject: Re: PI addressing in IPv6 advances in ARIN From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" , "ppml@arin.net" , "shim6@psg.com" Message-ID: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdw= In-Reply-To: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060414:v6ops@ops.ietf.org::MVPnsgKzuAXGYwV3:00000000000000000000000000000000000000000003R5M 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, Fri, 14 Apr 2006 12:20:02 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Hi Jim, Not sure if I got your question correctly, but let me try to explain my view. I understand the position of the people that say they need PI today, especially because not having it may be hurting the advancement of the IPv6 deployment. However, I want to balance this with the medium-long term implications created in the routing table and with the time needed to build and deploy a better technical solution (or several) which is accepted by the community. So my proposal basically is about having PI now everywhere (once ARIN adopt it, is unfair not having it in other regions), but those PI allocations for multihoming should be temporary and those address blocks returned to the RIRs some time (lets say 3 years) after the new technical solution is declared as a valid one. At this way, on the long-run, we will not have routing table implications, but we allow now the people that want to move ahead only if they have a multihoming solution doing so. This 3-years time for getting a multihoming network back to the new technical solution (once adopted) is enough time, I think (it could be changed to 5 years if needed, or whatever), so nobody today see the temporarily of the proposal as a showstopper to go for it now. Regards, Jordi > De: "Bound, Jim" > Responder a: > Fecha: Fri, 14 Apr 2006 03:11:58 -0400 > Para: , > Conversaci=F3n: PI addressing in IPv6 advances in ARIN > Asunto: RE: PI addressing in IPv6 advances in ARIN >=20 > Jordi, why this will work as is for now? > /jim=20 >=20 >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ >> Sent: Thursday, April 13, 2006 5:28 PM >> To: v6ops@ops.ietf.org >> Subject: Re: PI addressing in IPv6 advances in ARIN >>=20 >> Hi Thomas, all, >>=20 >> During my fly-back from Montreal, I've worked in a proposal >> and I'm talking to folks in each RIR/region, with the idea to >> submit it to all them as a kind of (if possible), global policy. >>=20 >> The idea is based on the comments that I did at the mic >> during the ARIN meeting. >>=20 >> I will try to get this submitted next Monday/Tuesday and get >> ready for a formal presentation during the next RIPE meeting >> at Istanbul (following week). >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >>> De: Thomas Narten >>> Responder a: >>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400 >>> Para: "Gunter Van de Velde (gvandeve)" >>> CC: "v6ops@ops.ietf.org" >>> Asunto: Re: PI addressing in IPv6 advances in ARIN >>>=20 >>>> What would be the prefix allocation per organization? >>>=20 >>> /48, though can be larger in some cases. Watch for the revised >>> proposal that gets last called for details. >>>=20 >>>> (Me being in Europe and not attending ARIN sessions) >>>=20 >>> Note: none of the other RIRs have such a policy in place >> today, though=20 >>> I wouldn't be surprised if they now followup with proposals >> of their=20 >>> own (though someone has to do it). >>>=20 >>>> Has there been study on the # of organizations going for >> this and if=20 >>>> the impact will be more significant then more's law on technology >>>> enhancement? >>>=20 >>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today," >>> "looking at the impact of the current IPv4 policies, the >> number of PI=20 >>> assignments is only on the 100s per year", and "we can update the >>> policy if things get problematical". >>>=20 >>> Thomas >>>=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 Fri Apr 14 06:47:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FULpN-0003Ti-Gb for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 06:47:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FULpL-0004i8-1N for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 06:47:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FULm4-0000hD-Pj for v6ops-data@psg.com; Fri, 14 Apr 2006 10:43:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FULm3-0000gs-LZ; Fri, 14 Apr 2006 10:43: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 k3EAhZc26900; Fri, 14 Apr 2006 12:43:35 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams3-vpn-dhcp30.cisco.com [10.61.64.30]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k3EAhXC29566; Fri, 14 Apr 2006 12:43:33 +0200 (CEST) Message-Id: <4.3.2.7.2.20060414123720.0369ed10@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Apr 2006 12:43:31 +0200 To: jordi.palet@consulintel.es From: "Gunter Van de Velde (gvandeve)" Subject: Re: PI addressing in IPv6 advances in ARIN Cc: "v6ops@ops.ietf.org" , "ppml@arin.net" , "shim6@psg.com" In-Reply-To: References: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Hi Jordi, Please see inline. At 12:20 14/04/2006 +0200, JORDI PALET MARTINEZ wrote: >Hi Jim, > >Not sure if I got your question correctly, but let me try to explain my >view. > >I understand the position of the people that say they need PI today, >especially because not having it may be hurting the advancement of the IPv6 >deployment. > >However, I want to balance this with the medium-long term implications >created in the routing table and with the time needed to build and deploy a >better technical solution (or several) which is accepted by the community. > >So my proposal basically is about having PI now everywhere (once ARIN adopt >it, is unfair not having it in other regions), but those PI allocations for >multihoming should be temporary and those address blocks returned to the >RIRs some time (lets say 3 years) after the new technical solution is >declared as a valid one. That will never happen i suppose... once there is PI space out there, then it will be there forever.... the discussion in 2 a 3 years will be the same= =20 as now because Network Management staff just don't like to renumber their infrastructures= =20 (and that is for valid reasons), and this is even more valid when speaking about the very large enterprise organizations. If PI is accepted now, then i suppose it=20 will be out there forever and ever. When PI space is out there then i wonder who of these organizations would=20 actually still be interested in a shim solution and further development may result=20 in an academical effort. Brgds, G/ >At this way, on the long-run, we will not have routing table implications, >but we allow now the people that want to move ahead only if they have a >multihoming solution doing so. > >This 3-years time for getting a multihoming network back to the new >technical solution (once adopted) is enough time, I think (it could be >changed to 5 years if needed, or whatever), so nobody today see the >temporarily of the proposal as a showstopper to go for it now. > >Regards, >Jordi > > > > > > De: "Bound, Jim" > > Responder a: > > Fecha: Fri, 14 Apr 2006 03:11:58 -0400 > > Para: , > > Conversaci=F3n: PI addressing in IPv6 advances in ARIN > > Asunto: RE: PI addressing in IPv6 advances in ARIN > > > > Jordi, why this will work as is for now? > > /jim > > > >> -----Original Message----- > >> From: owner-v6ops@ops.ietf.org > >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ > >> Sent: Thursday, April 13, 2006 5:28 PM > >> To: v6ops@ops.ietf.org > >> Subject: Re: PI addressing in IPv6 advances in ARIN > >> > >> Hi Thomas, all, > >> > >> During my fly-back from Montreal, I've worked in a proposal > >> and I'm talking to folks in each RIR/region, with the idea to > >> submit it to all them as a kind of (if possible), global policy. > >> > >> The idea is based on the comments that I did at the mic > >> during the ARIN meeting. > >> > >> I will try to get this submitted next Monday/Tuesday and get > >> ready for a formal presentation during the next RIPE meeting > >> at Istanbul (following week). > >> > >> Regards, > >> Jordi > >> > >> > >> > >> > >>> De: Thomas Narten > >>> Responder a: > >>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400 > >>> Para: "Gunter Van de Velde (gvandeve)" > >>> CC: "v6ops@ops.ietf.org" > >>> Asunto: Re: PI addressing in IPv6 advances in ARIN > >>> > >>>> What would be the prefix allocation per organization? > >>> > >>> /48, though can be larger in some cases. Watch for the revised > >>> proposal that gets last called for details. > >>> > >>>> (Me being in Europe and not attending ARIN sessions) > >>> > >>> Note: none of the other RIRs have such a policy in place > >> today, though > >>> I wouldn't be surprised if they now followup with proposals > >> of their > >>> own (though someone has to do it). > >>> > >>>> Has there been study on the # of organizations going for > >> this and if > >>>> the impact will be more significant then more's law on technology > >>>> enhancement? > >>> > >>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today," > >>> "looking at the impact of the current IPv4 policies, the > >> number of PI > >>> assignments is only on the 100s per year", and "we can update the > >>> policy if things get problematical". > >>> > >>> Thomas > >>> > >> > >> > >> > >> > >> ********************************************** > >> 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. > >> > >> > >> > >> > >> > > > > > > >********************************************** >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=20 >confidential. The information is intended to be for the use of the=20 >individual(s) named above. If you are not the intended recipient be aware= =20 >that any disclosure, copying, distribution or use of the contents of this= =20 >information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Apr 14 07:25:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUMQT-00013W-Sx for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 07:25:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUMQQ-0006GU-Nz for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 07:25:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMPu-0003Vy-Ex for v6ops-data@psg.com; Fri, 14 Apr 2006 11:24:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 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 1FUMPs-0003Va-0H for v6ops@ops.ietf.org; Fri, 14 Apr 2006 11:24:44 +0000 Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001742331.msg for ; Fri, 14 Apr 2006 13:24:13 +0200 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 14 Apr 2006 13:24:31 +0200 Subject: Re: PI addressing in IPv6 advances in ARIN From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" CC: "ppml@arin.net" , "shim6@psg.com" Message-ID: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZftf+uPmnPgsupEdqXyQANky3PwA== In-Reply-To: <4.3.2.7.2.20060414123720.0369ed10@strange-brew> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060414:v6ops@ops.ietf.org::3YKpZ4KneCseAAiF:00000000000000000000000000000000000000000005ggx 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, Fri, 14 Apr 2006 13:24:18 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba See below. Regards, Jordi > De: "Gunter Van de Velde (gvandeve)" > Responder a: > Fecha: Fri, 14 Apr 2006 12:43:31 +0200 > Para: > CC: "v6ops@ops.ietf.org" , "ppml@arin.net" > , "shim6@psg.com" > Asunto: Re: PI addressing in IPv6 advances in ARIN >=20 > Hi Jordi, >=20 > Please see inline. >=20 > At 12:20 14/04/2006 +0200, JORDI PALET MARTINEZ wrote: >> Hi Jim, >>=20 >> Not sure if I got your question correctly, but let me try to explain my >> view. >>=20 >> I understand the position of the people that say they need PI today, >> especially because not having it may be hurting the advancement of the IPv6 >> deployment. >>=20 >> However, I want to balance this with the medium-long term implications >> created in the routing table and with the time needed to build and deploy a >> better technical solution (or several) which is accepted by the community. >>=20 >> So my proposal basically is about having PI now everywhere (once ARIN adopt >> it, is unfair not having it in other regions), but those PI allocations for >> multihoming should be temporary and those address blocks returned to the >> RIRs some time (lets say 3 years) after the new technical solution is >> declared as a valid one. >=20 > That will never happen i suppose... once there is PI space out there, then > it will be there forever.... the discussion in 2 a 3 years will be the same > as now because > Network Management staff just don't like to renumber their infrastructures > (and that is > for valid reasons), and this is even more valid when speaking about the very > large enterprise organizations. If PI is accepted now, then i suppose it > will be out there > forever and ever. Precisely, writing it in the policy will make clear what is not forever. Even if the policy don't say it is temporary, it can be changed at any time. I think is more fair to tell it clearly since the time time the policy is accepted. By the way, something else that I've in my proposal is clarifying that if a use of this policy don't want to go to the technical solution later on, he has, of course, the chance to become an LIR at that time and avoid renumbering (of course, needs to qualify for LIR). >=20 > When PI space is out there then i wonder who of these organizations would > actually > still be interested in a shim solution and further development may result > in an academical > effort. I'm not necessarily talking about shim or only about shim. I hope there will be solutions that will make attractive going for this change. >=20 > Brgds, > G/ >=20 >> At this way, on the long-run, we will not have routing table implications, >> but we allow now the people that want to move ahead only if they have a >> multihoming solution doing so. >>=20 >> This 3-years time for getting a multihoming network back to the new >> technical solution (once adopted) is enough time, I think (it could be >> changed to 5 years if needed, or whatever), so nobody today see the >> temporarily of the proposal as a showstopper to go for it now. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >>> De: "Bound, Jim" >>> Responder a: >>> Fecha: Fri, 14 Apr 2006 03:11:58 -0400 >>> Para: , >>> Conversaci=F3n: PI addressing in IPv6 advances in ARIN >>> Asunto: RE: PI addressing in IPv6 advances in ARIN >>>=20 >>> Jordi, why this will work as is for now? >>> /jim >>>=20 >>>> -----Original Message----- >>>> From: owner-v6ops@ops.ietf.org >>>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ >>>> Sent: Thursday, April 13, 2006 5:28 PM >>>> To: v6ops@ops.ietf.org >>>> Subject: Re: PI addressing in IPv6 advances in ARIN >>>>=20 >>>> Hi Thomas, all, >>>>=20 >>>> During my fly-back from Montreal, I've worked in a proposal >>>> and I'm talking to folks in each RIR/region, with the idea to >>>> submit it to all them as a kind of (if possible), global policy. >>>>=20 >>>> The idea is based on the comments that I did at the mic >>>> during the ARIN meeting. >>>>=20 >>>> I will try to get this submitted next Monday/Tuesday and get >>>> ready for a formal presentation during the next RIPE meeting >>>> at Istanbul (following week). >>>>=20 >>>> Regards, >>>> Jordi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> De: Thomas Narten >>>>> Responder a: >>>>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400 >>>>> Para: "Gunter Van de Velde (gvandeve)" >>>>> CC: "v6ops@ops.ietf.org" >>>>> Asunto: Re: PI addressing in IPv6 advances in ARIN >>>>>=20 >>>>>> What would be the prefix allocation per organization? >>>>>=20 >>>>> /48, though can be larger in some cases. Watch for the revised >>>>> proposal that gets last called for details. >>>>>=20 >>>>>> (Me being in Europe and not attending ARIN sessions) >>>>>=20 >>>>> Note: none of the other RIRs have such a policy in place >>>> today, though >>>>> I wouldn't be surprised if they now followup with proposals >>>> of their >>>>> own (though someone has to do it). >>>>>=20 >>>>>> Has there been study on the # of organizations going for >>>> this and if >>>>>> the impact will be more significant then more's law on technology >>>>>> enhancement? >>>>>=20 >>>>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today," >>>>> "looking at the impact of the current IPv4 policies, the >>>> number of PI >>>>> assignments is only on the 100s per year", and "we can update the >>>>> policy if things get problematical". >>>>>=20 >>>>> Thomas >>>>>=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 ********************************************** 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 Fri Apr 14 08:05:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUN3b-00053B-Vu for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 08:05:47 -0400 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 1FUMXj-0006YK-HW for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 07:32:51 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FUMI3-0006e4-St for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 07:16:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMGT-0002mf-Ry for v6ops-data@psg.com; Fri, 14 Apr 2006 11:15:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMGS-0002m3-Jn; Fri, 14 Apr 2006 11:15:01 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3EBEOJ3045505 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Apr 2006 13:14:24 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4.3.2.7.2.20060414123720.0369ed10@strange-brew> References: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> <4.3.2.7.2.20060414123720.0369ed10@strange-brew> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <173E8519-DCA6-4D2A-ADFA-1542F24605CB@muada.com> Cc: jordi.palet@consulintel.es, "v6ops@ops.ietf.org" , "ppml@arin.net" , "shim6@psg.com" Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Subject: Re: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 13:14:49 +0200 To: Gunter Van de Velde (gvandeve) X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 While I'm in a nasty mood anyway, let me make the most of it... Would you people prune the god damn quotes already!!!!!! On 14-apr-2006, at 12:43, Gunter Van de Velde (gvandeve) wrote: > Hi Jordi, > > Please see inline. > > At 12:20 14/04/2006 +0200, JORDI PALET MARTINEZ wrote: >> Hi Jim, >> >> Not sure if I got your question correctly, but let me try to =20 >> explain my >> view. >> >> I understand the position of the people that say they need PI today, >> especially because not having it may be hurting the advancement of =20= >> the IPv6 >> deployment. >> >> However, I want to balance this with the medium-long term =20 >> implications >> created in the routing table and with the time needed to build and =20= >> deploy a >> better technical solution (or several) which is accepted by the =20 >> community. >> >> So my proposal basically is about having PI now everywhere (once =20 >> ARIN adopt >> it, is unfair not having it in other regions), but those PI =20 >> allocations for >> multihoming should be temporary and those address blocks returned =20 >> to the >> RIRs some time (lets say 3 years) after the new technical solution is >> declared as a valid one. > > That will never happen i suppose... once there is PI space out =20 > there, then > it will be there forever.... the discussion in 2 a 3 years will be =20 > the same as now because > Network Management staff just don't like to renumber their =20 > infrastructures (and that is > for valid reasons), and this is even more valid when speaking about =20= > the very > large enterprise organizations. If PI is accepted now, then i =20 > suppose it will be out there > forever and ever. > > When PI space is out there then i wonder who of these organizations =20= > would actually > still be interested in a shim solution and further development may =20 > result in an academical > effort. > > Brgds, > G/ > >> At this way, on the long-run, we will not have routing table =20 >> implications, >> but we allow now the people that want to move ahead only if they =20 >> have a >> multihoming solution doing so. >> >> This 3-years time for getting a multihoming network back to the new >> technical solution (once adopted) is enough time, I think (it =20 >> could be >> changed to 5 years if needed, or whatever), so nobody today see the >> temporarily of the proposal as a showstopper to go for it now. >> >> Regards, >> Jordi >> >> >> >> >> > De: "Bound, Jim" >> > Responder a: >> > Fecha: Fri, 14 Apr 2006 03:11:58 -0400 >> > Para: , >> > Conversaci=F3n: PI addressing in IPv6 advances in ARIN >> > Asunto: RE: PI addressing in IPv6 advances in ARIN >> > >> > Jordi, why this will work as is for now? >> > /jim >> > >> >> -----Original Message----- >> >> From: owner-v6ops@ops.ietf.org >> >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET =20 >> MARTINEZ >> >> Sent: Thursday, April 13, 2006 5:28 PM >> >> To: v6ops@ops.ietf.org >> >> Subject: Re: PI addressing in IPv6 advances in ARIN >> >> >> >> Hi Thomas, all, >> >> >> >> During my fly-back from Montreal, I've worked in a proposal >> >> and I'm talking to folks in each RIR/region, with the idea to >> >> submit it to all them as a kind of (if possible), global policy. >> >> >> >> The idea is based on the comments that I did at the mic >> >> during the ARIN meeting. >> >> >> >> I will try to get this submitted next Monday/Tuesday and get >> >> ready for a formal presentation during the next RIPE meeting >> >> at Istanbul (following week). >> >> >> >> Regards, >> >> Jordi >> >> >> >> >> >> >> >> >> >>> De: Thomas Narten >> >>> Responder a: >> >>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400 >> >>> Para: "Gunter Van de Velde (gvandeve)" >> >>> CC: "v6ops@ops.ietf.org" >> >>> Asunto: Re: PI addressing in IPv6 advances in ARIN >> >>> >> >>>> What would be the prefix allocation per organization? >> >>> >> >>> /48, though can be larger in some cases. Watch for the revised >> >>> proposal that gets last called for details. >> >>> >> >>>> (Me being in Europe and not attending ARIN sessions) >> >>> >> >>> Note: none of the other RIRs have such a policy in place >> >> today, though >> >>> I wouldn't be surprised if they now followup with proposals >> >> of their >> >>> own (though someone has to do it). >> >>> >> >>>> Has there been study on the # of organizations going for >> >> this and if >> >>>> the impact will be more significant then more's law on =20 >> technology >> >>>> enhancement? >> >>> >> >>> Mostly just hand waving, with a lot of "IPv4 hasn't melted =20 >> today," >> >>> "looking at the impact of the current IPv4 policies, the >> >> number of PI >> >>> assignments is only on the 100s per year", and "we can update the >> >>> policy if things get problematical". >> >>> >> >>> Thomas >> >>> >> >> >> >> >> >> >> >> >> >> ********************************************** >> >> 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. >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> ********************************************** >> 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 =20 >> privileged or confidential. The information is intended to be for =20 >> the use of the individual(s) named above. If you are not the =20 >> intended recipient be aware that any disclosure, copying, =20 >> distribution or use of the contents of this information, including =20= >> attached files, is prohibited. > > --=20 I've written another book! http://www.runningipv6.net/ From owner-v6ops@ops.ietf.org Fri Apr 14 08:08:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUN6f-0006Yr-6o for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 08:08:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUN6d-0007eR-Ly for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 08:08:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUN6D-0007QK-F2 for v6ops-data@psg.com; Fri, 14 Apr 2006 12:08:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 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 1FUN6C-0007Pv-6X for v6ops@ops.ietf.org; Fri, 14 Apr 2006 12:08:28 +0000 Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001742375.msg for ; Fri, 14 Apr 2006 14:07:51 +0200 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 14 Apr 2006 14:08:05 +0200 Subject: Re: [ppml] PI addressing in IPv6 advances in ARIN From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" , "ppml@arin.net" , "shim6@psg.com" , "sig-ipv6@lists.apnic.net" , , "politicas@lacnic.net" , , IPv6 in Africa , , Message-ID: Thread-Topic: [ppml] PI addressing in IPv6 advances in ARIN Thread-Index: AcZfuAnRSJIaL8urEdqXyQANky3PwAABAvsn In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060414:v6ops@ops.ietf.org::PUAPFoM38xh8bUMF:00000000000000000000000000000000000000000001f/F 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, Fri, 14 Apr 2006 14:08:02 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6@lists.apnic.net So, if you aren't subscribed in the global-v6@lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ > Responder a: > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops@ops.ietf.org" , "ppml@arin.net" > , "shim6@psg.com" > Conversaci=F3n: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >=20 > Hi Owen, >=20 > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. >=20 > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. >=20 > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. >=20 > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >> De: Owen DeLong >> Responder a: >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: , "v6ops@ops.ietf.org" >> , >> "ppml@arin.net" , "shim6@psg.com" >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >>=20 >>=20 >>=20 >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> wrote: >>=20 >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>>=20 >> I think we first need to define what we consider a solution... See below. >>=20 >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>>=20 >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >>=20 >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >>=20 >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >>=20 >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >>=20 >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >>=20 >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >>=20 >>=20 >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>>=20 >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >>=20 >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>>=20 >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >>=20 >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >>=20 >> Owen >>=20 >>=20 >> --=20 >> If it wasn't crypto-signed, it probably didn't come from me. >=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 >=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 ********************************************** 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 Fri Apr 14 09:04:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUNyd-0007Pz-17 for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 09:04:43 -0400 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 1FUN60-0007bQ-Fc for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 08:08:16 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FUMeY-0006qi-3o for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 07:39:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMe7-0004kU-SV for v6ops-data@psg.com; Fri, 14 Apr 2006 11:39:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 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 1FUMe6-0004kE-PC for v6ops@ops.ietf.org; Fri, 14 Apr 2006 11:39:26 +0000 Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001742344.msg for ; Fri, 14 Apr 2006 13:38:55 +0200 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 14 Apr 2006 13:39:07 +0200 Subject: Re: [ppml] PI addressing in IPv6 advances in ARIN From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" , "ppml@arin.net" , "shim6@psg.com" Message-ID: Thread-Topic: [ppml] PI addressing in IPv6 advances in ARIN Thread-Index: AcZfuAnRSJIaL8urEdqXyQANky3PwA== In-Reply-To: <45724B568004AB728EEE8258@imac-en0.delong.sj.ca.us> 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:060414:v6ops@ops.ietf.org::wQ+nexX9nrnPDmJT:00000000000000000000000000000000000000000007MI3 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, Fri, 14 Apr 2006 13:39:00 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Hi Owen, You said it: If somebody find the good solution, it will be attractive to the people to go for it. Otherwise, you always have the chance to become an LIR. My proposal actually is already considering this point and a way to avoid a need for renumbering if that happens. I just want to make sure that we have a way-out if it becomes necessary, but avoid a showstopper now. I think is it possible. I don't have a technical solution yet (and agree with your views on this in the email below in general), but I'm confident we will have. If it will take 4 years from now, or just 2, who knows, so my proposal is ensuring that we have those 4 years+3 for allowing the people either to return the block, or become an LIR and avoid renumbering an any changes in their network. By the way, it may happen, and I'm hoping so, that the technical solution don't make necessary to return the PI block anymore, and in that case, we will be even able to remove at that time the "temporarily" point in the policy (if it becomes accepted). Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Fri, 14 Apr 2006 03:48:34 -0700 > Para: , "v6ops@ops.ietf.org" , > "ppml@arin.net" , "shim6@psg.com" > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > > > --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ > wrote: > > [snip] >> However, I want to balance this with the medium-long term implications >> created in the routing table and with the time needed to build and deploy >> a better technical solution (or several) which is accepted by the >> community. >> > I think we first need to define what we consider a solution... See below. > >> So my proposal basically is about having PI now everywhere (once ARIN >> adopt it, is unfair not having it in other regions), but those PI >> allocations for multihoming should be temporary and those address blocks >> returned to the RIRs some time (lets say 3 years) after the new technical >> solution is declared as a valid one. >> > I would not actually support this idea. The whole point of having PI > space is to have the addresses for a long-term. Having a timeframe for > return would simply restore the same barrier to entry that existed > prior to passing the policy. > > Other RIRs are free to implement whatever v6 PI policy they feel is > appropriate for their region. I would support a globally standardized > v6 PI policy along the lines of ARIN 2005-1. > > However, I would like to argue that if the new technical solution will > benefit from the return of this address space, it is most likely not > truly a solution, but, instead, another clever hack piled on top of > the existing set of hacks. > > I suppose if someone found the magic bullet to make geotopological > addressing really work, that might qualify. However, I have very low > expectations in that area. > > Absent that, any true solution will involve making the size of the routing > table independent of the number of PI (or even PA) blocks issued by > the RIRs or will make the size of the routing table practically > irrelevant. > > I know this isn't the easy solution, but, we need to look long and > hard at the way we do things. I think that solving these problems > is going to require a significant paradigm shift. Assuming that we > can use IP addresses for both end system identification and for > routing topology indicators is how we created this problem. I don't > see solving it without breaking that assumption, at least at the > interdomain level. > > >> At this way, on the long-run, we will not have routing table implications, >> but we allow now the people that want to move ahead only if they have a >> multihoming solution doing so. >> > If you think there is a possible solution (a real solution, not just > a hack that postpones the inevitable at the expense of usability > like CIDR did), then I'd like to hear what you are thinking. > >> This 3-years time for getting a multihoming network back to the new >> technical solution (once adopted) is enough time, I think (it could be >> changed to 5 years if needed, or whatever), so nobody today see the >> temporarily of the proposal as a showstopper to go for it now. >> > I think you underestimate the momentum and requirements of the modern > enterprise if you believe that to be true. Any capability available > in v4 that is not available on at least equal or better terms in v6 > is a deterrent to v6 deployment. > > The ability to get permanent addresses which do not have to be returned > when you switch providers or renumbered on a schedule determined by > some external organization is a major example of such a capability. > > Owen > > > -- > If it wasn't crypto-signed, it probably didn't come from me. ********************************************** 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 Fri Apr 14 09:22:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOGE-0003xg-7J for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 09:22:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUOGD-0001Rj-Qw for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 09:22:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUOEe-000Cbu-6o for v6ops-data@psg.com; Fri, 14 Apr 2006 13:21:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUOEd-000CbZ-DB for v6ops@ops.ietf.org; Fri, 14 Apr 2006 13:21:15 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2006 06:21:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,120,1144047600"; d="scan'208"; a="25903897:sNHT24751852" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3EDL4vF023435; Fri, 14 Apr 2006 09:21:04 -0400 (EDT) Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 09:21:04 -0400 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: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 09:21:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdwAA0OvXwACjpKg From: "Craig Huegen \(chuegen\)" To: "Durand, Alain" , , , X-OriginalArrivalTime: 14 Apr 2006 13:21:04.0557 (UTC) FILETIME=[482ADDD0:01C65FC6] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On Friday, April 14, 2006 6:54 AM, Alain Durand wrote: > A) if PI addresses are to be returned at some point in time, > they loose a dreat deal of their value. Folks like PI because > it shields them from renumbering. I'd like to clarify this a bit. As a large enterprise network operator, I'm less concerned about the need to renumber the network once than I am the need to renumber every time that I want to change a service provider. Don't take that the wrong way: renumbering is still a significant pain, but the real reason that enterprises haven't adopted PA space is that it represents a de-facto "lock-in" to the service providers they choose initially and they're faced with a network-wide renumber any time they drop or add a service provider. Most enterprise network operators that I have spoken to would be willing to renumber once in the future, in exchange for a reasonable way to get portable IPv6 space today. > B) any address reclaim process might be lenghty and costly Maybe I'm being overly simplistic, but the policy can set a recovery timeframe in its allocation of PI space to end users and the market forces can drive the recovery based on the impact to the infrastructure. If only a few hundred prefixes are handed out, it might not be enough of a problem to force recovery. This may be a moot point for the ARIN discussion, though, as ARIN typically doesn't play all that much of an enforcer role. It can declare prefixes and prefix ranges as dead, but reachability is determined by the service providers. > C) given how long the shim6/multi homing has taken so far, it > seems hazardous to make any bet that in 3 years it will be > finish, implemented, adopted, deployed... I think that Jordi was referring to 3 years after the solution is declared "available" -- admittedly that's a tough milestone to set. Finally, I agree with all four other points you make; adoption of IPv6 has been held up because the capabilities offered lack a critical requirement for enterprise networks (connectivity without de-facto service provider lock-in). The agreement to move forward with a policy is a very positive thing that enables IPv6 to work for large enterprises while the right solution is determined and rolled out. /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-v6ops@ops.ietf.org Fri Apr 14 09:35:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOSd-0005H3-NC for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 09:35:43 -0400 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 1FUN5q-0007bQ-Km for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 08:08:06 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FUMtL-0006xM-Dz for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 07:55:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMtD-000658-IE for v6ops-data@psg.com; Fri, 14 Apr 2006 11:55:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMtC-000641-PR; Fri, 14 Apr 2006 11:55:03 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3EBsVk7046147 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Apr 2006 13:54:32 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34CF1CE8-013E-4F4C-BEEB-93C00F1BDAAA@muada.com> Cc: "v6ops@ops.ietf.org" , "ppml@arin.net" , "shim6@psg.com" Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [ppml] PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 13:54:56 +0200 To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On 14-apr-2006, at 13:39, JORDI PALET MARTINEZ wrote: > my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the > block, or > become an LIR and avoid renumbering an any changes in their network. I don't see the logic of an end-user organization becoming a LIR in the sense that they give out address space to other end-user organizations. And even if they did, a /48 or even a reserved /44 (why not give them the /44 right away then, at least that saves us from accepting /48s which is dangerous because of potentially deaggregated /32s and we have IPv6 addresses aplenty) isn't big enough to be a LIR without obtaining a new address block. > By the way, it may happen, and I'm hoping so, that the technical > solution > don't make necessary to return the PI block anymore, and in that > case, we > will be even able to remove at that time the "temporarily" point in > the > policy (if it becomes accepted). If the PI blocks are given out according to a geographic addressing plan we leave the door open for geographic aggregation in the future. I know few people believe in this today but if we're going to have PI anyway, giving out those prefixes geographically doesn't do any harm but it allows for future developments. From owner-v6ops@ops.ietf.org Fri Apr 14 09:50:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOhO-00061Q-Fg for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 09:50:58 -0400 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 1FUN5r-0007bQ-Ai for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 08:08:07 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FUMt8-0006x6-Rh for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 07:54:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMs8-0005y1-AD for v6ops-data@psg.com; Fri, 14 Apr 2006 11:53:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [208.17.33.59] (helo=pacdcoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUMs7-0005xd-Ly for v6ops@ops.ietf.org; Fri, 14 Apr 2006 11:53:55 +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="UTF-8" Content-Transfer-Encoding: base64 Subject: Re: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 07:53:33 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730405F207@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdwAA0OvXw== From: "Durand, Alain" To: , , X-OriginalArrivalTime: 14 Apr 2006 11:53:35.0934 (UTC) FILETIME=[0FBE8DE0:01C65FBA] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.0 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 V3J0IEpvcmRpJ3MgcHJvcG9zYWw6DQoNCkkgaGF2ZSBzeW1wYXRoeSB0byB0aGUgaWRlYSBvZiBi YWxhbmNpbmcgUEkgbmVlZCB3aXRoIHJvdXRpbmcgdGFibGUgZ3Jvd3RoLCBob3dldmVyOg0KDQpB KSBpZiBQSSBhZGRyZXNzZXMgYXJlIHRvIGJlIHJldHVybmVkIGF0IHNvbWUgcG9pbnQgaW4gdGlt ZSwgdGhleSBsb29zZSBhIGRyZWF0IGRlYWwgb2YgdGhlaXIgdmFsdWUuIEZvbGtzIGxpa2UgUEkg YmVjYXVzZSBpdCBzaGllbGRzIHRoZW0gZnJvbSByZW51bWJlcmluZy4NCg0KQikgYW55IGFkZHJl c3MgcmVjbGFpbSBwcm9jZXNzIG1pZ2h0IGJlIGxlbmdodHkgYW5kIGNvc3RseQ0KDQpDKSBnaXZl biBob3cgbG9uZyB0aGUgc2hpbTYvbXVsdGkgaG9taW5nIGhhcyB0YWtlbiBzbyBmYXIsIGl0IHNl ZW1zIGhhemFyZG91cyB0byBtYWtlIGFueSBiZXQgdGhhdCBpbiAzIHllYXJzIGl0IHdpbGwgYmUg ZmluaXNoLCBpbXBsZW1lbnRlZCwgYWRvcHRlZCwgZGVwbG95ZWQuLi4NCg0KRCkgSSBhbSBzZW5z aXRpdmUgdG8gdGhlIGFyZ3VtZW50IHRoYXQgdjQgaGFzIG5vdCAibWVsdGVkIiB3aXRoIFBJLCBz byB3aHkgc2hvdWxkIHY2IG1lbHQgbW9yZT8gSSBiZWxpZXZlIHRoZSBiZW5lZml0cyBvZiBoYW5k aW5nIG91dCBQSSAqbm93KiBvdXR3ZWlnaHQgdGhlIGNvc3Qgb2YgYSAqc21hbGwqIHN3YW1wLiAN Cg0KRSkgZ2l2ZW4gdGhlIHN0YXRlIG9mIHY2IGRlcGxveW1lbnQgbm93LCBJIGRvIG5vdCB0aGlu ayB0aGVyZSBpcyBtdWNoIHJpc2sgd2l0aCB0aGlzIHBvbGljeSBhdCB0aGlzIG1vbWVudC4gQW5k IGFzIFRob21hcyByZWxheWVkLCB0aGlzIHBvbGljeSBjb3VsZCBiZSBjaGFuZ2VkIGFueXdheSBp ZiB0aGluZ3MgZ2V0IG91dCBvZiBjb250cm9sLg0KDQpGKSBpZiB0aGlzIG1lYW5zIGdpdmluZyBh ZHZhbnRhZ2UgdG8gdGhlIGVhcmx5IGFkb3B0ZXJzIGJ5IG9mZmVyaW5nIHRoZW0gUEksIEkgbG9v ayBhdCB0aGlzIGFzIGEgcG9zaXRpdmUgdGhpbmcuDQoNCkcpIGEga2V5IHRoaW5nIGlzIHRvIGxp bWl0IHRoZSBzaXplIG9mIHRoZSBzd2FtcCB0aGF0IHdvdWxkIGJlIGNyZWF0ZWQsIG9yIG1vcmUg c3BlY2lmaWNhbGx5IGxpbWl0IGl0cyBncm93dGguIFNvIGl0IG1pZ2h0IGJlIGEgZ29vZCBpZGVh IHRvIGhhdmUgYSBzdW5zZXQgY2xhdXNlIGluIHRoZSBwb2xpY3ksIGxpa2UgaXQgd2lsbCBoYXZl IHRvIGJlIHJldmlzaXRlZCBpbiAyIHllYXJzIG9yIHdoZW4gYSBjZXJ0YWluIGFsbG9jYXRpb24g KG9yIGFsbG9jYXRpb24gcmF0ZSkgdGhyZXNob2xkIHdpbGwgYmUgcmVhY2hlZC4NCg0KICAgIC0g QWxhaW4uDQo= From owner-v6ops@ops.ietf.org Fri Apr 14 10:03:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOtx-0007bG-HI for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 10:03:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUOtw-0002gu-9I for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 10:03:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUOsm-000FGc-UD for v6ops-data@psg.com; Fri, 14 Apr 2006 14:02:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [208.17.33.58] (helo=pacdcoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUOsm-000FGR-Ep for v6ops@ops.ietf.org; Fri, 14 Apr 2006 14:02:44 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 10:02:17 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305627DD2@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdwAA0OvXwACjpKgAAHZ5wA= From: "Durand, Alain" To: "Craig Huegen \(chuegen\)" , , , , X-OriginalArrivalTime: 14 Apr 2006 14:02:18.0713 (UTC) FILETIME=[0AE11C90:01C65FCC] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 =20 > -----Original Message----- > From: Craig Huegen (chuegen) [mailto:chuegen@cisco.com]=20 > > B) any address reclaim process might be lenghty and costly >=20 > Maybe I'm being overly simplistic, but the policy can set a=20 > recovery timeframe in its allocation of PI space to end users=20 > and the market forces can drive the recovery based on the=20 > impact to the infrastructure. > If only a few hundred prefixes are handed out, it might not=20 > be enough of a problem to force recovery. One could argue that if we are only talking about a few hundred prefixes, Why do we care reclaiming them? - Alain. From owner-v6ops@ops.ietf.org Fri Apr 14 10:38:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPQy-0008Er-A4 for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 10:38:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPQy-0003uI-0c for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 10:38:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUPPX-000HVn-Be for v6ops-data@psg.com; Fri, 14 Apr 2006 14:36:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUPPW-000HVU-Oe for v6ops@ops.ietf.org; Fri, 14 Apr 2006 14:36:34 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Apr 2006 10:36:34 -0400 X-IronPort-AV: i="4.04,120,1144036800"; d="scan'208"; a="86456257:sNHT32564304" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3EEaYTL029074; Fri, 14 Apr 2006 10:36:34 -0400 (EDT) Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 10:36:33 -0400 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: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 10:36:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdwAA0OvXwACjpKgAAHZ5wAAAOvz0A== From: "Craig Huegen \(chuegen\)" To: "Durand, Alain" , , , , X-OriginalArrivalTime: 14 Apr 2006 14:36:33.0997 (UTC) FILETIME=[D3EC8FD0:01C65FD0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Friday, April 14, 2006 9:02 AM, Durand, Alain wrote: >> -----Original Message----- >> From: Craig Huegen (chuegen) [mailto:chuegen@cisco.com] >>> B) any address reclaim process might be lenghty and costly >>=20 >> Maybe I'm being overly simplistic, but the policy can set a >> recovery timeframe in its allocation of PI space to end users >> and the market forces can drive the recovery based on the impact to >> the infrastructure. If only a few hundred prefixes are handed out, >> it might not be enough of a problem to force recovery. >=20 > One could argue that if we are only talking about a few hundred > prefixes, Why do we care reclaiming them? I agree with that argument, _if_ there are only a few hundred. I'm also leaving room for a case here that results in tens of thousands of these prefixes being routed (for instance, if the community can't reach any consensus on architectures for many years). I believe that the RIR's who assign PI space should do so with explicit agreement that there may need to be a reclamation in the future, when a new architecture exists. RIR's do not have the ability to enforce that today except through some specific policy hurdles and perhaps some fee structuring. The primary enforcer will likely need to be service providers, depending upon the pain they feel from having to carry these prefixes. /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-v6ops@ops.ietf.org Fri Apr 14 10:41:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPUd-0001d0-Hg for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 10:41:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPUc-00041K-8y for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 10:41:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUPUU-000Hv1-F6 for v6ops-data@psg.com; Fri, 14 Apr 2006 14:41:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUPUT-000Hud-EB; Fri, 14 Apr 2006 14:41:41 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3EEejgw048880 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Apr 2006 16:40:45 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7305627DD2@PACDCEXCMB01.cable.comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C7305627DD2@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Craig Huegen \(chuegen\)" , , , , Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 16:41:10 +0200 To: "Durand, Alain" X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On 14-apr-2006, at 16:02, Durand, Alain wrote: >> Maybe I'm being overly simplistic, but the policy can set a >> recovery timeframe in its allocation of PI space to end users >> and the market forces can drive the recovery based on the >> impact to the infrastructure. >> If only a few hundred prefixes are handed out, it might not >> be enough of a problem to force recovery. > One could argue that if we are only talking about a few hundred > prefixes, > Why do we care reclaiming them? If the number of prefixes becomes large enough to be problematic, reclaiming those to solve these problems isn't going to work. For one thing, it's likely that such problems won't be experienced to the same degree by different people: people with a few large routers (and deep pockets) will be in a much better position than people with a larger number of smaller routers (and less money). Also, policy development is done regionally while the results are suffered globally. But even discounting all of that, if ARIN were to decide that the prefixes must be revoked, it will take a significant amount of time before that actually happens. It gets worse when people start to sue. So in practice the only thing that can happen is that if the problem is severe (i.e., that 51% of all people in the (rich) ARIN region feel the pain) the policy is changed so that no _new_ prefixes of this type are given out, and then we have to wait for the increase in router performance over time to make the problem disappear. If it gets really bad a quick "ipv6 prefix-list no-v6-pi deny ::/0 ge 48" will clean up the routing table and a timeout or two later you're back on IPv4 when trying to reach the holders of these PI blocks. From owner-v6ops@ops.ietf.org Fri Apr 14 11:08:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPuZ-0000Vl-A0 for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 11:08:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPuY-0004bB-2P for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 11:08:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUPtt-000Jho-15 for v6ops-data@psg.com; Fri, 14 Apr 2006 15:07:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUPts-000JhT-8Y; Fri, 14 Apr 2006 15:07:56 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3EF72Js049413 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Apr 2006 17:07:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Jason Schillerschiller@uu.net" , Joe Abley , shim6-wg , ppml@arin.net, global-v6@lists.apnic.net, IETF Discussion , address-policy-wg@ripe.net, v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Fri, 14 Apr 2006 17:07:26 +0200 To: Scott Leibrand X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On 14-apr-2006, at 16:57, Scott Leibrand wrote: > 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. From owner-v6ops@ops.ietf.org Fri Apr 14 11:21:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQ7B-0006Ay-5u for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 11:21:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUQ79-000528-U7 for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 11:21:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUQ6s-000Kle-Ac for v6ops-data@psg.com; Fri, 14 Apr 2006 15:21:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.1.1 Received: from [63.105.122.7] (helo=multicasttech.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUQ6r-000KlQ-Ts for v6ops@ops.ietf.org; Fri, 14 Apr 2006 15:21:21 +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 4441266; Fri, 14 Apr 2006 11:20:19 -0400 In-Reply-To: <173E8519-DCA6-4D2A-ADFA-1542F24605CB@muada.com> References: <936A4045C332714F975800409DE0924002217015@tayexc14.americas.cpqcorp.net> <4.3.2.7.2.20060414123720.0369ed10@strange-brew> <173E8519-DCA6-4D2A-ADFA-1542F24605CB@muada.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Gunter Van de Velde (gvandeve) , jordi.palet@consulintel.es, "v6ops@ops.ietf.org" , "ppml@arin.net" , "shim6@psg.com" Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: PI addressing in IPv6 advances in ARIN Date: Fri, 14 Apr 2006 11:21:34 -0400 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On Apr 14, 2006, at 7:14 AM, Iljitsch van Beijnum wrote: > While I'm in a nasty mood anyway, let me make the most of it... > > Would you people prune the god damn quotes already!!!!!! It might be a good idea to stop cross posting to 3 lists while you are at it. Regards Marshall (who will send future replies to ppml only) From owner-v6ops@ops.ietf.org Fri Apr 14 12:07:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQpx-00024f-9Y for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 12:07:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUQpv-000742-VI for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 12:07:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUQoU-000NcQ-ST for v6ops-data@psg.com; Fri, 14 Apr 2006 16:06:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [216.93.240.35] (helo=mx01.bos.ma.towardex.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUQoT-000Nbt-OM for v6ops@ops.ietf.org; Fri, 14 Apr 2006 16:06:25 +0000 Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN, from userid 1143) id F2BA46D512; Fri, 14 Apr 2006 12:06:24 -0400 (EDT) Received: from hcmczombvvlcmo (ip-216-93-252-30.twdx.net [216.93.252.30]) by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN) with ESMTP id 7375C6D4FF; Fri, 14 Apr 2006 12:06:21 -0400 (EDT) Reply-To: From: "James Jun" To: "'Iljitsch van Beijnum'" Cc: , , Subject: RE: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Fri, 14 Apr 2006 12:09:21 -0400 Organization: TowardEX Technologies, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Thread-Index: AcZf1j27rGWGiMTqTgesYImpAcecxQABrvbA Message-Id: <20060414160621.7375C6D4FF@mx01.bos.ma.towardex.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Iljitsch van Beijnum > Sent: Friday, April 14, 2006 11:07 AM > To: Scott Leibrand > Cc: Jason Schillerschiller@uu.net; Joe Abley; shim6-wg; ppml@arin.net; > global-v6@lists.apnic.net; IETF Discussion; address-policy-wg@ripe.net; > v6ops@ops.ietf.org > Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] > > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > 60 voted in favor of moving forward with PI. 6 voted against. > > Wow, 10 to 1. Amazing. > > Even more amazing: 60 people who represent nobody but their own > paycheck get to blow up the internet. > > Where is ICANN when you need it? This little experiment in playground > democracy has to end before people get hurt. How about you start operating a real network and feel the pain of your enterprise customers who require usability? IPv6 is a failure because of ongoing FUD regarding so called 'routing table explosion' that even IPv4 is still susceptible to, and all this "ipv6 will even wash your dishes!" claims having no ROI. I was hoping for people to stop preaching to choir on FUD and 'utopian routing policies' (see geographical, or should I say geopolitical routing), and this move toward PI addressing in ARIN land is definitely a great step and achievement toward success of IPv6 as an internet protocol. -- Regards, James Jun Managing Director TowardEX Technologies, Inc. Phone: +1 617-459-4051 x179 Mobile: +1 978-394-2867 Fax: +1 432-225-3784 Email: james@towardex.com From owner-v6ops@ops.ietf.org Fri Apr 14 13:23:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS1B-0006Xg-Nk for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 13:23:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUS1A-0000bR-Fy for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 13:23:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FURz6-0003et-VY for v6ops-data@psg.com; Fri, 14 Apr 2006 17:21:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FURz6-0003ea-6n for v6ops@ops.ietf.org; Fri, 14 Apr 2006 17:21:28 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3EHKsQT051507 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Apr 2006 19:20:55 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20060414160621.7375C6D4FF@mx01.bos.ma.towardex.com> References: <20060414160621.7375C6D4FF@mx01.bos.ma.towardex.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B8FEB27-A215-498B-AD7E-E8805F639808@muada.com> Cc: , , Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Fri, 14 Apr 2006 19:21:18 +0200 To: X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On 14-apr-2006, at 18:09, James Jun wrote: > How about you start operating a real network and feel the pain of your > enterprise customers who require usability? How about you do a "show ip bgp" and experience some pain of your own? > IPv6 is a failure IPv6 was created so we could continue to have an internet when we're out of IPv4 addresses. We're not out of IPv4 addresses yet. How can IPv6 be a failure at this point? > because of > ongoing FUD regarding so called 'routing table explosion' that even > IPv4 is > still susceptible to, We've managed to make a fairly big mess of IPv4 in 25 years. Yes, it still works but it's not pretty. IPv6 is supposed to last a lot longer than 25 years, so explosions of any kind are to be discouraged. From owner-v6ops@ops.ietf.org Fri Apr 14 13:36:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSDV-0007Rb-5g for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 13:36:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSDU-00016a-T3 for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 13:36:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUSD0-0004UB-CM for v6ops-data@psg.com; Fri, 14 Apr 2006 17:35:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [216.93.240.35] (helo=mx01.bos.ma.towardex.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUSCz-0004Tc-CF for v6ops@ops.ietf.org; Fri, 14 Apr 2006 17:35:49 +0000 Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN, from userid 1143) id DA5C06D4F6; Fri, 14 Apr 2006 13:35:48 -0400 (EDT) Received: from hcmczombvvlcmo (ip-216-93-252-30.twdx.net [216.93.252.30]) by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN) with ESMTP id 941E36D4F1; Fri, 14 Apr 2006 13:35:43 -0400 (EDT) Reply-To: From: "James Jun" To: "'Iljitsch van Beijnum'" Cc: , , Subject: RE: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Fri, 14 Apr 2006 13:38:43 -0400 Organization: TowardEX Technologies, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1B8FEB27-A215-498B-AD7E-E8805F639808@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Thread-Index: AcZf597/0PsDsV9SSqq5Givi/8F0ZgAAISdA Message-Id: <20060414173543.941E36D4F1@mx01.bos.ma.towardex.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Friday, April 14, 2006 1:21 PM > To: james@towardex.com > Cc: ppml@arin.net; global-v6@lists.apnic.net; v6ops@ops.ietf.org > Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] > > On 14-apr-2006, at 18:09, James Jun wrote: > > > How about you start operating a real network and feel the pain of your > > enterprise customers who require usability? > > How about you do a "show ip bgp" and experience some pain of your own? > > > IPv6 is a failure > > IPv6 was created so we could continue to have an internet when we're > out of IPv4 addresses. We're not out of IPv4 addresses yet. How can > IPv6 be a failure at this point? > > > because of > > ongoing FUD regarding so called 'routing table explosion' that even > > IPv4 is > > still susceptible to, > > We've managed to make a fairly big mess of IPv4 in 25 years. Yes, it > still works but it's not pretty. IPv6 is supposed to last a lot > longer than 25 years, so explosions of any kind are to be discouraged. Yes, discouraging customers from multihoming and delivering reliability--that appears to be the common message from a good portion of IPv6-advocacy groups. IPv6 is still IP, and not anything different than IPv4 other than a color: more address space. If it is all of a sudden going to require shim6 or similar, and discourage multihoming like the way it happens today in IPv4, it certainly does not help. Yes I look at `sh ip bgp` everyday (or show route protocols bgp for that matter). The deaggregation is there, but nowhere is it at a level that I'm going to lose sleep over it. One would think if you want IPv6 to better develop, let people *use* the technology as they did freely in IPv4, and work on a more scalable forwarding lookup & routing technology instead of restricting people's ability to become multihomed. To say that we service providers are simply more worried about our paycheck than the internet... well, I beg to differ. James From owner-v6ops@ops.ietf.org Fri Apr 14 14:53:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTPt-00085R-Co for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 14:53:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUTPr-0003yP-Qi for v6ops-archive@lists.ietf.org; Fri, 14 Apr 2006 14:53:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUTOJ-0008zN-NT for v6ops-data@psg.com; Fri, 14 Apr 2006 18:51:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUTOI-0008zA-82 for v6ops@ops.ietf.org; Fri, 14 Apr 2006 18:51:34 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id AA359557E; Fri, 14 Apr 2006 20:51:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id A616B554A; Fri, 14 Apr 2006 20:51:32 +0200 (CEST) Date: Fri, 14 Apr 2006 20:51:32 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: James Jun Cc: 'Iljitsch van Beijnum' , ppml@arin.net, global-v6@lists.apnic.net, v6ops@ops.ietf.org Subject: RE: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] In-Reply-To: <20060414173543.941E36D4F1@mx01.bos.ma.towardex.com> Message-ID: <20060414204546.K92605@mignon.ki.iif.hu> References: <20060414173543.941E36D4F1@mx01.bos.ma.towardex.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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On Fri, 14 Apr 2006, James Jun wrote: > >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Friday, April 14, 2006 1:21 PM >> To: james@towardex.com >> Cc: ppml@arin.net; global-v6@lists.apnic.net; v6ops@ops.ietf.org >> Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] >> >> On 14-apr-2006, at 18:09, James Jun wrote: >> >>> How about you start operating a real network and feel the pain of your >>> enterprise customers who require usability? >> >> How about you do a "show ip bgp" and experience some pain of your own? >> >>> IPv6 is a failure >> >> IPv6 was created so we could continue to have an internet when we're >> out of IPv4 addresses. We're not out of IPv4 addresses yet. How can >> IPv6 be a failure at this point? >> >>> because of >>> ongoing FUD regarding so called 'routing table explosion' that even >>> IPv4 is >>> still susceptible to, >> >> We've managed to make a fairly big mess of IPv4 in 25 years. Yes, it >> still works but it's not pretty. IPv6 is supposed to last a lot >> longer than 25 years, so explosions of any kind are to be discouraged. > > Yes, discouraging customers from multihoming and delivering > reliability--that appears to be the common message from a good portion of > IPv6-advocacy groups. IPv6 is still IP, and not anything different than > IPv4 other than a color: more address space. If it is all of a sudden going > to require shim6 or similar, and discourage multihoming like the way it > happens today in IPv4, it certainly does not help. There is some solution to provide some form multihoming for IPv6: 3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. Snyder. October 2001. (Format: TXT=24453 bytes) (Status: INFORMATIONAL This solution is not very pretty, but you can keep the aggregation at Tier-1 and probably at Tier-2 porviders. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From owner-v6ops@ops.ietf.org Sun Apr 16 03:21:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV1a3-0007M9-SX for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 03:21:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV1a1-0000Pu-Gt for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 03:21:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FV1Wm-000HOC-5M for v6ops-data@psg.com; Sun, 16 Apr 2006 07:18:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FV1Wk-000HNp-Rd; Sun, 16 Apr 2006 07:18:35 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3G7HP1i082037 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 16 Apr 2006 09:17:26 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> Cc: shim6-wg , ppml@arin.net, global-v6@lists.apnic.net, IETF Discussion , address-policy-wg@ripe.net, v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Sun, 16 Apr 2006 09:17:52 +0200 To: "Patrick W. Gilmore" X-Mailer: Apple Mail (2.749.3) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: > Wow, Iljitsch, I have never lost so much respect so quickly for > someone who was not flaming a specific person or using profanity. > Congratulations. Well, that's too bad. But several years of trying to get a scalable multihoming off the ground (flying to different meetings on my own dime) where first my ideas about PI aggregation are rejected within the IETF mostly without due consideration because it involves the taboo word "geography" only to see the next best thing being rejected by people who, as far as I can tell, lack a view of the big picture, is enough to make me lose my cool. Just a little. > Back on topic, it is not just those 60 people - the "playground" > appears to overwhelmingly agree with their position. I know I do. Don't you think it's strange that the views within ARIN are so radically different than those within the IETF? Sure, inside the IETF there are also people who think PI in IPv6 won't be a problem, but it's not the majority (as far as I can tell) and certainly not anything close to 90%. Now the IETF process isn't perfect, as many things depend on whether people feel like actually doing something. But many of the best and the brightest in the IETF have been around for some time in multi6 and really looked at the problem. Many, if not most, of them concluded that we need something better than IPv4 practices to make IPv6 last as long as we need it to last. Do you think all of them were wrong? > I am sorry your technical arguments have not persuaded us in the > past. But I would urge you to stick to those, Stay tuned. From owner-v6ops@ops.ietf.org Sun Apr 16 14:12:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVBji-0005dF-Ib for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 14:12:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVBji-0001XU-04 for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 14:12:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVBh5-00045m-Jq for v6ops-data@psg.com; Sun, 16 Apr 2006 18:09:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 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 1FVBh3-00045W-UB for v6ops@ops.ietf.org; Sun, 16 Apr 2006 18:09:54 +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 9A11081FD; Sun, 16 Apr 2006 20:09:48 +0200 (CEST) Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] From: Jeroen Massar To: "Patrick W. Gilmore" Cc: shim6-wg , v6ops@ops.ietf.org In-Reply-To: References: <7B6A4704-0EE4-4207-BB3E-F91CC78F3B15@muada.com> <6170143F-8B08-41D9-A579-0B5E8C757BE3@muada.com> <2D01165E-056A-4981-9634-8185BFCC4A64@ianai.net> <1145206143.23746.32.camel@firenze.zurich.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eBsQrCwfCW+qQ22Ppg9V" Organization: Unfix Date: Sun, 16 Apr 2006 20:09:45 +0200 Message-Id: <1145210985.23746.53.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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 --=-eBsQrCwfCW+qQ22Ppg9V Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2006-04-16 at 13:20 -0400, Patrick W. Gilmore wrote: > On Apr 16, 2006, at 12:49 PM, Jeroen Massar wrote: >=20 > > [very nice cross posting going on here ;) ] >=20 > Nah, I just hit "reply-all", but only one actually made it through. =20 > I'm not subscribed to the rest of the lists. >=20 > I've lowered the CC list to something more reasonable now. >=20 > Oh, and commenting derisively on something you do yourself seems a =20 > bit silly. Well, just like you, I also nicely hit 'reply-all', except that I am on the other lists too, thus now your original message did mostly come through anyway. > > On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote: > > [... > > large snip about trying to bash shim6 which is not finalized > > yet, thus how can you bash it ? > > Note: extra sarcasm included in this post. Eat the eggs with salt. > > ...] >=20 > I don't remember bashing shim6. I remember saying people do not =20 > agree it is the way to go. > > As for "finalized", if I don't agree with the basic idea of a =20 > technology (e.g. inserting a "shim" into the IP packet), how can you =20 > "finalize" it to something with which I will agree? How can you not agree with something which is not there yet? You don't like super-duper space engines yet either? As mentioned, from a business point of view I agree totally, I would not want it either. From a tech point of view, it will be one of the better things since sliced bread. The future will tell though. > >> Oh, and one thing I should have said last time: Technical arguments > >> are important, but they are only part of the decision process. > > > > In other words: "You are right with your arguments, but I just threw > > your args away as they are futile based on the comparison of money > > earned this way or the other."... >=20 > I'm going to assume you are being sarcastic here, since your =20 > "translation" is factually incorrect. I was clear the technical =20 > arguments are not sufficient, or even close. I was adding that the =20 > business elements are an additional hurdle. Yes, there is some work to be done on shim6, but as long as it isn't complete, don't say that it is dead already. > BTW: Sarcasm is usually intended to either be funny or illustrate a =20 > point. Your sarcasms is definitely not funny, and the only point you =20 > are illustrating here is a complete misunderstanding of the =20 > discussion at hand. The discussion: "yeah shim6 is dead, long live PI". Very hard indeed. > >> People (like me) have explained that the Internet is a business, and > >> in addition to being .. technically unsavory to many people, shim6 is > >> simply not viable in a business setting. > > > > And as you will only care for your business for the coming 10 or maybe > > 20 years you really can't care what happens to the internet afterward. [..] > This is close to a useful argument. >=20 > First... [..] I would not agree less. > >> Neither backbone operators > >> (vendors) nor end users (customers) are warming to the idea. Just > >> the opposite. (At least in general, the one-in-a-million end user > >> with DSL and cable who likes the idea 'cause he can't figure out how > >> to spell "B-G-P" or doesn't want to pay for it is irrelevant.) > > > > Irrelevant for you as they don't give you money. Indeed, you only look > > at your own business interrest (and who can blame you for that ;) > > (Once though the internet was there for the masses and not only for =20 > > the > > ones with cash) >=20 > No, irrelevant PERIOD. You cannot architect the Internet for the one-=20 > in-a-million end user, _especially_ one who does not pay for the =20 > infrastructure. Isn't that like *exactly* what I wrote there: "They don't _pay you_ money and thus you don't care about them." Which is perfectly valid from a business point of view. But it is totally not perfect when looking at what the IETF wanted to achieve with PA-only space. Some people tend to the little guys, other only cash in on the big ones. That is business. But that has nothing to do with engineering a sound protocol. [..] > And I still dislike shim6 both technically and commercially, =20 > personally and professionally. So does every technical person at my =20 > company who has any interest in this topic. As I wrote in the previous mail, just wait till shim6 is finalized then start flaming it. Nevertheless, it should be backward compatible and it will=20 > It is not just backbones. Shim6 is not commercially viable. Period. As I also mentioned, there is enough interrest for it, if you don't want it then simply ignore it. > > That is in the long run, most likely in the coming 10-20 years the =20 > > IPv6 > > routing tables will not have 'exploded' yet, but the folks selling > > equipment and having stocks of those venders after that most likely =20 > > will > > have a nice retirement fund. Thanks to you! >=20 > First, thank you for thinking I am so important. Well the "you" is the group of people who arranged the PI. But if you want to take the credit, they are all yours ;) > Second: Whatever. If you honestly believe cisco & juniper will fail =20 > or succeed based on shim6, you really need to reevaluate your =20 > hypothesis. Those companies can't care less, why should they, they can keep on selling bigger fatter newer shinier boxes anyway. > > Nevertheless, the PI thing is really *not* a bad thing, as it can be > > used as an identifier for shim6, which is actually perfect. It just > > saves on having to do a complete policy process for getting address > > space for this type of usage. But thanks to this, this won't be needed > > and thus in the end anybody who can get PI can use a shim6-alike > > solution and won't have any problem with the upstream that actually > > wanted to lock them in by letting them pay loads for an entry in =20 > > the BGP > > tables. > > > > Thus people voting for PI, thanks for helping shim6 or another =20 > > solution > > in that space, progress a lot :) >=20 > Then why are we arguing about this? Did I argue? I only commented about some of your statements to which I don't agree. Greets, Jeroen --=-eBsQrCwfCW+qQ22Ppg9V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEABECADUFAkRCiGkuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I7ihAJ4mrTFly751aVgvL4Ajk7bTnjs1 BgCfVIvlqdcSlEAMK+t+zhVPXr11aWo= =Rxj/ -----END PGP SIGNATURE----- --=-eBsQrCwfCW+qQ22Ppg9V-- From owner-v6ops@ops.ietf.org Sun Apr 16 17:49:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVF7N-0004BN-8L for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:49:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVF7I-0000ZM-OK for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:49:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVF56-000Ghm-Im for v6ops-data@psg.com; Sun, 16 Apr 2006 21:46:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVF52-000GhI-CR for v6ops@ops.ietf.org; Sun, 16 Apr 2006 21:46:52 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id C6A2534012; Sun, 16 Apr 2006 17:46:54 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 17:46:50 -0400 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: PI addressing in IPv6 advances in ARIN Date: Sun, 16 Apr 2006 17:46:48 -0400 Message-ID: <936A4045C332714F975800409DE092400225024B@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdwAfINS4A== From: "Bound, Jim" To: , , , X-OriginalArrivalTime: 16 Apr 2006 21:46:50.0681 (UTC) FILETIME=[44B16A90:01C6619F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Jordi, thanks. I completely disagree with you. So we can debate as = apppropriate, but at the end of the day any RIR only accepts input from = "individuals" not organizations.=20 Thanks for your response. /jim=20 > -----Original Message----- > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On=20 > Behalf Of JORDI PALET MARTINEZ > Sent: Friday, April 14, 2006 6:20 AM > To: v6ops@ops.ietf.org; ppml@arin.net; shim6@psg.com > Subject: Re: PI addressing in IPv6 advances in ARIN >=20 > Hi Jim, >=20 > Not sure if I got your question correctly, but let me try to=20 > explain my view. >=20 > I understand the position of the people that say they need PI=20 > today, especially because not having it may be hurting the=20 > advancement of the IPv6 deployment. >=20 > However, I want to balance this with the medium-long term=20 > implications created in the routing table and with the time=20 > needed to build and deploy a better technical solution (or=20 > several) which is accepted by the community. >=20 > So my proposal basically is about having PI now everywhere=20 > (once ARIN adopt it, is unfair not having it in other=20 > regions), but those PI allocations for multihoming should be=20 > temporary and those address blocks returned to the RIRs some=20 > time (lets say 3 years) after the new technical solution is=20 > declared as a valid one. >=20 > At this way, on the long-run, we will not have routing table=20 > implications, but we allow now the people that want to move=20 > ahead only if they have a multihoming solution doing so. >=20 > This 3-years time for getting a multihoming network back to=20 > the new technical solution (once adopted) is enough time, I=20 > think (it could be changed to 5 years if needed, or=20 > whatever), so nobody today see the temporarily of the=20 > proposal as a showstopper to go for it now. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > > De: "Bound, Jim" > > Responder a: > > Fecha: Fri, 14 Apr 2006 03:11:58 -0400 > > Para: , > > Conversaci=F3n: PI addressing in IPv6 advances in ARIN > > Asunto: RE: PI addressing in IPv6 advances in ARIN > >=20 > > Jordi, why this will work as is for now? > > /jim > >=20 > >> -----Original Message----- > >> From: owner-v6ops@ops.ietf.org > >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of JORDI PALET MARTINEZ > >> Sent: Thursday, April 13, 2006 5:28 PM > >> To: v6ops@ops.ietf.org > >> Subject: Re: PI addressing in IPv6 advances in ARIN > >>=20 > >> Hi Thomas, all, > >>=20 > >> During my fly-back from Montreal, I've worked in a=20 > proposal and I'm=20 > >> talking to folks in each RIR/region, with the idea to submit it to=20 > >> all them as a kind of (if possible), global policy. > >>=20 > >> The idea is based on the comments that I did at the mic during the=20 > >> ARIN meeting. > >>=20 > >> I will try to get this submitted next Monday/Tuesday and get ready=20 > >> for a formal presentation during the next RIPE meeting at Istanbul=20 > >> (following week). > >>=20 > >> Regards, > >> Jordi > >>=20 > >>=20 > >>=20 > >>=20 > >>> De: Thomas Narten Responder a:=20 > >>> > >>> Fecha: Thu, 13 Apr 2006 17:14:54 -0400 > >>> Para: "Gunter Van de Velde (gvandeve)" > >>> CC: "v6ops@ops.ietf.org" > >>> Asunto: Re: PI addressing in IPv6 advances in ARIN > >>>=20 > >>>> What would be the prefix allocation per organization? > >>>=20 > >>> /48, though can be larger in some cases. Watch for the revised=20 > >>> proposal that gets last called for details. > >>>=20 > >>>> (Me being in Europe and not attending ARIN sessions) > >>>=20 > >>> Note: none of the other RIRs have such a policy in place > >> today, though > >>> I wouldn't be surprised if they now followup with proposals > >> of their > >>> own (though someone has to do it). > >>>=20 > >>>> Has there been study on the # of organizations going for > >> this and if > >>>> the impact will be more significant then more's law on=20 > technology=20 > >>>> enhancement? > >>>=20 > >>> Mostly just hand waving, with a lot of "IPv4 hasn't melted today," > >>> "looking at the impact of the current IPv4 policies, the > >> number of PI > >>> assignments is only on the 100s per year", and "we can update the=20 > >>> policy if things get problematical". > >>>=20 > >>> Thomas > >>>=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=20 > >> individual(s) named above. If you are not the intended=20 > 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 >=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 Sun Apr 16 17:51:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVF9K-0004Gt-A5 for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:51:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVF9H-0000cK-0j for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:51:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVF9B-000H2x-8D for v6ops-data@psg.com; Sun, 16 Apr 2006 21:51:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVF9A-000H2Z-M5 for v6ops@ops.ietf.org; Sun, 16 Apr 2006 21:51:08 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 514EE34010; Sun, 16 Apr 2006 17:51:05 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 17:51:04 -0400 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: PI addressing in IPv6 advances in ARIN Date: Sun, 16 Apr 2006 17:51:03 -0400 Message-ID: <936A4045C332714F975800409DE0924002250251@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdwAA0OvXwB5ZSfw From: "Bound, Jim" To: "Durand, Alain" , , , X-OriginalArrivalTime: 16 Apr 2006 21:51:04.0519 (UTC) FILETIME=[DBFE0570:01C6619F] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca I am not sure this is valid discussion for v6ops with respect to a deliverable from v6ops because IETF has no more input to the RIRs than GM, BT, Governments etc. =20 V6ops Chairs: Is this valid discussion to any of our working group deliverables other than good fyi to the team? Thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Durand, Alain > Sent: Friday, April 14, 2006 7:54 AM > To: v6ops@ops.ietf.org; ppml@arin.net; shim6@psg.com > Subject: Re: PI addressing in IPv6 advances in ARIN >=20 > Wrt Jordi's proposal: >=20 > I have sympathy to the idea of balancing PI need with routing=20 > table growth, however: >=20 > A) if PI addresses are to be returned at some point in time,=20 > they loose a dreat deal of their value. Folks like PI because=20 > it shields them from renumbering. >=20 > B) any address reclaim process might be lenghty and costly >=20 > C) given how long the shim6/multi homing has taken so far, it=20 > seems hazardous to make any bet that in 3 years it will be=20 > finish, implemented, adopted, deployed... >=20 > D) I am sensitive to the argument that v4 has not "melted"=20 > with PI, so why should v6 melt more? I believe the benefits=20 > of handing out PI *now* outweight the cost of a *small* swamp.=20 >=20 > E) given the state of v6 deployment now, I do not think there=20 > is much risk with this policy at this moment. And as Thomas=20 > relayed, this policy could be changed anyway if things get=20 > out of control. >=20 > F) if this means giving advantage to the early adopters by=20 > offering them PI, I look at this as a positive thing. >=20 > G) a key thing is to limit the size of the swamp that would=20 > be created, or more specifically limit its growth. So it=20 > might be a good idea to have a sunset clause in the policy,=20 > like it will have to be revisited in 2 years or when a=20 > certain allocation (or allocation rate) threshold will be reached. >=20 > - Alain. >=20 From owner-v6ops@ops.ietf.org Sun Apr 16 17:56:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVFEc-00055c-GN for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:56:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVFEZ-0000hx-3N for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:56:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFEL-000HU9-Ux for v6ops-data@psg.com; Sun, 16 Apr 2006 21:56:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFEL-000HTx-6j for v6ops@ops.ietf.org; Sun, 16 Apr 2006 21:56:29 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 1D88B34010; Sun, 16 Apr 2006 17:56:29 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 17:56:27 -0400 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: PI addressing in IPv6 advances in ARIN Date: Sun, 16 Apr 2006 17:55:50 -0400 Message-ID: <936A4045C332714F975800409DE0924002250253@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZfQS9vbdugdss0EdqXyQANky3PwAAUYHSAAAaTrdwAA0OvXwACjpKgAHbzBcA= From: "Bound, Jim" To: "Craig Huegen (chuegen)" , "Durand, Alain" , , X-OriginalArrivalTime: 16 Apr 2006 21:56:27.0807 (UTC) FILETIME=[9CAFDAF0:01C661A0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Regarding Address Reclaim. My private individual input to RIR is that the private sector should have binding legal agreement with any LIR that they cannot force a renumber without proper X time to renumber which would be different depending on the business impact real time of a renumbering operation. Not clear how Governments will operate as they are truly ISPs and the issue could be moot to them. /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Craig Huegen (chuegen) > Sent: Friday, April 14, 2006 9:21 AM > To: Durand, Alain; v6ops@ops.ietf.org; ppml@arin.net; shim6@psg.com > Subject: RE: PI addressing in IPv6 advances in ARIN >=20 > On Friday, April 14, 2006 6:54 AM, Alain Durand wrote: >=20 > > A) if PI addresses are to be returned at some point in time, they=20 > > loose a dreat deal of their value. Folks like PI because it shields=20 > > them from renumbering. >=20 > I'd like to clarify this a bit. As a large enterprise=20 > network operator, I'm less concerned about the need to=20 > renumber the network once than I am the need to renumber=20 > every time that I want to change a service provider. Don't=20 > take that the wrong way: renumbering is still a significant=20 > pain, but the real reason that enterprises haven't adopted PA=20 > space is that it represents a de-facto "lock-in" to the=20 > service providers they choose initially and they're faced=20 > with a network-wide renumber any time they drop or add a=20 > service provider. >=20 > Most enterprise network operators that I have spoken to would=20 > be willing to renumber once in the future, in exchange for a=20 > reasonable way to get portable IPv6 space today. >=20 > > B) any address reclaim process might be lenghty and costly >=20 > Maybe I'm being overly simplistic, but the policy can set a=20 > recovery timeframe in its allocation of PI space to end users=20 > and the market forces can drive the recovery based on the=20 > impact to the infrastructure. > If only a few hundred prefixes are handed out, it might not=20 > be enough of a problem to force recovery. >=20 > This may be a moot point for the ARIN discussion, though, as=20 > ARIN typically doesn't play all that much of an enforcer=20 > role. It can declare prefixes and prefix ranges as dead, but=20 > reachability is determined by the service providers. >=20 > > C) given how long the shim6/multi homing has taken so far, it seems=20 > > hazardous to make any bet that in 3 years it will be finish,=20 > > implemented, adopted, deployed... >=20 > I think that Jordi was referring to 3 years after the=20 > solution is declared "available" -- admittedly that's a tough=20 > milestone to set. >=20 > Finally, I agree with all four other points you make;=20 > adoption of IPv6 has been held up because the capabilities=20 > offered lack a critical requirement for enterprise networks=20 > (connectivity without de-facto service provider lock-in). =20 > The agreement to move forward with a policy is a very=20 > positive thing that enables IPv6 to work for large=20 > enterprises while the right solution is determined and rolled out. >=20 > /cah >=20 > --- > Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s > IT - Intelligent Network Solutions || || > Cisco Systems, Inc., 400 East Tasman Drive || || > San Jose, CA 95134, (408) 526-8104 |||| |||| > email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. >=20 >=20 From owner-v6ops@ops.ietf.org Sun Apr 16 17:58:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVFGF-0007CG-AW for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:58:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVFGB-0000nH-Uq for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:58:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFG0-000Hgg-Vo for v6ops-data@psg.com; Sun, 16 Apr 2006 21:58:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFG0-000HgM-7b for v6ops@ops.ietf.org; Sun, 16 Apr 2006 21:58:12 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 4030B34002; Sun, 16 Apr 2006 17:58:12 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 17:58:10 -0400 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: PI addressing in IPv6 advances in ARIN Date: Sun, 16 Apr 2006 17:58:09 -0400 Message-ID: <936A4045C332714F975800409DE0924002250255@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PI addressing in IPv6 advances in ARIN Thread-Index: AcZf0ZquYNXD5DhNRfWebdvTXk+GNQBzwU9A From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Durand, Alain" Cc: "Craig Huegen (chuegen)" , , X-OriginalArrivalTime: 16 Apr 2006 21:58:10.0836 (UTC) FILETIME=[DA18D540:01C661A0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 ALso if those prefixes are for a nuclear power plant I want them to have proper time to renumber for sure. It is relevant to what business impact it has specifically in mission critical environments. I am removing all but IETF lists in my responses. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Friday, April 14, 2006 10:41 AM > To: Durand, Alain > Cc: Craig Huegen (chuegen); v6ops@ops.ietf.org;=20 > ppml@arin.net; shim6@psg.com; global-v6@lists.apnic.net > Subject: Re: PI addressing in IPv6 advances in ARIN >=20 > On 14-apr-2006, at 16:02, Durand, Alain wrote: >=20 > >> Maybe I'm being overly simplistic, but the policy can set=20 > a recovery=20 > >> timeframe in its allocation of PI space to end users and=20 > the market=20 > >> forces can drive the recovery based on the impact to the=20 > >> infrastructure. > >> If only a few hundred prefixes are handed out, it might=20 > not be enough=20 > >> of a problem to force recovery. >=20 > > One could argue that if we are only talking about a few hundred=20 > > prefixes, Why do we care reclaiming them? >=20 > If the number of prefixes becomes large enough to be=20 > problematic, reclaiming those to solve these problems isn't=20 > going to work. For one thing, it's likely that such problems=20 > won't be experienced to the same degree by different people:=20 > people with a few large routers (and deep pockets) will be in=20 > a much better position than people with a larger number of=20 > smaller routers (and less money). Also, policy development is=20 > done regionally while the results are suffered globally. But=20 > even discounting all of that, if ARIN were to decide that the=20 > prefixes must be revoked, it will take a significant amount=20 > of time before that actually happens. It gets worse when=20 > people start to sue. >=20 > So in practice the only thing that can happen is that if the=20 > problem is severe (i.e., that 51% of all people in the (rich)=20 > ARIN region feel the pain) the policy is changed so that no=20 > _new_ prefixes of this type are given out, and then we have=20 > to wait for the increase in router performance over time to=20 > make the problem disappear. >=20 > If it gets really bad a quick "ipv6 prefix-list no-v6-pi deny=20 > ::/0 ge 48" will clean up the routing table and a timeout or=20 > two later you're back on IPv4 when trying to reach the=20 > holders of these PI blocks. >=20 >=20 From owner-v6ops@ops.ietf.org Sun Apr 16 17:59:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVFHX-0007zA-VB for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:59:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVFHT-0000pJ-MP for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 17:59:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFHL-000Hs1-Kv for v6ops-data@psg.com; Sun, 16 Apr 2006 21:59:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFHL-000Hrm-2e for v6ops@ops.ietf.org; Sun, 16 Apr 2006 21:59:35 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id A281534002; Sun, 16 Apr 2006 17:59:35 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 17:59:33 -0400 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: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Sun, 16 Apr 2006 17:59:32 -0400 Message-ID: <936A4045C332714F975800409DE0924002250256@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Thread-Index: AcZf1Vzs5znvHalTQLG5V98QTn33owBy4gjA From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Scott Leibrand" Cc: "Jason Schillerschiller@uu.net" , "Joe Abley" , "shim6-wg" , X-OriginalArrivalTime: 16 Apr 2006 21:59:33.0740 (UTC) FILETIME=[0B82FAC0:01C661A1] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Well that is how RIRs are structured and supported by ICANN. =20 /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Friday, April 14, 2006 11:07 AM > To: Scott Leibrand > Cc: Jason Schillerschiller@uu.net; Joe Abley; shim6-wg;=20 > ppml@arin.net; global-v6@lists.apnic.net; IETF Discussion;=20 > address-policy-wg@ripe.net; v6ops@ops.ietf.org > Subject: Re: [narten@us.ibm.com: PI addressing in IPv6=20 > advances in ARIN] >=20 > On 14-apr-2006, at 16:57, Scott Leibrand wrote: >=20 > > 60 voted in favor of moving forward with PI. 6 voted against. >=20 > Wow, 10 to 1. Amazing. >=20 > Even more amazing: 60 people who represent nobody but their=20 > own paycheck get to blow up the internet. >=20 > Where is ICANN when you need it? This little experiment in=20 > playground democracy has to end before people get hurt. >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun Apr 16 18:01:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVFJf-00016H-Dq for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:01:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVFJc-0000uU-1f for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:01:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFJK-000IBZ-BY for v6ops-data@psg.com; Sun, 16 Apr 2006 22:01:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFJJ-000IBE-Kj for v6ops@ops.ietf.org; Sun, 16 Apr 2006 22:01:37 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 7CBD33403C; Sun, 16 Apr 2006 18:01:38 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 18:01:36 -0400 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: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Sun, 16 Apr 2006 18:01:34 -0400 Message-ID: <936A4045C332714F975800409DE0924002250257@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Thread-Index: AcZf9LcMlN+GzRLhQ/y0RZApvUkVTABrJcmw From: "Bound, Jim" To: "Mohacsi Janos" , "James Jun" Cc: "Iljitsch van Beijnum" , , , X-OriginalArrivalTime: 16 Apr 2006 22:01:36.0018 (UTC) FILETIME=[54651F20:01C661A1] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Agree. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mohacsi Janos > Sent: Friday, April 14, 2006 2:52 PM > To: James Jun > Cc: 'Iljitsch van Beijnum'; ppml@arin.net;=20 > global-v6@lists.apnic.net; v6ops@ops.ietf.org > Subject: RE: [narten@us.ibm.com: PI addressing in IPv6=20 > advances in ARIN] >=20 >=20 > On Fri, 14 Apr 2006, James Jun wrote: >=20 > > > >> -----Original Message----- > >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > >> Sent: Friday, April 14, 2006 1:21 PM > >> To: james@towardex.com > >> Cc: ppml@arin.net; global-v6@lists.apnic.net; v6ops@ops.ietf.org > >> Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in=20 > >> ARIN] > >> > >> On 14-apr-2006, at 18:09, James Jun wrote: > >> > >>> How about you start operating a real network and feel the pain of=20 > >>> your enterprise customers who require usability? > >> > >> How about you do a "show ip bgp" and experience some pain=20 > of your own? > >> > >>> IPv6 is a failure > >> > >> IPv6 was created so we could continue to have an internet=20 > when we're=20 > >> out of IPv4 addresses. We're not out of IPv4 addresses yet. How can > >> IPv6 be a failure at this point? > >> > >>> because of > >>> ongoing FUD regarding so called 'routing table explosion'=20 > that even > >>> IPv4 is > >>> still susceptible to, > >> > >> We've managed to make a fairly big mess of IPv4 in 25=20 > years. Yes, it=20 > >> still works but it's not pretty. IPv6 is supposed to last a lot=20 > >> longer than 25 years, so explosions of any kind are to be=20 > discouraged. > > > > Yes, discouraging customers from multihoming and delivering=20 > > reliability--that appears to be the common message from a=20 > good portion=20 > > of IPv6-advocacy groups. IPv6 is still IP, and not=20 > anything different=20 > > than > > IPv4 other than a color: more address space. If it is all=20 > of a sudden=20 > > going to require shim6 or similar, and discourage=20 > multihoming like the=20 > > way it happens today in IPv4, it certainly does not help. >=20 > There is some solution to provide some form multihoming for IPv6: > 3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. > Snyder. October 2001. (Format: TXT=3D24453 bytes) (Status: > INFORMATIONAL >=20 > This solution is not very pretty, but you can keep the aggregation at > Tier-1 and probably at Tier-2 porviders. >=20 > Regards, >=20 > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun Apr 16 18:02:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVFJu-0001Tj-EB for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:02:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVFJr-0000uf-57 for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:02:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFJn-000IGC-M3 for v6ops-data@psg.com; Sun, 16 Apr 2006 22:02:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFJn-000IFw-1E for v6ops@ops.ietf.org; Sun, 16 Apr 2006 22:02:07 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 6AC3234031; Sun, 16 Apr 2006 18:02:06 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 18:02:05 -0400 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: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Sun, 16 Apr 2006 18:02:04 -0400 Message-ID: <936A4045C332714F975800409DE0924002250258@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Thread-Index: AcZhDAAiCHZ2G4QPQGujGIYX1Z0tggAlWHVg From: "Bound, Jim" To: "Patrick W. Gilmore" , "Iljitsch van Beijnum" Cc: "shim6-wg" , , , "IETF Discussion" , , X-OriginalArrivalTime: 16 Apr 2006 22:02:05.0658 (UTC) FILETIME=[660FD3A0:01C661A1] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 I agree. /jim=20 > -----Original Message----- > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On=20 > Behalf Of Patrick W. Gilmore > Sent: Sunday, April 16, 2006 12:10 AM > To: Iljitsch van Beijnum > Cc: Patrick W. Gilmore; shim6-wg; ppml@arin.net;=20 > global-v6@lists.apnic.net; IETF Discussion;=20 > address-policy-wg@ripe.net; v6ops@ops.ietf.org > Subject: Re: [narten@us.ibm.com: PI addressing in IPv6=20 > advances in ARIN] >=20 > On Apr 14, 2006, at 11:07 AM, Iljitsch van Beijnum wrote: >=20 > > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > >> 60 voted in favor of moving forward with PI. 6 voted against. > > > > Wow, 10 to 1. Amazing. > > > > Even more amazing: 60 people who represent nobody but their own=20 > > paycheck get to blow up the internet. > > > > Where is ICANN when you need it? This little experiment in=20 > playground=20 > > democracy has to end before people get hurt. >=20 > Wow, Iljitsch, I have never lost so much respect so quickly for =20 > someone who was not flaming a specific person or using profanity. =20 > Congratulations. >=20 >=20 > Back on topic, it is not just those 60 people - the "playground" =20 > appears to overwhelmingly agree with their position. I know I do. >=20 > I am sorry your technical arguments have not persuaded us in=20 > the past. But I would urge you to stick to those, or at=20 > least consider why we remain unconvinced, rather than devolve=20 > into .. whatever that post was supposed to be. >=20 > -- > TTFN, > patrick >=20 >=20 From owner-v6ops@ops.ietf.org Sun Apr 16 18:03:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVFLG-00022D-BS for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:03:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVFLC-00011L-Vs for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:03:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFL4-000ITI-O7 for v6ops-data@psg.com; Sun, 16 Apr 2006 22:03:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFL4-000ISv-0f for v6ops@ops.ietf.org; Sun, 16 Apr 2006 22:03:26 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 6B56234012; Sun, 16 Apr 2006 18:03:43 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 18:03:24 -0400 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: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Sun, 16 Apr 2006 18:03:22 -0400 Message-ID: <936A4045C332714F975800409DE0924002250259@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Thread-Index: AcZhJmCAL2EYZi3wTyGI8IpC/G3B6AAexMxQ From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Patrick W. Gilmore" Cc: "shim6-wg" , , , "IETF Discussion" , , X-OriginalArrivalTime: 16 Apr 2006 22:03:24.0078 (UTC) FILETIME=[94CDC4E0:01C661A1] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 The IETF has NOTHING to say anymore than any other body about any RIR policy. I want it to remain that way. IETF job is a standards body not a deployment body. /jim=20 > -----Original Message----- > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On=20 > Behalf Of Iljitsch van Beijnum > Sent: Sunday, April 16, 2006 3:18 AM > To: Patrick W. Gilmore > Cc: shim6-wg; ppml@arin.net; global-v6@lists.apnic.net; IETF=20 > Discussion; address-policy-wg@ripe.net; v6ops@ops.ietf.org > Subject: Re: [narten@us.ibm.com: PI addressing in IPv6=20 > advances in ARIN] >=20 > On 16-apr-2006, at 6:09, Patrick W. Gilmore wrote: >=20 > > Wow, Iljitsch, I have never lost so much respect so quickly for =20 > > someone who was not flaming a specific person or using profanity. =20 > > Congratulations. >=20 > Well, that's too bad. But several years of trying to get a=20 > scalable multihoming off the ground (flying to different=20 > meetings on my own > dime) where first my ideas about PI aggregation are rejected=20 > within the IETF mostly without due consideration because it=20 > involves the taboo word "geography" only to see the next best=20 > thing being rejected by people who, as far as I can tell,=20 > lack a view of the big picture, is enough to make me lose my=20 > cool. Just a little. >=20 > > Back on topic, it is not just those 60 people - the "playground" =20 > > appears to overwhelmingly agree with their position. I know I do. >=20 > Don't you think it's strange that the views within ARIN are=20 > so radically different than those within the IETF? Sure,=20 > inside the IETF there are also people who think PI in IPv6=20 > won't be a problem, but it's not the majority (as far as I=20 > can tell) and certainly not anything close to 90%. Now the=20 > IETF process isn't perfect, as many things depend on whether=20 > people feel like actually doing something. =20 > But many of the best and the brightest in the IETF have been=20 > around for some time in multi6 and really looked at the=20 > problem. Many, if not most, of them concluded that we need=20 > something better than IPv4 practices to make IPv6 last as=20 > long as we need it to last. Do you think all of them were wrong? >=20 > > I am sorry your technical arguments have not persuaded us=20 > in the past. =20 > > But I would urge you to stick to those, >=20 > Stay tuned. >=20 >=20 From owner-v6ops@ops.ietf.org Sun Apr 16 18:05:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVFN6-0003j7-Ge for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:05:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVFN3-00017Q-0c for v6ops-archive@lists.ietf.org; Sun, 16 Apr 2006 18:05:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFMv-000Ip4-I2 for v6ops-data@psg.com; Sun, 16 Apr 2006 22:05:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVFMu-000IoS-G3 for v6ops@ops.ietf.org; Sun, 16 Apr 2006 22:05:20 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id A8BC034052; Sun, 16 Apr 2006 18:05:20 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 18:05:19 -0400 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: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Date: Sun, 16 Apr 2006 18:05:17 -0400 Message-ID: <936A4045C332714F975800409DE092400225025A@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Thread-Index: AcZhelfEKyRTY5k8Q7qDA/fKueo1sgAJ07HA From: "Bound, Jim" To: "Patrick W. Gilmore" , "Jeroen Massar" Cc: "shim6-wg" , X-OriginalArrivalTime: 16 Apr 2006 22:05:19.0122 (UTC) FILETIME=[D9601720:01C661A1] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 I don't mind stopping the cross postings. Can someone send a mail to where we post this and I will abide? I suggest this is v6ops discussion now but I am unclear on how this helps any v6ops deliverable. It is kind of like good customer input to SHIM6 and V6OPS? /jim=20 > -----Original Message----- > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On=20 > Behalf Of Patrick W. Gilmore > Sent: Sunday, April 16, 2006 1:21 PM > To: Jeroen Massar > Cc: Patrick W. Gilmore; shim6-wg; v6ops@ops.ietf.org > Subject: Re: [narten@us.ibm.com: PI addressing in IPv6=20 > advances in ARIN] >=20 > On Apr 16, 2006, at 12:49 PM, Jeroen Massar wrote: >=20 > > [very nice cross posting going on here ;) ] >=20 > Nah, I just hit "reply-all", but only one actually made it through. =20 > I'm not subscribed to the rest of the lists. >=20 > I've lowered the CC list to something more reasonable now. >=20 > Oh, and commenting derisively on something you do yourself=20 > seems a bit silly. >=20 >=20 > > On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote: > > [... > > large snip about trying to bash shim6 which is not=20 > finalized yet, thus=20 > > how can you bash it ? > > Note: extra sarcasm included in this post. Eat the eggs with salt. > > ...] >=20 > I don't remember bashing shim6. I remember saying people do=20 > not agree it is the way to go. >=20 > As for "finalized", if I don't agree with the basic idea of a=20 > technology (e.g. inserting a "shim" into the IP packet), how=20 > can you "finalize" it to something with which I will agree? >=20 >=20 > >> Oh, and one thing I should have said last time: Technical=20 > arguments=20 > >> are important, but they are only part of the decision process. > > > > In other words: "You are right with your arguments, but I=20 > just threw=20 > > your args away as they are futile based on the comparison of money=20 > > earned this way or the other."... >=20 > I'm going to assume you are being sarcastic here, since your=20 > "translation" is factually incorrect. I was clear the=20 > technical arguments are not sufficient, or even close. I was=20 > adding that the business elements are an additional hurdle. >=20 > BTW: Sarcasm is usually intended to either be funny or=20 > illustrate a point. Your sarcasms is definitely not funny,=20 > and the only point you are illustrating here is a complete=20 > misunderstanding of the discussion at hand. >=20 >=20 > >> People (like me) have explained that the Internet is a=20 > business, and=20 > >> in addition to being .. technically unsavory to many=20 > people, shim6 is=20 > >> simply not viable in a business setting. > > > > And as you will only care for your business for the coming=20 > 10 or maybe=20 > > 20 years you really can't care what happens to the internet=20 > afterward. > > > > The idea of IPv6 is (still not was) to have it around for=20 > quite some=20 > > time longer than the lifespan of IPv4. Fortunately, the PI thing is=20 > > far from the end of the world and will only help catch on,=20 > see below. > > > > Of course any vendor will love the idea of having to do another IP=20 > > version of course, bring in the cash ;) >=20 > This is close to a useful argument. >=20 > First, predicting things like router-engine capabilities 20=20 > years in the future is beyond silly. >=20 > Second, the is a very real possibility that arguments about=20 > 'blowing up the routing table' are completely incorrect. =20 > People have been =20 > worried about it for over a decade and it has yet to come to pass. =20 > (You could argue that it hasn't happened because people are=20 > worried about it, but that it true with or without shim6, so=20 > it's a wash either way.) >=20 > Lastly, whether it is right or wrong, getting businesses to=20 > do something based on a 20 year horizon, especially when it=20 > is painful today - and will be for the next 20 years! - is=20 > essentially impossible. So why are you trying to get them to=20 > do it? Personally, I have much more important windmills at=20 > which to tilt. >=20 >=20 > >> Neither backbone operators > >> (vendors) nor end users (customers) are warming to the idea. Just=20 > >> the opposite. (At least in general, the one-in-a-million end user=20 > >> with DSL and cable who likes the idea 'cause he can't=20 > figure out how=20 > >> to spell "B-G-P" or doesn't want to pay for it is irrelevant.) > > > > Irrelevant for you as they don't give you money. Indeed,=20 > you only look=20 > > at your own business interrest (and who can blame you for that ;)=20 > > (Once though the internet was there for the masses and not only for=20 > > the ones with cash) >=20 > No, irrelevant PERIOD. You cannot architect the Internet for=20 > the one- in-a-million end user, _especially_ one who does not=20 > pay for the infrastructure. >=20 > If you argue that they are at all relevant, then we have a=20 > lot more problems with shim6 than we've discussed. (And with=20 > the Internet in > general.) So please explain to me why they are relevant in=20 > any way whatsoever? I am honestly eager to hear your=20 > thinking along this line. >=20 > Just be completely clear on the implications of "proving" a=20 > non- paying one-in-a-million end-user is reason enough to=20 > change the core architecture of the whole Internet. >=20 >=20 > >> So how do you get a technology widely accepted when the=20 > majority of=20 > >> people involved do not think it is the best technical=20 > solution? When=20 > >> the majority of vendors supposed to implement it will not=20 > do so for=20 > >> technical -and- business reasons. > > > > There is for you indeed a business reason to not like it:=20 > the end-site=20 > > won't have any reason to stick to the upstream. Which is=20 > indeed a bad=20 > > business for many of the 'vendors' you mean. > > > > As Eliot Lear also said very clearly: Thanks for lining the vendors=20 > > and all the stockholders pockets ;) >=20 > I'm not a backbone. I am personally an end user. And my=20 > company is not a backbone, and does not sell transit to=20 > anyone. In fact, we are =20 > probably the largest "end-site" consumer of bandwidth in the world. =20 > And I still dislike shim6 both technically and commercially,=20 > personally and professionally. So does every technical=20 > person at my company who has any interest in this topic. >=20 > It is not just backbones. Shim6 is not commercially viable. Period. >=20 > But thank you for attempting to divert the real discussion. >=20 >=20 > > That is in the long run, most likely in the coming 10-20 years the > > IPv6 > > routing tables will not have 'exploded' yet, but the folks selling=20 > > equipment and having stocks of those venders after that most likely=20 > > will have a nice retirement fund. Thanks to you! >=20 > First, thank you for thinking I am so important. >=20 > Second: Whatever. If you honestly believe cisco & juniper=20 > will fail or succeed based on shim6, you really need to=20 > reevaluate your hypothesis. >=20 >=20 > > Nevertheless, the PI thing is really *not* a bad thing, as=20 > it can be=20 > > used as an identifier for shim6, which is actually perfect. It just=20 > > saves on having to do a complete policy process for getting address=20 > > space for this type of usage. But thanks to this, this=20 > won't be needed=20 > > and thus in the end anybody who can get PI can use a shim6-alike=20 > > solution and won't have any problem with the upstream that actually=20 > > wanted to lock them in by letting them pay loads for an=20 > entry in the=20 > > BGP tables. > > > > Thus people voting for PI, thanks for helping shim6 or another=20 > > solution in that space, progress a lot :) >=20 > Then why are we arguing about this? >=20 > -- > TTFN, > patrick >=20 >=20 From owner-v6ops@ops.ietf.org Mon Apr 17 11:14:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVQy-00069K-5m for v6ops-archive@lists.ietf.org; Mon, 17 Apr 2006 11:14:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVQv-00037f-PT for v6ops-archive@lists.ietf.org; Mon, 17 Apr 2006 11:14:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVVMf-0005gI-64 for v6ops-data@psg.com; Mon, 17 Apr 2006 15:10:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 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 1FVVMd-0005fM-GP; Mon, 17 Apr 2006 15:10:07 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k3HF9TIV029204; Mon, 17 Apr 2006 15:09:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k3HF9NLc029203; Mon, 17 Apr 2006 15:09:23 GMT Date: Mon, 17 Apr 2006 15:09:23 +0000 From: bmanning@vacation.karoshi.com To: "Bound, Jim" Cc: Iljitsch van Beijnum , Scott Leibrand , "Jason Schillerschiller@uu.net" , Joe Abley , shim6-wg , v6ops@ops.ietf.org Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Message-ID: <20060417150923.GA29091@vacation.karoshi.com.> References: <936A4045C332714F975800409DE0924002250256@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE0924002250256@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Jim, you may want to revisit your understanding here. --bill On Sun, Apr 16, 2006 at 05:59:32PM -0400, Bound, Jim wrote: > Well that is how RIRs are structured and supported by ICANN. > /jim > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Iljitsch van Beijnum > > Sent: Friday, April 14, 2006 11:07 AM > > To: Scott Leibrand > > Cc: Jason Schillerschiller@uu.net; Joe Abley; shim6-wg; > > ppml@arin.net; global-v6@lists.apnic.net; IETF Discussion; > > address-policy-wg@ripe.net; v6ops@ops.ietf.org > > Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 > > advances in ARIN] > > > > On 14-apr-2006, at 16:57, Scott Leibrand wrote: > > > > > 60 voted in favor of moving forward with PI. 6 voted against. > > > > Wow, 10 to 1. Amazing. > > > > Even more amazing: 60 people who represent nobody but their > > own paycheck get to blow up the internet. > > > > Where is ICANN when you need it? This little experiment in > > playground democracy has to end before people get hurt. > > > > > > > From owner-v6ops@ops.ietf.org Mon Apr 17 13:46:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXoB-0008Tc-W5 for v6ops-archive@lists.ietf.org; Mon, 17 Apr 2006 13:46:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXoB-0003TE-OF for v6ops-archive@lists.ietf.org; Mon, 17 Apr 2006 13:46:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVXmJ-000Ism-TJ for v6ops-data@psg.com; Mon, 17 Apr 2006 17:44:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVXmI-000Ire-BR for v6ops@ops.ietf.org; Mon, 17 Apr 2006 17:44:46 +0000 Received: (qmail 63012 invoked by uid 1007); 17 Apr 2006 17:44:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=JzgG/6/NCG6nYezUeEDs0IQzbv4XNqelKpYCfZvjjBz0f/2vVNOn/Il06MN12778 ; Date: Mon, 17 Apr 2006 19:44:44 +0200 From: Gert Doering To: "Bound, Jim" Cc: Iljitsch van Beijnum , "Patrick W. Gilmore" , shim6-wg , ppml@arin.net, global-v6@lists.apnic.net, IETF Discussion , address-policy-wg@ripe.net, v6ops@ops.ietf.org Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN] Message-ID: <20060417174444.GM60910@Space.Net> References: <936A4045C332714F975800409DE0924002250259@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE0924002250259@tayexc14.americas.cpqcorp.net> 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: 7655788c23eb79e336f5f8ba8bce7906 Hi, On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote: > The IETF has NOTHING to say anymore than any other body about any RIR > policy. I want it to remain that way. IETF job is a standards body not > a deployment body. Things work a lot better if IETF and RIRs work hand-in-hand - that is, IETF makes standards that people can work with, and RIRs use allocation policies that somewhat reflect what the protocol designers had in mind. For IPv6, this isn't a huge success story yet... 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 Wed Apr 19 03:33:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW7BP-00025m-S0 for v6ops-archive@lists.ietf.org; Wed, 19 Apr 2006 03:33:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW7BN-00041o-Gb for v6ops-archive@lists.ietf.org; Wed, 19 Apr 2006 03:33:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FW77H-0003ml-I3 for v6ops-data@psg.com; Wed, 19 Apr 2006 07:28:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 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 1FW77G-0003mH-7V for v6ops@ops.ietf.org; Wed, 19 Apr 2006 07:28:46 +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 BA4BE827D; Wed, 19 Apr 2006 09:28:33 +0200 (CEST) Subject: The Pope gets IPv6 PA space (not PI :) From: Jeroen Massar Reply-To: jeroen@unfix.org To: "v6ops@ops.ietf.org" , "nanog@merit.edu" Cc: ARIN PPML , ipv6-wg@ripe.net Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ikDmCUTTbHK/pCOemEiB" Organization: Unfix Date: Wed, 19 Apr 2006 09:28:30 +0200 Message-Id: <1145431710.17463.2.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: 8b30eb7682a596edff707698f4a80f7d --=-ikDmCUTTbHK/pCOemEiB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable inet6num: 2a01:b8::/32 netname: VA-VATICAN-20060418 descr: Holy See - Vatican City State country: VA So now that IPv6 is officially blessed go deploy it :) Greets, Jeroen Reply-To explicitly set to myself so that people don't reply to this silly post to all the lists... override to the one you like if=20 you want --=-ikDmCUTTbHK/pCOemEiB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEABECADUFAkRF5p0uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+wBAKCvwJALIMwOuV7zjUM34Pl0nej8 2wCgl5/RnKVI7cnBxxAKGSGXgouMIm8= =CH2S -----END PGP SIGNATURE----- --=-ikDmCUTTbHK/pCOemEiB-- From owner-v6ops@ops.ietf.org Wed Apr 26 15:58:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq9i-0002HO-5Z for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 15:58:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq9g-0001mm-Qp for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 15:58:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq9P-0000e6-8X for v6ops-data@psg.com; Wed, 26 Apr 2006 19:58:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,NO_REAL_NAME,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq9O-0000ds-Mi for v6ops@ops.ietf.org; Wed, 26 Apr 2006 19:58:14 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2006 12:58:15 -0700 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 k3QJwEh0000348; Wed, 26 Apr 2006 12:58:14 -0700 (PDT) Received: from [10.32.244.219] (stealth-10-32-244-219.cisco.com [10.32.244.219]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k3QJv1cs003983; Wed, 26 Apr 2006 12:57:02 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David Kessens Content-Transfer-Encoding: 7bit From: fred@cisco.com Subject: WGLC draft-ietf-v6ops-icmpv6-filtering-recs-00.txt Date: Wed, 26 Apr 2006 12:58:12 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.749.3) DKIM-Signature: a=rsa-sha1; q=dns; l=435; t=1146081422; x=1146945422; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:fred@cisco.com |Subject:WGLC=20=20draft-ietf-v6ops-icmpv6-filtering-recs-00.txt |To:v6ops@ops.ietf.org; X=v=3Dcisco.com=3B=20h=3DLSJAmwmfWTD7xCPeiTFAGms7i8Q=3D; b=nIKio8knhJrlrqbl8j2UkyBjpPXTOn7gmyHfK5T0j75Ct1UR8U18zyR2c9deA4AtjdKehFCb plZX5Q4WMsvmOcr2kDu8gHQA9OhSVQqxfptRyigBkXlixz1Jb3LP8Aa3; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Per the WG decision in the meeting last month, I am opening a working group last call on the filtering document http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6- filtering-recs-00.txt "Best Current Practice for Filtering ICMPv6 Messages in Firewalls" Two weeks from Friday, barring substantive issues, the last call will close, Elwyn will post a final update, and we will send the report to the AD. From owner-v6ops@ops.ietf.org Wed Apr 26 16:14:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq50-0004u2-6e for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 15:53:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq4z-0000K3-Ps for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 15:53:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq1Z-000Pnx-Jq for v6ops-data@psg.com; Wed, 26 Apr 2006 19:50:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 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 1FYq1W-000Pmz-Rp for v6ops@ops.ietf.org; Wed, 26 Apr 2006 19:50:07 +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 k3QJo29W003090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYq1S-00078G-0G; Wed, 26 Apr 2006 15:50:02 -0400 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-recs-00.txt Message-Id: Date: Wed, 26 Apr 2006 15:50:02 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --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 : Recommendations for Filtering ICMPv6 Messages in Firewalls Author(s) : E. Davies, J. Mohacsi Filename : draft-ietf-v6ops-icmpv6-filtering-recs-00.txt Pages : 34 Date : 2006-4-26 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-recs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-icmpv6-filtering-recs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26133131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-icmpv6-filtering-recs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26133131.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Apr 26 16:56:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYr3u-0005yX-UN for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 16:56:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYr3r-0005C0-D9 for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 16:56:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYr2O-0004iO-1u for v6ops-data@psg.com; Wed, 26 Apr 2006 20:55:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYr2M-0004hD-KZ for v6ops@ops.ietf.org; Wed, 26 Apr 2006 20:55:02 +0000 Received: from 252.254.187.81.in-addr.arpa ([81.187.254.252] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FYr2K-0008Vy-GM; Wed, 26 Apr 2006 21:55:00 +0100 Message-ID: <444FDEC3.6030201@dial.pipex.com> Date: Wed, 26 Apr 2006 21:57:39 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: fred@cisco.com CC: v6ops@ops.ietf.org, David Kessens Subject: Re: WGLC draft-ietf-v6ops-icmpv6-filtering-recs-00.txt References: In-Reply-To: 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.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Please note that the title in the file has been changed to "Recommendations for Filtering ICMPv6 Messages in Firewalls" in line with the file name and the discussion in Dallas. This is necessary, because notwithstanding previous discussions in the wg, the IESG is unwilling to sanction a BCP for which there is relatively little operational experience. The changes from draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt apart from changing the title are editorial plus updating of references to take into account the publication of rfc2463bis (RFC4443). Due to a misreading of the I-D database, I have managed to replace RFC2461 with RFC4311 which is *not* rfc2461bis. Both rfc2461bis and rfc2462bis are hung up waiting for resolution of the M/O bits problem - hopefully this has been resolved just today so these drafts should go to RFC fairly shortly. /Elwyn fred@cisco.com wrote: > Per the WG decision in the meeting last month, I am opening a working > group last call on the filtering document > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-00.txt > > "Best Current Practice for Filtering ICMPv6 Messages in Firewalls" > > Two weeks from Friday, barring substantive issues, the last call will > close, Elwyn will post a final update, and we will send the report to > the AD. > From owner-v6ops@ops.ietf.org Wed Apr 26 17:36:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrgM-0003Nr-09 for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 17:36:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrgL-0007aJ-ON for v6ops-archive@lists.ietf.org; Wed, 26 Apr 2006 17:36:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYrfZ-0007gQ-9Y for v6ops-data@psg.com; Wed, 26 Apr 2006 21:35:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYrfY-0007gF-Pt for v6ops@ops.ietf.org; Wed, 26 Apr 2006 21:35:32 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2006 14:35:32 -0700 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 k3QLZVRT018348; Wed, 26 Apr 2006 14:35:32 -0700 (PDT) Received: from [10.32.244.219] (stealth-10-32-244-219.cisco.com [10.32.244.219]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k3QLYIw7007055; Wed, 26 Apr 2006 14:34:18 -0700 In-Reply-To: <444FDEC3.6030201@dial.pipex.com> References: <444FDEC3.6030201@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org, David Kessens Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: WGLC draft-ietf-v6ops-icmpv6-filtering-recs-00.txt Date: Wed, 26 Apr 2006 14:35:30 -0700 To: Elwyn Davies X-Mailer: Apple Mail (2.749.3) DKIM-Signature: a=rsa-sha1; q=dns; l=615; t=1146087259; x=1146951259; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20WGLC=20=20draft-ietf-v6ops-icmpv6-filtering-recs-00.txt |To:Elwyn=20Davies=20; X=v=3Dcisco.com=3B=20h=3DGMKNahSnuYrihKd4IJ1nEYwcCwM=3D; b=Hy+sfng4jUHOCBVuWs2NYHEIyqkh/Qk2mAp9EnC1OCwQg0yuwLbaTASL3nGFG6JnMfg9zC3i 0yqyA+TysQKEcDQKDi2ZLKJxerl1NNwbrHgxmQqPoOVGGeKKToF59Dli; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Apr 26, 2006, at 1:57 PM, Elwyn Davies wrote: > Due to a misreading of the I-D database, I have managed to replace > RFC2461 with RFC4311 which is *not* rfc2461bis. Both rfc2461bis > and rfc2462bis are hung up waiting for resolution of the M/O bits > problem - hopefully this has been resolved just today so these > drafts should go to RFC fairly shortly. Sorting that out can be a last call comment, or if it is the only thing that needs to be done it could be picked up during the sorting out of IESG comments or as a note to the RFC Editor. Let's see what other issues come up. From owner-v6ops@ops.ietf.org Thu Apr 27 15:06:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBop-0001tw-UZ for v6ops-archive@lists.ietf.org; Thu, 27 Apr 2006 15:06:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZBol-00024y-Av for v6ops-archive@lists.ietf.org; Thu, 27 Apr 2006 15:06:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZBlA-0005gD-DN for v6ops-data@psg.com; Thu, 27 Apr 2006 19:02:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [213.186.38.137] (helo=27.mail-out.ovh.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZBl8-0005fI-Ph for v6ops@ops.ietf.org; Thu, 27 Apr 2006 19:02:39 +0000 Received: (qmail 27554 invoked by uid 503); 27 Apr 2006 19:03:49 -0000 Received: from b7.ovh.net (HELO mail138.ha.ovh.net) (213.186.33.57) by 27.mail-out.ovh.net with SMTP; 27 Apr 2006 19:03:49 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 27 Apr 2006 19:02:23 -0000 Received: from mail138.ha.ovh.net (10.0.50.138) by mail138.ha.ovh.net with SMTP; 27 Apr 2006 19:02:21 -0000 Received: from b0.ovh.net (HELO queue-pre) (213.186.33.50) by b0.ovh.net with SMTP; 27 Apr 2006 19:02:21 -0000 Received: from alille-251-1-21-173.w82-127.abo.wanadoo.fr (HELO auguste.home.simphalempin.com) (postmaster%simphalempin.com@82.127.211.173) by ns0.ovh.net with SMTP; 27 Apr 2006 19:02:21 -0000 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: SimPhalempin.Com To: v6ops@ops.ietf.org Subject: Re: WGLC draft-ietf-v6ops-icmpv6-filtering-recs-00.txt Date: Thu, 27 Apr 2006 21:02:30 +0200 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline X-Length: 2397 X-UID: 24 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200604272102.31270@auguste.remlab.net> X-Ovh-Remote: 82.127.211.173 (alille-251-1-21-173.w82-127.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Le Mercredi 26 Avril 2006 21:58, vous avez =C3=A9crit : > Per the WG decision in the meeting last month, I am opening a working > group last call on the filtering document > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6- > filtering-recs-00.txt > "Best Current Practice for Filtering ICMPv6 Messages in Firewalls" A few minor notes: 1/ The specification does not seem to consider what should be made with=20 filtered packets, and seems to assume they will be dropped. In some=20 case (such as the _currently_ undefined ICMP codes), it might be nicer,=20 so long as the local policy permits, to cause the firewall to craft an=20 Administratively prohibited error or something like that (=C3=A0=20 la =E2=80=9Cip6tables -j REJECT=E2=80=9D), maybe... though I guess some kin= d of rate=20 limiting would obviously be required in that case. 2/ When I see sample rules like these: =E2=80=9C # Deny icmps to/from link local addresses ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP =E2=80=9D... I'm becoming worried that the forwarding/routing software from= =20 Linux IPv6 stack actually let this packets through by default=20 (particularly the first rule). I'm pretty sure the first one is=20 redumdant, and I hope the second one is also. That's not to say=20 firewall admin should not use them for the sake of verbosity and/or=20 quietness of mind, but it might be worth adding a comment that these=20 are already sort of built-in. By the way, if anyone can confirm that these rules are actually=20 redumdant... 3/ I believe filter Echo requests is fairly lame, and I did complain=20 that Teredo needs it to work at all. Now Teredo is mentioned and Echo=20 requests were promoted from "Should not be blocked" to "Must not be=20 blocked" :) Some other yet-to-be-defined protocols/schemes might also=20 rely on incoming Echo requests to not be firewalled, and I surely hope=20 not so many company and SOHO firewalls will block IPv6 echo requests,=20 as IPv4 echo requests.... but as far as Teredo is concerned, only Echo=20 requests coming from the Teredo prefix (2001:0::/32) needs to be passed=20 (and of course Echo replies, only the other way). Regards, =2D-=20 R=C3=A9mi Denis-Courmont http://www.simphalempin.com/home/