From owner-v6ops@ops.ietf.org Thu Dec 01 19:39:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehyxw-0004A4-Ry for v6ops-archive@megatron.ietf.org; Thu, 01 Dec 2005 19:39:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11617 for ; Thu, 1 Dec 2005 19:39:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ehyuh-0001bj-Eg for v6ops-data@psg.com; Fri, 02 Dec 2005 00:36:35 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ehyue-0001bV-2w for v6ops@ops.ietf.org; Fri, 02 Dec 2005 00:36:32 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2005 16:36:32 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB20aT73022478; Thu, 1 Dec 2005 16:36:29 -0800 (PST) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jB20iDDa004584; Thu, 1 Dec 2005 16:44:13 -0800 In-Reply-To: <438F5198.1070103@reed.com> References: <438F10E4.7050007@dcrocker.net> <438F5198.1070103@reed.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-557754582" Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [e2e] End-to-end is a design guideline, not a rigid rule Date: Thu, 1 Dec 2005 16:36:16 -0800 To: end2end-interest@postel.org X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Gpgmail-State: signed X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=12982; t=1133484253; x=1133916453; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[e2e]=20End-to-end=20is=20a=20design=20guideline,=20not=20a=20ri gid=20rule| From:Fred=20Baker=20| Date:Thu,=201=20Dec=202005=2016=3A36=3A16=20-0800| Content-Type:multipart/signed=3B=20protocol=3D=22application/pgp-signature=22=3B=20mi calg=3Dpgp-sha1=3B=20boundary=3D=22Apple-Mail-3-557754582=22| Content-Transfer-Encoding:7bit; b=T1CazSejPESCsSs47WSGJHoM3YZ6TSN1u1gam4jZmgc0oGrIGByyY7Dn9zSpAK7DSz12jE5N 3+aS7OeatdbQ5B/J8IsX6nyZ8NRnGb7jiKmdjkKsvulNIXLv51219XE8NQg+cArk1PtgyaNRCV2 6K802mLp+d7hb+7v+9AYkXSI= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( 28 extraneous bytes; message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3-557754582 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable I'll agree with points made in each of the emails in this thread. =46rom my perspective, "end to end" includes both "end-to-end-across-a-=20= single-communication" and the "end-to-end-in-a-disruption-tolerant-=20 manner" models that Dave C mentioned. End to end in an email means =20 that when I send a message to the various recipients of end2end-=20 interest, I expect service in each of the hundreds of cases of that =20 to be essentially the same - that the content of the message will not =20= be changed en route, that the envelope of the SMTP message will be =20 updated at each application layer hop to facilitate problem =20 diagnosis, and that delivery will be timely within the service limits =20= of the application or a response will be sent to me saying that it =20 could not be accomplished. Supporting that, the MUA-MTA, MTA-MTA, and =20= MTA-MUA hops will similarly be handled with minimal effort. One would =20= expect that the interaction of MUAs and MTAs across a network of ISPs =20= to be indistinguishable from one in which they all happened to be =20 colocated on a common LAN apart from the rate and timing side-effects =20= of the engineering of the network. One place where I depart from a common view of the end to end =20 argument is that there are times when it makes sense to actively =20 enquire of the network and expect the network to make a response that =20= characterizes itself. A completely "stupid" network, such as a 3/4" =20 diameter yellow coaxial cable, would not be able to respond, and as I =20= understand Isenberg, that is the way all networks should behave. All =20 intelligence should be in the end system and only in the end system. =20 But (Dave R, tell me if I am wrong) Saltzer/Reed doesn't seem to =20 suggest that. The point of the original end-to-end argument was not =20 that intelligence should reside only in the end station or only in =20 the application; it was that a lower layer should not do something =20 that also had to be done at a higher layer without a good =20 justification. An example, often repeated, is that LAPB go-back-N =20 retransmission is redundant in the presence of TCP or application =20 retransmission, and that it measurably resulted in packet duplication =20= around bit errors. That said, 802.11 also has retransmission, and if =20 it didn't, behavior on wireless LANs would be a lot worse than it is. =20= Hence, we retransmit in TCP in the general case, but 802.11 presents =20 a case where link layer retransmission is still justified. This =20 understanding of the end-to-end principle would seem to suggest that =20 interactions with the network that inform the intelligent edge and =20 enable it to make better decisions are within the principle's scope. =20 I view both the integrated services and the differentiated services =20 architectures in that light - one doesn't want the network to subvert =20= the intent of the intelligent edge, but interactions that enable it =20 to better achieve its intent are good. And then, what is subversion? It is pretty common to put in what =20 amounts to a network honeypot, in which one of the addresses in a =20 prefix is routed down a tunnel to a collector. In the event that =20 anyone sends something to the address, the collector picks it up, and =20= management remediation actions follow. Is this "subversion of =20 routing"? I would argue that it is "routing", but is not =20 "subversion". Ditto the case where a system comes under attack and =20 network ops staff reroutes the address through the same kind of =20 tunnel. That certainly subverts the attack, and makes the targeted =20 system unavailable for a period of time until the attack can be =20 interdicted. But for any legitimate use of the targeted system, it's =20 hard to describe as subversion; it's part of the process of restoration. As to NATs and such - to my way of thinking, a NAT is two things in =20 one. It is a stateful firewall (it maps active authorized address/=20 port pairs, creates such a mapping if it originates from "inside", =20 and if the mapping doesn't exist it blocks communication from the =20 "outside"), which if one thinks having skin on the human body is good =20= for its health one has to consider a reasonable prophylactic =20 protection. To the extent that applications and protocols above the =20 network layer know something about network layer addresses, NATs also =20= create difficulties in deploying such applications. In that sense, a =20 NAT is a man-in-the-middle attack, something that makes life =20 difficult for the application. I'm all for good firewalls; the end to =20= end model doesn't speak highly of things that break application =20 behavior, however. So, coming back to Dave C's point about our current network =20 architecture not doing very well with hidden boundaries, I would say =20 "you are correct; it doesn't". I don't think that is a failure of the =20= end-to-end principle, however. It may be a failure of our ability to =20 apply it correctly. If all applications were message-based, like =20 email is, one could imagine a firewall acting something like an MTA - =20= terminating the conversation in one domain and then repeating it in =20 another, in a manner entirely consistent with the end-to-end =20 principle as applied to email in its two forms of end-to-end-ness. If =20= all applications were able to be proxied, like SIP, or the various =20 users of SOCKS are, the proxy could literally be the trusted-and-=20 known third party that made the transition happen. If IP were very =20 slightly different, with the AS number in the header and listed in =20 DNS and the routing protocols, and addresses being understood as =20 local to the identified AS, we could assign an AS to every region =20 behind a NAT, and the whole thing would work quite nicely end to end. The problem is not that the architecture and available tools don't =20 handle the concept of separation of domains; it is that our current =20 common implementation of separation of domains involves a man-in-the-=20 middle attack on a subset of the relevant applications and protocols. =20= As Dave R points out, the man-in-the-middle attacks that we build in =20 make the network harder to manage and harder to maintain, and makes =20 the applications harder to improve. Fixing the architecture, in my =20 opinion, will involve removing the things that subvert the intent of =20 the end system, which is to say, changes them in the direction of =20 Salter/Reed's version of the end-to-end principle. > From: Dave Crocker > Date: December 1, 2005 7:04:04 AM PST > To: end2end-interest@postel.org > Subject: [e2e] End-to-end is a design guideline, not a rigid rule > Reply-To: dcrocker@bbiw.net > > Folks, > > A posting on Farber's IP list finally prompted me to write some =20 > thoughts that have been wandering around in the back of my mind. =20 > I'm interested in reactions you might have: > > > "Andrew W. Donoho" wrote: > > The debate about NAT obscures the real issue - that there are =20 > legitimate reasons to assert policies for net access at =20 > organizational boundaries. Yes, we want the internet architecture =20 > to be end to end. > > > This struck me as a particularly useful summary statement about =20 > some core architectural issues at hand: Internet technical =20 > discussions tend to lack good architectural constructs for =20 > describing operations, administration and management (OA&M) =20 > boundaries, and we lack robustness in the "end to end" construct. > > The issue of OA&M boundaries has long been present in the Internet. =20= > Note the distinction between routing within an Autonomous System =20 > and routing between ASs. To carry this a bit further, note that =20 > the original Internet had a single core (backbone) service, run by =20 > BBN. The creation of NSFNet finally broke this simplistic public =20 > routing model and required development of a routing protocol that =20 > supported multiple backbones. > > As another example, the email DNS MX record, that one finds over =20 > the open Internet, is also generally viewed as marking this =20 > boundary and is often called a Boundary MTA. However the Internet =20 > Mail architecture does not have the construct explicitly. For a =20 > year or so, I have been searching for a term that marks =20 > independent, cohesive operational environments, but haven't found =20 > one that the community likes. Some folks have suggested a =20 > derivation of an old X.400 term: Administrative Management Domain =20 > (ADMD). > > More generally I think that this issue of boundaries between =20 > islands of cohesive policy -- defining differences in the trust =20 > within an island, versus between islands -- is a key point of =20 > enhancement to the Internet architecture work that we must focus =20 > on. I have found =93Tussle in Cyberspace: Defining Tomorrow=92s =20 > Internet,=94 (Clark, D., Wroclawski, J., Sollins, K., and R. Braden, =20= > ACM SIGCOMM, 2002) a particularly cogent starting point, for this =20 > issue. > > On the question of the "end to end" construct I believe we suffer =20 > from viewing it simplistically. What I think our community has =20 > missed is that it is a design guideline, not a rigid rule. In fact =20= > with a layered architecture, the construct varies according to the =20 > layer. At the IP level, this is demonstrated two ways. One is the =20= > next IP hop, which might go through many nodes in a layer-2 =20 > network, and the other is the source/destination IP addresses, =20 > which might go through multiple IP nodes. > > The TCP/IP split is the primary example of end-to-end, but it is =20 > deceptive. TCP is end-to-end but only at the TCP layer. The =20 > applications that use TCP represent points beyond the supposed end-=20 > to-end framework. > > My own education on this point came from doing EDI over Email. Of =20 > course I always viewed the email author-to-recipient as "end to =20 > end" but along comes EDI that did additional routing at the =20 > recipient site. To the EDI world, the entire email service was =20 > merely one hop. > > This proved enlightening because the point has come up repeatedly: =20= > For email, user-level re-routing and forwarding are common, but =20 > outside the scope of the generally recognized architecture. I've =20 > been working on a document that is trying to fully describe the =20 > current Internet Mail architecture: > > > > However it is not clear whether it will reach rough consensus. > > My own view is that the email concept of end to end has two =20 > versions. One is between the posting location and the SMTP RCPT-TO =20 > (envelope) address and the other is between the author and the =20 > (final) recipient. Failure to deal with this explicitly in the =20 > architecture is proving problematic to such email enhancements as =20 > transit responsibility, such as by SPF or DKIM). > > In other words, the Internet technology has never been a pure "end =20 > to end" model. Rather, end to end is a way of distinguishing =20 > between components that compose an infrastructure versus components =20= > that use the infrastructure -- at a particular layer. "End to end" =20 > is a way of characterizing a preference to keep the infrastructure =20 > as simple as possible. > > This does not mean that we are prohibited from putting anything =20 > into the infrastructure or changing the boundaries of the =20 > infrastructure, merely that we prefer to keep the it unchanged. In =20= > this light, NATs (and firewalls) are merely a clear demonstration =20 > of market demand for some facilities that make end to end layered =20 > with respect to some operational policies, to permit the addition =20 > of a trust boundary between intra-network operations and inter-=20 > network operations. > > We should not be surprised by this additional requirement nor =20 > should we resist it. The primary Internet lesson is about scaling, =20= > and this appears to be a rather straightforward example of scaling =20 > among very large numbers of independent and diverse operational =20 > groups. Growth like this always comes with vast cultural =20 > diversity. That means that the basis for trust among the =20 > independent groups is more fragile. It needs much more careful =20 > definition and enforcement than was required in the kinder and =20 > gentler days of a smaller Internet. > > > d/ > --=20 > > Dave Crocker > Brandenburg InternetWorking > > From: Joe Touch > Date: December 1, 2005 11:38:42 AM PST > To: dcrocker@bbiw.net > Cc: end2end-interest@postel.org > Subject: Re: [e2e] End-to-end is a design guideline, not a rigid rule > > The "ends" and "hops" in E2E are relative, at least they always =20 > have been to me. All the E2E argument says, in that context, is =20 > that you can't compose HBH services to end up with the equivalent E2E. > > It never said not to do HBH (e.g., for performance). It never said =20 > where the ends definitively were for all layers, IMO. > > Joe > From: "David P. Reed" > Date: December 1, 2005 11:40:08 AM PST > To: end2end-interest@postel.org > Subject: Re: [e2e] End-to-end is a design guideline, not a rigid rule > > [oops, Dave C. pointed out that I replied only to him, instead of =20 > only to e2ei, and encouraged me to send it to the whole list] > > The end-to-end argument was indeed a design guideline not a rigid =20 > rule as proposed. On the other hand, as you point out, Dave, its =20 > value as a guideline is making a system scalable and evolvable. =20 > And there's a corollary: building function into the network has =20 > costs as well as benefits. Too often we ignore those costs, =20 > because they are less visible than the benefits. > > However, I disagree with your example. The problem is that =20 > topology doesn't map to authority. Yes, there are organizational =20 > boundaries, and organizations have an interest in communications =20 > between peers. However, those organizational boundaries do NOT =20 > correlate closely with physical network boundaries. The premature =20= > binding of organizational boundaries to physical topological =20 > connect points is why NATs and so forth so often miss the mark on =20 > solving the true "end-to-end" problems we have. > > So, I agree with you on your major point, but I disagree that email =20= > is a good example of how to either apply or ignore the end-to-end =20 > argument. > > One merely has to examine the move to having hotel ISPs spoofing =20 > SMTP connections based on their organizational "interest" in =20 > blocking spam (and their lawyers assert that the the law *requires* =20= > them to do this). That man-in-the-middle solution actually prevents =20= > better solutions (such as crypto-authentication that prevents man-=20 > in-the-middle attacks) to the actual end-to-end requirements that =20 > users want. > --Apple-Mail-3-557754582 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDj5cLbjEdbHIsm0MRAt3PAKD9tnJHCUs9hMhAPlpKDy+K2IzTJwCgvA8e Ns/lGuqH5/VhGEe8sQD6wyI= =taYH -----END PGP SIGNATURE----- --Apple-Mail-3-557754582-- From owner-v6ops@ops.ietf.org Mon Dec 05 04:56:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjD5B-0004mB-SI for v6ops-archive@megatron.ietf.org; Mon, 05 Dec 2005 04:56:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24092 for ; Mon, 5 Dec 2005 04:55:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjD1I-0000bv-6b for v6ops-data@psg.com; Mon, 05 Dec 2005 09:52:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjD1H-0000bk-G4 for v6ops@ops.ietf.org; Mon, 05 Dec 2005 09:52:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F981.98F64EB4" Subject: SIIT translation Date: Mon, 5 Dec 2005 01:57:08 -0800 Message-ID: Thread-Topic: SIIT translation Thread-Index: AcX5gkEbXKWcXY3sRQCzp6JdKqIEtg== From: "Vishwas Manral" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F981.98F64EB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric/ folks, =20 As the ICMPv6 has a checksum which includes a pseudo header, though the ICMPv6 does not have the same, I think we cannot do SIIT (stateless translation) for fragmented ICMPv4 packets. We need to get all the fragements before we can find the checksum, hence it becomes stateful. =20 I think this seems to be missing in the RFC, though it talks about a similar case for UDP packet with checksum 0. Is my understanding correct? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5F981.98F64EB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric/ folks,

 

As the ICMPv6 has a checksum which includes a pseudo = header, though the ICMPv6 does not have the same, I think we cannot do SIIT = (stateless translation) for fragmented ICMPv4 packets. We need to get all the = fragements before we can find the checksum, hence it becomes = stateful.

 

I think this seems to be missing in the RFC, though = it talks about a similar case for UDP packet with checksum 0. Is my understanding correct?

 

Thanks,

Vishwas

 

------_=_NextPart_001_01C5F981.98F64EB4-- From owner-v6ops@ops.ietf.org Mon Dec 05 16:59:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjON0-0003OG-AN for v6ops-archive@megatron.ietf.org; Mon, 05 Dec 2005 16:59:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20405 for ; Mon, 5 Dec 2005 16:58:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjOKT-000BJV-AI for v6ops-data@psg.com; Mon, 05 Dec 2005 21:57:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjOKS-000BJI-Lt for v6ops@ops.ietf.org; Mon, 05 Dec 2005 21:57:00 +0000 Received: from jurassic.eng.sun.com ([129.146.68.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jB5LuxdK002812; Mon, 5 Dec 2005 13:57:00 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jB5Luxcm445539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 Dec 2005 13:56:59 -0800 (PST) Message-ID: <4394B7AB.3010801@sun.com> Date: Mon, 05 Dec 2005 13:56:59 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishwas Manral CC: v6ops@ops.ietf.org Subject: Re: SIIT translation 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 Content-Transfer-Encoding: 7bit Vishwas Manral wrote: > Hi Eric/ folks, > > > > As the ICMPv6 has a checksum which includes a pseudo header, though the > ICMPv6 does not have the same, I think we cannot do SIIT (stateless > translation) for fragmented ICMPv4 packets. We need to get all the > fragements before we can find the checksum, hence it becomes stateful. I haven't looked at the details recently, but I think the addition of the pseudo-header checksum is solvable without needing state in the translator. The pseudo-header (from the IPv6 header) is available in the same packet as the ICMP checksum field. Thus the checksum can be adjusted based on the delta of adding or deleting (for v4->v6 and v6->v4 translation, respectively) the pseudo-header checksum by only looking at that one packet. > I think this seems to be missing in the RFC, though it talks about a > similar case for UDP packet with checksum 0. Is my understanding > correct? The UDP with zero checksum is much different, because it requires a computation of the checksum for the whole datagram i.e. across all the fragments. Erik From owner-v6ops@ops.ietf.org Mon Dec 05 19:43:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQvz-0004io-QR for v6ops-archive@megatron.ietf.org; Mon, 05 Dec 2005 19:43:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07420 for ; Mon, 5 Dec 2005 19:43:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjQu3-0001vk-Md for v6ops-data@psg.com; Tue, 06 Dec 2005 00:41:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjQu2-0001vU-B7 for v6ops@ops.ietf.org; Tue, 06 Dec 2005 00:41:54 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jB60fSj03814; Tue, 6 Dec 2005 01:41:28 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jB60fSDA069899; Tue, 6 Dec 2005 01:41:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512060041.jB60fSDA069899@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Vishwas Manral , v6ops@ops.ietf.org Subject: Re: SIIT translation In-reply-to: Your message of Mon, 05 Dec 2005 13:56:59 PST. <4394B7AB.3010801@sun.com> Date: Tue, 06 Dec 2005 01:41:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: I haven't looked at the details recently, but I think the addition of the pseudo-header checksum is solvable without needing state in the translator. The pseudo-header (from the IPv6 header) is available in the same packet as the ICMP checksum field. Thus the checksum can be adjusted based on the delta of adding or deleting (for v4->v6 and v6->v4 translation, respectively) the pseudo-header checksum by only looking at that one packet. => I agree: the checksum is adjusted and not recomputed. Usually the address part is cached in the mapping, and when you can choose one part of an address you even try to make the update null. The UDP with zero checksum is much different, because it requires a computation of the checksum for the whole datagram i.e. across all the fragments. => note zero checksum UDPs should only occur in cases where they are small enough to be never fragmented, i.e., UDP checksums are highly recommended in NFS & co, DNS including EDNS0, but not for video or voice where large packets and fragmentation add too much delay. Regards Francis.Dupont@enst-bretagne.fr From 1jorean@absolutemotion.com Thu Dec 08 21:00:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkXYG-0002tk-4Q for v6ops-archive@megatron.ietf.org; Thu, 08 Dec 2005 21:00:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20336 for ; Thu, 8 Dec 2005 20:58:59 -0500 (EST) Received: from cpe-68-201-241-187.houston.res.rr.com ([68.201.241.187] helo=68.201.241.187) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkXYA-0006Kg-3P for v6ops-archive@ietf.org; Thu, 08 Dec 2005 20:59:58 -0500 Message-ID: <28f301c5fc61$dd43564f$90deaa2b@absolutemotion.com> From: "Steven A. Norman" <1jorean@absolutemotion.com> To: v6ops-archive@ietf.org Subject: Replica watch models Date: Fri, 09 Dec 2005 01:40:55 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_754AC4DB.14938F29" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_754AC4DB.14938F29 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_6A40E0E5.1B6F30FA" ------=_NextPart_001_0001_6A40E0E5.1B6F30FA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit REPLICA WATCH MODELS - exact copies of the original watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Bvlgari, Franck Muller .. and 15 other most famous manufacturers. http://www.snappier.net All copies are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_6A40E0E5.1B6F30FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
REPLICA WATCH MODELS

- exact copies of the original watches
- perfect as a gift for your colleagues and friends
- free gift box

Rolex, Patek Philippe, Omega
Cartier, Bvlgari, Franck Muller

.. and 15 other most famous manufacturers.

http://www.snappier.net

All copies are for only $239.95 - $279.95!


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_6A40E0E5.1B6F30FA-- ------=_NextPart_000_0000_754AC4DB.14938F29-- From herb@47jane.com Tue Dec 13 02:16:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em4OL-0003XR-5D for v6ops-archive@megatron.ietf.org; Tue, 13 Dec 2005 02:16:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10813 for ; Tue, 13 Dec 2005 02:15:07 -0500 (EST) Received: from [58.78.122.171] (helo=58.78.122.171) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Em4PF-0003pt-46 for v6ops-archive@ietf.org; Tue, 13 Dec 2005 02:17:02 -0500 Message-ID: <228b01c60021$e76d93cf$9409fb63@47jane.com> From: "Dr. Lewis Wallace" To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?VHJ5IFNwdXItTSE=?= Date: Tue, 13 Dec 2005 20:09:27 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_2013ECB6.27D82886" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_0000_2013ECB6.27D82886 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E5F443D6.8637784E" ------=_NextPart_001_0001_E5F443D6.8637784E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit SPUR-M is an omnipotent formula. It increases sperm production by 500%. Q.: Why would I want to increase my sperm production? A.: By increasing the amount of sperm you will automatically experience much longer orgasms, which are more intensive and satisfying. Q.: What do other benefits include? A.: Powerful ejacalutions, rock hard erections, increased desire. Learn more: http://pills-you-need.net/spa/ ___________________ To stop, go here ------=_NextPart_001_0001_E5F443D6.8637784E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

SPUR-M is an omnipotent formula. It increases sperm production by 500%.

Q.: Why would I want to increase my sperm production?
A.: By increasing the amount of sperm you will automatically experience much longer orgasms, which are more intensive and satisfying.

Q.: What do other benefits include?
A.: Powerful ejacalutions, rock hard erections, increased desire.

Learn more: http://pills-you-need.net/spa/


___________________
To stop, go here

------=_NextPart_001_0001_E5F443D6.8637784E-- ------=_NextPart_000_0000_2013ECB6.27D82886-- From owner-v6ops@ops.ietf.org Tue Dec 13 07:09:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em8yR-0002iY-RK for v6ops-archive@megatron.ietf.org; Tue, 13 Dec 2005 07:09:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13304 for ; Tue, 13 Dec 2005 07:08:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Em8v1-000NuY-Kv for v6ops-data@psg.com; Tue, 13 Dec 2005 12:06:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Em8v0-000NuL-Qe for v6ops@ops.ietf.org; Tue, 13 Dec 2005 12:06:06 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 13 Dec 2005 04:06:06 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBDC64QK005651 for ; Tue, 13 Dec 2005 04:06:04 -0800 (PST) Received: from [10.31.146.93] (ams-clip-vpn-dhcp4231.cisco.com [10.61.80.134]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jBDCD5IZ006127 for ; Tue, 13 Dec 2005 04:13:06 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) References: <033101c5ff78$cb8274d0$4e087c0a@china.huawei.com> X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <761163F2-1FA3-46A5-8AB2-A25C4FB6F8F4@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: Gen-ART Review of draft-ietf-v6ops-onlinkassumption-03.txt Date: Tue, 13 Dec 2005 12:58:07 +0100 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2849; t=1134475986; x=1134908186; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Fwd=3A=20Gen-ART=20Review=20of=20draft-ietf-v6ops-onlinkassumption-03.tx t| From:Fred=20Baker=20| Date:Tue,=2013=20Dec=202005=2012=3A58=3A07=20+0100| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=bjOcWFqtKlfI5+gXCAhCGy0jzhFB7d0HT0xztpQHAFIiypQQ9jDxLGTpb8Lmk5VD7lzvYEni GH4oFgL00gUdZg5x7X+sokjQKGhP/7oAOhVgWlhWQL6zTz9aTmXTbQMJ/2LnVeQuZgMOIqdcNtN fU1iPOMxoapxl0CpraNXfaA0= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Begin forwarded message: > From: "Spencer Dawkins" > Date: December 13, 2005 1:04:30 AM CEST > To: "General Area Review Team" > Cc: "David Kessens" , "Fred Baker" > , , > , , "Kurt > Lindqvist" > Subject: Gen-ART Review of draft-ietf-v6ops-onlinkassumption-03.txt > > I was selected as General Area Review Team reviewer for this > specification (for background on Gen-ART, please see http:// > www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Summary: this specification is headed the right direction for > publication as an Informational RFC, but still needs some work in a > couple of places that were confusing to me (and I thought I > understood the topic). > > Comments: > > If I understand this document correctly, it's telling me that the > on-link assumption was put in place to allow communication between > two hosts with different global prefixes in the absence of an IPv6 > router, and that this assumption causes problems (see section 3 for > details), so the assumption should be removed (see section 4 for > details). Right so far? Stop me now, or ... > > - The specification is arguing for the removal of the assumption, > but doesn't ever actually say whether we just don't care any more > about communications in the absence of an IPv6 router when two > hosts with different global prefixes are on the same link, or if > there is some other mechanism that now allows this communication to > succeed without the assumption. I think I know what actually > happens, but I'm guessing. I'd just like to see this spelled out a > bit more clearly. > > - Section 3.3 is a lot less clear than the other parts of section > 3. It wasn't clear to me whether dropping the packet is actual > behavior in deployed hosts or not, and I wasn't sure whether > dropping the assumption fixed all the problems with multiple links > (I think it does, but I'm reading between the lines). I suspect > that the problem is that, in the absence of one defined behavior, > you're trying to describe multiple problems at once, but Section > 3.3 is still confusing (that's why I'm not sure I can suggest > replacement text, beyond, "There are three things that an > implementation can do with a packet when faced with multiple > interfaces and the on-link assumption, and all of them are bad, and > only the most complex action is likely to work even most of the > time" - is that the point?) > > - In section 5, I'm guessing you are telling me that the removal of > the assumption "removes all of the security-related vulnerabilities > of the protocol as described in Section 3.4", but the current text > says "removes some vulnerabilities as described", and "some" is > ambiguous. > > Minor nits: > > - It bothers me that an observed implementation error is used in > Section 3.4 to justify changing the protocol. I understand the > problem, but OS implementations may be broken in lots of ways, > right? Probably doesn't matter because there are so many other > justifications, but... > > - Since RFC 1122 is, like, 116 pages long, it would be nice to > include the section number (4.2.3.5) in the reference at the bottom > of page 4. > > I hope this is helpful - most of the text is very clear, but there > are just some places that faded out on me. > > Thanks, > > Spencer From owner-v6ops@ops.ietf.org Tue Dec 13 12:00:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmDVk-0000ld-Pp for v6ops-archive@megatron.ietf.org; Tue, 13 Dec 2005 12:00:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20647 for ; Tue, 13 Dec 2005 11:59:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmDTD-000Pr8-IH for v6ops-data@psg.com; Tue, 13 Dec 2005 16:57:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmDTC-000Pqs-5y for v6ops@ops.ietf.org; Tue, 13 Dec 2005 16:57:42 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2005 08:57:32 -0800 X-IronPort-AV: i="3.99,248,1131350400"; d="scan'208"; a="377668277:sNHT3226958288" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBDGvU70026977 for ; Tue, 13 Dec 2005 08:57:30 -0800 (PST) Received: from [10.31.146.93] (ams-clip-vpn-dhcp444.cisco.com [10.61.65.188]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jBDH4B7v008362 for ; Tue, 13 Dec 2005 09:04:31 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) References: <439ED8B8.70201@dial.pipex.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51E421D2-346F-4B7A-85D8-C0CC1CB42B1A@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Fwd: Gen-art review of draft-ietf-v6ops-vlan-usage-00.txt Date: Tue, 13 Dec 2005 17:57:29 +0100 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1473; t=1134493471; x=1134925671; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Fwd=3A=20Gen-art=20review=20of=20draft-ietf-v6ops-vlan-usage-00.txt| From:Fred=20Baker=20| Date:Tue,=2013=20Dec=202005=2017=3A57=3A29=20+0100| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=V15Zl66GxXWhmLINDPYqzTT1YeF3c+ZlVKk6tyCt9YCBN/Aw+J7edEExwO2ApMF+HoBylb+p BHmoDH3Lvde0IweTWesA4axitYI7mzTVuDaJjDLjBfh1qnATzVh7TD6n6MNZiq0atu9XytWu9qm jn9AmZTxDqyMI2FodE4RaSbA= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Elwyn Davies > Date: December 13, 2005 3:20:40 PM CEST > To: gen-art@ietf.org > Cc: Mary Barnes , Fred Baker > , Tim Chown , David Kessens > > Subject: Gen-art review of draft-ietf-v6ops-vlan-usage-00.txt > > I was selected as General Area Review Team reviewer for this > specification > (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Document: draft-ietf-v6ops-vlan-usage-00 > Intended Status: Informational > Shepherding AD: David Kessens > Proto shepherd: Fred Baker > Review Trigger: IESG Telechat, 12 December 2005 > > Summary: > This document is essentially ready for Informational. > > There are a couple of editorial nits and I have suggested a small > number of editorial improvements below. > > Editorial: > s1, para 6: s/provided a/provided by a/ > > s1, last para: s/sites who/sites that/ > > s2.2, para 1: I think that 'BSD-based' could be removed - I think > the idea was that a standard PC rather than a dedicated router > could be used but that doesn't really matter here and if not you > ought to expand the acronym BSD. > > s2.2, para 1: The phrase '/64 size links' is a bit colloquial. How > about 'stub links using 64 bit subnet prefixes' > > s2.3, para 2: s/while IPv6/while the IPv6/ > > s2.5: Might be good to remind people that the VLAN tag is 16 bits > so that this can work with a 'usual' maximum 48 bit site prefix > > App A, para 1: s/for BSD/using a computer running the FreeBSD > variant of the Berkeley Software Distribution (BSD) operating > system as a router/ > > App A: In the configuration s/#Router advs/# Router advertisements/ From owner-v6ops@ops.ietf.org Thu Dec 15 06:33:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmrM6-0005LD-FR for v6ops-archive@megatron.ietf.org; Thu, 15 Dec 2005 06:33:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22415 for ; Thu, 15 Dec 2005 06:31:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmrIA-000GgB-Jj for v6ops-data@psg.com; Thu, 15 Dec 2005 11:28:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmrI8-000Gfq-1h for v6ops@ops.ietf.org; Thu, 15 Dec 2005 11:28:56 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id A9EA417A64; Thu, 15 Dec 2005 12:28:54 +0100 (CET) Date: Thu, 15 Dec 2005 12:28:54 +0100 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices Message-ID: <20051215112854.GA32690@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 29, 2005 at 02:47:37PM -0500, Dwight Jamieson wrote: > In the absence of mature protocol support for site multi-homing (shim6), shim6 is not a site multihoming protocol, and that's the one of the biggest problems of it. shim6 is (supposed to be) host multihoming. > what are the best practice recommendations for an enterprise or service > provider? Use BGP for what it was designed. To connect autonomous systems in the routing domain. There is no alternative yet, and none in sight. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From owner-v6ops@ops.ietf.org Fri Dec 16 04:29:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnBtb-0005VQ-8B for v6ops-archive@megatron.ietf.org; Fri, 16 Dec 2005 04:29:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22056 for ; Fri, 16 Dec 2005 04:27:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnBqV-000PXn-TW for v6ops-data@psg.com; Fri, 16 Dec 2005 09:25:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnBqS-000PXQ-AZ for v6ops@ops.ietf.org; Fri, 16 Dec 2005 09:25:44 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id jBG9Ovec130398 for ; Fri, 16 Dec 2005 09:25:01 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBG9Ovgi235726 for ; Fri, 16 Dec 2005 10:24:57 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jBG9OvXF031891 for ; Fri, 16 Dec 2005 10:24:57 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jBG9Oumb031874; Fri, 16 Dec 2005 10:24:57 +0100 Received: from zurich.ibm.com (sig-9-145-129-125.de.ibm.com [9.145.129.125]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA51838; Fri, 16 Dec 2005 10:24:55 +0100 Message-ID: <43A287E3.1060109@zurich.ibm.com> Date: Fri, 16 Dec 2005 10:24:51 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Daniel Roesen CC: v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices References: <20051215112854.GA32690@srv01.cluenet.de> In-Reply-To: <20051215112854.GA32690@srv01.cluenet.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Roesen wrote: > On Tue, Nov 29, 2005 at 02:47:37PM -0500, Dwight Jamieson wrote: > >>In the absence of mature protocol support for site multi-homing (shim6), > > > shim6 is not a site multihoming protocol, and that's the one of the > biggest problems of it. shim6 is (supposed to be) host multihoming. Actually, it is supposed to be for hosts inside multihomed sites, and I would maintain that it *is* a site multihoming solution, but implemented in the host TCP/IP stack. But it isn't yet fully specified and deployed, so naturally there are not yet best practice recommendations. We know that its interaction with traffic engineering practices still has to be defined. However, that discussion belongs over in shim6. >>what are the best practice recommendations for an enterprise or service >>provider? > > > Use BGP for what it was designed. To connect autonomous systems in the > routing domain. There is no alternative yet, and none in sight. We know that doesn't scale, and that was the reason the multi6 WG existed and why we converged on a scaleable solution. But if you need to multihome an IPv6 site today, well, yes, you probably have to use the techniques described for IPv4 in RFC 4116. Just don't expect that to work in a 10 billion node network. Brian From owner-v6ops@ops.ietf.org Fri Dec 16 10:38:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnHfW-0002aA-MJ for v6ops-archive@megatron.ietf.org; Fri, 16 Dec 2005 10:38:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05908 for ; Fri, 16 Dec 2005 10:37:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnHc2-0008Vd-Ax for v6ops-data@psg.com; Fri, 16 Dec 2005 15:35:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnHc0-0008VN-Cw for v6ops@ops.ietf.org; Fri, 16 Dec 2005 15:35:12 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBGFZ3o29539; Fri, 16 Dec 2005 10:35:03 -0500 (EST) 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: V6ops: IPv6 site multihoming best practices Date: Fri, 16 Dec 2005 10:34:43 -0500 Message-ID: Thread-Topic: V6ops: IPv6 site multihoming best practices Thread-Index: AcYCJ4qWfEIcuRpTRoiMtp7Xwcu8hwALGrEg From: "Dwight Jamieson" To: "Brian E Carpenter" Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, I am a member of the ATIS IPv6 task force. http://www.atis.org/ The task force is developing IPv6 transition and deployment recommendations targeted mainly at ATIS' Telco members.=20 Due to the reasons you mentioned, I didn't think the deployment strategies outlined in RFC4116 should be recommended to service providers for site multi-homing. Earlier in this thread, Janos Mohacsi suggested using the procedures outlined in RFC3178. Do you see this as a viable option to recommend? Cheers, Dwight -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, December 16, 2005 4:25 AM To: Daniel Roesen Cc: v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices Daniel Roesen wrote: > On Tue, Nov 29, 2005 at 02:47:37PM -0500, Dwight Jamieson wrote: >=20 >>In the absence of mature protocol support for site multi-homing=20 >>(shim6), >=20 >=20 > shim6 is not a site multihoming protocol, and that's the one of the=20 > biggest problems of it. shim6 is (supposed to be) host multihoming. Actually, it is supposed to be for hosts inside multihomed sites, and I would maintain that it *is* a site multihoming solution, but implemented in the host TCP/IP stack. But it isn't yet fully specified and deployed, so naturally there are not yet best practice recommendations. We know that its interaction with traffic engineering practices still has to be defined. However, that discussion belongs over in shim6. >>what are the best practice recommendations for an enterprise or=20 >>service provider? >=20 >=20 > Use BGP for what it was designed. To connect autonomous systems in the > routing domain. There is no alternative yet, and none in sight. We know that doesn't scale, and that was the reason the multi6 WG existed and why we converged on a scaleable solution. But if you need to multihome an IPv6 site today, well, yes, you probably have to use the techniques described for IPv4 in RFC 4116. Just don't expect that to work in a 10 billion node network. Brian From owner-v6ops@ops.ietf.org Fri Dec 16 11:21:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnIL5-0007DK-5G for v6ops-archive@megatron.ietf.org; Fri, 16 Dec 2005 11:21:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10620 for ; Fri, 16 Dec 2005 11:20:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnIKJ-000OSG-8z for v6ops-data@psg.com; Fri, 16 Dec 2005 16:20:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnIKH-000ORw-Sp for v6ops@ops.ietf.org; Fri, 16 Dec 2005 16:20:58 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id jBGGKtLs188324 for ; Fri, 16 Dec 2005 16:20:55 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBGGKtgi225120 for ; Fri, 16 Dec 2005 17:20:55 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jBGGKtt9020120 for ; Fri, 16 Dec 2005 17:20:55 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jBGGKsn9020113; Fri, 16 Dec 2005 17:20:55 +0100 Received: from zurich.ibm.com (sig-9-145-129-125.de.ibm.com [9.145.129.125]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA42814; Fri, 16 Dec 2005 17:20:53 +0100 Message-ID: <43A2E963.1090709@zurich.ibm.com> Date: Fri, 16 Dec 2005 17:20:51 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Dwight Jamieson CC: v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA10620 Dwight, here is a sequence of discussion from old multi6 list. As you can see, it isn't clear that 3178 really meets all needs. Brian -------- Original Message -------- Subject: RFC 3178 mh (was Re: I-D ACTION:draft-huston-multi6-architecture= s-00.txt) Date: Mon, 24 May 2004 11:38:06 +0200 From: marcelo bagnulo braun To: Pekka Savola CC: Multi6 List References: Hi Pekka, A couple of questions about RFC 3178 multihoming... El 20/05/2004, a las 10:21, Pekka Savola escribi=F3: > [...] > However, this draft does not > address another major drawback of the RFC 3178 approach, that > it does not protect against the complete failure of one or > more > connected ISPs. > > =3D=3D> I think this is something where one should make a reality chec= k. > How often is it that the _whole_ ISP fails? Pretty much _never_, IMHO the problem is that RFC 3178 multihoming situation not only fails when the complete ISP fails, but it also fails when - one of the access routers of the ISPs fail, - one of the exit routers of the site fail - one of the links between the ISPs and their upstream provider fail While i agree that probably the complete failure of the ISP may be a low probability event, i guess that the above mentioned events may be more common. The other reality check that i would like to do is how common is RFC 3178? if it is not very common, what do you think are the reasons for its non adoption? Regards, marcelo > > unless you count 1-man small ISPs which don't even have redundant > connectivity and routers (and we shouldn't care about this). -------- Original Message -------- Subject: Re: RFC 3178 mh (was Re: I-D ACTION:draft-huston-multi6-architec= tures-00.txt) Date: Mon, 24 May 2004 12:45:32 +0300 (EEST) From: Pekka Savola To: marcelo bagnulo braun CC: Multi6 List On Mon, 24 May 2004, marcelo bagnulo braun wrote: > El 20/05/2004, a las 10:21, Pekka Savola escribi=F3: > > > [...] > > However, this draft does not > > address another major drawback of the RFC 3178 approach, th= at > > it does not protect against the complete failure of one or > > more > > connected ISPs. > > > > =3D=3D> I think this is something where one should make a reality ch= eck. > > How often is it that the _whole_ ISP fails? Pretty much _never_, > > IMHO the problem is that RFC 3178 multihoming situation not only fails > when the complete ISP fails, but it also fails when > - one of the access routers of the ISPs fail, > - one of the exit routers of the site fail > - one of the links between the ISPs and their upstream provider fail > > While i agree that probably the complete failure of the ISP may be a > low probability event, i guess that the above mentioned events may be > more common. No, this is definitely not the case. The first two bullet points are only valid if site site does not have tunnels to from the other exit routers to the other ISPs (or the tunnel is terminated at the ISP to the same router as the physical link), right? The third point is only valid if the ISP has only one link to an upstream provider -- and no self-respecting ISP has only one upstream link. > The other reality check that i would like to do is how common is RFC > 3178? if it is not very common, what do you think are the reasons for > its non adoption? True enough. I don't think there is sufficient evidence to make conclusions of this, as the number of v6-enabled enterprises which don't have IPv6 /32 prefixes (but which multihome w/ v4) is very low..? --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------- Original Message -------- Subject: Re: RFC 3178 mh (was Re: I-D ACTION:draft-huston-multi6-architec= tures-00.txt) Date: Mon, 24 May 2004 12:22:54 +0200 From: marcelo bagnulo braun To: Pekka Savola CC: Multi6 List References: >> >> IMHO the problem is that RFC 3178 multihoming situation not only fail= s >> when the complete ISP fails, but it also fails when >> - one of the access routers of the ISPs fail, >> - one of the exit routers of the site fail >> - one of the links between the ISPs and their upstream provider fail >> >> While i agree that probably the complete failure of the ISP may be a >> low probability event, i guess that the above mentioned events may be >> more common. > > No, this is definitely not the case. The first two bullet points are > only valid if site site does not have tunnels to from the other exit > routers to the other ISPs (or the tunnel is terminated at the ISP to > the same router as the physical link), right? Well, this is possible but this is not described in RFC 3178 and it imposes additional configuration, for instance of the IGP of the ISP. But i agree that it is possible to support this configuration, with some added complexity. My point was aimed to identify another possible cause for the non success of this solution, which could be related to operational complexity? I mean, tunnel management, and added features like the support for additional failure modes may require additional manual configuration, which may make the solution less attractive. > The third point is only > valid if the ISP has only one link to an upstream provider -- and no > self-respecting ISP has only one upstream link. > Well, you are assuming that very small sites will obtain its own address block from the RIR, which may not hold, i guess >> The other reality check that i would like to do is how common is RFC >> 3178? if it is not very common, what do you think are the reasons for >> its non adoption? > > True enough. I don't think there is sufficient evidence to make > conclusions of this, as the number of v6-enabled enterprises which > don't have IPv6 /32 prefixes (but which multihome w/ v4) is very > low..? Well, i guess this is an important issue to understand, since if rfc 3178 multihoming is enough for some small sites (for instance), the new solution should be focused to satisfy the needs of the remaining sites (medium/big) sites, and the scalability required may be different. In other words, understanding the reasons why rfc 3178 is not a good option may provide us good information for the design of the new solution, especially w.r.t to deployability. regards, marcelo Dwight Jamieson wrote: > Brian, >=20 > I am a member of the ATIS IPv6 task force. http://www.atis.org/ >=20 > The task force is developing IPv6 transition and deployment > recommendations targeted mainly at ATIS' Telco members.=20 >=20 > Due to the reasons you mentioned, I didn't think the deployment > strategies outlined in RFC4116 should be recommended to service > providers for site multi-homing. >=20 > Earlier in this thread, Janos Mohacsi suggested using the procedures > outlined in RFC3178. Do you see this as a viable option to recommend? >=20 > Cheers, > Dwight >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Brian E Carpenter > Sent: Friday, December 16, 2005 4:25 AM > To: Daniel Roesen > Cc: v6ops@ops.ietf.org > Subject: Re: V6ops: IPv6 site multihoming best practices >=20 >=20 > Daniel Roesen wrote: >=20 >>On Tue, Nov 29, 2005 at 02:47:37PM -0500, Dwight Jamieson wrote: >> >> >>>In the absence of mature protocol support for site multi-homing=20 >>>(shim6), >> >> >>shim6 is not a site multihoming protocol, and that's the one of the=20 >>biggest problems of it. shim6 is (supposed to be) host multihoming. >=20 >=20 > Actually, it is supposed to be for hosts inside multihomed sites, and I > would maintain that it *is* a site multihoming solution, but implemente= d > in the host TCP/IP stack. But it isn't yet fully specified and deployed= , > so naturally there are not yet best practice recommendations. We know > that its interaction with traffic engineering practices still has to be > defined. >=20 > However, that discussion belongs over in shim6. >=20 >=20 >>>what are the best practice recommendations for an enterprise or=20 >>>service provider? >> >> >>Use BGP for what it was designed. To connect autonomous systems in the >=20 >=20 >>routing domain. There is no alternative yet, and none in sight. >=20 >=20 > We know that doesn't scale, and that was the reason the multi6 WG > existed and why we converged on a scaleable solution. But if you need t= o > multihome an IPv6 site today, well, yes, you probably have to use the > techniques described for IPv4 in RFC 4116. Just don't expect that to > work in a 10 billion node network. >=20 > Brian >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Dec 16 14:07:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnKvO-0002vp-W7 for v6ops-archive@megatron.ietf.org; Fri, 16 Dec 2005 14:07:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01860 for ; Fri, 16 Dec 2005 14:06:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnKsf-000ALJ-5f for v6ops-data@psg.com; Fri, 16 Dec 2005 19:04:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnKsd-000AL3-Bx for v6ops@ops.ietf.org; Fri, 16 Dec 2005 19:04:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jBGJ4Kp12304; Fri, 16 Dec 2005 21:04:21 +0200 Date: Fri, 16 Dec 2005 21:04:20 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Dwight Jamieson , v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices In-Reply-To: <43A2E963.1090709@zurich.ibm.com> Message-ID: References: <43A2E963.1090709@zurich.ibm.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-604668325-1134759860=:11968" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-604668325-1134759860=:11968 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA01860 On Fri, 16 Dec 2005, Brian E Carpenter wrote: > Dwight, here is a sequence of discussion from old multi6 list. > As you can see, it isn't clear that 3178 really meets all > needs. Brian, I think the two important needs we should see from that=20 discussion: 1) "RFC 3178 might be too complex to set up or use" (operational=20 complexity of tunnels, tunnel overhead, etc.) 2) folks want independence, i.e., PI addresses Shim6 doesn't meet the need 2) either, while it may help a bit with=20 1). I don't know if 1) would be too big of a hurdle if folks didn't=20 need to consider 2). > -------- Original Message -------- > Subject: RFC 3178 mh (was Re: I-D=20 > ACTION:draft-huston-multi6-architectures-00.txt) > Date: Mon, 24 May 2004 11:38:06 +0200 > From: marcelo bagnulo braun > To: Pekka Savola > CC: Multi6 List > References: > > Hi Pekka, > > A couple of questions about RFC 3178 multihoming... > > El 20/05/2004, a las 10:21, Pekka Savola escribi=F3: >> > [...] >> However, this draft does not >> address another major drawback of the RFC 3178 approach, that >> it does not protect against the complete failure of one or >> more >> connected ISPs. >> >> =3D=3D> I think this is something where one should make a reality chec= k. >> How often is it that the _whole_ ISP fails? Pretty much _never_, > > IMHO the problem is that RFC 3178 multihoming situation not only fails > when the complete ISP fails, but it also fails when > - one of the access routers of the ISPs fail, > - one of the exit routers of the site fail > - one of the links between the ISPs and their upstream provider fail > > While i agree that probably the complete failure of the ISP may be a > low probability event, i guess that the above mentioned events may be > more common. > > The other reality check that i would like to do is how common is RFC > 3178? if it is not very common, what do you think are the reasons for > its non adoption? > > Regards, marcelo > >> >> unless you count 1-man small ISPs which don't even have redundant >> connectivity and routers (and we shouldn't care about this). > > -------- Original Message -------- > Subject: Re: RFC 3178 mh (was Re: I-D=20 > ACTION:draft-huston-multi6-architectures-00.txt) > Date: Mon, 24 May 2004 12:45:32 +0300 (EEST) > From: Pekka Savola > To: marcelo bagnulo braun > CC: Multi6 List > > On Mon, 24 May 2004, marcelo bagnulo braun wrote: >> El 20/05/2004, a las 10:21, Pekka Savola escribi=F3: >> > >> [...] >> > However, this draft does not >> > address another major drawback of the RFC 3178 approach, th= at >> > it does not protect against the complete failure of one or >> > more >> > connected ISPs. >> > >> > =3D=3D> I think this is something where one should make a reality ch= eck. >> > How often is it that the _whole_ ISP fails? Pretty much _never_, >> >> IMHO the problem is that RFC 3178 multihoming situation not only fails >> when the complete ISP fails, but it also fails when >> - one of the access routers of the ISPs fail, >> - one of the exit routers of the site fail >> - one of the links between the ISPs and their upstream provider fail >> >> While i agree that probably the complete failure of the ISP may be a >> low probability event, i guess that the above mentioned events may be >> more common. > > No, this is definitely not the case. The first two bullet points are > only valid if site site does not have tunnels to from the other exit > routers to the other ISPs (or the tunnel is terminated at the ISP to > the same router as the physical link), right? The third point is only > valid if the ISP has only one link to an upstream provider -- and no > self-respecting ISP has only one upstream link. > >> The other reality check that i would like to do is how common is RFC >> 3178? if it is not very common, what do you think are the reasons for >> its non adoption? > > True enough. I don't think there is sufficient evidence to make > conclusions of this, as the number of v6-enabled enterprises which > don't have IPv6 /32 prefixes (but which multihome w/ v4) is very > low..? > > --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-604668325-1134759860=3D:11968-- --1589707168-604668325-1134759860=:11968-- From mailer_rp@mdb.mailyes.net Sat Dec 17 08:20:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enbz9-0007fT-1B for v6ops-archive@megatron.ietf.org; Sat, 17 Dec 2005 08:20:27 -0500 Received: from m16.mailyes.net ([125.187.32.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23542 for ; Sat, 17 Dec 2005 08:19:22 -0500 (EST) Received: (qmail 5891 invoked by uid 0); 17 Dec 2005 21:27:02 +0900 Message-ID: <20051217122702.5890.qmail@m16.mailyes.net> To: v6ops-archive Subject: =?ISO-2022-JP?B?GyRCJDwhQSRzJFYhIiU/JUAbKEI=?= =?ISO-2022-JP?B?GyRCJEAkaCJ2GyhCKF5eKXYbJEJCKDdoGyhC?= From: "minako1919@hotmail.co.jp" Reply-to: delivery_rt Date: 2005-12-17 20:25:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20051217_2000_44st Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit その名の通り完全無料で直電交換＆直電閲覧ができるよん♪ http://www.awg5.net/?ts1 メールでダラダラする必要無し！ ☆電話で即決だから間違い無し！ ☆もちろんメールを読むのも送るのも完全無料♪ ☆メールにするも良し！電話にするも良し！貴方次第でどうにでもしてね♪ http://www.awg5.net/?ts1 ☆┌──┐☆┌──┐☆┌──┐☆┌──┐☆┌──┐☆ ★│素人│★│人妻│★│逆援│★│学生│★│ＳＭ│★ ☆└──┘☆└──┘☆└──┘☆└──┘☆└──┘☆ 　 お好きなジャンルでどうぞぉ〜〜v(*^^*)vでも早いもの勝ちだよん☆ From owner-v6ops@ops.ietf.org Sun Dec 18 09:06:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnzBD-0001vX-GO for v6ops-archive@megatron.ietf.org; Sun, 18 Dec 2005 09:06:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13821 for ; Sun, 18 Dec 2005 09:05:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Enz7a-000CFd-OO for v6ops-data@psg.com; Sun, 18 Dec 2005 14:02:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Enz7Z-000CF9-NN for v6ops@ops.ietf.org; Sun, 18 Dec 2005 14:02:42 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id jBIE2bBN149654 for ; Sun, 18 Dec 2005 14:02:37 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBIE2aCT215270 for ; Sun, 18 Dec 2005 15:02:36 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jBIE2ajm026125 for ; Sun, 18 Dec 2005 15:02:36 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jBIE2Z5S026122; Sun, 18 Dec 2005 15:02:35 +0100 Received: from zurich.ibm.com (sig-9-145-133-216.de.ibm.com [9.145.133.216]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA36520; Sun, 18 Dec 2005 15:02:34 +0100 Message-ID: <43A56BF7.4080401@zurich.ibm.com> Date: Sun, 18 Dec 2005 15:02:31 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: Dwight Jamieson , v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices References: <43A2E963.1090709@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 16 Dec 2005, Brian E Carpenter wrote: > >> Dwight, here is a sequence of discussion from old multi6 list. >> As you can see, it isn't clear that 3178 really meets all >> needs. > > > Brian, I think the two important needs we should see from that discussion: > > 1) "RFC 3178 might be too complex to set up or use" (operational > complexity of tunnels, tunnel overhead, etc.) > > 2) folks want independence, i.e., PI addresses > > Shim6 doesn't meet the need 2) either, while it may help a bit with 1). > I don't know if 1) would be too big of a hurdle if folks didn't need to > consider 2). Independence of what? With agile multihoming, you don't need your prefix to be independent of your ISP; the argument is circular. If you want stable internal addressing, you can use an SLA prefix. Brian From owner-v6ops@ops.ietf.org Sun Dec 18 11:45:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo1fQ-0006EV-RE for v6ops-archive@megatron.ietf.org; Sun, 18 Dec 2005 11:45:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28574 for ; Sun, 18 Dec 2005 11:44:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eo1dU-000CRb-2V for v6ops-data@psg.com; Sun, 18 Dec 2005 16:43:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eo1dS-000CMc-RC for v6ops@ops.ietf.org; Sun, 18 Dec 2005 16:43:47 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jBIGfEIV025299; Sun, 18 Dec 2005 16:41:34 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jBIGdNug025293; Sun, 18 Dec 2005 16:39:23 GMT Date: Sun, 18 Dec 2005 16:39:18 +0000 From: bmanning@vacation.karoshi.com To: Brian E Carpenter Cc: Pekka Savola , Dwight Jamieson , v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices Message-ID: <20051218163918.GA25194@vacation.karoshi.com.> References: <43A2E963.1090709@zurich.ibm.com> <43A56BF7.4080401@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A56BF7.4080401@zurich.ibm.com> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, Dec 18, 2005 at 03:02:31PM +0100, Brian E Carpenter wrote: > Pekka Savola wrote: > >On Fri, 16 Dec 2005, Brian E Carpenter wrote: > > > >>Dwight, here is a sequence of discussion from old multi6 list. > >>As you can see, it isn't clear that 3178 really meets all > >>needs. > > > > > >Brian, I think the two important needs we should see from that discussion: > > > > 1) "RFC 3178 might be too complex to set up or use" (operational > >complexity of tunnels, tunnel overhead, etc.) > > > > 2) folks want independence, i.e., PI addresses > > > >Shim6 doesn't meet the need 2) either, while it may help a bit with 1). > >I don't know if 1) would be too big of a hurdle if folks didn't need to > >consider 2). > > Independence of what? With agile multihoming, you don't need your > prefix to be independent of your ISP; the argument is circular. > If you want stable internal addressing, you can use an SLA prefix. perhaps, just perhaps, independence is only one aspect ofthe concern. there is also the desire to have a persistant and consistant identifier for SNMP, AAA, RADIUS, SYSLOG, etc. and nearly all the renumbering or "agile multihoming" proposals to date do NOT meet the requirements to use these types of tools. the more metaphysical discussion about creating a subordinate reduced functionality class, walled gardens, and captive rate payers, as fundamental attributes of the Internet of the 21st century as distinctly different than the "level playing field" of the Internet of the 20th century will be left to other threads. --bill > > Brian > From owner-v6ops@ops.ietf.org Mon Dec 19 03:43:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoGcc-00019H-SX for v6ops-archive@megatron.ietf.org; Mon, 19 Dec 2005 03:43:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08302 for ; Mon, 19 Dec 2005 03:42:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoGZi-000O1x-H1 for v6ops-data@psg.com; Mon, 19 Dec 2005 08:40:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoGZf-000Np9-MX for v6ops@ops.ietf.org; Mon, 19 Dec 2005 08:40:52 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id D58F155B2; Mon, 19 Dec 2005 09:40:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id D200455AB; Mon, 19 Dec 2005 09:40:49 +0100 (CET) Date: Mon, 19 Dec 2005 09:40:49 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Pekka Savola Cc: Brian E Carpenter , Dwight Jamieson , v6ops@ops.ietf.org Subject: Re: V6ops: IPv6 site multihoming best practices In-Reply-To: Message-ID: <20051219093251.B9406@mignon.ki.iif.hu> References: <43A2E963.1090709@zurich.ibm.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-24236626-1134981645=:9406" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-24236626-1134981645=:9406 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Dec 2005, Pekka Savola wrote: > On Fri, 16 Dec 2005, Brian E Carpenter wrote: >> Dwight, here is a sequence of discussion from old multi6 list. >> As you can see, it isn't clear that 3178 really meets all >> needs. > > Brian, I think the two important needs we should see from that discussion= : > > 1) "RFC 3178 might be too complex to set up or use" (operational complexi= ty=20 > of tunnels, tunnel overhead, etc.) > In my opinion setting up a tunnel not so complex. It is fact of life in=20 IPv6 Internet (and also in VPNs). The overhead and management of tunnels=20 is not very good, however RFC 3178 is an attractive solution: You allocated prefix (e.g. /48) is "virtually provider independent" until= =20 your allocating ISP is in business and has an IPv4 connectivity with your= =20 other Internet providers. And also gives time to shim6 to be deployed which requires signifact=20 changes in operating systems...... Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > 2) folks want independence, i.e., PI addresses > > Shim6 doesn't meet the need 2) either, while it may help a bit with 1). = I=20 > don't know if 1) would be too big of a hurdle if folks didn't need to=20 > consider 2). > >> -------- Original Message -------- >> Subject: RFC 3178 mh (was Re: I-D=20 >> ACTION:draft-huston-multi6-architectures-00.txt) >> Date: Mon, 24 May 2004 11:38:06 +0200 >> From: marcelo bagnulo braun >> To: Pekka Savola >> CC: Multi6 List >> References: >>=20 >> Hi Pekka, >>=20 >> A couple of questions about RFC 3178 multihoming... >>=20 >> El 20/05/2004, a las 10:21, Pekka Savola escribi=F3: >>>=20 >> [...] >>> However, this draft does not >>> address another major drawback of the RFC 3178 approach, that >>> it does not protect against the complete failure of one or >>> more >>> connected ISPs. >>>=20 >>> =3D=3D> I think this is something where one should make a reality check= =2E >>> How often is it that the _whole_ ISP fails? Pretty much _never_, >>=20 >> IMHO the problem is that RFC 3178 multihoming situation not only fails >> when the complete ISP fails, but it also fails when >> - one of the access routers of the ISPs fail, >> - one of the exit routers of the site fail >> - one of the links between the ISPs and their upstream provider fail >>=20 >> While i agree that probably the complete failure of the ISP may be a >> low probability event, i guess that the above mentioned events may be >> more common. >>=20 >> The other reality check that i would like to do is how common is RFC >> 3178? if it is not very common, what do you think are the reasons for >> its non adoption? >>=20 >> Regards, marcelo >>=20 >>>=20 >>> unless you count 1-man small ISPs which don't even have redundant >>> connectivity and routers (and we shouldn't care about this). >>=20 >> -------- Original Message -------- >> Subject: Re: RFC 3178 mh (was Re: I-D=20 >> ACTION:draft-huston-multi6-architectures-00.txt) >> Date: Mon, 24 May 2004 12:45:32 +0300 (EEST) >> From: Pekka Savola >> To: marcelo bagnulo braun >> CC: Multi6 List >>=20 >> On Mon, 24 May 2004, marcelo bagnulo braun wrote: >>> El 20/05/2004, a las 10:21, Pekka Savola escribi=F3: >>> > >>> [...] >>> > However, this draft does not >>> > address another major drawback of the RFC 3178 approach, tha= t >>> > it does not protect against the complete failure of one or >>> > more >>> > connected ISPs. >>> > >>> > =3D=3D> I think this is something where one should make a reality che= ck. >>> > How often is it that the _whole_ ISP fails? Pretty much _never_, >>>=20 >>> IMHO the problem is that RFC 3178 multihoming situation not only fails >>> when the complete ISP fails, but it also fails when >>> - one of the access routers of the ISPs fail, >>> - one of the exit routers of the site fail >>> - one of the links between the ISPs and their upstream provider fail >>>=20 >>> While i agree that probably the complete failure of the ISP may be a >>> low probability event, i guess that the above mentioned events may be >>> more common. >>=20 >> No, this is definitely not the case. The first two bullet points are >> only valid if site site does not have tunnels to from the other exit >> routers to the other ISPs (or the tunnel is terminated at the ISP to >> the same router as the physical link), right? The third point is only >> valid if the ISP has only one link to an upstream provider -- and no >> self-respecting ISP has only one upstream link. >>=20 >>> The other reality check that i would like to do is how common is RFC >>> 3178? if it is not very common, what do you think are the reasons for >>> its non adoption? >>=20 >> True enough. I don't think there is sufficient evidence to make >> conclusions of this, as the number of v6-enabled enterprises which >> don't have IPv6 /32 prefixes (but which multihome w/ v4) is very >> low..? >>=20 >>=20 > > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --0-24236626-1134981645=:9406-- From huey@access-one.com Mon Dec 19 05:47:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoIYY-0006V0-FK for v6ops-archive@megatron.ietf.org; Mon, 19 Dec 2005 05:47:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23971 for ; Mon, 19 Dec 2005 05:46:48 -0500 (EST) Received: from [211.48.122.173] (helo=211.48.122.173) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EoIah-0007jN-1o for v6ops-archive@ietf.org; Mon, 19 Dec 2005 05:50:07 -0500 Message-ID: <6d0b01c60487$9d9db337$bfea9627@access-one.com> From: "Steven A. Norman" To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?VklQIHdhdGNoZXMgLSBMT1cgcHJpY2Uh?= Date: Mon, 19 Dec 2005 10:30:45 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_4BC93B20.7EEE86A8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_4BC93B20.7EEE86A8 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_15B8CC74.07DD6F13" ------=_NextPart_001_0001_15B8CC74.07DD6F13 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit TRUE COPIES OF SWISS WATCHES - exact copies of V.I.P. watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Bvlgari, Franck Muller .. and 15 other most famous manufacturers. http://www.watches-for-people.com All watches are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_15B8CC74.07DD6F13 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
TRUE COPIES OF SWISS WATCHES

- exact copies of V.I.P. watches
- perfect as a gift for your colleagues and friends
- free gift box

Rolex, Patek Philippe, Omega
Cartier, Bvlgari, Franck Muller

.. and 15 other most famous manufacturers.

http://www.watches-for-people.com

All watches are for only $239.95 - $279.95!


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_15B8CC74.07DD6F13-- ------=_NextPart_000_0000_4BC93B20.7EEE86A8-- From mailer_rp@mdb.mailyes.net Thu Dec 22 15:54:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpXSa-0006ES-Iq for v6ops-archive@megatron.ietf.org; Thu, 22 Dec 2005 15:54:48 -0500 Received: from m03.mailyes.net ([125.187.32.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02746 for ; Thu, 22 Dec 2005 15:53:41 -0500 (EST) Received: (qmail 31879 invoked by uid 0); 23 Dec 2005 05:49:40 +0900 Message-ID: <20051222204940.31878.qmail@m03.mailyes.net> To: v6ops-archive Subject: =?ISO-2022-JP?B?GyRCJDwhQSRzJFYhIiU/JUAbKEI=?= =?ISO-2022-JP?B?GyRCJEAkaCJ2GyhCKF5eKXYbJEJCKDdoGyhC?= From: "minako1919@hotmail.co.jp" Reply-to: delivery_rt Date: 2005-12-23 04:45:02 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20051223_0440_a44ts Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit その名の通り完全無料で直電交換＆直電閲覧ができるよん♪ http://www.awg5.net/?ts1 メールでダラダラする必要無し！ ☆電話で即決だから間違い無し！ ☆もちろんメールを読むのも送るのも完全無料♪ ☆メールにするも良し！電話にするも良し！貴方次第でどうにでもしてね♪ http://www.awg5.net/?ts1 ☆┌──┐☆┌──┐☆┌──┐☆┌──┐☆┌──┐☆ ★│素人│★│人妻│★│逆援│★│学生│★│ＳＭ│★ ☆└──┘☆└──┘☆└──┘☆└──┘☆└──┘☆ 　 お好きなジャンルでどうぞぉ〜〜v(*^^*)vでも早いもの勝ちだよん☆ From owner-v6ops@ops.ietf.org Mon Dec 26 00:15:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqkhr-0007Qy-QY for v6ops-archive@megatron.ietf.org; Mon, 26 Dec 2005 00:15:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04423 for ; Mon, 26 Dec 2005 00:14:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eqkcu-000K7W-VY for v6ops-data@psg.com; Mon, 26 Dec 2005 05:10:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eqkct-000K78-JR for v6ops@ops.ietf.org; Mon, 26 Dec 2005 05:10:27 +0000 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:214c:d33d:8091:9e20]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 137081525D; Mon, 26 Dec 2005 14:10:20 +0900 (JST) Date: Mon, 26 Dec 2005 14:10:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bob@thefinks.com, bob.hinden@nokia.com Cc: v6ops@ops.ietf.org Subject: towards phasing out the 6bone User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk (Not sure if the v6ops list is the appropriate forum for this topic, but I cannot think of a better place) Dear authors of RFC3701, according to the RFC the 6bone prefix (3ffe::/16) will be phased out on June 2006 and IPv6 routes that match the prefix may be filtered thereafter. However, there still seem to be a non-negligible number of 6bone prefixes advertised in the global IPv6 Internet. For example, http://bgp.potaroo.net/v6/as1221/bgptable.txt list 95 6bone prefixes exchanged via BGP (most of which seem pTLA prefixes). My question is: shouldn't the IETF take some action for smooth phase-out, avoiding sudden disruption of running services? For example, shouldn't we send a reminder message about the phase-out plan to the 6bone pTLA operators? Or are we simply trusting the operators to stop using the prefixes (and probably migrate to production prefixes) by the deadline? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Mon Dec 26 01:31:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqlth-0000Sk-3W for v6ops-archive@megatron.ietf.org; Mon, 26 Dec 2005 01:31:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10980 for ; Mon, 26 Dec 2005 01:30:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqlrC-0001Ol-4U for v6ops-data@psg.com; Mon, 26 Dec 2005 06:29:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [64.233.162.198] (helo=zproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqlrA-0001OQ-RZ for v6ops@ops.ietf.org; Mon, 26 Dec 2005 06:29:17 +0000 Received: by zproxy.gmail.com with SMTP id o37so1362051nzf for ; Sun, 25 Dec 2005 22:29:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YSGEU7eAf5sl7HldXh+nBCXZmqG8WKoqR0ms94zopbY6rhhoF154CPzIdKl6bDwKOQ2/4bh3UTiK0yRSRVBC3SZGxFwwd4Ibo5fqJOYUyiggJXTjnY31jHqPK5ZDVPFffUbif3txtRS4ZPzmF6lXxJNC3nvvZohHAuS4K1DDKS0= Received: by 10.65.153.12 with SMTP id f12mr2170023qbo; Sun, 25 Dec 2005 22:29:15 -0800 (PST) Received: by 10.64.143.11 with HTTP; Sun, 25 Dec 2005 22:29:15 -0800 (PST) Message-ID: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> Date: Sun, 25 Dec 2005 22:29:15 -0800 From: Robert Fink Reply-To: bob@thefinks.com To: =?ISO-2022-JP?Q?JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= Subject: Re: towards phasing out the 6bone Cc: bob.hinden@nokia.com, v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jinmei, Your point is a valid one. I will start sending regular reminders to the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/06. In spite of that, many nets will ignore these warnings and thus have to take the consequences when all 3FFE routes are filtered out as of 6/6/06, and I guess that's just the way it will have to be. Thanks, Bob On 12/25/05, JINMEI Tatuya / 神明達哉 wrote: > (Not sure if the v6ops list is the appropriate forum for this topic, > but I cannot think of a better place) > > Dear authors of RFC3701, > > according to the RFC the 6bone prefix (3ffe::/16) will be phased out > on June 2006 and IPv6 routes that match the prefix may be filtered > thereafter. > > However, there still seem to be a non-negligible number of 6bone > prefixes advertised in the global IPv6 Internet. For example, > http://bgp.potaroo.net/v6/as1221/bgptable.txt > list 95 6bone prefixes exchanged via BGP (most of which seem pTLA > prefixes). > > My question is: shouldn't the IETF take some action for smooth > phase-out, avoiding sudden disruption of running services? For > example, shouldn't we send a reminder message about the phase-out plan > to the 6bone pTLA operators? Or are we simply trusting the operators > to stop using the prefixes (and probably migrate to production > prefixes) by the deadline? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > From kristen@absorb.com Mon Dec 26 18:47:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Er24E-0006pu-Of for v6ops-archive@megatron.ietf.org; Mon, 26 Dec 2005 18:47:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19295 for ; Mon, 26 Dec 2005 18:46:40 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Er27w-0001a0-Kt for v6ops-archive@ietf.org; Mon, 26 Dec 2005 18:51:41 -0500 Received: from pcp425297pcs.naugus01.ga.comcast.net ([68.47.91.183] helo=68.47.91.183) by mx2.foretec.com with smtp (Exim 4.24) id 1Er247-0003Se-Ey for v6ops-archive@ietf.org; Mon, 26 Dec 2005 18:47:44 -0500 Message-ID: <9ff701c60a74$6fe6b528$19462197@absorb.com> From: George King To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gTm8gcHJlc2NyaXB0aW9uIG5lZWRlZCE=?= Date: Mon, 26 Dec 2005 23:31:30 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_856923DA.92EABBD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_0000_856923DA.92EABBD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_ED3776B9.C5ACB846" ------=_NextPart_001_0001_ED3776B9.C5ACB846 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Viagra - Cialis ..in 1 pack! http://www.2pills.net Only $2.99/dose! ___________________ To get removed, go here ------=_NextPart_001_0001_ED3776B9.C5ACB846 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Viagra - Cialis
..in 1 pack!

http://www.2pills.net

Only $2.99/dose!


___________________
To get removed, go here

------=_NextPart_001_0001_ED3776B9.C5ACB846-- ------=_NextPart_000_0000_856923DA.92EABBD0-- From owner-v6ops@ops.ietf.org Mon Dec 26 21:18:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Er4QF-0007N4-KX for v6ops-archive@megatron.ietf.org; Mon, 26 Dec 2005 21:18:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04020 for ; Mon, 26 Dec 2005 21:17:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Er4ME-0006T0-PC for v6ops-data@psg.com; Tue, 27 Dec 2005 02:14:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Er4MD-0006So-Q4 for v6ops@ops.ietf.org; Tue, 27 Dec 2005 02:14:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jBR2EKIV021917; Tue, 27 Dec 2005 02:14:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jBR2EHmr021916; Tue, 27 Dec 2005 02:14:17 GMT Date: Tue, 27 Dec 2005 02:14:17 +0000 From: bmanning@vacation.karoshi.com To: bob@thefinks.com Cc: JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJ?= , bob.hinden@nokia.com, v6ops@ops.ietf.org Subject: Re: towards phasing out the 6bone Message-ID: <20051227021417.GA21900@vacation.karoshi.com.> References: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA04020 will -ALL- 3ffe routes be filtered? i don't think this wil be the case. --bill On Sun, Dec 25, 2005 at 10:29:15PM -0800, Robert Fink wrote: > Jinmei, >=20 > Your point is a valid one. I will start sending regular reminders to > the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/06. >=20 > In spite of that, many nets will ignore these warnings and thus have > to take the consequences when all 3FFE routes are filtered out as of > 6/6/06, and I guess that's just the way it will have to be. >=20 > Thanks, >=20 > Bob >=20 >=20 > On 12/25/05, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > (Not sure if the v6ops list is the appropriate forum for this topic, > > but I cannot think of a better place) > > > > Dear authors of RFC3701, > > > > according to the RFC the 6bone prefix (3ffe::/16) will be phased out > > on June 2006 and IPv6 routes that match the prefix may be filtered > > thereafter. > > > > However, there still seem to be a non-negligible number of 6bone > > prefixes advertised in the global IPv6 Internet. For example, > > http://bgp.potaroo.net/v6/as1221/bgptable.txt > > list 95 6bone prefixes exchanged via BGP (most of which seem pTLA > > prefixes). > > > > My question is: shouldn't the IETF take some action for smooth > > phase-out, avoiding sudden disruption of running services? For > > example, shouldn't we send a reminder message about the phase-out pla= n > > to the 6bone pTLA operators? Or are we simply trusting the operators > > to stop using the prefixes (and probably migrate to production > > prefixes) by the deadline? > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, Toshiba= Corp. > > jinmei@isl.rdc.toshiba.co.jp > > From owner-v6ops@ops.ietf.org Mon Dec 26 22:23:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Er5Qr-0006ii-Ly for v6ops-archive@megatron.ietf.org; Mon, 26 Dec 2005 22:23:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10379 for ; Mon, 26 Dec 2005 22:22:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Er5OG-000A1d-PG for v6ops-data@psg.com; Tue, 27 Dec 2005 03:20:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [64.233.162.203] (helo=zproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Er5OE-000A1N-0x for v6ops@ops.ietf.org; Tue, 27 Dec 2005 03:20:42 +0000 Received: by zproxy.gmail.com with SMTP id 4so1325025nzn for ; Mon, 26 Dec 2005 19:20:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p4jM9okiaC8aVzHxOIQI9qdL4fwlaPIVosaBr3lRr+ZHBzs2PfyMkisOxB3cGSnmStvejiSJOxvbXqx9XFlotvWxZVnJojqErjvAvEbGLLzZk96ceoSY8m54JGh+MkyLzkI5i2i2gUM07jFS/A9yTtyUnBtMeU3Hy46sRoRlPLM= Received: by 10.64.204.11 with SMTP id b11mr1600957qbg; Mon, 26 Dec 2005 19:20:40 -0800 (PST) Received: by 10.64.143.11 with HTTP; Mon, 26 Dec 2005 19:20:40 -0800 (PST) Message-ID: <2a8350a60512261920l67f45c2cs46f4e8a417529821@mail.gmail.com> Date: Mon, 26 Dec 2005 19:20:40 -0800 From: Robert Fink Reply-To: bob@thefinks.com To: "bmanning@vacation.karoshi.com" Subject: Re: towards phasing out the 6bone Cc: =?ISO-2022-JP?Q?JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= , bob.hinden@nokia.com, v6ops@ops.ietf.org In-Reply-To: <20051227021417.GA21900@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> <20051227021417.GA21900@vacation.karoshi.com.> Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill, Why wouldn't they; or am I overlooking something obvious? Bob === On 12/26/05, bmanning@vacation.karoshi.com wrote: > > will -ALL- 3ffe routes be filtered? i don't think > this wil be the case. > > --bill > > > On Sun, Dec 25, 2005 at 10:29:15PM -0800, Robert Fink wrote: > > Jinmei, > > > > Your point is a valid one. I will start sending regular reminders to > > the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/06. > > > > In spite of that, many nets will ignore these warnings and thus have > > to take the consequences when all 3FFE routes are filtered out as of > > 6/6/06, and I guess that's just the way it will have to be. > > > > Thanks, > > > > Bob > > > > > > On 12/25/05, JINMEI Tatuya / 神明達哉 wrote: > > > (Not sure if the v6ops list is the appropriate forum for this topic, > > > but I cannot think of a better place) > > > > > > Dear authors of RFC3701, > > > > > > according to the RFC the 6bone prefix (3ffe::/16) will be phased out > > > on June 2006 and IPv6 routes that match the prefix may be filtered > > > thereafter. > > > > > > However, there still seem to be a non-negligible number of 6bone > > > prefixes advertised in the global IPv6 Internet. For example, > > > http://bgp.potaroo.net/v6/as1221/bgptable.txt > > > list 95 6bone prefixes exchanged via BGP (most of which seem pTLA > > > prefixes). > > > > > > My question is: shouldn't the IETF take some action for smooth > > > phase-out, avoiding sudden disruption of running services? For > > > example, shouldn't we send a reminder message about the phase-out plan > > > to the 6bone pTLA operators? Or are we simply trusting the operators > > > to stop using the prefixes (and probably migrate to production > > > prefixes) by the deadline? > > > > > > JINMEI, Tatuya > > > Communication Platform Lab. > > > Corporate R&D Center, Toshiba Corp. > > > jinmei@isl.rdc.toshiba.co.jp > > > > From owner-v6ops@ops.ietf.org Tue Dec 27 03:01:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Er9mO-0002GR-V2 for v6ops-archive@megatron.ietf.org; Tue, 27 Dec 2005 03:01:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07440 for ; Tue, 27 Dec 2005 03:00:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Er9hQ-0000ds-Nd for v6ops-data@psg.com; Tue, 27 Dec 2005 07:56:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Er9hP-0000db-JM for v6ops@ops.ietf.org; Tue, 27 Dec 2005 07:56:47 +0000 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001508850.msg for ; Tue, 27 Dec 2005 08:58:24 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 27 Dec 2005 08:56:28 +0100 Subject: Re: towards phasing out the 6bone From: JORDI PALET MARTINEZ To: , CC: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= , , "v6ops@ops.ietf.org" Message-ID: Thread-Topic: towards phasing out the 6bone Thread-Index: AcYKuwqfSSmX9nauEdqKcwANky3PwA== In-Reply-To: <20051227021417.GA21900@vacation.karoshi.com.> Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es 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, Tue, 27 Dec 2005 08:58:30 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I know that always we can have someone that decide not to filter, but today some are already filtering, so as many more decide to start filtering, more unreliable will be to use a 6bone prefix, and no incentive for those few to continue using it then. Is a kind of domino effect. Furthermore, there is no reason today you can't switch already to a production prefix, even in some RIRs at no cost if you are an IPv4 "customer" already. Regards, Jordi > De: > Responder a: > Fecha: Tue, 27 Dec 2005 02:14:17 +0000 > Para: > CC: JINMEI Tatuya / 神明達哉 , > , "v6ops@ops.ietf.org" > Asunto: Re: towards phasing out the 6bone > > > will -ALL- 3ffe routes be filtered? i don't think > this wil be the case. > > --bill > > > On Sun, Dec 25, 2005 at 10:29:15PM -0800, Robert Fink wrote: >> Jinmei, >> >> Your point is a valid one. I will start sending regular reminders to >> the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/06. >> >> In spite of that, many nets will ignore these warnings and thus have >> to take the consequences when all 3FFE routes are filtered out as of >> 6/6/06, and I guess that's just the way it will have to be. >> >> Thanks, >> >> Bob >> >> >> On 12/25/05, JINMEI Tatuya / 神明達哉 wrote: >>> (Not sure if the v6ops list is the appropriate forum for this topic, >>> but I cannot think of a better place) >>> >>> Dear authors of RFC3701, >>> >>> according to the RFC the 6bone prefix (3ffe::/16) will be phased out >>> on June 2006 and IPv6 routes that match the prefix may be filtered >>> thereafter. >>> >>> However, there still seem to be a non-negligible number of 6bone >>> prefixes advertised in the global IPv6 Internet. For example, >>> http://bgp.potaroo.net/v6/as1221/bgptable.txt >>> list 95 6bone prefixes exchanged via BGP (most of which seem pTLA >>> prefixes). >>> >>> My question is: shouldn't the IETF take some action for smooth >>> phase-out, avoiding sudden disruption of running services? For >>> example, shouldn't we send a reminder message about the phase-out plan >>> to the 6bone pTLA operators? Or are we simply trusting the operators >>> to stop using the prefixes (and probably migrate to production >>> prefixes) by the deadline? >>> >>> JINMEI, Tatuya >>> Communication Platform Lab. >>> Corporate R&D Center, Toshiba Corp. >>> jinmei@isl.rdc.toshiba.co.jp >>> > ********************************************** 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 Tue Dec 27 04:10:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErAqJ-00027j-BR for v6ops-archive@megatron.ietf.org; Tue, 27 Dec 2005 04:10:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14112 for ; Tue, 27 Dec 2005 04:08:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErAnn-0004cC-0H for v6ops-data@psg.com; Tue, 27 Dec 2005 09:07:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErAne-0004bP-0q for v6ops@ops.ietf.org; Tue, 27 Dec 2005 09:07:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jBR97CIV023771; Tue, 27 Dec 2005 09:07:12 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jBR97CK8023770; Tue, 27 Dec 2005 09:07:12 GMT Date: Tue, 27 Dec 2005 09:07:12 +0000 From: bmanning@vacation.karoshi.com To: bob@thefinks.com Cc: "bmanning@vacation.karoshi.com" , JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJ?= , bob.hinden@nokia.com, v6ops@ops.ietf.org Subject: Re: towards phasing out the 6bone Message-ID: <20051227090712.GA23717@vacation.karoshi.com.> References: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> <20051227021417.GA21900@vacation.karoshi.com.> <2a8350a60512261920l67f45c2cs46f4e8a417529821@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2a8350a60512261920l67f45c2cs46f4e8a417529821@mail.gmail.com> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA14112 operational costs ... for one. it is instructive to note that none of the RIRs make statements about routability or reachability of any delegated prefix -because- there is no single authority to mandate routing policy... that is strictly a local matter. so statements such as "all 3ffe routes will be filtered on {date}..." strike me as naieve at best. Joining an RIR has its own set of costs, not all monetary. and contrary to Jordi's apparent assertion, it is not reasonable to "shop" RIRs looking for the best deal. that said, i fully expect that all 3ffe:: space to disappear from the routing tables of those who filter it (and there are some today who filter it) and that number will get larger over the next six months. But it will -NOT- go away on 06jun2006, despite the best efforts of the kind folks in the engineering community. (witness RIP as a fine example of the IETF depricating a=20 technology and the user community ignoring those recomendations :) --bill On Mon, Dec 26, 2005 at 07:20:40PM -0800, Robert Fink wrote: > Bill, >=20 > Why wouldn't they; or am I overlooking something obvious? >=20 >=20 > Bob >=20 > =3D=3D=3D > On 12/26/05, bmanning@vacation.karoshi.com > wrote: > > > > will -ALL- 3ffe routes be filtered? i don't think > > this wil be the case. > > > > --bill > > > > > > On Sun, Dec 25, 2005 at 10:29:15PM -0800, Robert Fink wrote: > > > Jinmei, > > > > > > Your point is a valid one. I will start sending regular reminders t= o > > > the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/= 06. > > > > > > In spite of that, many nets will ignore these warnings and thus hav= e > > > to take the consequences when all 3FFE routes are filtered out as o= f > > > 6/6/06, and I guess that's just the way it will have to be. > > > > > > Thanks, > > > > > > Bob > > > > > > > > > On 12/25/05, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <= jinmei@isl.rdc.toshiba.co.jp> wrote: > > > > (Not sure if the v6ops list is the appropriate forum for this top= ic, > > > > but I cannot think of a better place) > > > > > > > > Dear authors of RFC3701, > > > > > > > > according to the RFC the 6bone prefix (3ffe::/16) will be phased = out > > > > on June 2006 and IPv6 routes that match the prefix may be filtere= d > > > > thereafter. > > > > > > > > However, there still seem to be a non-negligible number of 6bone > > > > prefixes advertised in the global IPv6 Internet. For example, > > > > http://bgp.potaroo.net/v6/as1221/bgptable.txt > > > > list 95 6bone prefixes exchanged via BGP (most of which seem pTLA > > > > prefixes). > > > > > > > > My question is: shouldn't the IETF take some action for smooth > > > > phase-out, avoiding sudden disruption of running services? For > > > > example, shouldn't we send a reminder message about the phase-out= plan > > > > to the 6bone pTLA operators? Or are we simply trusting the opera= tors > > > > to stop using the prefixes (and probably migrate to production > > > > prefixes) by the deadline? > > > > > > > > JINMEI, Tatuya > > > > Communication Platform La= b. > > > > Corporate R&D Center, Tos= hiba Corp. > > > > jinmei@isl.rdc.toshiba.co= .jp > > > > > > From owner-v6ops@ops.ietf.org Tue Dec 27 04:48:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErBRg-0007HY-RH for v6ops-archive@megatron.ietf.org; Tue, 27 Dec 2005 04:48:41 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19241 for ; Tue, 27 Dec 2005 04:47:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErBPw-0006sn-5F for v6ops-data@psg.com; Tue, 27 Dec 2005 09:46:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErBPs-0006sP-TK for v6ops@ops.ietf.org; Tue, 27 Dec 2005 09:46:49 +0000 Received: from [10.0.0.138] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001510340.msg for ; Tue, 27 Dec 2005 10:48:18 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 27 Dec 2005 10:46:28 +0100 Subject: Re: towards phasing out the 6bone From: JORDI PALET MARTINEZ To: , CC: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= , , "v6ops@ops.ietf.org" Message-ID: Thread-Topic: towards phasing out the 6bone Thread-Index: AcYKymiHpxzGbHa9EdqKcwANky3PwA== In-Reply-To: <20051227090712.GA23717@vacation.karoshi.com.> Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 10.0.0.138 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, Tue, 27 Dec 2005 10:48:27 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bill, No, I didn't said that, at least was not my intend. Each LIR need to go for their own RIR ! I was meaning that in general there is no extra cost "because you need to pay for the production prefix", so in that regards, keep using 6bone is not good neither rational. Regards, Jordi > De: > Responder a: > Fecha: Tue, 27 Dec 2005 09:07:12 +0000 > Para: > CC: "bmanning@vacation.karoshi.com" , JINMEI > Tatuya / 神明達哉 , , > "v6ops@ops.ietf.org" > Asunto: Re: towards phasing out the 6bone > > > operational costs ... for one. it is instructive to note > that none of the RIRs make statements about routability or > reachability of any delegated prefix -because- there is no > single authority to mandate routing policy... that is strictly > a local matter. so statements such as "all 3ffe routes will > be filtered on {date}..." strike me as naieve at best. > Joining an RIR has its own set of costs, not all monetary. > and contrary to Jordi's apparent assertion, it is not reasonable > to "shop" RIRs looking for the best deal. that said, i fully > expect that all 3ffe:: space to disappear from the routing > tables of those who filter it (and there are some today who > filter it) and that number will get larger over the next six > months. But it will -NOT- go away on 06jun2006, despite the > best efforts of the kind folks in the engineering community. > (witness RIP as a fine example of the IETF depricating a > technology and the user community ignoring those recomendations :) > > --bill > > > > On Mon, Dec 26, 2005 at 07:20:40PM -0800, Robert Fink wrote: >> Bill, >> >> Why wouldn't they; or am I overlooking something obvious? >> >> >> Bob >> >> === >> On 12/26/05, bmanning@vacation.karoshi.com >> wrote: >>> >>> will -ALL- 3ffe routes be filtered? i don't think >>> this wil be the case. >>> >>> --bill >>> >>> >>> On Sun, Dec 25, 2005 at 10:29:15PM -0800, Robert Fink wrote: >>>> Jinmei, >>>> >>>> Your point is a valid one. I will start sending regular reminders to >>>> the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/06. >>>> >>>> In spite of that, many nets will ignore these warnings and thus have >>>> to take the consequences when all 3FFE routes are filtered out as of >>>> 6/6/06, and I guess that's just the way it will have to be. >>>> >>>> Thanks, >>>> >>>> Bob >>>> >>>> >>>> On 12/25/05, JINMEI Tatuya / 神明達哉 wrote: >>>>> (Not sure if the v6ops list is the appropriate forum for this topic, >>>>> but I cannot think of a better place) >>>>> >>>>> Dear authors of RFC3701, >>>>> >>>>> according to the RFC the 6bone prefix (3ffe::/16) will be phased out >>>>> on June 2006 and IPv6 routes that match the prefix may be filtered >>>>> thereafter. >>>>> >>>>> However, there still seem to be a non-negligible number of 6bone >>>>> prefixes advertised in the global IPv6 Internet. For example, >>>>> http://bgp.potaroo.net/v6/as1221/bgptable.txt >>>>> list 95 6bone prefixes exchanged via BGP (most of which seem pTLA >>>>> prefixes). >>>>> >>>>> My question is: shouldn't the IETF take some action for smooth >>>>> phase-out, avoiding sudden disruption of running services? For >>>>> example, shouldn't we send a reminder message about the phase-out plan >>>>> to the 6bone pTLA operators? Or are we simply trusting the operators >>>>> to stop using the prefixes (and probably migrate to production >>>>> prefixes) by the deadline? >>>>> >>>>> JINMEI, Tatuya >>>>> Communication Platform Lab. >>>>> Corporate R&D Center, Toshiba >>>>> Corp. >>>>> jinmei@isl.rdc.toshiba.co.jp >>>>> >>> > ********************************************** 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 Tue Dec 27 09:12:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErFZG-0008Hc-7G for v6ops-archive@megatron.ietf.org; Tue, 27 Dec 2005 09:12:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22481 for ; Tue, 27 Dec 2005 09:11:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErFWF-000NMg-Dz for v6ops-data@psg.com; Tue, 27 Dec 2005 14:09:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErFWE-000NMR-ET for v6ops@ops.ietf.org; Tue, 27 Dec 2005 14:09:38 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 75EBE17995; Tue, 27 Dec 2005 15:09:37 +0100 (CET) Date: Tue, 27 Dec 2005 15:09:37 +0100 From: Daniel Roesen To: bmanning@vacation.karoshi.com Cc: bob@thefinks.com, JINMEI Tatuya / ???????????? , bob.hinden@nokia.com, v6ops@ops.ietf.org Subject: Re: towards phasing out the 6bone Message-ID: <20051227140937.GA18582@srv01.cluenet.de> Mail-Followup-To: bmanning@vacation.karoshi.com, bob@thefinks.com, JINMEI Tatuya / ???????????? , bob.hinden@nokia.com, v6ops@ops.ietf.org References: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> <20051227021417.GA21900@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051227021417.GA21900@vacation.karoshi.com.> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Dec 27, 2005 at 02:14:17AM +0000, bmanning@vacation.karoshi.com wrote: > will -ALL- 3ffe routes be filtered? i don't think > this wil be the case. Sure. Why should there be any exception? I myself will definately filter 3ffe BGP _and_ packet source/destination at the edge. And I'm seeing at least BGP filtering coming at some large IPv6 ISPs coming too. Frankly, there is nothing of importance in it anymore anyway, so why care at all? Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From owner-v6ops@ops.ietf.org Tue Dec 27 09:46:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErG5S-0004lx-U9 for v6ops-archive@megatron.ietf.org; Tue, 27 Dec 2005 09:46:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25500 for ; Tue, 27 Dec 2005 09:44:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErG3U-000PnZ-Q3 for v6ops-data@psg.com; Tue, 27 Dec 2005 14:44:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [216.93.240.35] (helo=mx01.bos.ma.towardex.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErG3T-000PnN-SK for v6ops@ops.ietf.org; Tue, 27 Dec 2005 14:43:59 +0000 Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN, from userid 1143) id 5B50D6D47D; Tue, 27 Dec 2005 09:43:59 -0500 (EST) Received: from hcmczombvvlcmo (unknown [216.93.252.30]) by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN) with ESMTP id 2E4596D46D; Tue, 27 Dec 2005 09:43:56 -0500 (EST) Reply-To: From: "James Jun" To: "'Daniel Roesen'" , Cc: , "'JINMEI Tatuya / ????????????'" , , Subject: RE: towards phasing out the 6bone Date: Tue, 27 Dec 2005 09:46:51 -0500 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: <20051227140937.GA18582@srv01.cluenet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Thread-Index: AcYK8R7+aXe3psnrS+2Rs5wMNDa5NAAAweJw Message-Id: <20051227144356.2E4596D46D@mx01.bos.ma.towardex.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Daniel Roesen > Sent: Tuesday, December 27, 2005 9:10 AM > To: bmanning@vacation.karoshi.com > Cc: bob@thefinks.com; JINMEI Tatuya / ????????????; bob.hinden@nokia.com; > v6ops@ops.ietf.org > Subject: Re: towards phasing out the 6bone > > On Tue, Dec 27, 2005 at 02:14:17AM +0000, bmanning@vacation.karoshi.com > wrote: > > will -ALL- 3ffe routes be filtered? i don't think > > this wil be the case. > > Sure. Why should there be any exception? I myself will definately filter > 3ffe BGP _and_ packet source/destination at the edge. And I'm seeing at > least BGP filtering coming at some large IPv6 ISPs coming too. > > Frankly, there is nothing of importance in it anymore anyway, so why > care at all? I already have heard from several ~large~ ASes planning to filter 3ffe::/16 on 6/6/06, and that also includes us.. 3ffe should be added as a bogon prefix too, IMHO. James From owner-v6ops@ops.ietf.org Tue Dec 27 09:48:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErG7t-00055Z-MN for v6ops-archive@megatron.ietf.org; Tue, 27 Dec 2005 09:48:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25705 for ; Tue, 27 Dec 2005 09:47:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErG6f-00006H-Vz for v6ops-data@psg.com; Tue, 27 Dec 2005 14:47:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErG6e-00004m-OR for v6ops@ops.ietf.org; Tue, 27 Dec 2005 14:47:17 +0000 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id DDE2E7FBB; Tue, 27 Dec 2005 15:47:11 +0100 (CET) Message-ID: <43B153E0.2070009@unfix.org> Date: Tue, 27 Dec 2005 15:46:56 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: v6ops@ops.ietf.org Subject: Re: towards phasing out the 6bone References: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> <20051227021417.GA21900@vacation.karoshi.com.> <20051227140937.GA18582@srv01.cluenet.de> In-Reply-To: <20051227140937.GA18582@srv01.cluenet.de> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE8B90DEE23A99489FA6CB721" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE8B90DEE23A99489FA6CB721 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Roesen wrote: > On Tue, Dec 27, 2005 at 02:14:17AM +0000, bmanning@vacation.karoshi.com= wrote: >> will -ALL- 3ffe routes be filtered? i don't think >> this wil be the case. >=20 > Sure. Why should there be any exception? I myself will definately filte= r > 3ffe BGP _and_ packet source/destination at the edge. And I'm seeing at= > least BGP filtering coming at some large IPv6 ISPs coming too. What Bill means to say that there will always be places that are too lazy or simply won't act and thus will keep on using it, most of the times because they do not know that they are using it and of course because they simply don't care. He also tries to emphasize on "ALL" because it is not everywhere. (99.9999 % is still not 100%) But as most of the ISP's will filter it out anyway, the old 3ffe/6bone space will become a nice walled garden for some people to play in which has no use whatsoever except for the people still playing in it. Fortunately many networks have moved along already and have made IPv6 full grown already, at least on the play factor. Now there still remain quite a number of other things to tackle. > Frankly, there is nothing of importance in it anymore anyway, so why > care at all? Not that I am aware of. Greets, Jeroen --------------enigE8B90DEE23A99489FA6CB721 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFDsVPnKaooUjM+fCMRAnm9AKDAuhJfOyhui8vW5CyND+cw5XhsVQCgnFVt ZK0N/ARO2stwgOZqhS6gnpk= =6dZL -----END PGP SIGNATURE----- --------------enigE8B90DEE23A99489FA6CB721-- From owner-v6ops@ops.ietf.org Tue Dec 27 11:04:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErHJG-0001e0-HQ for v6ops-archive@megatron.ietf.org; Tue, 27 Dec 2005 11:04:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05747 for ; Tue, 27 Dec 2005 11:03:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErHGi-0005hX-CL for v6ops-data@psg.com; Tue, 27 Dec 2005 16:01:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErHGh-0005hI-Ch for v6ops@ops.ietf.org; Tue, 27 Dec 2005 16:01:43 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 9F4B11799E; Tue, 27 Dec 2005 17:01:42 +0100 (CET) Date: Tue, 27 Dec 2005 17:01:42 +0100 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: towards phasing out the 6bone Message-ID: <20051227160142.GA19400@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> <20051227021417.GA21900@vacation.karoshi.com.> <20051227140937.GA18582@srv01.cluenet.de> <43B153E0.2070009@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B153E0.2070009@unfix.org> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Dec 27, 2005 at 03:46:56PM +0100, Jeroen Massar wrote: > Daniel Roesen wrote: > > On Tue, Dec 27, 2005 at 02:14:17AM +0000, bmanning@vacation.karoshi.com wrote: > >> will -ALL- 3ffe routes be filtered? i don't think > >> this wil be the case. > > > > Sure. Why should there be any exception? I myself will definately filter > > 3ffe BGP _and_ packet source/destination at the edge. And I'm seeing at > > least BGP filtering coming at some large IPv6 ISPs coming too. > > What Bill means to say that there will always be places that are too > lazy or simply won't act and thus will keep on using it, most of the > times because they do not know that they are using it and of course > because they simply don't care. He also tries to emphasize on "ALL" > because it is not everywhere. (99.9999 % is still not 100%) I read it different: I guess he wants to imply that there will be "special important folks who still use 3ffe as they can't get over the legacy who are SO important that the 3ffe filters will make exceptions for those special highly important folks". I seriously doubt that there are any of even nearly that importance. Can think of none. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0