There should be an I-D released soon proposing an update to 1918 to expand the private IPv4 space as draft-hain-1918bis-00.txt. As far as redefining 224/4; it is likely going to be impossible to redefine this space as no one really knows what it is being used for. In addition, there may be special handling in deployed stacks that will be impossible to replace in any reasonable timeframe. Tony > -----Original Message----- > From: ietf-admin@xxxxxxxx [mailto:ietf-admin@xxxxxxxx] On Behalf Of Geoff > Huston > Sent: Tuesday, April 20, 2004 5:26 AM > To: Iljitsch van Beijnum; IETF Discussion > Subject: Re: [Ietf] 240.0.0.0/4 > > [Just to be pedantic ( :-) ) there are the equivalent of 219.98 'useable' > unicast IPv4 addresses if you use a unit of /8s (16,777,216 /32 > addresses) (by my reading of the IANA IPv4 address registry plus > RFC3330).] > > You appear to be saying that using 224.0.0.0/4 in contexts such as used > by the current RFC 1918 space does not sacrifice 'usable' unicast > address space. Surely, however, if these addresses are 'useable' in 1918 > contexts they would be equally useable in a global context? > > As a more general comment on your proposal, it appears that the > consumption rates of address space in the Internet for the past four > years are best modelled by a constant growth model of just under 4 /8s > per year (http://bgp.potaroo.net/ipv4/). That class E space is some 4 > years of current average IPv4 address consumption rates. > > I personally do not see any value in using this address block up in a > 1918 role. My reasoning for this view is that life would be getting > mildly interesting if we ever reach the point when we are forced to use > this space, but life could be interesting a little sooner if we act now > to burn up this space for use in private / closed network contexts and > thereby make it completely unavailable to the public network. i.e. I > hope that collectively we, for some suitably large value of "we", will > manage this evolving situation so that the public Internet _never_ needs > to clamber into using the Class E space to sustain the continued growth > of the IPv4 public addressed network for some further extension of time > before the unallocated address pool completely dries up, but, for me, it > is some small comfort to know that if we do reach the point we we've > managed to assign, allocate and otherwise distribute these 219.98 /8 > addresses, there is something left in the address cupboard marked 'E" > that conceivably is there to use if we really _have_ to. > > > Geoff Huston > > > > > > At 06:19 PM 20/04/2004, Iljitsch van Beijnum wrote: > >I was wondering if there are any plans to change the status of the class > E > >address space (240.0.0.0 - 255.255.255.255). > > > >Currently, there are approximately 221 usable /8s: classes A (125), B > (64) > >and C (32). (0.0.0.0/8, 10.0.0.0/8 and 127.0.0.0/8 aren't usable at this > >time.) Adding 16 /8s from class E space would increase this by 7%, and > >increase the unused address space with something like 20%. > > > >However, it's almost certain that there are implementations out there > that > >won't accept 224.0.0.0/4 as regular unicast address space. So if we want > >to be able to use class E space as such, it is imperative that we > announce > >this a *very* long time in advance. > > > >Two other possible uses: > > > >It seems that there are now organizations who want/need more private > >address space than is available as per RFC 1918. Using class E space for > >this would make a lot of sense as this allows for a lot of private space > >without sacrificing usable unicast space. > > > >In large networks, a lot of address space is used up and/or fragmented > for > >point to point links and other infrastructure use. Using class E space > for > >this could be a good compromise between using regular unicast space on > the > >one hand or RFC 1918 space on the other hand. > > > >Thoughts? > > > >And is there a wg that deals / should deal with this issue? > > > >Iljitsch van Beijnum > > > > > >_______________________________________________ > >Ietf mailing list > >Ietf@xxxxxxxx > >https://www1.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf