240/4

Mailman List Mirror (Read Only)
1

vince,

thanks for your presentation on 240/4. i agree with it all. two points

do not hard-code address boundaries and special addresses, as we are
likely to regret doing so. two sub-lessons, ula and any other bright
ideas. "Those who cannot remember the past are condemned to repeat it."
-- George Santayana

my first thought on how to use it revolved around the idea that the
devices inside my site are more diverse than those on the transit
internet. therefore, if i can use 240/4 internally, certainly we will
all be able to transit it. where this died was the realization that, if
i want to transit 240/4, i am expecting all the devices in *your*
network to be able to handle 240/4, which is not reasonable. so i guess
i come down on the private use side of the how-to-use decision. i would
be interested in hearing counter-arguments.

again, thanks for the preso and the work. and i presume my ciscos will
soon be able to handle 240/4 at no additional hardware cost. :slight_smile:

randy

2

240/4 is tainted. The fact that some code exist somewhere to make it work is
good, but the reality is that there are tons of equipment that do not
support it. Deploying a large network with 240/4 is a problem of the same
scale as migrating to IPv6, you need to upgrade code, certify equipment,
etc...

Randy pointed out rightly, this is not only your network that needs
upgrading, this is all the networks who communicate with you that needs
upgrading.

So, classifying 240/4 as public use is unrealistic now and will remain
unrealistic in the near future.

Classifying it as private use should come with the health warning "use this
at your own risk, this stuff can blow up your network". In other words, this
is for experimental use only.

    - Alain.

3

Randy pointed out rightly, this is not only your network that needs
upgrading, this is all the networks who communicate with you that needs
upgrading.

So, classifying 240/4 as public use is unrealistic now and will remain
unrealistic in the near future.

agree

Classifying it as private use should come with the health warning "use this
at your own risk, this stuff can blow up your network". In other words, this
is for experimental use only.

disagree. as you point out, this is analogous to deploying ipv6; i do
not think you would want us to put an "experimental" warning on that. if
you certify your kit to handle it, then it will work in production.

randy

4

I'm trying to avoid setting the expectation that 240/4 is just a simple
extension to 10/8 and thus people should use it *today* when they run out of
space in RFC1918. Thus the health warning.

  - Alain.

5

Do we need to classify anything (yet)?

I say the proof is in the pudding. Once some major user decides they'll need 240/4 for something, they'll end up knocking their vendors' (probably dozens) and their own ops folks' doors. Once they get those vendors fixed up to support 240/4 in all the releases that they're interested in, and ops to change configs, they can deploy something in 240/4 for whatever (most likely private use, or private use with a NAT to the outside).

If the users decide that maybe doing the legwork is too difficult.. well, maybe that's a sign that deploying 240/4 isn't worth the trouble (yet) and reclassifying would also be premature.

It's not like the IETF or any other body is holding 240/4 hostage or something. It's what the vendors' code and what ops folks have configured that matters. If the code and configs can be changed and widely deployed, we have some proof that doing this might make sense at least in some context. Prior to that, there is no need to do anything.

6

Classifying it as private use should come with the health warning "use this
at your own risk, this stuff can blow up your network". In other words, this
is for experimental use only.

Do we need to classify anything (yet)?

Yes.

I say the proof is in the pudding. Once some major user decides they'll need 240/4 for something, they'll end up knocking their vendors' (probably dozens) and their own ops folks' doors. Once they get those vendors fixed up to support 240/4 in all the releases that they're interested in, and ops to change configs, they can deploy something in 240/4 for whatever (most likely private use, or private use with a NAT to the outside).

It would behoove us to allocate SOME of 240/4 as private address space, and mark the rest as "future, allocatable if it's deemed possible." If all of 240/4 is given over without guidance to private address use, a huge mess will follow, should we later decide it safe to use on the public network.

If the users decide that maybe doing the legwork is too difficult.. well, maybe that's a sign that deploying 240/4 isn't worth the trouble (yet) and reclassifying would also be premature.

It's not like the IETF or any other body is holding 240/4 hostage or something.

Yes, actually, it's specifically reserved, and it's in a block above multicast. I'm sure I was not the only one who saw that and said "this probably won't be 'normal' address space." If it's going to be used as unicast space, then it'd be helpful for an RFC to say so. However, I doubt that would happen, as it will likely be shouted down by those who see it as a threat to IPv6 deployment.

  It's what the vendors' code and what ops folks have configured that matters. If the code and configs can be changed and widely deployed, we have some proof that doing this might make sense at least in some context. Prior to that, there is no need to do anything.

Make a few /8's out of it available for experimental, private use. See what happens. But don't just throw the entire /4 out there for private use. We may later find it actually usable (or we may not) and want to visit that possibility later.

7

Daniel Senie wrote:

If all of 240/4 is given over without guidance to private address use, a
huge mess will follow, should we later decide it safe to use on the public network.

Nobody would allow that to happen. Once it goes RFC1918, it would never go back.

