Re: 240/4
On Thu, 18 Oct 2007, Stephen Sprunk wrote: Thus spake "Pekka Savola" <[EMAIL PROTECTED]> 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. 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 240/4? -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: 240/4
On Fri, Oct 19, 2007, Joe Greco wrote: > So is this a statement that Cisco is volunteering to provide free binary > patches for its entire product line? Including the really old stuff > that happens to be floating around out there and still in use? Considering there's forklift upgrades required to support changes in technology anyway, I see this as not a problem. People can choose if they'd like to use that space. People -chose- to use some new IP space which had once been bogon space and then spent quite a bit of time figuring out why the hell customers couldn't reach the general internet. People adapted. > The day you guys release a set of free binary patches for all your > previous products, including stuff like the old Compatible Systems > line, old Cisco gear like the 2500, and old Linksys products, then > I'll be happy to concede that I could be wrong and that vendors might > actually make it possible for IPv4-240+ to be usable. 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 Its so not 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 satisfy the vendors that would block on 240/4 being routable and satisfy those who are worried that putting it on the public internet is bad (and I'm one of them for now); then let the market decide what they want to do. Adrian
Re: 240/4
I hadn't intended to post any further replies, but given the source and the message here, felt this warranted it: > Compared to the substantial training (just getting NOC monkeys to understand > hexidecimal can be a challenge), back office system changes, deployment > dependencies, 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 are painful but one > is orders of magnitude more so than the other. So is this a statement that Cisco is volunteering to provide free binary patches for its entire product line? Including the really old stuff that happens to be floating around out there and still in use? Because if it's not, your first stop should be to get your own shop in order and on board, because for a major router vendor to not make free binary patches available for its entire product line certainly does represent a huge roadblock with adoption of IPv4-240+. The day you guys release a set of free binary patches for all your previous products, including stuff like the old Compatible Systems line, old Cisco gear like the 2500, and old Linksys products, then I'll be happy to concede that I could be wrong and that vendors might actually make it possible for IPv4-240+ to be usable. Until then, this doesn't carry much credibility, and continuing this thread is a waste of time. Nobody cares if you're able to patch a current Linux system so that you can make one measly node on the Internet work with IPv4-240+. It's getting the rest of them to be patched - including all the hosts and networking gear - that's the problem. If you just want to discuss your clever Linux patches, the Linux mailing lists are >>> thataway. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: 240/4
Thus spake "Pekka Savola" <[EMAIL PROTECTED]> 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. 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 group to allow 240/4 until the IETF reclassifies it from experimental to unicast address space. Note that doing that would _not_ automatically imply that the IETF would direct IANA to delegate that space to the RIRs; the IETF could direct IANA to mark one /8 as private and the rest reserved. Releasing the rest to the RIRs shouldn't be done until it is observed that a non-trivial number of hosts on the public network support it -- if that ever happens. I can see cases for using 240/4 on private networks where one has more control over patches getting deployed (or is using OSes one can patch themselves or bully vendors to patch), but that's all that's worth discussing now. Short of someone from Microsoft indicating they'd post a patch on Windows Update for Vista, XP, and possibly earlier systems, any discussion of _when_ these addresses _might_ be usable on a public network is a waste of bits. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: Level3 in cleveland/ohio?
On Fri, 19 Oct 2007, Drew Weaver wrote: Anyone else having major difficulty with service with ICG/Level3 circuits in Ohio/Cleveland? We've had a circuit down for 10 hours and just two hours ago they notified us that they're having a major outage in our region and have not provided __any__ further information. When did your outage start? Perhaps last night was a big migration^Wbreak the network night for Level3. We had a Progress Telecom^W^WLevel3 DS3 break at about 4:20AM and not get fixed until about 4:30PM today. I don't have a good explanation yet as to why they broke our circuit or more importantly, why it took them >12h to put it back in service. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Level3 in cleveland/ohio?
Anyone else having major difficulty with service with ICG/Level3 circuits in Ohio/Cleveland? We've had a circuit down for 10 hours and just two hours ago they notified us that they're having a major outage in our region and have not provided __any__ further information. TIA, -Drew
Re: unsuc
unsubscribe
unsuc
unsubscribe nanog
Re: dns authority changes and lame servers
[EMAIL PROTECTED] (Mike Lewinski) writes: > Justin Scott wrote: > > > I suppose the problem with having an official list to query would be > > getting all of the various registries to participate and keep it > > regularly updated. I personally qualify this as a slight inconvenience, > > but I'm not sure I would call it a flaw in the DNS system. > > If we just call DNS a distributed database, then it is easy to see that > when the keys (glue at root) get updated, the relations to those keys > *should* all reflect that change. ... > > And I'll admit, I'm not sure how to properly fix it either. My first > thought was a BIND directive to "expire-stale-zones ;" so that > every the server might check to be sure it is still auth, and > if it has found authority changed, would stop giving out AAs for it. But > I see all kinds of operational issues arising from that too (such as, > how do we gracefully setup new customer's zone before it has > transitioned here). as duane said, it's possible to accomplish this with creative nagios plugins. however, i agree that it's something BIND should do, to be comprehensive. if someone is excited enough about this to consider sponsoring the work, please contact me ([EMAIL PROTECTED]) to discuss details. > Really, in my ideal Internet, once my server was notified that it was no > longer authoritative, it would have an option to do a reverse xfer to > the new auth servers (who would then be free to accept/reject the old > information as necessary - can't count the number of times I've tried to > get customers to provide zone file records in advance and failed because > they don't know how/where to get them from). But that's an ideal > Internet that will never exist, I know. it's because we didn't know exactly how to scope this problem that RFC 2136 does not permit the insertion or deletion of authority zones. noting that the ideal internet you want is within our grasp if we can only define it and sponsor it, i recommend taking up this thread on [EMAIL PROTECTED] or [EMAIL PROTECTED] -- Paul Vixie
Re: dns authority changes and lame servers
The correct way to change a delegation is to: * add the new servers as stealth servers for the current zone. * if the old master is to be removed, make it a slave of the new master. * add the new NS records to the zone. * wait for all the slaves to have the new zone. * inform the parent zone of the new NS records. * wait until all the old NS RRsets have expired from caches (implies waiting for the parent's changes to propagate). * remove the old NS records from the zone. * wait for all the slaves to update. * inform the parent zone of the new NS records. * wait until all the intermediate NS RRsets have expired from caches (implies waiting for the parent's changes to propagate). * any slaves that are not being remove and that are still using the old master (or slave that is going away) need to be configured to use the new master by this point. * stop serving the zone on the old servers. Note: all through this process the namesevers listed in the NS records are answering for the zone in a consistant manner. Note: even if the parents informed you that the delegation was removed you still have to wait for the records to expire from caches *before* you can stop serving the zone. One can collapse the above slightly by informing the parent of the final NS RRset, rather than the intermediate NS RRset, but that won't work with registrars that check the childs NS RRset. One way to get around this would be to charge a cleanup fee that only gets charged when the client fails to notify you in advance that they are going change delegations. Mark
Re: dns authority changes and lame servers
[EMAIL PROTECTED] (David Ulevitch) writes: > I should also mention the related work starting over here: > http://www.nanog.org/mtg-0710/presentations/Vixie-lightning.pdf indeed. while i don't have even a tenth of the analysis expertise of someone like robt, wessels, florian, or april, i am most assurely going to gather the raw data and make it available to those folks and similar folks. (noting that i've got 5Mbit/sec now and am hoping for 1000X that much a year from now, and noting that robt, wessels, florian, april, paul laudanski, and jeff chan have already got dedicated or shared hosts connected to the rebroadcast switch, and that more are welcome.) we may yet publish a top-500-domains web page, since that's a fairly easy thing to build using this raw data. current zonecuts, and nameserver name or address deltas, may also come from us, though i think it'll come sooner from wessels, april, or florian. if you're not submitting data yet, i hope you'll decide to do so, and drop me some e-mail ([EMAIL PROTECTED]) to discuss details. -- Paul Vixie
Re: 240/4
On Thu, Oct 18, 2007 at 11:00:42PM +0100, [EMAIL PROTECTED] wrote:
>
> > 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 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 addresses.
Actually, to do the job right, you have to change a handful of conditionals
in about five different files in the Linxux kernel: in.h (really just
cleanup to remove unused macros), devinet.c, fib_frontend.c, ipconfig.c,
and route.c.
Attached are the diffs for a 2.6 kernel (implemented and tested on an Ubuntu
7.04 system) and for a 2.4 kernel (implemented and tested on a Linksys
WRT45GL running OpenWRT whiterussian 0.9).
As mentioned in an earlier message, Mac OSX, at least the version that came
with a Powerbook G4 that I have, will accept a 240/4 address without any
modifications - I used it to test the Linux patches. There does appear to be
a one line change needed to FreeBSD and/or OSX for it to act as a router.
Have fun.
--Vince
diff -c 2.6-orig/devinet.c 2.6/devinet.c
*** 2.6-orig/devinet.c 2007-09-20 15:32:16.0 -0700
--- 2.6/devinet.c 2007-09-19 11:29:32.0 -0700
***
*** 1,3
--- 1,6
+ /*27-Aug-07 22:27:25, Edit by vaf */
+ /* use /24 default netmask for "class-E" space */
+
/*
*NET3IP device support routines.
*
***
*** 594,599
--- 597,604
rc = 16;
else if (IN_CLASSC(haddr))
rc = 24;
+ else if (IN_CLASSE(haddr))
+ rc = 24;
}
return rc;
diff -c 2.6-orig/fib_frontend.c 2.6/fib_frontend.c
*** 2.6-orig/fib_frontend.c 2007-09-20 15:32:16.0 -0700
--- 2.6/fib_frontend.c 2007-09-19 11:29:30.0 -0700
***
*** 1,3
--- 1,6
+ /*16-Aug-07 16:26:55, Edit by vaf */
+ /* replace check for "BADCLASS" with explicit check for INADDR_BROADCAST */
+
/*
* INET An implementation of the TCP/IP protocol suite for the
LINUX
*operating system. INET is implemented using the BSD Socket
***
*** 152,158
struct fib_result res;
unsigned ret = RTN_BROADCAST;
! if (ZERONET(addr) || BADCLASS(addr))
return RTN_BROADCAST;
if (MULTICAST(addr))
return RTN_MULTICAST;
--- 155,161
struct fib_result res;
unsigned ret = RTN_BROADCAST;
! if (ZERONET(addr) || addr == INADDR_BROADCAST)
return RTN_BROADCAST;
if (MULTICAST(addr))
return RTN_MULTICAST;
diff -c 2.6-orig/in.h 2.6/in.h
*** 2.6-orig/in.h 2007-09-20 15:33:11.0 -0700
--- 2.6/in.h2007-09-19 11:29:32.0 -0700
***
*** 1,3
--- 1,5
+ /*27-Aug-07 22:26:39, Edit by vaf */
+ /* add macros for "class-E"; remove those for BADCLASS and EXPERIMENTAL */
/*
* INET An implementation of the TCP/IP protocol suite for the
LINUX
*operating system. INET is implemented using the BSD Socket
***
*** 215,222
--- 217,232
#define IN_MULTICAST(a) IN_CLASSD(a)
#define IN_MULTICAST_NET 0xF000
+ #define IN_CLASSE(a) long int) (a)) & 0xf000) == 0xf000)
+ #define IN_CLASSE_NET 0xff00
+ #define IN_CLASSE_NSHIFT8
+ #define IN_CLASSE_HOST (0x & ~IN_CLASSE_NET)
+
+ /*
+ * these are no longer used
#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) ==
0xf000)
#define IN_BADCLASS(a) IN_EXPERIMENTAL((a))
+ */
/* Address to accept any incoming messages. */
#define INADDR_ANY ((unsigned long int) 0x)
diff -c 2.6-orig/ipconfig.c 2.6/ipconfig.c
*** 2.6-orig/ipconfig.c 2007-09-20 15:32:16.0 -0700
--- 2.6/ipconfig.c 2007-09-19 11:29:31.0 -0700
***
*** 1,3
--- 1,5
+ /*28-Aug-07 10:21:56, Edit by vaf */
+ /* add default net mask for "class-E" */
/*
* $Id: ipconfig.c,v 1.46 2002/02/01 22:01:04 davem Exp $
*
***
*** 379,384
--- 381,388
ic_netmask = htonl(IN_CLASSB_NET);
else if (IN_CLASSC(ntohl(ic_myaddr)))
ic_netmask = htonl(IN_CLASSC_NET);
+ else if (IN_CLASSE(ntohl(ic_myaddr)))
+ ic_netmask = htonl(IN_CLASSE_NET);
else {
printk(KERN_ERR "IP-Config: Unable to guess netmask for
address %u.%u.%u.%u\n",
NIPQ
Re: dns authority changes and lame servers
On Thu, 18 Oct 2007, Jack Bates said: We use home-grown scripts to follow the NS trail and verify that we are I do something similar with a nagios plugin (perl script). It reports lameness and serial mismatch. I've put it online here: http://www.life-gone-hazy.com/src/nagios/check_zone_auth Duane W.
Re: 240/4
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 same > scale as migrating to IPv6, you need to upgrade code, certify equipment, > etc... Sorry, but this is a completely bogus argument. The edits necessary to allow 240/4 took about 10 minutes on Linux (figuring out the kernel build/install process took longer, but I'm out of practice). OSX (and perhaps FreeBSD) doesn't require any changes - you can already configure 240.1.1.1/24 on your Mac today. For someone familiar with deploying binary patches on Windows, Linux, etc., I'm guessing that appropriate changes could be available in a matter of days. Compared to the substantial training (just getting NOC monkeys to understand hexidecimal can be a challenge), back office system changes, deployment dependencies, 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 are painful but one is orders of magnitude more so than the other. --Vince
Re: 240/4
> > 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 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 addresses. > > This demonstrates that enabling 240/4 is a very simple technical issue. > The only real difficulty here is getting the right people to act on it. > > Companies like Cisco don't even need to wait for the IETF in order to > implement a command like >ip class-e > as long as they ship it with a default of >no ip class-e I don't even know where to begin. Well, maybe here: "The only real difficulty here is getting the right people to act on it." That neatly sums up the problem. When you can round up: 1) All the programmers for all the tens of thousands of different IP devices that are out on the market, have them dig up the source code for these devices (some of which may have been a few employers ago), and you get them all to agree to post updated copies of their firmware, which might be problematic for those companies that went T.U., You still have the giant problem of: 2) Getting over 100 MILLION users to all update the BILLIONS of devices that are out there with that firmware. Once you have a game plan for getting those hundred million people to do this, then we may have something to talk about. Until then, not so much. Your "people whose technical expertise trust" clearly figured out that there are cases where you can make moving an IPv4-240+ packet work. Anyone can make that happen. However, they apparently failed to impress upon you that what they were (hopefully) saying is that "enabling IPv4- 240+ on a single device is a very simple technical issue." Deploying it on a wider scale ... not so simple. What kind of customer would actively solicit an IP address assignment that won't reach random segments of the Internet? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: 240/4
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 devices which can't or won't be upgraded to IPv4-240+? I'm not sure what the problem is. If a machine isn't upgraded to support 240/4, then you can't talk to it. I would imagine an ISP could (for example) ensure its routers could handle 240/4 and then configure those routers to use 240/4 for their loopback addresses, thereby reducing that ISP's need of "regular" space (be it public or private). If someone is suggesting IANA allocate 240/4 to the RIRs as "regular" /8s for subsequent allocations to ISPs or end users, they're deeply confused. Regards, -drc
RE: 240/4
> > 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 purpose. > > I guess I have a certain amount of skepticism that an auto > company's robotic control network needs to have public IP addresses. Of course they don't need public addresses, but they do need to have non-private globally unique IP addresses. And RFC 2050 does allow such companies to go to an RIR and get an allocation of globally unique IPv4 addresses. You may not have noticed it, but IP addresses are *NOT* Internet addresses, they are internet-protocol addresses, and can be used on or off the Internet wherever IP stacks are used. --Michael Dillon
RE: 240/4 (MLC NOTE)
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 have something new (not listed here) to say, can you please avoid posting to this thread? If you disagree with me, please take it to nanog-futures. Summary of arguments: In favor of experimental use only: Alain Durand: at your own risk, this stuff can blow up your network In favor of private use: Randy Bush: if it works for you, why mark it experimental Dillon: why shouldn't people use it if they can In favor of no use at all: Joe Greco: "it doesn't work now (today) on current-generation OSes, there is no chance to get it to work in any shape of form by the time v4 space is exhausted". Steve Wilcox: "it will never work" Mixed: Daniel Senie: Allocate some as private, reserve rest as 'allocatable' once vendors get the gear fixed to accomodate those who use as private Additional points: David Ulevitch: If it is ever designated rfc1918, it cannot ever become public. Many: It will buy us some time before v4 address space is exhausted, and much less painful than v6 deployment Many: Old gear cannot be v6-enabled, but it can be 240-enabled Dillon: This is not our decision, this is IETF/IANA decision. -alex [mlc chair]
RE: 240/4
> 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 your gear allows it. Not quite. I don't want to see 240/4 space considered to be like RFC 1918 space in any way shape or form. I just want it available for use between consenting partners which is why I suggest that the RIRs only give it to people who ask for it. Eventually I expect that some ISPs will support this due to customer demand and because it isn't that hard to install the patches required in routers. Anyone who doesn't want to support it need not do anything because the packets will fall on the floor as soon as they hit a router that doesn't support 240/4 addresses. Depending on how the IPv6 transition pans out, there might be a day when 240/4 addressing is widely supported on the Internet. Or there might not. I would just like to see the "reserved" status removed for 240/4 because it is no longer appropriate or necessary. > If anyone really thinks it can be announced into the global > routing table and expected to function, I'm afraid they've > swallowed the crack pipe so far down that this thread is > pointless for them. Too many devices will never (can > never[2]) be upgraded and are unlikely to go away in the > forseeable future. Agreed. Routing between consenting networks is not the same as universal routing (if that even exists anymore). Unfortunately, many people do not understand that Internet connectivity is not an all-or-nothing proposition. There are many extranets that function using only a small group of certified ISPs, for instance. > 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 that if/when networks merge IP conflicts are avoided. I think that RFC 1918 exhaustion is a separate issue and can only be solved by setting aside another /8 for RFC 1918 space. Either take 125/8 or else see if Softbank Japan is willing to allow 126/8 to be set aside for that purpose. > 1) As much as this can ever be known...you can't stop random > IP squatters from picking random IP space out of their hats > for use as "private" > networks behind NAT. Eventually, they realize some bit of > the internet is unreachable...because it's their LAN. Not necessarily. In many cases they only want to reach a subnet of the Internet so they never see the unreachability problem. Or they don't route packets into or out of the public Internet and use split-horizon DNS. > 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? As long as this stuff > generally works, nobody's likely to replace it. That's why we will see IPv4 in widespread use for at least the next 20 years. --Michael Dillon
RE: 240/4
> 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 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 addresses. This demonstrates that enabling 240/4 is a very simple technical issue. The only real difficulty here is getting the right people to act on it. Companies like Cisco don't even need to wait for the IETF in order to implement a command like ip class-e as long as they ship it with a default of no ip class-e --Michael Dillon
Re: dns authority changes and lame servers
Justin Scott wrote: We also have home-grown scripts that figure out whether a domain is delegated to us or not and flag the ones that aren't. In the case of the free service we flag them for two weeks and if they still aren't delegated to us after that period we disable them on the DNS servers but leave the domain in their account. In the case of the paid service we make a note of the status in the database but do not make any changes to the account (they're paying us, after all, to have it there). We don't do recursive lookups so it's not an issue (even though it's technically an RFC violation, if I remember correctly). We use home-grown scripts to follow the NS trail and verify that we are listed in some form or fashion. If we aren't, we handle the problem based on the criteria. If the domain is listed elsewhere, we immediately remove and notify. If the domain isn't listed in TLD, we notify yet hold the domain for I think 30 days before removing it; unless the status changes. Jack
Re: 240/4
> 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. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: 240/4
> 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 purpose. I guess I have a certain amount of skepticism that an auto company's robotic control network needs to have public IP addresses. In an ideal world, where it's like it was 20 years ago and we tell everyone "register some space," yeah, it was a grand idea. Now, with space running out, we need IPv6 for that, and in ten years, all those little robots will begin to find themselves having their controller boards replaced. There may not be a perfect path forward for them, but it seems likely that they can actually deal with the problem in suboptimal ways until they're actually capable of IPv6. It is in no way thrilling, but it doesn't seem likely that IPv4-240+ is going to be a grand solution for devices where the IP stacks are already admittedly barely functional, or that public IP addresses are necessary, in which case there's a certain amount of freedom to recycle as much of the existing IP space as is needed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: dns authority changes and lame servers
> How annoying or frustrating is it for people? > > Is it so annoying that you'd be willing to pay for > a list of every public-facing NS record pointed at > a given IP? Nope. As I mentioned earlier, I qualify this as a minor inconvenience on the servers that I manage. It may be for someone who manages more zones than I do though. -Justin Scott
Re: 240/4
> Joe, > On Oct 18, 2007, at 8:49 AM, Joe Greco wrote: > > The ROI on the move to v6 is immense compared to the ROI on the move > > to v4-240+, which will surely only benefit a few. > > I am told by people who have inside knowledge that one of the issues > they are 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 > 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 devices which can't or won't be upgraded to IPv4-240+? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: 240/4
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 signature
Re: dns authority changes and lame servers
Justin Scott wrote: As an operator of both free and paid DNS services, I wish there was a quick and easy way to pull a list of all of the zones that were delegated to a specific IP address. I say IP because people can now register their own DNS name servers at the registrar and use our IP addresses, so using the "official" hostname isn't even fool-proof. Being able to pull such an "official" list for forward DNS zones would certainly make life easier. How annoying or frustrating is it for people? Is it so annoying that you'd be willing to pay for a list of every public-facing NS record pointed at a given IP? I should also mention the related work starting over here: http://www.nanog.org/mtg-0710/presentations/Vixie-lightning.pdf -David
Re: more-specifics via IX
Stephen Wilcox wrote: On 17 Oct 2007, at 20:55, Bradley Urberg Carlson wrote: Thanks for the suggestions. On Oct 17, 2007, at 6:06 PM, Stephen Wilcox wrote: well.. the problem of course is that you pull in the traffic from the aggregate transit prefix which costs you $$$ but then you offload it to the customer via a peering link for which you are not being paid A bigger problem is that my IX peer pays less to my customer for transit. If my customer notices that transit traffic has been going around him, he may be grumpy. I prefer happy customers. Okay but: 1. Your customer/customer's customer is the one doing the broken routing here not you.. if he wants to be grumpy you should point him in the direction of the guy who is announcing the bad routes in the first place! s/broken// and s/bad// 'broken' and 'bad' are all a matter of perspective here. 2. If I'm following this, your peer pays your customer? So you are peering with your customer's customer? If that was me I would either depeer them or tell them that you have an issue and need it resolving urgently or you my depeer them. It's an MLPA policy based exchange (and probably just using a central route-server) not bi-lateral peering. De-peering isn't possible here. It's not an excuse for lack of filters, but as the OP pointed out, the filters weren't expecting the routes from their customer's customer. -david
Re: 240/4
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 practical as what you suggest, and yet I'd say that the overall > solution is just as likely to work well as IPv4-240+. It'd probably > also solve the transition to IPv6 issue; we wouldn't need to. 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. ;-) - Alain.
Re: 240/4
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 purpose. Cutler On Oct 18, 2007, at 2:53 PM, Jon Lewis 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? As long as this stuff generally works, nobody's likely to replace it. James R. Cutler [EMAIL PROTECTED]
Re: dns authority changes and lame servers
Hi, Chuck! This report used to be quite useful in that regard: http://www.cymru.com/DNS/lame.html Perhaps Rob needs a coffee injection to get that going again? Oh, my, I'd totally forgotten about that report. I do need to get that going again. I'll dig around now to see what we can produce in short order. (BTW: Need/want some more of our famous "Colo Blend" Mr. Thomas?) That was some of the best joe I've had, and I'd welcome another batch! Just don't tell the rest o' Team Cymru about it - it's mine, all mine! Muahaha! :) Thanks! Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ cmn_err(do_panic, "Out of coffee!");
Re: dns authority changes and lame servers
Justin Scott wrote: I suppose the problem with having an official list to query would be getting all of the various registries to participate and keep it regularly updated. I personally qualify this as a slight inconvenience, but I'm not sure I would call it a flaw in the DNS system. If we just call DNS a distributed database, then it is easy to see that when the keys (glue at root) get updated, the relations to those keys *should* all reflect that change. The flaw is that the system creates cruft almost continuously. I'd love to see a graph of the cruft on a global scale, because I'm positive that over time it is growing (though in ways that are not always operationally impactful since most of it will be dead and abandoned zones still sitting in our named.conf). And I'll admit, I'm not sure how to properly fix it either. My first thought was a BIND directive to "expire-stale-zones ;" so that every the server might check to be sure it is still auth, and if it has found authority changed, would stop giving out AAs for it. But I see all kinds of operational issues arising from that too (such as, how do we gracefully setup new customer's zone before it has transitioned here). Really, in my ideal Internet, once my server was notified that it was no longer authoritative, it would have an option to do a reverse xfer to the new auth servers (who would then be free to accept/reject the old information as necessary - can't count the number of times I've tried to get customers to provide zone file records in advance and failed because they don't know how/where to get them from). But that's an ideal Internet that will never exist, I know.
Re: 240/4
> > Okay, this has descended to a point where we need some fact injection. > > 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 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've been UNABLE to get the vast majority of customers to automatically patch their Windows installs. There are still deployed fleets of Cobalt Raq's. There's a TON of problems on both the client and server sides of this. I'm not sure what magic "literature" I'm supposed to review which describes how this will all magically fix itself. I have no idea why you are unable to see the extent of the problem space. I am confused as to why you would think that patches make a difference, when we're talking about a need to patch billions of devices. That you might someday be able to get an IP packet from one 240.* net to another halfway around the globe isn't unthinkable. You can patch devices under your control and make clients and servers under your control work. You just won't get the global interoperability that is what the Internet is famous for. > > > 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 for everybody but merely remove the barriers that allow others to > engineer solutions for their situation. Unless you have some magic wand that can update a few billion IPv4-capable devices to be IPv4-240+ capable, it would appear that you have no method to remove these barriers. That would seem to be a showstopper bug. > > So, what's your game plan to replace all these broken IPv4 stacks? > > Again, we are not the gods of the Internet. It is not our reponsibility > to fix every problem out there, but neither do we have to sit on our > hands when we could enable others to deal with the issue. There's a vast difference between enabling others to deal with an issue, and requiring everyone else on the Internet to change something for your convenience to fix your issue so that you don't break catastrophically. > > Certainly. So why would we distract them with an > > intermediate transition to "IPv4-240+"? > > I believe that people are not that stupid. The only organizations that > go after the 240/4 solution space will have good reasons for doing so. > We do not have a good reason to deny them that possibility. The problem, then, is that if they go after that space, and nobody else does, then they don't reach about oh... well, by my (admittedly small) sample set, 100% of the Internet. Let's be generous and say that even 90% of the Internet is upgraded, somehow. Does 10% unreachability sound good? How do the customers you put onto that address space feel about not being able to reach (at least many parts of) the rest of the 'net? > > Remember, I was not > > able to find any case that successfully worked; > > Your investigation showed that the software appears to have an extra > line of code here and there which explicitly disallows 240/4 addresses. > This is easy for vendors to fix. When the vendor still exists, and the user is willing to upgrade, and the user actually does upgrade, but in many cases, that's not true. > > But we could cop out on releasing 240/4 because it's just too > > much work for a small benefit to a few sites on the Internet, > > at a huge cost to the rest of the Internet. That's not fair. > > It is a trivial amount of work for the IETF to release the address space > and for ARIN to add an extra question to their allocation forms "Do you > want 240/4 addresses?". As for fixing code, given the level of code > patching that is already done on a regular basis, removing the 240/4 > blockages could also be considered a trivial level of effort. After > that, it is not a public problem any more, and those of us who do not > want or need 240/4 addresses can ignore it. Yes, but then when you get allocated space out of 240/4, what's going to happen is that one of your customers is going to try to reach my web site, and when your customer contacts you, you're going to tell them that I'm broken, because heaven knows it's not your problem . So then I get to be called broken, and I'm coerced into doing something to upgrade services, or, worse, I have no idea because I'm just a guy running a web site, and therefore I don't (or maybe even can't) do anything. > > I'm fine with that, especially since it appears that > > implementing "IPv4-240+" will incur even more serious money > > for every participating network on the Internet, in upgrades, > > a
Re: 240/4
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 about the same order of magnitude as moving to IPv6. Not worth it for us. - Alain.
Re: 240/4
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 to address all their CPE > > gear...and/or they really want unique addressing so that if/when > networks > > merge IP conflicts are avoided. > > I do work for one of those "large cable companies" and no, 240/4 is not > useable for us either for the exact same reasons that you pointed out to > explain why 240/4 will not work in public space: there are just too many > devices that can't easily be upgraded. > >- Alain. Alain, Correct me if I'm wrong, but Comcast started moving to IPv6 addressing *because* they ran out of 10. space. My 0.02: Hacking together IPv4 solutions involving retasking previously reserved address space simply delays the inevitable exhaustion of said address space. -brandon
Re: 240/4
Scott Weeks wrote: > I have seen a LOT of that equipment out there in places like universities and > whatnot. Eventually this stuff falls out of the internet or gets consigned to roles where it can't do much in the way of damage. The timescale over which this happens is extremely 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 that use of 240/4 requires the modification of the installed base. IPV6 deployment is not going to affect the installed base with the exception of the devices that already support it. the ipv4 internet will continue to operate as it does today except perhaps with additional pressure on address space constraints, growth of large nated space and erosion of end-to-end reachability. > scott. >
Re: dns authority changes and lame servers
This report used to be quite useful in that regard: http://www.cymru.com/DNS/lame.html Perhaps Rob needs a coffee injection to get that going again? (BTW: Need/want some more of our famous "Colo Blend" Mr. Thomas?) --chuck
Re: 240/4
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 that if/when networks > merge IP conflicts are avoided. I do work for one of those "large cable companies" and no, 240/4 is not useable for us either for the exact same reasons that you pointed out to explain why 240/4 will not work in public space: there are just too many devices that can't easily be upgraded. - Alain.
Re: 240/4
--- [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? As long as this stuff generally works, nobody's likely to replace it. -- I have seen a LOT of that equipment out there in places like universities and whatnot. scott.
RE: dns authority changes and lame servers
> 1) Does anyone else find this flaw in the DNS system > as annoying as I do? If authority is to be regularly > moved around between ISPs (who may be hosting thousands As an operator of both free and paid DNS services, I wish there was a quick and easy way to pull a list of all of the zones that were delegated to a specific IP address. I say IP because people can now register their own DNS name servers at the registrar and use our IP addresses, so using the "official" hostname isn't even fool-proof. Being able to pull such an "official" list for forward DNS zones would certainly make life easier. We also have home-grown scripts that figure out whether a domain is delegated to us or not and flag the ones that aren't. In the case of the free service we flag them for two weeks and if they still aren't delegated to us after that period we disable them on the DNS servers but leave the domain in their account. In the case of the paid service we make a note of the status in the database but do not make any changes to the account (they're paying us, after all, to have it there). We don't do recursive lookups so it's not an issue (even though it's technically an RFC violation, if I remember correctly). I suppose the problem with having an official list to query would be getting all of the various registries to participate and keep it regularly updated. I personally qualify this as a slight inconvenience, but I'm not sure I would call it a flaw in the DNS system. -Justin Scott
Re: 240/4
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 support 240/4. step awy from the crack pipe... I almost wrote a message similar to Joe's (actually did, and then canceled it). I think (realy hope) that there's a misunderstanding here about exactly what 240/4 space would be used for. 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 your gear allows it. If anyone really thinks it can be announced into the global routing table and expected to function, I'm afraid they've swallowed the crack pipe so far down that this thread is pointless for them. Too many devices will never (can never[2]) be upgraded and are unlikely to go away in the forseeable future. You just can't expect 240/4 (regardless of how trivial the code change would be) to ever work as globally & reliably as people expect the internet to work. 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 that if/when networks merge IP conflicts are avoided. 1) As much as this can ever be known...you can't stop random IP squatters from picking random IP space out of their hats for use as "private" networks behind NAT. Eventually, they realize some bit of the internet is unreachable...because it's their LAN. The various squatters using 1/8 and the other "not-yet-allocated" /8s will all get the rude awakenings they deserve in time. 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? As long as this stuff generally works, nobody's likely to replace it. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 240/4
Wow,, that's pretty heavy.. I understand and can appreciate the passion involved with this topic. But Ladies and gentlemen, please lets keep it civil ok.. In some way, shape or form we are all in this together.. Some may be less informed then others, or perhaps a difference in opinion or point of view as understood by the individual.. Please when making sarcastic/ or opinionated comments please consider all parties involved.. It in my impression this list is used for intelligent, collaboration, not flame wars over a touchy topic.. so please try to keep that in mind. ok. I do like the facility this forum provides and would like to keep it like that, it would be a sad day when people (key resources) drop off this list due to the over-whelming feeling of being (crapped on) because of the difference of vision or opinion.. Pls. lets try and keep it safe ok.. Apologies for the off 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 2007, at 09:34, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > >> Okay, this has descended to a point where we need some fact >> injection. > > 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 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 on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK so, as using these IPs publically isnt feasible why bother privately. you may as well use RFC1918 or IPv6. the latter whilst not without issues is at least being rolled out as part of a series of standards that are 10+yrs old i am really struggling with some of the logic being given here. more specifically the omissions in that logic are glaring. > not attempt to engineer a solution that will work for everybody .. > not our reponsibility to fix every problem out there .. > I believe that people are not that stupid. .. > We do not have a good reason to deny them that possibility. .. > This is easy for vendors to fix. .. > It is a trivial amount of work for the IETF to release the address > space .. > removing the 240/4 blockages could also be considered a trivial > level of effort. .. > those of us who do not want or need 240/4 addresses can ignore it. .. > The cost is effectively zero in the first case, .. > why should anyone try and convert them to the one true Internet > architecture? i think you are somewhat deluded. Steve
Re: 240/4
On 18 Oct 2007, at 09:34, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: Okay, this has descended to a point where we need some fact injection. 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 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 on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK so, as using these IPs publically isnt feasible why bother privately. you may as well use RFC1918 or IPv6. the latter whilst not without issues is at least being rolled out as part of a series of standards that are 10+yrs old i am really struggling with some of the logic being given here. more specifically the omissions in that logic are glaring. not attempt to engineer a solution that will work for everybody .. not our reponsibility to fix every problem out there .. I believe that people are not that stupid. .. We do not have a good reason to deny them that possibility. .. This is easy for vendors to fix. .. It is a trivial amount of work for the IETF to release the address space .. removing the 240/4 blockages could also be considered a trivial level of effort. .. those of us who do not want or need 240/4 addresses can ignore it. .. The cost is effectively zero in the first case, .. why should anyone try and convert them to the one true Internet architecture? i think you are somewhat deluded. Steve
Re: 240/4
Joe, On Oct 18, 2007, at 8:49 AM, Joe Greco wrote: The ROI on the move to v6 is immense compared to the ROI on the move to v4-240+, which will surely only benefit a few. I am told by people who have inside knowledge that one of the issues they are 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 that can be done with a binary patch and no additional memory. And there are a _lot_ of these devices. Regards, -drc
Re: more-specifics via IX
On 17 Oct 2007, at 20:55, Bradley Urberg Carlson wrote: Thanks for the suggestions. On Oct 17, 2007, at 6:06 PM, Stephen Wilcox wrote: well.. the problem of course is that you pull in the traffic from the aggregate transit prefix which costs you $$$ but then you offload it to the customer via a peering link for which you are not being paid A bigger problem is that my IX peer pays less to my customer for transit. If my customer notices that transit traffic has been going around him, he may be grumpy. I prefer happy customers. Okay but: 1. Your customer/customer's customer is the one doing the broken routing here not you.. if he wants to be grumpy you should point him in the direction of the guy who is announcing the bad routes in the first place! 2. If I'm following this, your peer pays your customer? So you are peering with your customer's customer? If that was me I would either depeer them or tell them that you have an issue and need it resolving urgently or you my depeer them. You're not the bad guy here ;) its a pain but you cant stop the customer from doing it.. you can however filter your customers prefix at the IX (an ASN filter would be easiest) In this case, the IX peer had let their transit provider (my customer) source the routes, then later advertised their own routes at the IX using their own ASN (so inconsistent source-as, and my as- path filter missed them). I don't think they were trying to steal bandwidth; just sloppy networking. wow, i think i need a diagram!! :P i don't like sloppy networking, i would depeer anyone who i find is not up to my standards on what makes a 'peer'. this doesnt happen very often but if we want to educate people you can try talking and if that fails take action. I can either build a big import filter, dropping routes offered to me at the IX that are subnets of routes advertised to me by my transit customers (doesn't scale); or just audit customer routes versus peer routes periodically, looking for "bandwidth stealers". It sounds like that is the usual approach. not really, its pretty unusual. now that i understand the picture better tho i think you dont want to be filtering.. 90% of people won't peer with downstreams to avoid this kind of issue.. either you need to do that too or you need to make them fix it (if your peering is valuable to them they will do it) don't forget they are getting a free lunch here, and that is unacceptable. if they are intentionally stealing your bandwidth then that is a major problem, if its an accident then you really should take action and insist they fix it. immediately and temporarily dropping the peering would be a good option Steve
RE: 240/4
> Okay, this has descended to a point where we need some fact injection. 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 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 for everybody but merely remove the barriers that allow others to engineer solutions for their situation. > So, what's your game plan to replace all these broken IPv4 stacks? Again, we are not the gods of the Internet. It is not our reponsibility to fix every problem out there, but neither do we have to sit on our hands when we could enable others to deal with the issue. > Certainly. So why would we distract them with an > intermediate transition to "IPv4-240+"? I believe that people are not that stupid. The only organizations that go after the 240/4 solution space will have good reasons for doing so. We do not have a good reason to deny them that possibility. > Remember, I was not > able to find any case that successfully worked; Your investigation showed that the software appears to have an extra line of code here and there which explicitly disallows 240/4 addresses. This is easy for vendors to fix. > But we could cop out on releasing 240/4 because it's just too > much work for a small benefit to a few sites on the Internet, > at a huge cost to the rest of the Internet. That's not fair. It is a trivial amount of work for the IETF to release the address space and for ARIN to add an extra question to their allocation forms "Do you want 240/4 addresses?". As for fixing code, given the level of code patching that is already done on a regular basis, removing the 240/4 blockages could also be considered a trivial level of effort. After that, it is not a public problem any more, and those of us who do not want or need 240/4 addresses can ignore it. > I'm fine with that, especially since it appears that > implementing "IPv4-240+" will incur even more serious money > for every participating network on the Internet, in upgrades, > adminitrative time and effort, etc. There are only two reasons that we would do such an upgrade. First, if it is bundled up in a patch release with other stuff. And secondly if a customer requests it. The cost is effectively zero in the first case, and in the second case it will be covered by revenue. > > We should do everything we can to remove roadblocks which > would cause > > IPv4 to run out sooner, > > Where practical. This ... isn't. What is impractical with asking the IETF to revise an RFC? What is impractical in asking ARIN to add a question to their forms just as they have already done for 32-bit AS numbers? What is impractical in asking vendors to remove the code blocks in their next patch release cycle? > And this ... would cause some people to delay IPv6. So it's bad. IPv6 is not a universal good. The Internet is far more complex with far more dark corners than you realize. But for the owners of those dark corners it makes economic sense so why should anyone try and convert them to the one true Internet architecture? --Michael Dillon
Re: 240/4
> 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 have already > provided patches for Linux and BSD so that 240/4 addresses work > normally. Cisco would fix IOS if the IETF would unreserve these > addresses, and likely MS would follow suit, especially after Cisco makes > their changes. Now, please explain the magic method you're going to use to cause that "one line of code" to be removed from more than a billion devices that are currently able to use the Internet. Remember that a lot of these devices are deployed in spots such as little gateway NAT devices owned by John Doe at 123 Anydrive, and so when he is unable to get to some website because some brilliant hosting service has chosen to place a bunch of servers on 241.2.3.0/24, his reaction is most likely going to be "so and so sucks" and move onto a competitor's web site. Further, when one of your magic clients with the "updated" version of Windows XP that supports "IPv4-240+" and the misfortune to actually *BE* on one of those decides to contact pretty much any existing website on a VPS that's on "auto pilot", and there's a ton of those, dontchaknow, we are talking a problem significantly worse than "failed to update bogon filters". Not only does the hosting company have to fix their bogon filters, but they also have to fix the TCP stack on every server under their control, which is going to be extremely labor intensive. Do we want to start discussing all the other places that knowledge of network classes is built into software, and the subtle ways in which things may break, even if they appear to "work" for some crappy definition of "work"? Please don't try to re-engineer the entire IPv4 Internet because you'd like a small additional allocation of IP space that isn't currently usable. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: 240/4
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 were released for RFC1918 use behind NAT devices," though implementors may find some of the same problems that I did. I attempted(!) to configure: Windows XP FreeBSD 4 FreeBSD 6 Mandriva Linux for use with 240/4 on a standard Ethernet interface. Both Windows XP and Mandriva Linux refused to accept 240 as a valid first octet. Both FreeBSD 4 and FreeBSD 6 accepted the 240 address, but would not put traffic on the wire, and did not answer a local ping of the address (i.e. "ping 240.0.0.2" on the box with 240.0.0.2). I use a FreeBSD based router here at the house, and I had configured it as 240.0.0.1. It does not answer a local ping for 240.0.0.1. However, from a directly connected client on a normally addressed IP network, I am actually able to ping 240.0.0.1: % ping 240.0.0.1 PING 240.0.0.1 (240.0.0.1): 56 data bytes 64 bytes from 240.0.0.1: icmp_seq=0 ttl=64 time=0.371 ms 64 bytes from 240.0.0.1: icmp_seq=1 ttl=64 time=0.379 ms 64 bytes from 240.0.0.1: icmp_seq=2 ttl=64 time=0.445 ms 64 bytes from 240.0.0.1: icmp_seq=3 ttl=64 time=0.255 ms ^C --- 240.0.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.255/0.363/0.445/0.068 ms However, pings for 240.0.0.2 do not result in any traffic on the 240.0.0.* wire. Quagga did not seem to be interested in propagating the route to the other router, though I did not bother to investigate this. Looking to this bright point of success, I proceeded to ask Windows XP to ping 240.0.0.1, hoping that perhaps it would be acceptable as a destination. Windows XP responded with "Destination specified is invalid." I then tried with the Mandriva, which responded with "connect: Invalid argument." So. We can draw some interesting and useful conclusions. A number of major client and server operating systems do not currently work with "IPv4-240+". It is certainly possible to make any given major client or server operating system work with "IPv4-240+", but doing so only fixes one endpoint. The Internet works because there's a general property that any node can talk to any other node. Introducing nodes that can only talk to other nodes with shiny new IP stacks introduces a problem similar to the transition to IPv6, except that the transition to IPv6 is at least a fairly obvious and readily- identifiable issue. If you ask someone "do you support IPv6", it's pretty easy to know. If you ask someone "do you support IPv4-240+", that's less easy to know. Getting all nodes to upgrade to "IPv4-240+" is simply not possible. I have no idea where I'd get the upgrade for the Ascend GRF's (okay, well, they're not in production, but point remains). The ROI on the move to v6 is immense compared to the ROI on the move to v4-240+, which will surely only benefit a few. Do the math. This is stupid. If you happen to have all WinXP clients, a patch to make 240 work, and you stick them all behind NAT, well, golly, by all means, have fun. > > 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 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, > maybe even years. And for the rest of us, the IPv4 addresses that are > NOT used by those organizations, do indeed buy only a little extra time. The problem is that it's not useful space if it can't talk to most of the Internet. And if you're proposing it as NAT space, then it isn't really relevant if the space is "released" or not. Just use it. It's a virtual certainty that Class E space will never find some new magic use. > But the point is that we are not gods. We cannot foresee all the > variables. Yeah, well, maybe YOU can't, but *I* can see enough of the variables to reliably predict a "doomed to failure." I don't need to see all the variables. > 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? Great. > Therefore, even if 240/4 only gives us a few extra months > before IPv4 is exhausted, it is still worthwhile because it is likely to > help some more organizations get their IPv6 transition completed before > hitting the brick wall. So, what's your game plan to replace all these broken IPv4 stacks? > Since the value of the Internet, IPv4 or IPv6, > is in the near universality of access, it is to the bene
Re: 240/4
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-Unallocated.pdf There's an article about this in the latest IPJ: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ ipj_10-3/103_awkward.html Of course, these issues aren't new: http://www.merit.edu/mail.archives/nanog/2006-05/msg00290.html But I wouldn't be surprised if the number of problems increases as we near the point that all the unicast IPv4 space is allocated. Regards, Leo Vegoda
Re: 240/4
> 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
Re: 240/4
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 > > stuff for free. I doubt ISPs are going to pay huge amounts of money to > > support a peer crazy enough to try this. And until tested, there is no > > guarantee that hardware based routing platforms (your PFCs, etc) can > > route Class E addresses as if they're unicast. > > So how about pulling a reachability test and announcing a few /19's from > 240/4, stick a website on it and get people to report back? If there was serious community interest in this, I am sure the RIPE NCC could be persuaded to test this as part of the well-oiled de-bogonising machinery. this immediately provides automated measurements as well. It may take a little longer than sual to set up as we may want to ask all our de-bogonising peers whether they are OK with this just to be sure. Daniel PS: Personally I am not convinced that this space will ever become useful for global routing. But we won't know for sure until we have tried it.
