On Fri, Oct 19, 2007 at 12:35:52PM -0400, Jon Lewis wrote:
> Interestingly, my unpatched Ubuntu 7.04 notebook would let me install
> routes for networks in 240/4, but would not let me configure an interface
> IP in 240/4.
although this is not linux-l@ , here is a hint for those who ke
n-upgradable gear.
You know, Cisco do release updates to old IOS software periodically.
ISTR seeing a Cisco 2500 IOS update -this year-. Yup:
c2500-is-l.123-23.bin 16 16 25-JUL-2007
Lots of 2500s can't run that code. Where can I get a 240/4 compatible
update of c5200-is-l.
Did you all miss this post?
Thanks.
Alex Pilosov wroteth on 10/18/2007 3:26 PM:
Guys, this thread has gone over 50 posts, and doesn't seem to want to end.
By now, everyone has had a chance to advance their argument (at least
once), and we are just going in circles, increasing noise and not
c
On 18-okt-2007, at 3:46, BELLEVILLE Ray wrote:
What ever happened to pushing on the traditional class A owners to
free up their address space?
The ARIN lawyers say it can't be done.
I don't find that a compelling argument, but unless something happens
very soon in this area, it will be to
to work, and live to tell
about it, maybe we can consider that sufficient proof that we can start
thinking about reclassification.
There are, fortunately, a number of vendors that don't like to go against
existing RFCs.
So.. can you clarify. Which RFCs require routers or hosts to reject
out of the realm of possibility Cisco, just as an example
of one vendor of $LOTS, would do a software rebuild run just for this
particular issue.
All IETF "has to do" is possibly reclassify 240/4 from "experimental/future
use" to "experimental unicast space" to sati
s, etc. to use ipv6, the effort involved in patching systems to use
> 240/4 is lost in the noise. Saying "deploying a large network with 240/4
> is a problem of the same scale as migrating to ipv6" is like saying that
> trimming a hangnail is like having a leg amputated; both a
we can consider that sufficient proof that we can start
thinking about reclassification.
There are, fortunately, a number of vendors that don't like to go against
existing RFCs. We're one of them. Regardless of customer demand, I will
block any attempt inside our development grou
the TCP/IP code of Linux and FreeBSD and were able
> to freely use 240/4 address space to communicate between machines. This
> means that IT WILL WORK.
>
> The reports stated that the code patch was simple because it involved
> simply removing a line of code that disallowed 240/4 ad
On Tue, Oct 16, 2007 at 11:48:00AM -0600, Alain Durand wrote:
> 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 sam
> > why on earth would you want to go and hack this stuff together,
> > knowing that it WILL NEVER WORK
>
> Because I have read reports from people whose technical expertise I
> trust. They modified the TCP/IP code of Linux and FreeBSD and were able
> to freely us
Joe,
On Oct 18, 2007, at 3:22 PM, Joe Greco wrote:
Fixing devices so that they can accept 240/4 is a software fix
that can be done with a binary patch and no additional memory. And
there are a _lot_ of these devices.
Sure, I agree there are. How does that number compare to the
number of
> > Consider an auto company network. behind firewalls and having
> > thousands and thousands of robots and other factory floor
> machines.
> > Most of these have IPv4 stacks that barely function and would never
> > function on IPv6. One company estimated that they needed
> 40 million
>
Guys, this thread has gone over 50 posts, and doesn't seem to want to end.
By now, everyone has had a chance to advance their argument (at least
once), and we are just going in circles, increasing noise and not
contributing to signal.
I'd like to summarize arguments advanced - and if you don't
> I think Michael's point is that it can be allocated as
> "unique space for internal use". i.e. kind of like 1918
> space, but you know your slice of
> 240/4 is only used on your network[1]. For that purpose,
> it's fine, as long as you determine that all
> why on earth would you want to go and hack this stuff together,
> knowing that it WILL NEVER WORK
Because I have read reports from people whose technical expertise I
trust. They modified the TCP/IP code of Linux and FreeBSD and were able
to freely use 240/4 address space to commu
> Or simply ask IANA to open up 256/5. After all, this is just an entry in a
> table, should be easy to do, especially if it is done on Apr 1st. ;-)
DOH! Point: you.
... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule
> Consider an auto company network. behind firewalls and having
> thousands and thousands of robots and other factory floor machines.
> Most of these have IPv4 stacks that barely function and would never
> function on IPv6. One company estimated that they needed 40 million
> addresses fo
facing in deploying IPv6 is that an IPv6 stack + IPv4 stack
> have a larger memory footprint that IPv4 alone in devices that have
> essentially zero memory for code left (in fact, they're designed that
> way). Fixing devices so that they can accept 240/4 is a software fix
>
On Thu, 18 Oct 2007 14:53:58 MDT, Alain Durand said:
> Or simply ask IANA to open up 256/5. After all, this is just an entry in a
> table, should be easy to do, especially if it is done on Apr 1st. ;-)
And to think that we all laughed at Eugene Terrell
pgp1oANR5GLQa.pgp
Description: PGP sig
On 10/18/07 2:24 PM, "Joe Greco" <[EMAIL PROTECTED]> wrote:
> Actually, though, I have a better solution. Let's ask the IETF to revise
> an RFC, and define the first octet of an IPv4 address as being from 0-
> 65535. That's asking the IETF to revise an RFC, too, such request being
> just as
Consider an auto company network. behind firewalls and having
thousands and thousands of robots and other factory floor machines.
Most of these have IPv4 stacks that barely function and would never
function on IPv6. One company estimated that they needed 40 million
addresses for this pu
her versions of the software
> that have been patched to support 240/4.
And what's your grade, because you aren't displaying a realistic worldview
that takes into account that there are tons (tons!) of sites where these
"patched" versions of software simply will never run.
We
On 10/18/07 2:17 PM, "Brandon Galbraith" <[EMAIL PROTECTED]>
wrote:
> Alain,
>
> Correct me if I'm wrong, but Comcast started moving to IPv6 addressing
> *because* they ran out of 10. space.
Absolutely. I made the point earlier, making 240/4 work is abo
On 10/18/07, Alain Durand <[EMAIL PROTECTED]> wrote:
>
> On 10/18/07 12:53 PM, "Jon Lewis" <[EMAIL PROTECTED]> wrote:
>
> > I could see bits of 240/4 perhaps being of use to large cable companies
> > for whom there just isn't enough 1918 space
long. ipv4 exhasution has it's own
timeline and I daresay most network operators will be focused on:
Deployment of new resources (ie deployment of ipv6)
Not causing damage to or requiring modification of the installed
base.
It seems clear to some if not to everyone t
On 10/18/07 12:53 PM, "Jon Lewis" <[EMAIL PROTECTED]> wrote:
> I could see bits of 240/4 perhaps being of use to large cable companies
> for whom there just isn't enough 1918 space to address all their CPE
> gear...and/or they really want unique addressing so th
--- [EMAIL PROTECTED] wrote:
2) Anyone care to guess how much network gear is deployed that either
won't or can't be upgraded? i.e. Old cisco gear without the RAM and/or
flash to handle a newer code train...the old one in use long since
unsupported, or gear from vendors that no longer exist?
On Thu, 18 Oct 2007, Stephen Wilcox wrote:
You get a D on those facts because you did not review the "literature",
did not attempt reasonable coverage of the problem space, and did not
investigate whether or not there were other versions of the software
that have been patched to sup
topic comments, but I truly felt it is/was
necessary..
Eric
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Stephen Wilcox
Sent: Thursday, October 18, 2007 11:21 AM
To: <[EMAIL PROTECTED]>
Cc: nanog@merit.edu
Subject: Re: 240/4
On 18 Oct 200
problem space, and did not
investigate whether or not there were other versions of the software
that have been patched to support 240/4.
step awy from the crack pipe...
Joe's facts were excellent. I read his email and thought "wow, this
will kill this thread for sure"
why o
stack + IPv4 stack
have a larger memory footprint that IPv4 alone in devices that have
essentially zero memory for code left (in fact, they're designed that
way). Fixing devices so that they can accept 240/4 is a software fix
that can be done with a binary patch and no additional m
are
that have been patched to support 240/4.
> > We cannot engineer a set of solutions that will work for everybody.
>
> Therefore, you want to engineer a solution that'll work for
> mostly nobody?
No, therefore we should not attempt to engineer a solution that will
work fo
> Please don't try to engineer other people's networks because they are
> not going to listen to you. It is a fact that 240/4 addresses work fine
> except for one line of code in IOS, MS-Windows, Linux, BSD, that
> explicitly disallows packets with this address. People h
Okay, this has descended to a point where we need some fact injection.
This very morning, I have done some simple research. My research focused
on the question, "what if 240/4 were released for use on the public
Internet."
I am not interested in the question of "what if 240/4 we
On 18 Oct 2007, at 15:09, Rob Evans wrote:
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?
Leo Vegoda mentioned this at the last UKNOF meeting:
http://www.uknof.org.uk/uknof8/Vegoda-Unall
> 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?
Leo Vegoda mentioned this at the last UKNOF meeting:
http://www.uknof.org.uk/uknof8/Vegoda-Unallocated.pdf
Cheers,
Rob
On 18.10 10:48, Adrian Chadd wrote:
>
> > Asking the whole internet to support 240/4 is going to tie up
> > valuable resources that would be far better off working on IPv6. Keep
> > in mind that it's not just software patches. Software vendors don't do
> &
Stephen Wilcox wrote:
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.
I can see a reasonable amount of demand for 240/4 with carriers in
> > 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
> Asking the whole internet to support 240/4 is going to tie up
> valuable resources that would be far better off working on IPv6. Keep
> in mind that it's not just software patches. Software vendors don't do
> stuff for free. I doubt ISPs are going to pay hu
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
>We want to release 240/4 as a solution for those
>organizations that are in a position to control enough variables to
make
>it useful. For those organizations, 240/4 space could
ea, but it only deals with the symptoms, not the cause.
- Original Message -
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: nanog@merit.edu
Sent: Wed Oct 17 18:41:39 2007
Subject: RE: 240/4
> the other point as was mentioned later in the thread is that
> this buys you very l
On Thu, 18 Oct 2007 00:41:39 BST, [EMAIL PROTECTED] said:
> This is not the case. We want to release 240/4 as a solution for those
> organizations that are in a position to control enough variables to make
> it useful. For those organizations, 240/4 space could buy a LOT of time,
>
> 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.
On average, it buys everybody very little time. But that assumes that
240/4 is being released as a general solution for everybody.
This is not the case. We w
On 16 Oct 2007, at 09:42, Randy Bush wrote:
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
On 10/17/07 3:38 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>
>
>> 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.
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
On Oct 17, 2007, at 5:42 PM, <[EMAIL PROTECTED]> wrote:
If you were really trying to "av
> 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 yo
> 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
* 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 t
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
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.
I'm trying to avoid setting the expectation t
> 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
&
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
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 repe
56 matches
Mail list logo