Adding four /8's to the IPv4 RIR assignable space (as you suggest) isn't buying anyone any time before we run out.

The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities.

-David

8

* Pekka Savola:

Do we need to classify anything (yet)?

I say the proof is in the pudding. Once some major user decides
they'll need 240/4 for something, they'll end up knocking their
vendors' (probably dozens) and their own ops folks' doors.

If there's risk that we'll see end user assignments from 240/4 at any
time in the future, this certainly reduces the set of possible
experiments even further. So I think it makes sense to designate part
of it as "private use, not subject to allocation" if anybody sees any
benefit from encouraging experimentation.

9

After the pain felt by 69/8, 70/8, 71/8, and others, you'd think it would
almost be enough to make a provider say "screw it" and go IPv6-only. :slight_smile:

10

I agree. The current rate at which blocks of IPv4 space are being allocated to the RIRs suggests that releasing a chunk from, say, 240/5 or 248/5 for consumption gets you about 1 year, tops.

jms

11

Daniel Senie wrote:

If all of 240/4 is given over without guidance to private address use, a
huge mess will follow, should we later decide it safe to use on the public network.

Nobody would allow that to happen. Once it goes RFC1918, it would never go back.

Adding four /8's to the IPv4 RIR assignable space (as you suggest) isn't buying anyone any time before we run out.

No. It would provide a play space where this could be explored further, and may be of use for private interconnects between some companies. It would not hurt anything to allocate this space.

The effort someone would spend figuring out if 204/4 is reachable and not-pain-inducing in their infrastructure is better spent figuring out how to make IPv6 work within their sphere of responsibilities.

The code changes to solid, proven IPv4 stacks to allow 240/4 to work are likely to expose enterprises to very little risk. Certainly we can expect it to be a lot less risk than IPv6 stacks which are at this point largely unproven. Adding additional IPv4 space from 240/4 may well buy enterprises enough time in the IPv4 world for IPv6 to receive sufficient code coverage and native deployment for corporations to accept the risk of introducing IPv6 on a broad scale.

I know you're trying to beat the drum that everyone should get off their posteriors and roll out IPv6, but every time I go research another product that'd be needed, it's not ready. The latest was in reading the release notes for firewalls from one vendor. Sure the boxes will handle IPv6 in some fashion, but oh, sorry, you wanted to deploy a redundant pair of firewalls? The stateful synchronization isn't ready yet.

Given the relative simplicity of the code change to activate 240/4 in an IPv4 stack, it's likely all major vendors could have patches out for allowing its use in private networks with little risk and little expendature of time. It's quite likely such changes could be out a very long time before IPv6 stacks in firewalls, routers and hosts receive sufficient testing to be deemed safe.

12

A year is good. My recommendation would be to adamantly refuse to let the RIRs
assign it for public space and insist that it's for experimental use only,
even though these days the place for research is IPv6 or its
interaction with IPv4,
and maybe even put out some interesting but not actually useful piece
of researchware
such as RFC1149bis (homeland security emergency warning notification
via location-agile mobile distribution of audio recordings using
peer-to-peer avian carriers.)

Then when we actually do run out of IPv4 space and major players start
complaining
that they're Just Not Ready for IPv6, because you know that's going to happen,
have the RFC author grudgingly agree to release the space and retarget
the research,
giving the carriers and other players one more year to get serious.

13

Remind me again how long A.B.C.0 and A.B.C.255 took to be "fixed"
to be usable as IP addresses?

Adrian

14

First, my primary assumption here is that it's never reasonable to expect that 240/4 would work as a publically routed address space (cf. Randy's mail on imposing demands on others). If there is agreement so far, and the addresses would be used in non-public contexts or NATted along the way, no experiment coordination is required.

You seem to be under the illusion that the IETF or IANA controls the Internet or private internets (e.g., experiments, private use, contexts not visible to the public Internet).

The operators who want to do something private with this space don't need the IETF or IANA approval to do so. So they should just go ahead and do it. If they can manage to get it to work, and live to tell about it, maybe we can consider that sufficient proof that we can start thinking about reclassification.

15

--- "Justin M. Streiner" <streiner@cluebyfour.org>
wrote:

I agree. The current rate at which blocks of IPv4
space are being
allocated to the RIRs suggests that releasing a
chunk from, say, 240/5 or
248/5 for consumption gets you about 1 year, tops.

How about releasing a /6 or two in /23 increments or
so with the idea of jumpstarting a market in IPv4
space explicitly stated?

