Subject: [Ietf] 240.0.0.0/4

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Apr 2004 10:19:49 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Mark Smith <[email-masked]>
Date: Tue, 20 Apr 2004 18:29:29 +0930

Hi Iljitsch, 

On Tue, 20 Apr 2004 10:19:49 +0200
Iljitsch van Beijnum <[email-masked]> 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.

Presuming this extra "RFC1918" address space is going to be used
in conjunction with NAT (a reasonable assumption I would
suspect), I'd question any IETF endorsed measures which would
encourage further adoption or use of NAT.

I would suggest that if all the RFC1918 address space isn't big
enough, it is time for the organisation in question to start
deploying IPv6. Plenty of address space there, and no NAT
uglyness.

HTH,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 20 Apr 2004 18:29:29 +0930

Hi Iljitsch, 

HTH,
Mark.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 20 Apr 2004 22:26:12 +1000

[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:
>
>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?
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 20 Apr 2004 22:26:12 +1000

Geoff Huston

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Apr 2004 20:22:59 +0200

> contexts they would be equally useable in a global context?

I don't think this is the case. If an organization were to adopt 
addresses from 224.0.0.0/4 for use in an RFC 1918-like fashion, they 
would only have to make sure that all their internal systems are able 
to treat class E addresses as regular unicast addresses. However, class 
E addresses would only be globeally useable if and when all systems 
connected to the net throughout the globe are able to use them as 
regular unicast addresses.

> 1918 role.

I tend to agree, not having heard the case for additional private space.

> My reasoning for this view is that life would be getting
> to burn up this space for use in private / closed network contexts

I'm not sure whether you are trying to optimize for an interesting or a 
less interesting life...

> and
> to clamber into using the Class E space

Why?

The addresses are there. Leaving them unused while address assignment 
policies grow more strict over time doesn't make much sense.

> for me, it

My comfort level would be much higher if by the time that we need the 
extra address space, we have a fighting chance of actually being able 
to use it. So I think it would be a good idea to make it very clear 
that implementations must, in the absence of more specific information, 
regard class E space as regular unicast space, the same way the IPv6 
addressing RFCs spell this out for IPv6 address space that hasn't 
received a specific purpose yet. If we do this now we have ten years or 
more to clean up implementations.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Apr 2004 20:22:59 +0200

Why?

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 20 Apr 2004 12:16:46 -0700

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: [email-masked] [mailto:[email-masked]] 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
> 
> (64)
> that
> for

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 20 Apr 2004 12:16:46 -0700

Tony

---

From: Dean Anderson <[email-masked]>
Date: Tue, 20 Apr 2004 17:08:53 -0400 (EDT)

> space without sacrificing usable unicast space.

Can you elaborate?  I used to work for Hitachi, which is/was then the 7th
largest company in the world.  I can think of very few organizations that
need more than 1 /8 and 17 /16's of unique, non-public space.

Allowing a non-global address space as a subset of the global space means
that one (or many) can reach the public network through a default route
that leads to a NAT.  But if you have such a large network that it has
something greater than 20 million hosts that must each have direct access
to any of the rest, and you can't NAT internally, then you probably have
reached a point where you will need a more sophisticated mechanism than
NAT to reach the public internet.

Underlying this is the question of whether such a large network really
needs to simultanously reach the public network. If it doesn't, then there
is no reason to limit oneself to the RFC 1918 space.

I might also suggest that such a heavy address user migrate to IPv6
internally as IPv6 has similar problems and it is developing means to deal
with them.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 20 Apr 2004 17:08:53 -0400 (EDT)

--Dean

---

From: Geoff Huston <[email-masked]>
Date: Wed, 21 Apr 2004 08:54:51 +1000

I believe we are in complete agreement when you say:

>extra address space, we have a fighting chance of actually being able to 
>use it. So I think it would be a good idea to make it very clear that 
>implementations must, in the absence of more specific information, regard 
>class E space as regular unicast space, the same way the IPv6 addressing 
>RFCs spell this out for IPv6 address space that hasn't received a specific 
>purpose yet. If we do this now we have ten years or more to clean up 
>implementations.

The reason why I responded to your original proposal was that I understood
you were advocating that this space should be used to extend the
private use RFC 1918 space, whereas I am advocating the view that
this space should be considered part of the global use IPv4 unicast address
pool. My apologies if I misunderstood what you were proposing.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Wed, 21 Apr 2004 08:54:51 +1000

Geoff

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 20 Apr 2004 16:58:36 -0700

Dean Anderson wrote:
> ...
> something greater than 20 million hosts
                                   ^^^^^^^
Fatal flaw... The concept of a network is not limited to the traditional
perspective of 'hosts'. 

> that must each have direct access

You assume a network & traffic model that may not apply.

> is no reason to limit oneself to the RFC 1918 space.

Yes there is when some of the nodes do need access to the public network.
You can't expect to use a private version of a publicly routed prefix.

> internally as IPv6 has similar problems and it is developing means to deal

Easy to say, but turning something with that mass takes more time than the
dentist office network. Yes it is the right thing to do, but don't expect it
to happen in a timeframe shorter than 3-5 years. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 20 Apr 2004 16:58:36 -0700

^^^^^^^

Tony

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Apr 2004 15:53:10 -0700

Iljitsch,

>purpose yet. If we do this now we have ten years or more to clean up 

The only way to make this happen would be to start assigning them to some 
real users.  Otherwise, the bugs will not be found, reported, and 
fixed.  Just publishing an RFC with a MUST in it won't be sufficient.

The challenge here is that there may be a lot of IPv4 implementations may 
have little or any support, and may not be possible to upgrade.  This would 
put anyone receiving a Class-E address at a big disadvantage.  These 
addresses might have to be used behind a NAT to be useful (i.e., allow 
direct communication to the rest of the Internet) and this, of course, 
defeats the purpose of using them in the first place.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Apr 2004 15:53:10 -0700

Iljitsch,

Bob

---

From: Dean Anderson <[email-masked]>
Date: Wed, 21 Apr 2004 09:31:52 -0400 (EDT)

> Fatal flaw... The concept of a network is not limited to the traditional

Ok, fair enough. Instead of "hosts" in the traditional sense, the above
should be considered as '... approximately 20 million simultaneous uses of
unique IP addresses'.

> > that must each have direct access to any of the rest, and you can't
> > NAT internally, then you probably have reached a point where you will
> > need a more sophisticated mechanism than NAT to reach the public
> > internet.
> 

_I_ don't make that assumption. This was asserted by the person who
suggests that there is not enough private IP address space. Otherwise,
they would not need more than 20 million unique private IP addresses.  

Either we accept it as a given that they really do need more than ~20
million unique private IP addresses and also do need to reach the public
network, or else assert that perhaps no one really needs more than ~20
million unique, private IP addresses while also needing to reach a public
network. Or alternately, assert that if such a case does exist, then it is
so unusual that some more sophisticated mechanism is needed for that case.  

> You can't expect to use a private version of a publicly routed prefix.

I don't think you understood my text. I meant "If it doesn't [need access
to the public network], then there is no reason to limit oneself to the
RFC 1918 space"

> to happen in a timeframe shorter than 3-5 years. 

That is the same (or perhaps shorter) lifetime as changing the class E
definition. 

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 21 Apr 2004 09:31:52 -0400 (EDT)

--Dean

---

From: Fred Templin <[email-masked]>
Date: Wed, 21 Apr 2004 13:12:40 -0700

Tony,

Tony Hain wrote:

>this space as no one really knows what it is being used for.
>

Did you mean to say 224/4, or 240/4 - or perhaps both?

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 21 Apr 2004 13:12:40 -0700

Tony,

Thanks - Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 22 Apr 2004 11:46:30 -0700

Please forgive the typeo... it should be 240

> From: Fred Templin [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2004 1:13 PM
> To: Tony Hain
> Cc: 'Geoff Huston'; 'Iljitsch van Beijnum'; 'IETF Discussion'

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 22 Apr 2004 11:46:30 -0700

> so unusual that some more sophisticated mechanism is needed for that case.

You appear to overlook the case that H-D ratios apply to large complex
enterprise networks just as they do to ISPs. Also, it is not necessary for
all nodes to need public access. As soon as any do there is a need to avoid
using any public prefixes on the internal network.

> to the public network], then there is no reason to limit oneself to the

I understand what you wrote, but I think you are being overly simplistic. In
some scenarios it is very likely that only 5% of the nodes need public
access. This creates a situation where acquiring more public allocation is
impossible due to current policy. At the same time there is no room to grow
without guessing which /8's are going to be allocated last.

> That is the same (or perhaps shorter) lifetime as changing the class E

Changing the Class E definition will take longer because people will be less
inclined to change an IPv4 stack until it clearly breaks. At that point it
is generating support calls so the reality is people will do whatever they
can to avoid using Class E addresses.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 22 Apr 2004 11:46:30 -0700

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 22 Apr 2004 11:46:30 -0700

Tony

---

From: Daniel Senie <[email-masked]>
Date: Fri, 23 Apr 2004 08:37:07 -0400

At 06:53 PM 4/20/2004, Bob Hinden wrote:
>>RFCs spell this out for IPv6 address space that hasn't received a 
>>specific purpose yet. If we do this now we have ten years or more to 
>>clean up implementations.
>

No, it won't. What's being suggested is that we get such a document out 
SOON, so that by the time there's a need to use this space, there's a 
chance of having it be usable.

Devices grow old and die, just as companies do. If a document were 
published today, it might be 5 or 10 years before devices that treat class 
E space specially are either upgraded or face end of life.

If we do nothing now, then there's no chance of ever using the space. 
Please take a step back and look at a calendar covering the next decade or 
two. I know lots of folks would like that calendar to show a timeline for 
IPv6 deployment.

>have little or any support, and may not be possible to upgrade.

Will they be around in 10 years? Some, perhaps. Others may well have died 
by then. The document has to set a target, not define the path.

>   This would put anyone receiving a Class-E address at a big 
> disadvantage.  These addresses might have to be used behind a NAT to be 
> useful (i.e., allow direct communication to the rest of the Internet) and 
> this, of course, defeats the purpose of using them in the first place.

I don't think this is the only alternative.

My suggestion:

1) Move forward with a document as proposed, requiring implementations to 
treat class E space as unicast space. Target 5 or 10 years after 
publication as the earliest time space from the block could be allocated 
for use by RIRs.

2) Make available several chunks of space for RFC1918 usage, perhaps a few 
/8's, a whole mess of /12's, and many /16's. This space does two things: 
First, it provides additional private address space, which is needed. 
Second, it provides a usage battleground for class E space testing. There 
is the very real possibility users of these blocks will run into trouble as 
vendors have special handling for class E. By allowing these to be 
discovered during use in private networks, there is a much better chance of 
public usage of these blocks later.

I do NOT agree that the entire class E space should go to RFC 1918. That 
seems wasteful. But using some large chunks of space for that purpose 
clearly provides a test bed to prove out equipment before eventual public 
address usage in that region of IP address space.

Dan

---

From: Daniel Senie <[email-masked]>
Date: Fri, 23 Apr 2004 08:37:07 -0400

My suggestion:

Dan

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Apr 2004 13:26:16 -0400

On 23 Apr 2004, at 08:37, Daniel Senie wrote:

> 2) Make available several chunks of space for RFC1918 usage, perhaps a 
> few /8's, a whole mess of /12's, and many /16's. This space does two 
> things: First, it provides additional private address space, which is 
> needed.

It is?

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Apr 2004 13:26:16 -0400

It is?