Re: FW: Why?
Noel Chiappa wrote: I mean, it's now coming up on *11 years* since IPv6 was selected (i.e. back when the latest and greatest uSoft-ware was *Windows 3.1*, and the WWW had a grand total of about 3K sites), and still we hear the "oh, it will take off soon" - the same line we've been hearing for close to a decade. That is to be expected. As you know, the value of a network is roughly proportional to the square of the participants. Since adoption is influenced by the value of the network it can take quite a long time to acquire "take off", whatever that is. Is it just an arbitrary point along the geometric growth curve or is it some milestone like native access being widely available to the average home? It took a very long time to get native IPv4 connectivity to the average home. Even as late as 1993, long after IPv4 had taken off in academic circles it was difficult (expensive) to get native connectivity, even dialup. At that time dialup shell/terminal server access was more common but severely limited as it is non-native. Native IPv4 wasn't widely available to the average home user until about 1995. So given the decades it took for IPv4 to be commonly available why do we expect an accelerated deployment for IPv6? Leveraging the existing IPv4 infrastructure does help deployment but that alone does not affect the value or desire to deploy. Just as government subsidies helped deployment of IPv4 but did not directly affect the value or desire to deploy. I hear the exact same excuses for not adopting IPv6 as I heard for IPv4 in the early 1990's: "I have no reason to connect" and/or "I can't justify the cost" The solution to both problems is n^2. If you really want to jump start n^2, find a way to convince the RIR's to require demonstration of IPv6 deployment for subsequent (non initial) IPv4 allocations. Kevin Loch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why?
Michel Py wrote: I realize now that this is where we erred: by shifting the multi-homing problem from the ISP to the end-user, we made a less-palatable protocol that is adoption-challenged. Then shift it back to the ISP's [1]: - Encourage RIR's to allocate /32's to large multihomed end sites (connected to 3 or more upstreams) - Use something like alternate path encoded addresses/routing for trivial multihoming (2 upstreams) Allocating anything longer than /32 is asking for a massive swamp. It's bad enough that ARIN is issuing /48 microallocations as many operators are only filtering routes longer than /48 right now. Alternate path routing allows you to set the bar a bit higher for getting PI space and allows anyone with two connections to multihome (including people who couldn't multihome in IPv4). Kevin Loch [1]http://www.ietf.org/internet-drafts/draft-loch-multi6-alternate-path-encoding-03.txt "While many IPv6 multihoming methods require changes to host software, this method only requires changes to routers. This will make widespread implementation far more practical and likely in the near term than methods that require upgrading host software (provided that router vendors support this feature)." ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: "IETF servers aren't for testing"
Jeroen Massar wrote: The problem here seems to be more the fact that, in the US, getting IPv6 connectivity can be quite tiresome. Cogent, the current IPv4 upstream, doesn't do IPv6 (they have 2001:500:2::/48) for instance. UUnet could maybe do IPv6. Maybe the secretariat would wants to try out some tunnels? If connectivity means a colocated server with IPv4 and IPv6 service, that can easially be found in the US. Finding an IPv6 ISP POP in an arbitrary local town is quite a bit more difficult. If these are just dedicated/colocated servers and IPv6 is a requirement, move them to a hosting company that supports IPv6. If you are not willing to take your business elsewhere then why should your current hosts offer it? - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]
Dean Anderson wrote: Right. But all DNS in the past (and most in the present) is small, stateless UDP packets. RFC1546 Anycast allows PPLB on diverse links. But future DNS will use large UDP packets, fragments, and more TCP. That's a big change for something we depending so much on today. Perhaps this future DNS should have a new name and use a different well known port to avoid confusion. I suggest calling it "LDAP" and using ports 389/636. Add "discourages protocol bloat" to the list of well known benefits of anycast DNS. - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Iljitsch van Beijnum wrote: Wow, 10 to 1. Amazing. Sounds like a rough consensus to me. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. I find this comment extremely offensive. Nobody in that room would have supported a policy they actually believed would blow up the Internet. Your implication that the participants were either uninformed or diddn't care about the consequences is completely off base. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. You would actually prefer ICANN replace the open policy process of the RIR's? ARIN participants are simply following the principles the IETF used to use: rough consensus AND running code. - Kevin (trimming the cc: list for everyone's sanity) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Iljitsch van Beijnum wrote: I'm not saying that these people expected the internet to melt down by supporting this policy, but that's exactly the problem. Within the IETF, we've been working long and hard to find a way to allow for multihoming that we KNOW won't melt the internet, and now just as these efforts are getting close to paying off (shim6) In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. This failure of leadership from the IETF to provide a roadmap for a viable alternative to PI is a factor in the support for going with the current technology. - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Joe Abley wrote: On 14-Apr-2006, at 14:01, Kevin Loch wrote: In case you (IETF) diddn't get the memo, the operational community has flat out rejected shim6 in it's current form as a replacement for PI. I presume you're not saying that the operational community has rejected all possible, future alternatives to open slather on PI, nor that the vast majority of Internet users who are (for example) not served by the ARIN proposal should never be allowed to multi-home. No, I'm not saying that at all. This policy change is about creating a viable migration path for non-isp PI users before the IPv4 panic begins. Shim6 was seen as not doing that even if/when it was widely deployed. A scalable routing architecture that is a suitable replacement for PI for end sites would be great. Please don't give up on that. - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Noel Chiappa wrote: PI is like spam - it looks attractive to the people using it, because it's free to them. The fact that it costs *other* people money is something they don't care about - it's not coming out of their pocket. Where are these free routers and how do I get one? - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Peter Sherbin wrote: This is a proper model which should remain this way with a little fix. IETF engineering effort is funded (indirectly) by the employers of the engineers. RIRs administrative work is funded through membership and allocation fees, which essentially equals selling of IP addresses. Because the Internet is a shared resourse its enablers such as IP addresses are not for sale but rather for a free assignment to everyone. RIRs function should be funded through a politically / economically neutral body, e.g. UN. Technically the current way of RIR cost recovery hinders the network neutrality. I wouldn't consider any policital body, especially the UN to be politically (and thus economically) neutral. I also don't see how RIR fees affect policy in any way. At least in ARIN, anyone is allowed to participate in the policy process regardless of resources delegated or fees paid. - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
Sam Hartman wrote: "secIETF" == IETF Secretariat <[EMAIL PROTECTED]> writes: secIETF> * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 secIETF> Native firewall (pings, traceroutes etc. are dropped) Please make sure that ICMP messages needed for path MTU discovery are not filtered. Is there a compelling reason to filter ICMP at all? - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