If clear title were granted (or at least clear 99-year
lease with transferability), that might be a far more
interesting IPv4 experiment than a lot of the
technical projects, which should probably be moved to
IPv6 by now (or if they haven't, would they please
hurry up? I'd like more stuff to work).

-David

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

16

240/4 is tainted. The fact that some code exist somewhere to
make it work is good, but the reality is that there are tons
of equipment that do not support it.

If you believe that, then don't use it.

But don't dictate to me and everyone else what we can and cannot use in
our networks. If somebody, somewhere, wants to use 240/4 then they
should be allowed to do so without putting additional BUREAUCRATIC
roadblocks in their way. IANA's failure to allocate 240/4 to RIRs is a
bureaucratic roadblock. ARIN's failure to allocate 240/4 space to THOSE
WHO DESIRE IT is a bureaucratic roadblock. IETF's failure to un-reserve
240/4 space is a bureaucratic roadblock.

Investigation has shown that the router code and O/S code only requires
a very simple change to enable 240/4 to function as normal IPv4 unicast
addresses. Vendors have no excuse for not including this change in their
next software releases. The impending exhaustion of the IPv4 space is
the reason why it is an imperative for vendors to make this change.

You might not use it, and I might not use it, but I believe that there
will be enough people who can find some use for it that the pressure on
the remaining IPv4 space will be diminished. And every extra day that we
can buy before IPv4 exhaustion helps people get their IPv6 planning and
deployment up to the same "carrier-level" standards as we currently
enjoy with IPv4.

Deploying a large
network with 240/4 is a problem of the same scale as
migrating to IPv6, you need to upgrade code, certify equipment, etc...

Yes we know that, as with any other tecnological change, there is a set
of ifs ands and buts that engineers need to deal with in order to use
240/4 addresses. It is good to document what these conditions are so
that people don't do something stupid and just treat them as normal IPv4
unicast addresses. But, in general, the people who would request 240/4
addresses are not stupid and will do the right thing.

So, classifying 240/4 as public use is unrealistic now and
will remain unrealistic in the near future.

RFC 1918 addresses are not public use yet I will bet that you see them
in packets hitting the edge of your network. So you filter them. If you
can't handle 240/4 then do the same, just don't tell other CONSENTING
networks what they can do.

Classifying it as private use should come with the health
warning "use this at your own risk, this stuff can blow up
your network". In other words, this is for experimental use only.

This is ridiculous and untrue. There is no evidence that 240/4 addresses
will blow up anything. A while back people reported on the NANOG list
what happened when they tried to use them. Short answer, nothing
happened. That's why vendors need to take out the one line of code that
disables these addresses. And the buggy-whip manufacturers like you can
just safely ignore the whole business.

--Michael Dillon

17

I'm trying to avoid setting the expectation that 240/4 is
just a simple extension to 10/8 and thus people should use it
*today* when they run out of space in RFC1918.

I don't believe you.

If you were really trying to "avoid setting the expectation" then you
would be communicating with the authors of
http://www.ietf.org/internet-drafts/draft-fuller-240space-00.txt to see
that the IETF gets their wording right.

This is IETF work and IANA work at this point, not NANOG work.

--Michael Dillon

18

An interesting tidbit of information:

While traveling home via phx last night their free wireless was using 1.1.1.1 as the web auth portal. Perhaps this means that 1/8 is tainted as well?

Jared Mauch

19

240/4 is tainted. The fact that some code exist somewhere to
make it work is good, but the reality is that there are tons
of equipment that do not support it.

If you believe that, then don't use it.

But don't dictate to me and everyone else what we can and cannot use in
our networks. If somebody, somewhere, wants to use 240/4 then they
should be allowed to do so without putting additional BUREAUCRATIC
roadblocks in their way. IANA's failure to allocate 240/4 to RIRs is a
bureaucratic roadblock. ARIN's failure to allocate 240/4 space to THOSE
WHO DESIRE IT is a bureaucratic roadblock. IETF's failure to un-reserve
240/4 space is a bureaucratic roadblock.

If you use this stuff internally and don't tell anybody about it and nobody
ever know, you're fine. You do not need IANA, ARIN nor IET permission to do
that.

I suggest respectfully you re-read Randy's initial email. If you release
240/4 as public space, there are transitive issues. I care about having one
Internet, so this matters.

Classifying it as private use should come with the health
warning "use this at your own risk, this stuff can blow up
your network". In other words, this is for experimental use only.

This is ridiculous and untrue. There is no evidence that 240/4 addresses
will blow up anything.
A while back people reported on the NANOG list
what happened when they tried to use them. Short answer, nothing
happened.

This is not my recollection. I, and others, tried it on many platforms and
it did not work. Try it again on a windows XP box.

That's why vendors need to take out the one line of code that
disables these addresses.

This is not enough to put it safely into production. All equipment &
software will have to be tested and certified. This takes time & energy.

And the buggy-whip manufacturers like you can
just safely ignore the whole business.

I'd appreciate if you did not insult me.

   - Alain.

20

yup, this was my conclusion when i had a debate on this a while back

think of all the OS protocol stacks out there that may or may not work (you can test it now, try a trace from your windows/linux/bsd/osx box and see the different results)

then even if all vendors start releasing fixed stacks, imagine how many non-upgradable network devices ($20 dsl routers, nat devices etc) are out there that wont work

unfortunately i think this is a non-started for all except private deployments

the other point as was mentioned later in the thread is that this buys you very little in terms of time before v4 is gone.

Steve