Re: Call for Artworks! 'Graphic Drawing' Deadline 25th July 2006.
Raju, How is this event related to the IETF? This is the third e-mail I've seen to ietf@ietf.org about this event, but I have yet to figure out how it's related. Can you please clarify the connection for me? Thanks, Scott On 06/26/06 at 6:10pm +0530, Raju Sutar [EMAIL PROTECTED] wrote: *Call for Artworks * *'Graphic and Drawing' 2006, *is the* *second inaugural annual event announced, after the overwhelming response to 'Expressions in Miniature Size' 2006. From the series of international curated exhibitions by artEperiments.com in association with Waves Art Gallery. Art of graphic and drawing is the skeleton of the artist's structural thought; Very often the seed of breakthroughs are hidden in the drawings and meticulous practice of graphic art. We intend to call entries from the artists all over the world, and at least 12 entries will be selected by artist/curator Raju Sutar for a physical as well as online exhibition, along with a catalogue to be printed of the select exhibits. In case of more selections the exhibition will be held in sequence like 'I II' Waves Art Gallery is located in Pune (INDIA), a city that is known to be the city of knowledge and culture. Our endeavor is to bring out the best possible works of art, to understand the growth of the contemporary art. *Eligibility* Any artist from any country can apply, provided: * Art works falling under the category of: *Graphic:* e.g. Lithograph, Serigraph, Etching, Dry Point, Linocut, Woodcut, etc. *Drawing:* e.g. Pencil, Charcoal, Pastel, Ink, etc. *Note* : Processing fees *INR 100/-* (Indian Rupees One hundred only) OR *USD 2.5* (two dollars and fifty cents only) per application (up to three images). Please submit your entries at *www.artexperiments.com* online only! Deadline 25th July 2006. Raju Sutar Artist/Curator ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 04/14/06 at 5:07pm +0200, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 14-apr-2006, at 16:57, Scott Leibrand wrote: 60 voted in favor of moving forward with PI. 6 voted against. Wow, 10 to 1. Amazing. Even more amazing: 60 people who represent nobody but their own paycheck get to blow up the internet. Did you participate in the process? Even if you can't justify travel to Montreal, the PPML is wide open. ARIN doesn't go solely by the vote in the room; they also consider whether there was consensus on the PPML. Where is ICANN when you need it? This little experiment in playground democracy has to end before people get hurt. I think the ARIN process is closer to the IETF's rough consensus process than to democracy. If you think the PI policy ARIN passed will blow up the internet, I would encourage you to participate in drafting policy proposals to help limit the impact of PI on the routing table. Bear in mind that we didn't approve an IPv6 PI for everyone policy precisely to avoid blowing up the Internet: instead we only extended existing IPv4 policy to IPv6. As I've written before, I'm attempting to draft an ARIN policy proposal to ensure PI addresses are assigned in a regular fashion instead of the random chronological fashion we do now with IPv4. As you seem to support that, I would encourage you to help draft such a policy proposal and help get people to support it. -Scott P.S. I don't think we need quite so much cross-posting as this... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 04/14/06 at 11:05am -0700, Michel Py [EMAIL PROTECTED]: Iljitsch van Beijnum wrote: However, geographic addressing could give us aggregation with provider independence. Brian E Carpenter wrote: You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. The problem with geo PI aggregation is expectations: if we set any aggregation expectations it won't fly because too many people have legitimate concerns about its feasibility. Personally I think that some gains are possible, but I'm not sure these gains will offset the amount of work required. I agree, especially in the near term. Aggregation is not required right now, but having the *ability* to aggregate later on is a prudent risk reduction strategy if today's cost to do so is minimal (as I think it is). My $0.02 about geo PI: a strategy change is needed. Instead of presenting geo PI as the solution that would give PI without impacting the routing table (this will not fly because there are too few believers and too many unknowns), present it as the icing on the cake of a comprehensive non-geo PI proposal. That's exactly what I'm pushing for. I'm in the process of brainstorming with other interested parties (and potential co-authors) to put together an ARIN public policy proposal that directs ARIN to assign PI netblocks in a regular fashion instead of the current random (chronological) fashion used for IPv4. As I stated above, I don't think aggregating is necessary or wise just yet, but I think that setting things up now, to make it possible to do so later if needed, is wise and prudent, and can be done with little or no additional complexity (cost). -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On 04/14/06 at 2:17pm -0400, Noel Chiappa [EMAIL PROTECTED] wrote: From: Kevin Loch [EMAIL PROTECTED] Nobody in that room would have supported a policy they actually believed would blow up the Internet. Who was in the room, BTW? How many of those 60 were from ISP's? Noel, Jason had the chair ask how many folks in the room were in the Default Free Zone, and 20 people raised their hands. So from that I conclude at the very least that 14 of those 20 did not oppose the PI proposal. I suspect a number of them, like myself, actually supported the proposal as a good balance between the need for workable multihoming and the desire not to pass a PI for everyone policy that would explode the routing table. Bear in mind that the number of IPv4 PI blocks ARIN has given out is rather small, and there's little reason to think that will change in the near term. Also, does that group have any commitments from ISP's (particularly the large global backbones) to carry these PI addresses? (I assume the group is expecting that PI addresses will be supported by the routing, not by some as-yet-undefined other mechanism.) I suspect they will indeed be accepted. At least initially, all the transit providers I know of will accept such routes from their customers, and I suspect they will begin accepting them from their peers as well as multihoming enterprises demand it. -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the size of the available address space. So if what you say is true, and we manage to use up an exponential resource in linear time, then we can change our approach and try again with the second 1/8 of the space, without having to go through the upgrade pain that is the v4-v6 transition again. I suspect even arrogant engineers can get it right in 8 tries. :) -Scott On 03/29/06 at 6:15am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Thomas Narten writes: This is FUD. Care to back up your assertions with real analysis? Sure. The consistent mistake engineers make in allocating addresses is that they estimate capacity in terms of sequential and consecutive assignment of addresses--but they _assign_ addresses in terms of bit spans within the address itself, which exhausts addresses in an exponential way. They do this in part because they attempt to encode information directly into the address, instead of just using it as a serial identifier. An address of n bits contains 2^n available addresses _only_ if they are assigned serially and consecutively; dividing those bits into any arrangement of smaller fields reduces capacity exponentially. For example, if you have a 16-bit address field, at first it looks as those it has 65,536 addresses. And it does ... if you assign addresses as 0001, 0010, and so on. But if you allocate addresses by dividing those 16 bits into fields, you dramatically reduce the total address space available. If you reserve the first eight bits for a vendor, and the second eight bits for a product, you've cut the address space by 99.6%, not by 50%. You will run out of addresses in record time, and yet you'll never use more than a tiny fraction of the theoretical capacity of the address space. All because you wanted the short-term convenience of encoding information into the address itself. Engineers make this mistake over, and over, and over. I don't know if they are just too stupid to understand the above concepts, or if they are so arrogant that they think they can somehow short-circuit information theory and do the impossible. I tend to vote for arrogance, since I think (and hope) that engineers aren't really that stupid. And further evidence for pure arrogance is that engineers try to allocate address spaces now for a future that they are unable to imagine. They allocate /64 fields out of 128 bits for purposes that they understand now, even though the real need for addresses is likely to be completely different (and unforseeable) by the time addresses actually start to run short. I know I'm wasting my breath; if engineers were that easy to persuade, they would not have made the same mistake over and over for nearly a hundred years. I'm sure others have tried to point out their errors time and again, especially in recent years as more people have caught on to the problem. But they can't be told. They are convinced that it won't happen to them, even though it happened to everyone else. A 128-bit address seems like more than the universe will ever need, and it definitely is ... but only if addresses are assigned serially from the address space, without any information encoded into the address itself. As soon as you reserve any portion of the field in any way, there are multiple exponential reductions in capacity, which can exhaust the address space entirely in a very short time. The mistakes have already been made with IPv6. Someone decided to allocate bit spans out of the address, instantly invalidating the very vast majority of all possible addresses in the address space, and thereby reducing address capacity exponentially. Nobody really knows how addresses will be used 20 years from now, so why do people try to guess and sacrifice the capacity of IPv6 in the process? Don't they ever learn? Is there a safe and conservative way of allocating IPv6 address space? Yes. Set the first 96 bits to zero, and set the remaining 32 to the current IPv4 addresses. When that runs out, set the first 95 bits to zero, set the 96th bit to one, and use the remaining 32 bits for another IPv4 address space. And so on. A space of 128 bits will last for eternity in this way, and most of the space will remain available for any conceivable future addressing scheme, even those we cannot dream of today. In other words, don't allocate bit spans within the address field, allocate address _ranges_ out of the full 128 bits. But I know that won't happen. However, perhaps this message will remain archived somewhere so that I can say I told you so when the address space finally runs out (I'm pretty sure I'll still be around--we all will). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On 03/28/06 at 6:11am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Scott Leibrand writes: NAT (plus CIDR) was the short-term solution, and is realistic as a medium-term solution. In the long term, though, I don't think it will be the only solution. It will be if ISPs continue to charge for extra IP addresses, as they probably always will. They can charge for IPv4 addresses because they're perceived to be scarce. With IPv6 they may be able to charge for allowing me a /48 instead of a /56 or /64, but IMO they won't be able to assign me a /128 by default and charge me if I want a /64. And if someday I want to switch to a new ISP who prefers not to give out IPv4 addresses at all, that'll be fine with me, as long as my ISP provides me IPv4 translation services to reach that portion of the Internet that is still IPv4-only at that point. If your ISP charges you extra for more than one IPv6 address, what will you do? Then I will switch ISPs. ARIN guidelines specifically require ISPs to give out larger blocks when requested. If any ISPs try to be hard-nosed about it and give out /128's anyway, it will be pretty easy to pressure shame them sufficiently that they'll feel it in the marketplace. -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 03/28/06 at 7:00am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Keith Moore writes: don't think upgrade; think coexistence. How do IPv4 and IPv6 coexist? Like ASCII and EBCDIC, perhaps? Um, have you heard of dual stack? My Windows XP does it quite transparently (after I enable IPv6 at the command line), and presumably Vista will do IPv4/IPv6 dual stack transparently without any command-line enabling. As an engineer, the right thing to do is to transition away from NAT (along with IPv4), so that eventually it can be discarded. I'm not aware of a smooth transition option; how does it work? OS's (and anything with a TCP/IP stack) starts looking for both IPv4 and IPv6 connectivity at connect time (DHCP for v4, DHCPv6 or RA's for IPv6). If an ISP has enabled IPv6 on their network, the IP stack gets an IPv4 address and one or more IPv6 addresses. When it goes to talk to a host with a v4 address, it uses v4. To talk to a v6 host, it uses v6. If a network wants to stop giving out v4 addresses, they provide v4/v6 translation capabilities of some sort. And NAT is economically driven. Unless ISPs stop charging for extra addresses, it's hear to stay. As I argued in another message, IMO ISPs will not be able to charge extra for an IPv6 /64. That gives you basically as many hosts as your routing/switching gear can handle on a single subnet (as you won't be able to put 2^64 hosts on a single broadcast domain). for some applications, it's simply impractical; for other apps, it's much more expensive (in terms of added infrastructure and support costs) to operate them in the presence of NAT. in either case the market for those apps is greatly reduced, and the apps are more expensive as a result. It might still be cheaper than converting them to IPv6. As long as you already have v6-capable gear, enabling IPv6 shouldn't be significantly more expensive than running v4. IMO it doesn't make sense to try to run v6 on gear that only supports v4, but since pretty much all new gear supports v6 now, folks should be able to gradually turn on v6 as appropriate in their networks. again, this doesn't really solve the problem - it only nibbles off a small corner of it. NATs do harm in several different ways - they take away a uniform address space, they block traffic in arbitrary directions, they hamper appropriate specification of security policies, and these days they often destroy transparency. Agreed, but they reduce the amount of money you must pay to your ISP each month by a factor of ten or more. Your ISP charges you 9 times as much for IPv4 addresses as they do for bandwidth? I'd recommend switching ISPs. All the ones I've seen charge a small premium for additional IP space, but it's never more than about a 50% premium. the reason this looks so complicated compared to NATs is that NATs never really worked all of this stuff out. NATs started with a simple design, pretended it would work well without doing the analysis, and have been trying to fix it with bizarre hacks ever since that have only made the problem worse. People will go to great lengths sometimes to save money. Or to avoid hassle. I have a single IP on my DSL, and run NAT, mainly because it's not worth the hassle to get additional IPv4 space. However, as soon as my ISP starts offering IPv6 with DHCPv6 Prefix Delegation, I'll upgrade my NAT box to something that supports DHCPv6-PD. That might be a linksys/d-link/netgear box, or it might be a PC running Linux. -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On 03/28/06 at 8:54pm +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Scott Leibrand writes: They can charge for IPv4 addresses because they're perceived to be scarce. With IPv6 they may be able to charge for allowing me a /48 instead of a /56 or /64, but IMO they won't be able to assign me a /128 by default and charge me if I want a /64. They will charge you for every address beyond one. Wait and see. We definitely will have to see how it shapes up in the US. In Japan, where they actually have IPv6 deployed to end users, it looks like most ISPs are giving out /64's to home users, and /48's to business users: http://www.apnic.net/meetings/18/docs/sigs/policy/policy-pres-tomohiro-ipv6-endusers.pdf BTW, giving out /64s is one reason why the IPv6 address space will be exhausted in barely more time than was required to exhaust the IPv4 address space. Then I will switch ISPs. They will all be doing it. I doubt it. There are RFC's (3177) and RIR policies (http://www.arin.net/policy/nrpm.html#six54) that *require* ISPs to allocated a /64 or larger unless it is absolutely known that one and only one device is connecting. ARIN guidelines specifically require ISPs to give out larger blocks when requested. If any ISPs try to be hard-nosed about it and give out /128's anyway, it will be pretty easy to pressure shame them sufficiently that they'll feel it in the marketplace. How? I haven't been able to pressure or shame my ISP into setting rDNS correctly for my IP address. In fact, nobody at my ISP knows what that means. What is correct rdns? Is adsl-066-156-091-129.sip.asm.bellsouth.net correct? -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 03/28/06 at 9:00pm +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Scott Leibrand writes: Um, have you heard of dual stack? My Windows XP does it quite transparently (after I enable IPv6 at the command line), and presumably Vista will do IPv4/IPv6 dual stack transparently without any command-line enabling. How does your ISP handle this? They could do so (when they implement IPv6) by running dual-stack routers. How much extra does your ISP charge you for IPv6 support? My ISP doesn't yet provide IPv6 support. But at some point they (or another ISP) will. As I argued in another message, IMO ISPs will not be able to charge extra for an IPv6 /64. A /64 is a criminal waste of address space; they _should_ charge extra for that. I don't think you understand exponential math as it applies to IPv6. IPv6 was specifically designed to make this possible. With /48 assignments and an HD ratio of .94, projections indicate a ~500 year lifetime to exhaust the IPv6 address space. That gives you basically as many hosts as your routing/switching gear can handle on a single subnet (as you won't be able to put 2^64 hosts on a single broadcast domain). And even with a million hosts, you'll be wasting fully 99.99945% of the /64. Yep. And since there are about 18,446,744,073,709,600,000 /64's, such wastage is not a problem. IPv6 was *designed* to make sure that address space conservation is *not* required. Do you see why IPv6 address space will soon be exhausted? If you consider hundreds of years soon, then sure. As long as you already have v6-capable gear, enabling IPv6 shouldn't be significantly more expensive than running v4. IMO it doesn't make sense to try to run v6 on gear that only supports v4, but since pretty much all new gear supports v6 now, folks should be able to gradually turn on v6 as appropriate in their networks. When did all applications become capable of handling IPv6? They don't need to be. For the life of any existing applications, IPv4 connectivity will still be available in some fashion. All the ones I've seen charge a small premium for additional IP space, but it's never more than about a 50% premium. Fifty percent is a small premium? No, usually it's a lot less than 50%. More typical is like $5/mo extra for additional IP(s). -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On 03/27/06 at 1:51pm -0800, Austin Schutz [EMAIL PROTECTED] wrote: This is reasonable, but there is no realistic path to ipv6 that the known world can reasonably be expected to follow. I think a good number of exclusively-IPv4-using* realists (like myself) will disagree with you here. (* Exclusively-IPv4-using except at conferences like IETF and NANOG where native IPv6 access is provided.) NAT is a done deal. It's well supported at network edges. It solves the addressing issue, which was what the market wanted. It voted for NAT with dollars and time. It is the long term solution - not because it is better, but because it is. NAT (plus CIDR) was the short-term solution, and is realistic as a medium-term solution. In the long term, though, I don't think it will be the only solution. So the real question is: Given NAT, what are the best solutions to the long term challenges? You seem to assume that IPv4 w/ NAT and IPv6 are mutually exclusive. I disagree. I have IPv4 and NAT at home, for example, but my hosts all can support IPv4/IPv6 dual stack. If my DSL provider starts doing IPv6 DHCP-PD, I will make sure I have a gateway box that can do both IPv4 w/ NAT and IPv6 w/ DHCP-PD, and run everything dual stack. That way I can start accessing my own hosts without stupid static NAT/PAT tricks, but still access the IPv4 Internet directly. And if someday I want to switch to a new ISP who prefers not to give out IPv4 addresses at all, that'll be fine with me, as long as my ISP provides me IPv4 translation services to reach that portion of the Internet that is still IPv4-only at that point. -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Anatole in-room net confusion
Are they talking about two different SSID's? -Scott On 03/20/06 at 7:24pm -0500, Sam Weiler [EMAIL PROTECTED] wrote: The FAQ at www.ietf65.org says: Is there free wired Internet access in the hotel rooms? No. While http://www.ietf.org/meetings/hotels_65.html says: ** Attendees with reservations within the IETF room block will receive complimentary high speed Internet, local and domestic long distance calls from their guestrooms. And the nice front desk person I spoke with this morning indicated there would be no charge for wired net. What gives? -- Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
