Re: I-D ACTION:draft-wilson-class-e-00.txt
On Tuesday 21 August 2007 02:47:16 ext Mark Andrews wrote: > > Mark Andrews writes: > > > Cable companies need this amount of address space for > > > controlling the CPE boxes. The customers still get public > > > addresses. That's a minimum of two addresses per customer. > > > > One of which can easily be an IPv6 address, so allocating 240/x for this > > would seem to cater to those people who can and will modify their > > devices to accept 240/4, but cannot or will not give them IPv6 ability. > > That assumes that they won't work with those addresses today. > My FreeBSD boxes will happily talk to each other using class > E addresses. No everything has had a lobotomy. You mean, the same BSD stack that has a specific check for not routing class E packets? In all due fairness, I have to admit it does not reject class F+. -- Rémi Denis-Courmont ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
> Mark Andrews writes: > > Cable companies need this amount of address space for > > controlling the CPE boxes. The customers still get public > > addresses. That's a minimum of two addresses per customer. > > One of which can easily be an IPv6 address, so allocating 240/x for this > would seem to cater to those people who can and will modify their > devices to accept 240/4, but cannot or will not give them IPv6 ability. That assumes that they won't work with those addresses today. My FreeBSD boxes will happily talk to each other using class E addresses. No everything has had a lobotomy. Mark bsdi# ifconfig tx0 inet 255.255.254.2 netmask 0xff00 alias drugs# ifconfig bge0 inet 255.255.254.1 netmask 0xff00 alias drugs# tcpdump host 255.255.254.1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes 09:40:00.364407 IP 255.255.254.2.1565 > 255.255.254.1.ssh: S 3539319153:3539319153(0) win 57344 09:40:00.364886 IP 255.255.254.1.ssh > 255.255.254.2.1565: S 2293183390:2293183390(0) ack 3539319154 win 65535 09:40:00.365495 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 1 win 57920 09:40:00.504633 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 1:40(39) ack 1 win 33304 09:40:00.505719 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 1:40(39) ack 40 win 57920 09:40:00.518965 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 40:776(736) ack 40 win 33304 09:40:00.520554 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 40:584(544) ack 776 win 57184 09:40:00.620569 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 584 win 33304 09:40:00.627956 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 584:608(24) ack 776 win 57920 09:40:00.727778 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 608 win 33304 09:40:00.753739 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 776:1056(280) ack 608 win 33304 09:40:00.847195 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 1056 win 57920 09:40:00.866975 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 608:880(272) ack 1056 win 57920 09:40:00.966562 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 880 win 33304 09:40:01.123954 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 1056:2224(1168) ack 880 win 33304 09:40:01.217178 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 2224 win 57920 09:40:03.863875 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 880:896(16) ack 2224 win 57920 09:40:03.967049 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 896 win 33304 09:40:03.967597 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 896:944(48) ack 2224 win 57920 09:40:03.969216 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2224:2272(48) ack 944 win 33304 09:40:03.970430 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 944:1008(64) ack 2272 win 57920 09:40:03.982462 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2272:2336(64) ack 1008 win 33304 09:40:03.984466 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 1008:1536(528) ack 2336 win 57920 09:40:04.028809 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2336:2816(480) ack 1536 win 33304 09:40:04.060597 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 1536:2112(576) ack 2816 win 57920 09:40:04.104782 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2816:2848(32) ack 2112 win 33304 09:40:04.106312 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2112:2176(64) ack 2848 win 57920 09:40:04.132479 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2848:2896(48) ack 2176 win 33304 09:40:04.134269 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2176:2560(384) ack 2896 win 57920 09:40:04.152359 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2896:2944(48) ack 2560 win 33304 09:40:04.162486 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2944:4320(1376) ack 2560 win 33304 09:40:04.164080 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4320 win 56544 09:40:04.925327 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4320:4416(96) ack 2560 win 33304 09:40:04.925396 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4416:4480(64) ack 2560 win 33304 09:40:04.925904 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4480 win 57760 09:40:04.935872 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4480:4544(64) ack 2560 win 33304 09:40:05.027081 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4544 win 57920 09:40:48.766603 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2560:2608(48) ack 4544 win 57920 09:40:48.768701 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4544:4592(48) ack 2608 win 33304 09:40:48.868036 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4592 win 57920 09:40:48.935145 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2608:2656(48) ack 4592 win 57920 09:40:48.936066 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4592:4640(48) ack 2656 win 33304 09:40:49.028134 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4640 win 57920 09:40:49.077229 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2656:2704(48) ack
Re: I-D ACTION:draft-wilson-class-e-00.txt
Mark Andrews writes: Cable companies need this amount of address space for controlling the CPE boxes. The customers still get public addresses. That's a minimum of two addresses per customer. One of which can easily be an IPv6 address, so allocating 240/x for this would seem to cater to those people who can and will modify their devices to accept 240/4, but cannot or will not give them IPv6 ability. Large corporations need more than a /8. A /48 is that, too... Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Geoff, [cable-modems] was a scenario that was envisaged by the authors of the draft as being consistent with the intended re-designated use and consistent with the caveats noted in the draft. For a closed system, which is what you are talking about, one could make CLNS and TMIP work!! If you can do that, why not simply use the specified standard, IPv6? Doing otherwise discredits CableLabs and probably causes a CM respin. The authors were interested in providing a succinct statement of the administrative actions required to redefine the use of this currently reserved address block. That is necessary but NOT sufficient. There needs to be motivation. This was the case in RFCs 1597 and 1918, and it should be so here as well. You are asking for the last allocation of addresses. Let's have the reasoning be sound, please. It would be quite appropriate, as already noted in the draft, to generate additional material describing use cases and actions required on the part of network admins to enable use of this address prefix in various scenarios. That's fine, but without the motivation I would strongly object to this document advancing. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Brian E Carpenter wrote: On 2007-08-07 16:15, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title: Redesignation of 240/4 from 'Future Use" to "Limited Use for Large Private Internets' Author(s): P. Wilson, et al. Filename: draft-wilson-class-e-00.txt Pages: 4 Date: 2007-8-7 This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for limited use in large private Internets. It seems to me that we first need a discussion about why this space can't be released as public address space. Is it known to be already deployed as de facto private space? I'd be a bit nervous about unintended side effects if DHCP assigned me 255.255.255.255/32. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf I remember trying it. I wanted to clandestinely communicate between linklocal boxes. I could use it with Unifix linux 2.0 and kernel 2.0.48 I did not find any other operating system, not even linux, who could use it. I did not find any hardware except nonmanaged switches who could use it. I tried to "fix" the tcp/ip stack of a more modern linux. Sideffects. I did not get it working. To many places in the software. Kind regards Peter and Karin Dambier -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Keith Moore wrote: One thing I'm pretty sure of is that allocating this space for another RFC1918-like private network block isn't going to solve the collision problem. I could see more utility in letting this be space for "router" use only, say to allow cable ISPs to assign such addresses to non-publicly accessible components in their networks. Such use would presumably have fewer deployment barriers than use as either ordinary public or private space. This was a scenario that was envisaged by the authors of the draft as being consistent with the intended re-designated use and consistent with the caveats noted in the draft. I could also see some utility in assigning smaller blocks from this space to enterprise networks, similar to ULIAs in IPv6. Such blocks could be used, for instance, to interconnect between private networks without address collisions. But for that kind of use I would assume that the deployment barriers would be much greater. Bottom line - I think that any proposal to reassign class E addresses needs to provide one or more specific use cases. And for each of those cases, it should consider deployment cost vs. benefit, and compare that to the cost vs. benefit of using IPv6. The authors were interested in providing a succinct statement of the administrative actions required to redefine the use of this currently reserved address block. It would be quite appropriate, as already noted in the draft, to generate additional material describing use cases and actions required on the part of network admins to enable use of this address prefix in various scenarios. If you, and others who have an interest in this topic, are volunteering to write one (or more) such documents about use of this address block and/or the caveats relating to such use, then that would be great! thanks, Geoff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
> It is not up to the IETF to engineer a transition to IPv6, > merely to make the tools available. nor is it up to the IETF to engineer a (very slightly) longer lifetime for IPv4. > Freeing up the former class E space > is an example of making a minor tool available, and it also sends a > strong message that the IETF believes that IPv4's days are numbered, > some people might interpret that message differently. they might believe that since we're making a large chunk of new addresses available, it's okay to keep depending on IPv4. (seems like we're notoriously bad at getting _any_ message across to the public, since IETF says little to the media and we don't object when marketroids from various big name companies claim that we've done things that we haven't done.) Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
> >> Some widespread IPv4 stacks refuse to handle these addresses, so > >> nobody would ever want to use them on the public IPv4 Internet. > >> > > > > And some widespread IPv4 stacks, refuse to handle IPv6 addresses. > > > it seems likely that more hosts currently support IPv6 than > support use of these IPv4 addresses. why should we go to > more effort to gain a bit more life out of IPv4 than it takes > to transition to IPv6? Because the two are not mutually exclusive. And when companies begin to suffer significant dollar damages as a result of the IPv4 address shortage and start slinging unfair lawsuits around, we can get judge to quickly and CHEAPLY dismiss such lawsuits by demonstrating that we did not unfairly put roadblocks in the way of solutions that extend the life of IPv4. The IETF engineers protocols, not business models or technology choices. We should make choices available but not try to force people down only one road. It is not up to the IETF to engineer a transition to IPv6, merely to make the tools available. Freeing up the former class E space is an example of making a minor tool available, and it also sends a strong message that the IETF believes that IPv4's days are numbered, therefore there is no longer any need to reserve any portion of the IPv4 space for future use. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
One thing I'm pretty sure of is that allocating this space for another RFC1918-like private network block isn't going to solve the collision problem. I could see more utility in letting this be space for "router" use only, say to allow cable ISPs to assign such addresses to non-publicly accessible components in their networks. Such use would presumably have fewer deployment barriers than use as either ordinary public or private space. I could also see some utility in assigning smaller blocks from this space to enterprise networks, similar to ULIAs in IPv6. Such blocks could be used, for instance, to interconnect between private networks without address collisions. But for that kind of use I would assume that the deployment barriers would be much greater. Bottom line - I think that any proposal to reassign class E addresses needs to provide one or more specific use cases. And for each of those cases, it should consider deployment cost vs. benefit, and compare that to the cost vs. benefit of using IPv6. Keith > Keith, all, > > The common use case that people discuss is cable. My impression is > that CableLabs has done a pretty good job of driving IPv6 adoption in > cable modems for DOCSIS 3.0. The authors being from APNIC, I would > imagine there is a billion person problem (or so) to be solved? > > What I'd ask, therefore, is that the authors include in their > introduction answers to the following questions: > > 1. Should the address space be allocated to private networks? If so, > please give some examples of uses. > 2. If the space is to be allocated for global reachability, could you > please provide a current estimate as to how much time is bought? > > In addition, while I don't think the coding issues are all that > substantial, deployment issues could be sizable. Anyone planning to > make use of this address space because they have exhausted 10/8 should > CLEARLY be making plans to go to IPv6. Anyone expecting to avoid a > collision through the use of this space should be cautioned. > > Also the document should be in the same class as RFC 1918, which is a > BCP and not a standard. If you proceed, you might want to consider > obsoleting 1918 in favor of an abbreviated replacement, as much of the > text in that document is dated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Keith, all, The common use case that people discuss is cable. My impression is that CableLabs has done a pretty good job of driving IPv6 adoption in cable modems for DOCSIS 3.0. The authors being from APNIC, I would imagine there is a billion person problem (or so) to be solved? What I'd ask, therefore, is that the authors include in their introduction answers to the following questions: 1. Should the address space be allocated to private networks? If so, please give some examples of uses. 2. If the space is to be allocated for global reachability, could you please provide a current estimate as to how much time is bought? In addition, while I don't think the coding issues are all that substantial, deployment issues could be sizable. Anyone planning to make use of this address space because they have exhausted 10/8 should CLEARLY be making plans to go to IPv6. Anyone expecting to avoid a collision through the use of this space should be cautioned. Also the document should be in the same class as RFC 1918, which is a BCP and not a standard. If you proceed, you might want to consider obsoleting 1918 in favor of an abbreviated replacement, as much of the text in that document is dated. Regards, Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
[EMAIL PROTECTED] wrote: >> Some widespread IPv4 stacks refuse to handle these addresses, >> so nobody would ever want to use them on the public IPv4 Internet. >> > > And some widespread IPv4 stacks, refuse to handle IPv6 addresses. > it seems likely that more hosts currently support IPv6 than support use of these IPv4 addresses. why should we go to more effort to gain a bit more life out of IPv4 than it takes to transition to IPv6? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
> > >This document directs the IANA to designate the block of IPv4 > > >addresses from 240.0.0.0 to 255.255.255.255 > (240.0.0.0/4) as unicast > > >address space for limited use in large private Internets. > Some widespread IPv4 stacks refuse to handle these addresses, > so nobody would ever want to use them on the public IPv4 Internet. And some widespread IPv4 stacks, refuse to handle IPv6 addresses. I guess that means we should deprecate IPv6? Or should we merely update the software? In any case, the most worrying aspect of this is the number fo /8's that are proposed to be handed over for private use at a time when we are running short of IPv4 addresses. I would think that two /8s is more than enough. Assuming that these private users manage to resolve the technical issues of using former class E addresses, and get some vendors to update their software/firmware, then the rest of the /8's should be handed over to the RIRs for general use (with caveats). In much the same way as an applicant for an AS number can now specify that they will accept a 4-byte Asnum, these former class E addresses could be handed out to those who will accept it. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
Hi Daniel, [large snip] Very nice post, as usual. However, > Daniel Senie wrote: > Initially allowing blocks from this space as additional > RFC1918-style space would provide a playground where > enterprises, users and vendors could test their wares, > without risk to the public Internet. I have to disagree with that, and here's why: today: I already get a 10/8 address on my AT&T cell phone. Should 240/4 become an extension of RFC1918, it won't take operators long to deploy it to customers. In two years, I don't want to have to fork out another $600 for a cell phone because mine is not in the upgrade path anymore. Furthermore, I also use this phone as a wireless modem for a laptop and even if I get a new cell phone I don't want to have to replace that laptop because the PPP stack or some other component on it does not understand 240/4. > Microsoft updates desktops and servers weekly or more often, and > people are fearful enough of security matters that they do apply > them. Linux vendors similarly release patches quite often. Router > vendors seem to have new software for one fix or another daily. Only for "current" products. I don't think vendors will play ball nicely on this one. Note that I am not saying they are wrong or bad; I have shares of some of them; a reasonable amount of built-in obsolescence has always been there and is good for business. I don't think we should give vendors extra ammo to push yet another forklift upgrade though; as discussed above, this proposal has wider ramifications than private intranets. If it succeeds, it will force many people or organizations to upgrade to the latest software (which might not be free) or worse have to buy new hardware capable of running the latest software. > the changes required in IP stacks to enable Class-E as > valid addressing is minimal, resulting in little new code, > and thus little risk from untested code. The changes might not be limited to software. Remember the good old days with the classes based on the first bits: 0... Class A 10.. Class B 110. Class C 1110 Class D Class E I would not be surprise to find this hard-coded in the silicon of some hardware-optimized packet processing gear. In short: I acknowledge the very valid points you make. In the end though, even if I would have supported this a few years ago, I don't support it anymore. Too little too late; too small the carrot and a too big the stick. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
> Douglas Otis writes: > > The draft classifies Class-E as "Limited Use for Large Private Internets". > > What large private internets are these, really? Are we discussing Google > potentially needing more than one /8 for its web servers, or are we > discussing providers (DSL, Wimax, 802.11, GSM, 3G or other) giving > customers addresses from 240/4 via DHCP or PPP? > > Employees using 240/4 is one thing. Your mother-in-law getting > 247.1.76.22 from her cable modem is quite another. > > Arnt Cable companies need this amount of address space for controlling the CPE boxes. The customers still get public addresses. That's a minimum of two addresses per customer. Large corporations need more than a /8. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 9, 2007, at 12:11 PM, Arnt Gulbrandsen wrote: Douglas Otis writes: The draft classifies Class-E as "Limited Use for Large Private Internets". What large private internets are these, really? Are we discussing Google potentially needing more than one /8 for its web servers, or are we discussing providers (DSL, Wimax, 802.11, GSM, 3G or other) giving customers addresses from 240/4 via DHCP or PPP? Employees using 240/4 is one thing. Your mother-in-law getting 247.1.76.22 from her cable modem is quite another. It will likely take more than a handful of years before this range of addresses can be made universally usable as public IP addresses. Most unmodified equipment and software treat this range as non- routable. Without some incentive beyond altruism, the requisite changes will not occur in a timely manner. It would be wholly unfair to suggest to those late in asking that their assigned public address from this range. However, when employed as a private address, the equipment and software that must be upgraded can be ascertained, and those that would need to make upgrades are also both motivated and able to ensure requisite changes are made. A large company, Google, access providers and others will easily find 16 million addresses are easily exceeded. For example, by employing IPv4 to IPv6 proxies, large existing deployments might be readily transitioned to IPv6. When done at a large scale, each event would have the potential of freeing up a Class-E worth of unencumbered IPv4 addresses. With this in mind, perhaps IPv6 should be assigned in blocks of 268,435,456 to any large organization. : ) Yes, there will be considerable pain when using addresses within Class-E. For this to be resolved in a timeframe that has a chance of impacting the exhaustion of IPv4 addresses, these problems MUST BE resolved within the private address space. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
It's not just host stacks and routers that would be impacted by this change. Some applications recognize RFC 1918 addresses and treat them specially, realizing that they don't work like ordinary IP addresses. Such applications would need to be updated if another block of private addresses were created. It seems like the last thing we need is another set of private addresses in IPv4 space, especially when use of such addresses is likely to result in even more flakiness because of stack, router, and application assumptions. The existing arrangement with RFC 1918 addresses and NATs (sometimes multiple layers of NATs) is already flaky enough, and reuse of addresses already makes diagnosis of problems more difficult than it needs to be. (of course, that might make IPv4 so unusable that people would be forced to migrate to IPv6, which would be a Good Thing. but I don't like the idea of deliberately making IPv4 flakier.) If these addresses are going to be reclassified, they should either be public addresses (so that when problems did occur the nature of the problem would be relatively clear), or reserved for very limited uses that won't impact legacy hosts and applications. Keith > > If the IETF published an RFC that reassigned 240/4 to private address > space usage today, it would likely be possible for enterprises to use > it within a reasonably short period, perhaps a year or so, depending > on how many vendors they work with, and their ability to assert pressure. > > Let's look at the reality of software stacks in the present time. > Micorosoft updates desktops and servers weekly or more often, and > people are fearful enough of security matters that they do apply them. > Linux vendors similarly release patches quite often. Router vendors > seem to have new software for one fix or another daily. > > If enterprises started working toward a deployment of pieces of 240/4, > vendors would make it possible. > > A few of us looked at the Class-E issue some years ago, and thought it > was worthwhile at that time to reclassify the space. Everyone > understood it would take some time before the space was widely usable. > > If there's to be any use of the space, ever, a scenario that would get > us to usability might be: > > - Reclassify Class-E space as usable address space > > - Enable a few pieces of 240/4 as private address space use. Let > people start using that. > > - Enterprises, if there's interest will push vendors to make changes > to stacks > > - In a few years, evaluate whether the space is viable for public > assignment by ARIN, et. al. > > Even if the initial use of such space is limited to a few platforms > and routers, it may be sufficiently useful to enterprises to use in > private interconnects between companies, an area where significant > difficulties are encountered today due to address re-use. > > There will of course be a chorus of responses that if changes are > required anyway, folks should just migrate to IPv6. The > counter-argument I'd make is simple: the changes required in IP stacks > to enable Class-E as valid addressing is minimal, resulting in little > new code, and thus little risk from untested code. Initially allowing > blocks from this space as additional RFC1918-style space would provide > a playground where enterprises, users and vendors could test their > wares, without risk to the public Internet. > > For enterprises, the migration to IPv6 will be slow. The protocol > stacks from all of the vendors are largely untested. I don't mean they > haven't run code coverage, had QA teams and even interoperability > testing. I mean there is limited experience with wide scale networks, > high traffic volumes, exposure to denial of service and probing > attacks. There will be vulnerabilites, just as there is with any code > that's relatively new. > > As I believed several years ago, reclassifying 240/4 is worthwhile. > Leveraging the need of enterprises for additional, sanctioned, private > IPv4 space for interconnects may result in widescale implementation. > Or it might not. The point is, it would be relatively simple to find > out, and would not be overly distracting to the IETF or to efforts to > migrate to IPv6 . ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Douglas Otis writes: The draft classifies Class-E as "Limited Use for Large Private Internets". What large private internets are these, really? Are we discussing Google potentially needing more than one /8 for its web servers, or are we discussing providers (DSL, Wimax, 802.11, GSM, 3G or other) giving customers addresses from 240/4 via DHCP or PPP? Employees using 240/4 is one thing. Your mother-in-law getting 247.1.76.22 from her cable modem is quite another. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 8, 2007, at 12:20 PM, william(at)elan.net wrote: On Wed, 8 Aug 2007, Douglas Otis wrote: Some larger providers and private organizations who depend upon private IPv4 addresses have complained there is no suitably large "private" IP address range which can assure each user within their network can obtain a unique private IP address. It would seem class E could, and might already, function as a larger "private" IP address range. They also need to route it locally. Guess what kind of problems they'd run into... BTW, even if this draft were implemented (which would require changes to many operating systems, firewalls and local sites configs), it would just delay ipv4 exhausting by about 2 years, not allow to avoid it. What should be done is greater effort to migrate to ipv6 including supporting ideas like (some are from ppml): 1. requiring at all RIRs that new ipv4 requesters include data on plans to migrate to ipv6. 2. policy in all RIRs to make it very easy for any existing ipv4 holder to get ipv6 block with no additional fees 3. for vendors have ipv6 on by default on new systems and have it complain when it can not get ipv6 address from dhcp or can not do ipv6 routing, etc. That would put pressure on ISPs who will be asked about ipv6 more and more 4. requirements for ipv6 for renew of ISP contacts by government and educational institutions (also more pressure to ISPs) It would appear both you and I are in agreement with the draft. See: http://www.apnic.net/mailing-lists/sig-policy/archive/2007/08/ msg5.html The draft classifies Class-E as "Limited Use for Large Private Internets". This range should not be divided into smaller regions as some suggest. Large Private Internets that bridge into a IPv4/IPv6 Public Internet represents a well considered long-term strategy. Declaring this range available for use by Large Private Internets will expedite a reduction in the dependence and use of public IPv4 addresses. A bridge into the private IPv4 address space can map into unique IPv6 addresses while utilizing existing local equipment. (Yankee thrift.) IPv6 is how IP address exhaustion is prevented. Assigning Class-E as "Limited Use for Large Private Internets" provides a far less painful transition to IPv6. Adoption of this draft will help forestall an acceleration in IPv4 assignment rates. At present, allocating this range for public use will likely afford much less than a year. However, not declaring this range as private will deprive large organizations and providers of a very attractive IPv6 transition strategy. Once it becomes clear how this range of IP addresses might be used in conjunction with IPv6, broader adoption of IPv6 is more likely to occur with far less cajoling. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 9, 2007, at 12:37 PM, todd glassey wrote: Its not all wrong - only the Multicast Address space is mislabeled... ACK, but that is what I was referring too... Marshall T - Original Message - From: "Marshall Eubanks" <[EMAIL PROTECTED]> To: "Douglas Otis" <[EMAIL PROTECTED]> Cc: "Harald Alvestrand" <[EMAIL PROTECTED]>; "IETF discussion list" Sent: Wednesday, August 08, 2007 10:52 AM Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt On Aug 8, 2007, at 1:35 PM, Douglas Otis wrote: On Aug 8, 2007, at 3:02 AM, Harald Alvestrand wrote: What happened to draft-hain-1918bis-01, which tried to get more address space for private Internets, but expired back in 2005? I see the point about regarding 240.0.0.0/4 as "tainted space" and therefore being less than useful on the public Internet. RFC 3330 listed as not currently part of the public Internet: 0.0.0.0/8 "this" 16,777,216 10.0.0.0/8 "private" 16,777,216 127.0.0.0/8 "loopback" 16,777,216 169.254.0.0/16 "link-local" 65,536 172.16.0.0/12 "private" 1,048,576 192.0.2.0/24 "test-net" 256 192.168.0.0/16 "private" 65,536 192.18.0.0/15 "benchmark" 131,072 224.0.0.0/4 "multicast" 268,435,456 This is simply wrong. Multicast is certainly part of the public Internet, it is certainly used on the public Internet and (I might point out) people (including yours truly) make money from it. Regards Marshall Eubanks 240.0.0.0/4 "reserved" 268,435,466 - 587,569,816 (13.68% of total non- public) 4,294,967,296 (total) 3,707,397,480 (addresses public) Some larger providers and private organizations who depend upon private IPv4 addresses have complained there is no suitably large "private" IP address range which can assure each user within their network can obtain a unique private IP address. It would seem class E could, and might already, function as a larger "private" IP address range. -Doug ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Marshall, On Aug 9, 2007, at 4:38 AM, Marshall Eubanks wrote: If someone came out with a specific idea backed by hardware, though, is there a reason not to let them go forward ? I suspect it would be hard to say without knowing what the idea is... Rgds, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
This seems like the best course of action. Allocate 240/6 for private use as soon as practical and hold the rest of the E Class for private or public use as seems best later. Donald -Original Message- From: Daniel Senie [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 12:06 PM To: Marshall Eubanks Cc: ietf@ietf.org Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt ... If the IETF published an RFC that reassigned 240/4 to private address space usage today, it would likely be possible for enterprises to use it within a reasonably short period, perhaps a year or so, depending on how many vendors they work with, and their ability to assert pressure. Let's look at the reality of software stacks in the present time. Micorosoft updates desktops and servers weekly or more often, and people are fearful enough of security matters that they do apply them. Linux vendors similarly release patches quite often. Router vendors seem to have new software for one fix or another daily. If enterprises started working toward a deployment of pieces of 240/4, vendors would make it possible. A few of us looked at the Class-E issue some years ago, and thought it was worthwhile at that time to reclassify the space. Everyone understood it would take some time before the space was widely usable. If there's to be any use of the space, ever, a scenario that would get us to usability might be: - Reclassify Class-E space as usable address space - Enable a few pieces of 240/4 as private address space use. Let people start using that. - Enterprises, if there's interest will push vendors to make changes to stacks - In a few years, evaluate whether the space is viable for public assignment by ARIN, et. al. Even if the initial use of such space is limited to a few platforms and routers, it may be sufficiently useful to enterprises to use in private interconnects between companies, an area where significant difficulties are encountered today due to address re-use. There will of course be a chorus of responses that if changes are required anyway, folks should just migrate to IPv6. The counter-argument I'd make is simple: the changes required in IP stacks to enable Class-E as valid addressing is minimal, resulting in little new code, and thus little risk from untested code. Initially allowing blocks from this space as additional RFC1918-style space would provide a playground where enterprises, users and vendors could test their wares, without risk to the public Internet. For enterprises, the migration to IPv6 will be slow. The protocol stacks from all of the vendors are largely untested. I don't mean they haven't run code coverage, had QA teams and even interoperability testing. I mean there is limited experience with wide scale networks, high traffic volumes, exposure to denial of service and probing attacks. There will be vulnerabilites, just as there is with any code that's relatively new. As I believed several years ago, reclassifying 240/4 is worthwhile. Leveraging the need of enterprises for additional, sanctioned, private IPv4 space for interconnects may result in widescale implementation. Or it might not. The point is, it would be relatively simple to find out, and would not be overly distracting to the IETF or to efforts to migrate to IPv6 . ___ 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: I-D ACTION:draft-wilson-class-e-00.txt
Hello; On Aug 9, 2007, at 12:05 PM, Daniel Senie wrote: At 07:38 AM 8/9/2007, Marshall Eubanks wrote: On Aug 8, 2007, at 4:22 PM, David Conrad wrote: Hi, On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? I think it might be easier to identify stacks that don't disallow 240/4. I don't actually know of any widespread ones. I had a specific idea for 240 and asked around and didn't find any either. So, this means a year or two to develop and deploy at best, and probably a fork-lift upgrade at that, which does not seem that attractive. If someone came out with a specific idea backed by hardware, though, is there a reason not to let them go forward ? If the IETF published an RFC that reassigned 240/4 to private address space usage today, it would likely be possible for enterprises to use it within a reasonably short period, perhaps a year or so, depending on how many vendors they work with, and their ability to assert pressure. Let's look at the reality of software stacks in the present time. Micorosoft updates desktops and servers weekly or more often, and people are fearful enough of security matters that they do apply them. Linux vendors similarly release patches quite often. Router vendors seem to have new software for one fix or another daily. If enterprises started working toward a deployment of pieces of 240/4, vendors would make it possible. A few of us looked at the Class-E issue some years ago, and thought it was worthwhile at that time to reclassify the space. Everyone understood it would take some time before the space was widely usable. If there's to be any use of the space, ever, a scenario that would get us to usability might be: - Reclassify Class-E space as usable address space - Enable a few pieces of 240/4 as private address space use. Let people start using that. - Enterprises, if there's interest will push vendors to make changes to stacks I am specifically interested in assigned 1918 type space. In some applications, Enterprises need to connect directly, and having to deal with multiple address overlaps in 1918 space is a pain, to put it mildly. It would be nice if there was a 1918 RIR type entity that handed this out only for use off the public Internet. The other solution is to do this in PI space, which seems a waste. Regards Marshall - In a few years, evaluate whether the space is viable for public assignment by ARIN, et. al. Even if the initial use of such space is limited to a few platforms and routers, it may be sufficiently useful to enterprises to use in private interconnects between companies, an area where significant difficulties are encountered today due to address re-use. There will of course be a chorus of responses that if changes are required anyway, folks should just migrate to IPv6. The counter- argument I'd make is simple: the changes required in IP stacks to enable Class-E as valid addressing is minimal, resulting in little new code, and thus little risk from untested code. Initially allowing blocks from this space as additional RFC1918-style space would provide a playground where enterprises, users and vendors could test their wares, without risk to the public Internet. For enterprises, the migration to IPv6 will be slow. The protocol stacks from all of the vendors are largely untested. I don't mean they haven't run code coverage, had QA teams and even interoperability testing. I mean there is limited experience with wide scale networks, high traffic volumes, exposure to denial of service and probing attacks. There will be vulnerabilites, just as there is with any code that's relatively new. As I believed several years ago, reclassifying 240/4 is worthwhile. Leveraging the need of enterprises for additional, sanctioned, private IPv4 space for interconnects may result in widescale implementation. Or it might not. The point is, it would be relatively simple to find out, and would not be overly distracting to the IETF or to efforts to migrate to IPv6 . ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
At 07:38 AM 8/9/2007, Marshall Eubanks wrote: On Aug 8, 2007, at 4:22 PM, David Conrad wrote: Hi, On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? I think it might be easier to identify stacks that don't disallow 240/4. I don't actually know of any widespread ones. I had a specific idea for 240 and asked around and didn't find any either. So, this means a year or two to develop and deploy at best, and probably a fork-lift upgrade at that, which does not seem that attractive. If someone came out with a specific idea backed by hardware, though, is there a reason not to let them go forward ? If the IETF published an RFC that reassigned 240/4 to private address space usage today, it would likely be possible for enterprises to use it within a reasonably short period, perhaps a year or so, depending on how many vendors they work with, and their ability to assert pressure. Let's look at the reality of software stacks in the present time. Micorosoft updates desktops and servers weekly or more often, and people are fearful enough of security matters that they do apply them. Linux vendors similarly release patches quite often. Router vendors seem to have new software for one fix or another daily. If enterprises started working toward a deployment of pieces of 240/4, vendors would make it possible. A few of us looked at the Class-E issue some years ago, and thought it was worthwhile at that time to reclassify the space. Everyone understood it would take some time before the space was widely usable. If there's to be any use of the space, ever, a scenario that would get us to usability might be: - Reclassify Class-E space as usable address space - Enable a few pieces of 240/4 as private address space use. Let people start using that. - Enterprises, if there's interest will push vendors to make changes to stacks - In a few years, evaluate whether the space is viable for public assignment by ARIN, et. al. Even if the initial use of such space is limited to a few platforms and routers, it may be sufficiently useful to enterprises to use in private interconnects between companies, an area where significant difficulties are encountered today due to address re-use. There will of course be a chorus of responses that if changes are required anyway, folks should just migrate to IPv6. The counter-argument I'd make is simple: the changes required in IP stacks to enable Class-E as valid addressing is minimal, resulting in little new code, and thus little risk from untested code. Initially allowing blocks from this space as additional RFC1918-style space would provide a playground where enterprises, users and vendors could test their wares, without risk to the public Internet. For enterprises, the migration to IPv6 will be slow. The protocol stacks from all of the vendors are largely untested. I don't mean they haven't run code coverage, had QA teams and even interoperability testing. I mean there is limited experience with wide scale networks, high traffic volumes, exposure to denial of service and probing attacks. There will be vulnerabilites, just as there is with any code that's relatively new. As I believed several years ago, reclassifying 240/4 is worthwhile. Leveraging the need of enterprises for additional, sanctioned, private IPv4 space for interconnects may result in widescale implementation. Or it might not. The point is, it would be relatively simple to find out, and would not be overly distracting to the IETF or to efforts to migrate to IPv6 . ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 8, 2007, at 4:22 PM, David Conrad wrote: Hi, On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? I think it might be easier to identify stacks that don't disallow 240/4. I don't actually know of any widespread ones. I had a specific idea for 240 and asked around and didn't find any either. So, this means a year or two to develop and deploy at best, and probably a fork-lift upgrade at that, which does not seem that attractive. If someone came out with a specific idea backed by hardware, though, is there a reason not to let them go forward ? Regards Marshall Rather than wall off the space as private and thus put it beyond any use we should think about what other uses we might be putting it to. Calling address space private obviously does not "put it beyond any use". In fact, there are folks out there who are burning public IP address space for internal infrastructure that could instead be using private space but can't because their internal infrastructures are too large. Regards, -drc ___ 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: I-D ACTION:draft-wilson-class-e-00.txt
As for the address issue, I have to agree with PHB here as well: If these addresses are usable in a reasonable time frame then we shouldn't be quick to give them up for private use and if they are unusable in a reasonable time frame it really doesn't matter what we do with them. So I guess the question about stack support in different timeframe is interesting at least in the sense that it would tell us whether or not this is even worth the electrons we're using talking about it. "useable" is not a constant here. "useable" in the sense of the context of the public internet implies every host in the public Internet should be able to generate a packet with one of these addresses in the destination field be able to send it out an interface, every host in the public Internet should be able to receive a packet with one of these addresses in the source field, and every router in the public Internet should be able to forward a packet with one of these addresses in the source and/or destination field (and every firewall, NAT and other pieces of middleware). "useable" in a private context implies taking the above statement and /s/public Internet/private use context/ It should be evident that this distinction could be quite significant in certain private use contexts. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Not that I want to be in this argument, but I was intrigued by the name-dropping from folks who're not silly... Thanks for the compliment, I guess... Ned Freed wrote: > BTW, I suspect you are correct about about the IPv6 transition not being Pareto > efficient at the present time, but IMO the bigger issue is that it is widely > percieved as not even being Kaldor-Hicks efficient, due in large part to > address space exhaustion being seen as an externality. So there is a nice Wiki page about both, but the one about the latter says in part: "Another problem with Kaldor-Hicks efficiency is that it only considers private property and private income but does not take into account change in value of the Commons, Natural Environment, and other Externalities." I hadn't read the Wikipedia page on this before today, and IANAE, but this doesn't seem quite right to me. In particular, my understanding is that whether or not something is an externality depends on how the system is defined. I think this page (which was next in line in Google) explains it all better: http://www.reckon.co.uk/open/Pareto_improvements_and_Kaldor-Hicks_efficiency_criterion So, in this case, neither measure of efficiency blindingly obviously applies (the latter being a genaralisation of the former) since the items in question are very much part of a commons, natural environment or, whatever it means, an externality. I don't think so... The "efficency improvement" we're talking about here is someone switching from IPv4 to IPv6. We're both saying that we believe that under current conditions this is not "efficient" in either the Pareto efficiency sense, which basically just looks at whether or not the move benefits the person making the improvement while not hurting anyone else, or in the sense of Kaldor-Hicks, which allows for harm to others as long as there's an overall gain. A point made on the Wikipedia page (and with which I agree) is that Kaldor-Hicks is essentially a form of cost-benefit analysis. While you might argue that the way people perform these analyses uses different criteria than Kaldor-Hicks implies, I don't think you can make a case that people contemplating such a change don't look at costs and benefits in some way. The discussion about which stacks don't/could support these addresses in what timeframe, is more interesting IMO. My reason for commenting on this thread was to support PHB's assertion that getting some people with serious ecomonic chops involved would be a good idea. My remarks about efficiency were at most a side note - I'm sorry it has turned the discussion away from what IMO is the more important point. As for the address issue, I have to agree with PHB here as well: If these addresses are usable in a reasonable time frame then we shouldn't be quick to give them up for private use and if they are unusable in a reasonable time frame it really doesn't matter what we do with them. So I guess the question about stack support in different timeframe is interesting at least in the sense that it would tell us whether or not this is even worth the electrons we're using talking about it. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Not that I want to be in this argument, but I was intrigued by the name-dropping from folks who're not silly... Ned Freed wrote: BTW, I suspect you are correct about about the IPv6 transition not being Pareto efficient at the present time, but IMO the bigger issue is that it is widely percieved as not even being Kaldor-Hicks efficient, due in large part to address space exhaustion being seen as an externality. So there is a nice Wiki page about both, but the one about the latter says in part: "Another problem with Kaldor-Hicks efficiency is that it only considers private property and private income but does not take into account change in value of the Commons, Natural Environment, and other Externalities." So, in this case, neither measure of efficiency blindingly obviously applies (the latter being a genaralisation of the former) since the items in question are very much part of a commons, natural environment or, whatever it means, an externality. The discussion about which stacks don't/could support these addresses in what timeframe, is more interesting IMO. S. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 8, 2007, at 1:22 PM, David Conrad wrote: Hi, On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? I think it might be easier to identify stacks that don't disallow 240/4. I don't actually know of any widespread ones. Rather than wall off the space as private and thus put it beyond any use we should think about what other uses we might be putting it to. Calling address space private obviously does not "put it beyond any use". In fact, there are folks out there who are burning public IP address space for internal infrastructure that could instead be using private space but can't because their internal infrastructures are too large. The long term view for IPv4 employment should be an address space primarily used by internal networks. IPv4 is supported by a large array of SOHO equipment that will not disappear anytime soon. A near- term solution for IPv4 exhaustion will likely involve routers bridging between either private or public IPv4 address space into an Internet consisting of a mixture of IPv6 and IPv4. Internal use of IPv4 should accommodate internal deployments exceeding 16 million IP addresses. With rapid expansion of network equipment, 268 million addresses represents a far more reasonable range of addresses that rangers which are likely to be employed internally. Such a larger range of internal addresses could even encourage use of older IPv4 router equipment to support these larger internal networks. An aggressive strategy using this approach could be far more effective at postponing an enviable exhaustion of IPv4 addresses than would a year to few months reprieve a public assignment of the Class E space might provide. Not having a larger IPv4 private address space will cause existing IPv4 equipment to be less valuable when it can only be utilized within extremely limited address ranges by any particular organization. : ( BTW, there is a typo after 2. Caveats of Use Many implementations of the TCP/IP protocol stack have the 204.0.0.0/4 address... This should have been 240.0.0.0/4 addresses. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
> We need to get some real economists involved here and some real lawyers. We > do have some net-savy lawyers on tap, but economists are going to be harder to > find, or rather they are going to be easy to find but not so easy to find good > ones who are not peddling some ideology. I think getting some real economists involved is an excellent idea. As you say, ideology-peddlers (of all stripes) need to be avoided, but having some people who think about this from an economic perspective could be HUGELY beneficial. > Perhaps the folk at the LSE who designed the auction of wireless spectrum for > George Brown could help? It may not be the right group but it's a place to start. > What I want to know is how we establish the incentives that are necessary to > create the intended outcome. Exactly. For example, you might do something like make IPv4 allocations cheaper, or easer to get, or something along those lines, in exchange for deploying IPv6. (*) Perhaps this pool of addresses would best be saved for possible use as an incentive... BTW, I suspect you are correct about about the IPv6 transition not being Pareto efficient at the present time, but IMO the bigger issue is that it is widely percieved as not even being Kaldor-Hicks efficient, due in large part to address space exhaustion being seen as an externality. Of course that will eventually change, but it still may not drive things in the direction we want, and even if it does the resulting transition period will be a real mess. Ned (*) The example was Chris Newman's idea, not mine. And it is just an example - neither Chris nor I are economists and neither of us are making an actual proposal for an incentive here. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Hi, On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? I think it might be easier to identify stacks that don't disallow 240/4. I don't actually know of any widespread ones. Rather than wall off the space as private and thus put it beyond any use we should think about what other uses we might be putting it to. Calling address space private obviously does not "put it beyond any use". In fact, there are folks out there who are burning public IP address space for internal infrastructure that could instead be using private space but can't because their internal infrastructures are too large. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
If this really would buy us even a single year then we have to do it. Two years is the difference between a train wreck and an orderly transition. The question is whether we can buy any time with this change. That does not look very hopeful. But there might be opportunity. I certainly don't think that we should conclude on the basis of two data points that we should just abandon the whole address space. The point about requiring a transition plan to IPv6 might be a good one. I don't imagine that it would be very effecitve in coercing change but it could be effective in causing the hardware providers to converge on support for a viable transition strategy. This is politics, we need much more than an engineering strategy dictated from on high by a group with no members and no constituency. We need to get some real economists involved here and some real lawyers. We do have some net-savy lawyers on tap, but economists are going to be harder to find, or rather they are going to be easy to find but not so easy to find good ones who are not peddling some ideology. Perhaps the folk at the LSE who designed the auction of wireless spectrum for George Brown could help? What I want to know is how we establish the incentives that are necessary to create the intended outcome. From: william(at)elan.net [mailto:[EMAIL PROTECTED] Sent: Wed 08/08/2007 3:20 PM To: Douglas Otis Cc: Harald Alvestrand; IETF discussion list Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt On Wed, 8 Aug 2007, Douglas Otis wrote: > Some larger providers and private organizations who depend upon private IPv4 > addresses have complained there is no suitably large "private" IP address > range which can assure each user within their network can obtain a unique > private IP address. It would seem class E could, and might already, function > as a larger "private" IP address range. They also need to route it locally. Guess what kind of problems they'd run into... BTW, even if this draft were implimented (which would require changes to many operating systems, firewalls and local sites configs), it would just delay ipv4 exhausting by about 2 years, not allow to avoid it. What should be done is greater effrot to migrate to ipv6 including supporting ides like (some are from ppml): 1. requirying at all RIRs that new ipv4 requesters include data on plans to migrate to ipv6. 2. policy in all RIRs to make it very easy for any existing ipv4 holder to get ipv6 block with no additional fees 3. for vendors have ipv6 on by default on new systems and have it complain when it can not get ipv6 address from dhcp or can not do ipv6 routing, etc. That would put pressure on ISPs who will be asked about ipv6 more and more 4. requirements for ipv6 for renew of ISP contacts by government and educational institutions (also more pressure to ISPs) -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ 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: I-D ACTION:draft-wilson-class-e-00.txt
If a cable NAT box could survive on a tainted IPv4 we might well be able to find a use for them. I don't see how the addresses are any more viable as private space as public. Given the stakes with IPv4 allocations I would like to see a technical strategy in which the optimal course of action for all parties is to progress towards an orderly IPv6 transition. I do not beleive that transition to IPv6 is Pareto optimal today. I don't think that it makes sense to consider re-allocating any address space until we have such a strategy defined. It might make sense to tell IP stack providers that they should regard the block as routable IPv4 uncast at this point. I don't think it likely that we would roll out any new capablility for IPv4 at this point. From: Paul Hoffman [mailto:[EMAIL PROTECTED] Sent: Wed 08/08/2007 2:12 PM To: Hallam-Baker, Phillip; ietf@ietf.org Subject: RE: I-D ACTION:draft-wilson-class-e-00.txt At 10:18 AM -0700 8/8/07, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? And then you quoted a message that shows examples of some stacks: C:\>ver Microsoft Windows XP [Version 5.1.2600] C:\>ping -n 1 247.1.2.3 Pinging 247.1.2.3 with 32 bytes of data: Destination specified is invalid. Ping statistics for 247.1.2.3: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), --- % uname -ro 2.6.22-8-generic GNU/Linux % ping 247.1.2.3 connect: Invalid argument How many more do you think we need? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Wed, 8 Aug 2007, Douglas Otis wrote: Some larger providers and private organizations who depend upon private IPv4 addresses have complained there is no suitably large "private" IP address range which can assure each user within their network can obtain a unique private IP address. It would seem class E could, and might already, function as a larger "private" IP address range. They also need to route it locally. Guess what kind of problems they'd run into... BTW, even if this draft were implimented (which would require changes to many operating systems, firewalls and local sites configs), it would just delay ipv4 exhausting by about 2 years, not allow to avoid it. What should be done is greater effrot to migrate to ipv6 including supporting ides like (some are from ppml): 1. requirying at all RIRs that new ipv4 requesters include data on plans to migrate to ipv6. 2. policy in all RIRs to make it very easy for any existing ipv4 holder to get ipv6 block with no additional fees 3. for vendors have ipv6 on by default on new systems and have it complain when it can not get ipv6 address from dhcp or can not do ipv6 routing, etc. That would put pressure on ISPs who will be asked about ipv6 more and more 4. requirements for ipv6 for renew of ISP contacts by government and educational institutions (also more pressure to ISPs) -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
Title: RE: I-D ACTION:draft-wilson-class-e-00.txt At 10:18 AM -0700 8/8/07, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? And then you quoted a message that shows examples of some stacks: C:\>ver Microsoft Windows XP [Version 5.1.2600] C:\>ping -n 1 247.1.2.3 Pinging 247.1.2.3 with 32 bytes of data: Destination specified is invalid. Ping statistics for 247.1.2.3: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), --- % uname -ro 2.6.22-8-generic GNU/Linux % ping 247.1.2.3 connect: Invalid argument How many more do you think we need? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
At 10:35 AM -0700 8/8/07, Douglas Otis wrote: RFC 3330 listed as not currently part of the public Internet: I have elided the table that Doug posted. Doug: the sentence above made it sound like your table was taken from RFC 3330. It was not. And, as others have pointed out, your table was wrong. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 8, 2007, at 10:52 AM, Marshall Eubanks wrote: On Aug 8, 2007, at 1:35 PM, Douglas Otis wrote: On Aug 8, 2007, at 3:02 AM, Harald Alvestrand wrote: What happened to draft-hain-1918bis-01, which tried to get more address space for private Internets, but expired back in 2005? I see the point about regarding 240.0.0.0/4 as "tainted space" and therefore being less than useful on the public Internet. RFC 3330 listed as not currently part of the public Internet: 0.0.0.0/8 "this" 16,777,216 10.0.0.0/8 "private" 16,777,216 127.0.0.0/8 "loopback" 16,777,216 169.254.0.0/16 "link-local" 65,536 172.16.0.0/12 "private" 1,048,576 192.0.2.0/24"test-net"256 192.168.0.0/16 "private" 65,536 192.18.0.0/15 "benchmark" 131,072 224.0.0.0/4 "multicast" 268,435,456 This is simply wrong. Multicast is certainly part of the public Internet, it is certainly used on the public Internet and (I might point out) people (including yours truly) make money from it. You are right. Indeed Multicast is part of the public Internet. The concern has been with respect to availability of general purpose public IP addresses, where multicast would be excluded as would private IP addresses. This should have read "not currently part of the 'general use' public Internet." -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 8, 2007, at 1:35 PM, Douglas Otis wrote: On Aug 8, 2007, at 3:02 AM, Harald Alvestrand wrote: What happened to draft-hain-1918bis-01, which tried to get more address space for private Internets, but expired back in 2005? I see the point about regarding 240.0.0.0/4 as "tainted space" and therefore being less than useful on the public Internet. RFC 3330 listed as not currently part of the public Internet: 0.0.0.0/8 "this" 16,777,216 10.0.0.0/8 "private" 16,777,216 127.0.0.0/8 "loopback" 16,777,216 169.254.0.0/16 "link-local" 65,536 172.16.0.0/12 "private" 1,048,576 192.0.2.0/24"test-net"256 192.168.0.0/16 "private" 65,536 192.18.0.0/15 "benchmark" 131,072 224.0.0.0/4 "multicast" 268,435,456 This is simply wrong. Multicast is certainly part of the public Internet, it is certainly used on the public Internet and (I might point out) people (including yours truly) make money from it. Regards Marshall Eubanks 240.0.0.0/4 "reserved"268,435,466 - 587,569,816 (13.68% of total non- public) 4,294,967,296 (total) 3,707,397,480 (addresses public) Some larger providers and private organizations who depend upon private IPv4 addresses have complained there is no suitably large "private" IP address range which can assure each user within their network can obtain a unique private IP address. It would seem class E could, and might already, function as a larger "private" IP address range. -Doug ___ 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: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 8, 2007, at 3:02 AM, Harald Alvestrand wrote: What happened to draft-hain-1918bis-01, which tried to get more address space for private Internets, but expired back in 2005? I see the point about regarding 240.0.0.0/4 as "tainted space" and therefore being less than useful on the public Internet. RFC 3330 listed as not currently part of the public Internet: 0.0.0.0/8 "this" 16,777,216 10.0.0.0/8 "private" 16,777,216 127.0.0.0/8 "loopback" 16,777,216 169.254.0.0/16 "link-local" 65,536 172.16.0.0/12 "private" 1,048,576 192.0.2.0/24"test-net"256 192.168.0.0/16 "private" 65,536 192.18.0.0/15 "benchmark" 131,072 224.0.0.0/4 "multicast" 268,435,456 240.0.0.0/4 "reserved"268,435,466 - 587,569,816 (13.68% of total non-public) 4,294,967,296 (total) 3,707,397,480 (addresses public) Some larger providers and private organizations who depend upon private IPv4 addresses have complained there is no suitably large "private" IP address range which can assure each user within their network can obtain a unique private IP address. It would seem class E could, and might already, function as a larger "private" IP address range. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-wilson-class-e-00.txt
Which widespread IPv4 stacks? Given that we have a shortage of IPv4 space I cannot see how we could possibly put a quarter billion IPv4 addresses beyond use just because a number of unspecified IPv4 stacks have issues. Rather than wall off the space as private and thus put it beyond any use we should think about what other uses we might be putting it to. >From a PR point of view this plays very baddly. It reads as IPv6 zealots >eagerly bringing the crisis point nearer by a notch. We need to change the way that this transition is being managed Unless we get the stakeholders round the table and stop trying to dictate terms through technical unilateral specifications we are going to end up with the result that we like least and are trying to avoid. The wargames do not point to an inevitable transition to IPv6. If you play them honestly they lead to a heavily NAT-ed model where the large ISPs are free to re-establish the walled garden model that keeps re-appearing. This is brinksmanship diplomacy. It has a very poor record. From: Rémi Denis-Courmont [mailto:[EMAIL PROTECTED] Sent: Wed 08/08/2007 3:40 AM To: ietf@ietf.org Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt On Wednesday 08 August 2007 10:14:03 ext Brian E Carpenter wrote: > On 2007-08-07 16:15, [EMAIL PROTECTED] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Redesignation of 240/4 from 'Future Use" to "Limited > > Use for > > Large Private Internets' Author(s) : P. Wilson, et al. > > Filename: draft-wilson-class-e-00.txt > > Pages : 4 > > Date: 2007-8-7 > > > >This document directs the IANA to designate the block of IPv4 > >addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast > >address space for limited use in large private Internets. > > It seems to me that we first need a discussion about why this space can't > be released as public address space. Is it known to be already deployed > as de facto private space? Some widespread IPv4 stacks refuse to handle these addresses, so nobody would ever want to use them on the public IPv4 Internet. --- C:\>ver Microsoft Windows XP [Version 5.1.2600] C:\>ping -n 1 247.1.2.3 Pinging 247.1.2.3 with 32 bytes of data: Destination specified is invalid. Ping statistics for 247.1.2.3: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), --- % uname -ro 2.6.22-8-generic GNU/Linux % ping 247.1.2.3 connect: Invalid argument -- Rémi Denis-Courmont ___ 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: I-D ACTION:draft-wilson-class-e-00.txt
seems like the last thing the Internet needs is more private address space. Keith >> >>This document directs the IANA to designate the block of IPv4 >>addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast >>address space for limited use in large private Internets. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Carsten Bormann writes: Cheaper to use IPv6, then. Non-starter, I'd say. I'm not sure using this class e thing + ipv6 is significantly more expensive than using either alone, so we may be looking at way to let some people transition with less pain: A big network can grow bigger before some hosts have to use pure 6. Whether that makes the reclassification worthwhile is another matter. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Aug 08 2007, at 10:16, Arnt Gulbrandsen wrote: If example.com wants to use them, example.com will have to upgrade its own computers and routers to a version which supports this new class E. Nontrivial, rather expensive, but doable. Cheaper to use IPv6, then. Non-starter, I'd say. Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
What happened to draft-hain-1918bis-01, which tried to get more address space for private Internets, but expired back in 2005? I see the point about regarding 240.0.0.0/4 as "tainted space" and therefore being less than useful on the public Internet. Harald Brian E Carpenter wrote: On 2007-08-07 16:15, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title: Redesignation of 240/4 from 'Future Use" to "Limited Use for Large Private Internets' Author(s): P. Wilson, et al. Filename: draft-wilson-class-e-00.txt Pages: 4 Date: 2007-8-7 This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for limited use in large private Internets. It seems to me that we first need a discussion about why this space can't be released as public address space. Is it known to be already deployed as de facto private space? I'd be a bit nervous about unintended side effects if DHCP assigned me 255.255.255.255/32. Brian ___ 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: I-D ACTION:draft-wilson-class-e-00.txt
Brian E Carpenter writes: On 2007-08-08 09:40, Rémi Denis-Courmont wrote: ... Some widespread IPv4 stacks refuse to handle these addresses, so nobody would ever want to use them on the public IPv4 Internet. That will be a bit of a challenge in private networks too :-) Much smaller. If example.com wants to use them, example.com will have to upgrade its own computers and routers to a version which supports this new class E. Nontrivial, rather expensive, but doable. If you were to get 240.24.42/24 from your RIR, most/all of the public internet would have to upgrade before you could use the addresses. (Kind of like IPv6 but with a piddly little address space.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On 2007-08-08 09:40, Rémi Denis-Courmont wrote: ... Some widespread IPv4 stacks refuse to handle these addresses, so nobody would ever want to use them on the public IPv4 Internet. That will be a bit of a challenge in private networks too :-) Brian --- C:\>ver Microsoft Windows XP [Version 5.1.2600] C:\>ping -n 1 247.1.2.3 Pinging 247.1.2.3 with 32 bytes of data: Destination specified is invalid. Ping statistics for 247.1.2.3: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), --- % uname -ro 2.6.22-8-generic GNU/Linux % ping 247.1.2.3 connect: Invalid argument ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On Wednesday 08 August 2007 10:14:03 ext Brian E Carpenter wrote: > On 2007-08-07 16:15, [EMAIL PROTECTED] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Redesignation of 240/4 from 'Future Use" to "Limited > > Use for > > Large Private Internets' Author(s) : P. Wilson, et al. > > Filename: draft-wilson-class-e-00.txt > > Pages : 4 > > Date: 2007-8-7 > > > >This document directs the IANA to designate the block of IPv4 > >addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast > >address space for limited use in large private Internets. > > It seems to me that we first need a discussion about why this space can't > be released as public address space. Is it known to be already deployed > as de facto private space? Some widespread IPv4 stacks refuse to handle these addresses, so nobody would ever want to use them on the public IPv4 Internet. --- C:\>ver Microsoft Windows XP [Version 5.1.2600] C:\>ping -n 1 247.1.2.3 Pinging 247.1.2.3 with 32 bytes of data: Destination specified is invalid. Ping statistics for 247.1.2.3: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), --- % uname -ro 2.6.22-8-generic GNU/Linux % ping 247.1.2.3 connect: Invalid argument -- Rémi Denis-Courmont ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
On 2007-08-07 16:15, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Redesignation of 240/4 from 'Future Use" to "Limited Use for Large Private Internets' Author(s) : P. Wilson, et al. Filename: draft-wilson-class-e-00.txt Pages : 4 Date: 2007-8-7 This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for limited use in large private Internets. It seems to me that we first need a discussion about why this space can't be released as public address space. Is it known to be already deployed as de facto private space? I'd be a bit nervous about unintended side effects if DHCP assigned me 255.255.255.255/32. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
