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: 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: [routing-wg]BGP Update Report
>> The comment still applies. Imagine that this system were implemented >> globally on all international/intercontinental air routes. It would still >> be nice to avoid having each of those airplanes cause a globally-visible >> routing update whenever it crosses some geographical boundary. > > The problem is physics: The speed of light is about 300.000km/s in air > and about 200.000km/s in fibre, which means a VPN solution causes an > _additional_ >70ms delay for some additional 7000km VPN distance. If one assumes a well-engineered VPN solution that interconnects the ground stations to "peering" points to the rest of the Internet, then there should be no increase in delay for traffic outbound from the plane toward the Internet - traffic path will still be plane -> ground station -> nearest exit point to Internet. The amount of delay increase for return traffic is hard to quantify; it will depend on how well the Conxion service network/VPN is connected to its upstream providers, how well-connected those providers are to interconnect points to the rest of the Internet, whether shortest-exit routing (or some other "optimized exit routing") is implemented between the various providers, etc. Many of these issues will apply to the current, dynamically-route-every- prefix model, too. In some cases, the VPN will make little or no different in delay; in some cases, it may increase one-way delay a bit. On the upside, worries about more-specific filtering and route-dampening will go away. > No, VPN and NAT and PA and shim are not the solution for todays > mobile communications demands. From the view point of the developer > of such an intercontinental communications system todays internet > technology looks outdated, the BGP re-anouncement is just a hack. > Indeed, RFC1661 is dated July 1994. > > This is just another example for the obvious demand of a true dynamic > routing system beeing capable to handle large numbers of prefixes and > dynamic changes in the routing table. Other demand results from mobile > networks, IPv6 PI etc. > > The demand _is_ there, simply saying "don't use PI, do keep 200 customers > rules (IPv6), don't accept small prefixes, don't permit dynamic changes, > do wait for our perfect shim solution which takes short additional 10 years > to develop, do purely theoretical discussions on geoadressing" as the > "restrictive approach" is not the solution. > > Either the Internet community will find good answers to these demands, > or the markets will find solutions without the Internet community ... > > Ceterum Censeo: BGP_Standard_Update subito, IPv6 PI subito ... If one assumes no changes to ipv6 semantics, it is hard to envision such a solution being possible. "PI routing" degenerates into flat routing and building "a true dynamic routing system beeing capable to handle large numbers of prefixes and dynamic changes in the routing table" is difficult to impossible if one assumes a) a single number space that accomodates both routing information and endpoint-identification (which is a fundamental design assumption in ipv6 as currently specified) and b) continued super-linear growth in the number of unique subnets that are identified using that numbering space. There are smart people who have been looking at how to fix this for more than a decade (some would say that research along these lines dates back to the 1960s...see http://www.nanog.org/mtg-0606/fuller.html for a recent NANOG presentation on this topic, with pointers to earlier work); virtually all of the designs that have been offered require routing locator/endpoint-id separation. Unfortunately, those who put together the current ipv6 did not choose to follow the locator/endpoint-id separation path. For a variety of reasons, trying to retro-fit the split into ipv6 with something like shim6 is difficult and it running into a lot of resistance. --Vince
Re: [routing-wg]BGP Update Report
> On Mon, Sep 11, 2006 at 10:28:49AM -0700, Vince Fuller wrote: > > One might also imagine that more globally-friendly way to implement this > > would have been to build a network (VPN would be adequate) between the > > ground stations and assign each plane a prefix out of a block whose subnets > > are only dynamically advertsed within that network/VPN. Doing that would > > prevent the rest of the global Internet from having to track 1000+ routing > > changes per prefix per day as satellite handoffs are performed. > > As has been said before, and is also readable in that blog entry: the > system is supposed to create *one* advertisement change when the plane > is crossing from the "Europe" to the "US" ground station (etc.), not > 1000+. The comment still applies. Imagine that this system were implemented globally on all international/intercontinental air routes. It would still be nice to avoid having each of those airplanes cause a globally-visible routing update whenever it crosses some geographical boundary. --Vince
Re: [routing-wg]BGP Update Report
On Mon, Sep 11, 2006 at 12:32:57PM +0200, Oliver Bartels wrote: > Hi Gert, > On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote: > >Ummm, well, this is a damn fast plane if it will reach another continent > >1843 times per day (or even "per week")... - which should be the only > >time the BGP announcement moves. > > > >Sounds more like "the BGP-follows-plane system has some stability problems". > > Nack. > > Probably they are using low or medium earth orbit satellites, which > _are_ damn fast in orbit. Otherwise the round trip time would be > unacceptably high. > > As the whole thing is 3D, some of them might have contact to > ground stations on this or the other side of the great lake, > depending on their 3D position, even thru the plane travels > on a well defined track (probably a 3D circle, too) in just one > direction only. > > Ceterum censeo: Nevertheless this moving-clients application shows > some demand for a true-location-independend IP-addresses > announcement feature (provider independend "roaming") in IPv6, > as in v4 (even thru this isn't the "standard" way, but Connexion is > anything but standard). Shim etc. is not sufficient ... One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed. --Vince
Working on a long-term ipv6 multihoming solution
This is a follow-up to my and Jason's presentation from Wednesday. Several people mentioned in the hallways that they were interested in following this issue and possibly helping work on the solution. If you are one of them and haven't already seen a message subscribing you to the mailing list, please send email to: [EMAIL PROTECTED] It would be helpful to indicate whether you are interested in following the work or in actively participating in it. Note that "ipmh-interest" is not the actual mailing list (there will be two separate lists established: "ipmh-discuss", which is a open mailing list to follow and track the work and "ipmh-design" which will be a closed list for a small, focused design team. If anybody has issues with this list being hosted at Cisco (it is most definitely not a Cisco-only effort and shouldn't be perceived as such; I'm only hosting it there for convenience), please provide that comment too; if there is strong consensus, I'll be happy to move the list to a more "neutral" place. --Vince P.S. Jeff Burgan: can you please contact me offline? It looks like your employer's email system is misconfigured and is bouncing all mail that I attempt to send to you.
Re: a radical proposal (Re: protocols that don't meet the need...)
Uh-oh, two postings to NANOG in as many days... hopefully, this will be my last. > [[pushed the wrong button last time. This is the complete reply]] Oh, the irony in that statement... this whole argument has certainly pushed "the wrong button" for me. > > > - join a local IXP, which may be a physical switch or > > virtualized by a set of bilateral agreements. > > Why should they join an IXP if they already have > private peering arrangements? > > > - outside the region, they advertise the prefix of the > > regional authority > > Mixing government with operations? If you favor doing > that then why not just give IPv6 addresses to the various > national governments and let the UN sort it out? > > Personally I disagree with any scheme which calls for > national or municipal governments to assign IPv6 addresses > to end users. Dressing it up as a "regional authority" > does not make it any nicer. > > Forcing people to join an unecessary IX is not the way > to solve the problem of regional aggregation of routes. > This is a purely technical problem which can be solved > by the RIR practices in allocating IPv6 addresses. If they > would allocate addresses in a geo-topological manner then > end users and ISPs would be free to aggregate routes > outside of their region without any involvement of governments > or any requirement to join consortia or IXes. It does > require the users of such geo-topological addresses to > ensure that in THEIR region, there is sufficient > interconnectivity (physical and policy) between ISPs for > the addressing to work. But that does not need to be determined > or managed centrally. > > Geo-topological addressing refers to RIRs reserving large > blocks of designated addresses for areas served my large > cities (over 100,000) population. When end users are located > in fringe areas roughly equidistant between two or more such > centers, the RIR simply asks the end user (or ISP) which is > the center to which they want to connect (communicate). > This addressing scheme operates in parallel with the existing > provider-oriented IPv6 addressing scheme but uses a different > block of IPv6 addresses out of the 7/8ths that are currently > reserved. No hardware or software changes are required for this > to work, merely some geographical/economical research to determine > the relative sizes of the address pool to be reserved for each > of the world's 5000 largest cities. The routing system doesn't particularly care whether your "geo-topo" addressing is imposed by governments, RIRs, or a beneveolent dictator; in all cases, the result is Soviet-style central planning to force the network topology to conform to your idea of what it "should" be rather than following the economic realities of the those who would build the network. A "geo-topo" addressing scheme works great for address assignment *within* a single AS and it even could have worked pretty well back in 1990, when there was a "core" NSFNET and a bunch of regional networks. But the key attribute of these scanerios is the existance of centralized control of the topology. There is no such control of the topology today; those who wish to impose such control are asking for a regulatory environment that would radically change the nature of the Internet. > > > Whenever I have talked about the model with an ISP, I have gotten > > blasted. Basically, I have been told that > > > > (1) any idea on operations proposed in the IETF is a bad idea because > > the IETF doesn't listen to operators > > This is true. Top-down does not work in Internet operations. > We need bottom-up, i.e. customer demand. The IETF needs to > view their role as enablers of customer demand. If the IETF > can create something that will work for ISP customers, then > ISPs will be happy to go along, once the customers demand > the service. Interesting to see an argument for bottom-up design in a post which otherwise calls for top-down planning of the network architecture. What the IETF, and more specifically the IAB, really needs to do is to acknowledge that there is a very real problem with the ipv6 routing architecture (which is identical to the IPv4 routing architecture), one that cannot be fixed without making incompatible changes to protocol implementation. Band-aids like shim6 just aren't going to cut it if the goal is to build a highly-scalable network of autonomous routing domains (in other worse, a really big network where end sites have very flexible choices of providers). The first step to finding a solution is to admit that there is a problem. > > (2) the ISPs aren't going to be willing to make settlement payments > > among themselves in accordance with the plan > > Wait until this starts appearing as a requirement in > custome RFPs. Then wait until governmental bodies step in to offer their help in the form of regulation. The two go hand-in-hand. If you want to re-invent the telco model of interconnection, this is a prett
Re: a radical proposal (Re: protocols that don't meet the need...)
I'm sure I'm going to regret posting this, if for no other reason than that I will immediately start receiving more spam, and I suspect that I am just re-stating things that TLi and others have been trying to state both here and on PPML, but I guess I just can't resist today... [Disclaimer: I don't work for a provider these days; in fact, I work for the same vendor that Fred does, so it may seem odd that we are arguing... but I did work for university/regional/national/global ISPs from 1988 until 2001 and during this time did participate, to some degree, in the IETF process. I even tried to contribute to the IPNG process early on until it became clear that the political process that drove the selection of ipv6 had very little connection to operational reality. In case it isn't obvious, these views are mine alone and do not represent the position of my or your employer] > Interesting. This is what has been called metropolitan addressing. > I'm certainly not the one who first proposed it, although I have > thought about it for a while, dating at least as far back as 2001. ... > This turns the business model of routing on its head. Typically today > if Alice is using ISP AliceNet and Bob is using ISP BobNet, Alice > hands her packet to AliceNet, AliceNet gets it to BobNet in the > cheapest way it can, and BobNet carries it halfway around the world > to Bob. Bob's ISP carries the burden of most of the work. But in this > model, if AliceNet happens to also provide service in Bob's region, > AliceNet might carry the packet to the region and only give it to > BobNet for the last 500 feet. To address your points: > Whenever I have talked about the model with an ISP, I have gotten > blasted. Basically, I have been told that > > (1) any idea on operations proposed in the IETF is a bad idea because > the IETF doesn't listen to operators Would you disagree that the IPNG process essentially ignored the "hard" issues (multihoming, endpoint-id/routing locator split, easy/transparent renumbering, etc.) that were raised some 10 or more years ago? It may have been "operators" who were most vocal in raising these issues (since they are the ones who are suffering and will suffer the consequences of their not being addressed -- no pun intended) but there were some pretty smart people who didn't work for operators (e.g. JNC, TLi) who also argued for something better than "IP with bigger addresses" as being needed for IPNG. This certainly gave some credence to the idea that the IETF "doesn't listen to operators" or to the others calling for a re-examination of the routing architecture. Slight digression: I recall getting up during the plenary (at the time, I was very public-speaking-averse, so the memory is vivid) at the Amsterdam IETF (July, 1993) back when the whole "IP isn't going to scale; we need to build something better" sentiment was starting. I stated that any solution that didn't deal with transparent renumbering and multihoming was a non- tarter. There was lots of applause then and promises that these issues would definitely be covered. We still wound up with a non-functional ipv6. > (2) the ISPs aren't going to be willing to make settlement payments > among themselves in accordance with the plan > (3) routing isn't good enough to support it > (4) and in any event, this makes it too easy to change ISPs > > In short, "hell no". It's a little more basic than that. I'm no graph theory expert and reading such stuff gives me a headache, but I do understand that abstraction (summarization or aggregation) of routing information is only possible if the identifiers that are used for numbering network elements (the "addresses") are assigned in a manner that is isomporphic to the network topology. TLi started writing a good paper which described this in terms of sets and subsets; unfortunately, I don't think it ever saw the light of day). Those who propose "geo-topological" addressing, an oxymoron if ever there were one, are effectively dictating how the network topology is to be organized, with rather profound implications for provider business models. If addresses are assigned in this manner, then service providers whose networks span multiple address assignment domains (connect to more than one city or however the geograpic areas are split up) must: a) connect to all designated interconnection facilities associated with the address assignment authorities in the geographic areas they wish to serve and 1) carry all more-specific routes for all providers in all of the cities that they serve (which eliminates aggregation) or 2) provide free transit service for any customer of a competitor in a geographic area whose addresses are aggregated or 3) enter into a settlement agreement (which implies a regulatory regime unprecedented in the Internet business) with all other providers in geographic areas which they serve Is it any surprise that larg
