- Test - lists.nanog.org

IPv4 + IPv8 Addressing
by Jim Fleming 09 Nov '97

09 Nov '97

Since NANOG people are generally experts about IPv4 and other networking topics. It might be easier to explain the "IP handle" issues using more nitty gritty examples. Imagine that most packets entering the IPv4 core transport network are IPv8-style encapsulations. What you would have on the data links would be.... { [ IPv4 Header ] [ IPv8 Header ] } (payload) Where.... {} represents the combined IPv4/8 Header [] represents a 20 byte IPv4/8 header () represents the data or payload with other layers If you look at the combined IPv4 and IPv8 headers you will see that there are 40 bytes present. (assume no options) In the IPv4 Header is all of the standard stuff including a checksum and a 32 bit address field. In the IPv8 Header there is no checksum and instead there is a 3+8+32 bit address field (i.e.. 43 bits). The address field for the combined IPv4/8 Header is 75 bits long...32+3+8+32 = 75. Given this, it is important for NANOG planners to consider what that IPv4 address really means. In the current IPv4 network that 32 bit address is used by routers and hosts to route the packet to the correct O/S that pulls the headers off and routes the payload to the right processes or other parts of the O/S. In the future, that IPv4 32 bit address may not have the same "meaning". Instead, it may become a tag or ASN-based index which indicates where the packet shown above should be gatewayed onto the IPv8 network. In an IPv8-only world, in theory, large companies could have ONE IPv4 address and that address could be reused over and over on major networks that support a gateway to the IPv8 network. If a 16 bit ASN is used as a convention to form the low 16 bits of that 32 bit IPv4 number, then the 75 bits become... 16+16+3+8+32 or 16+ASN+3+8+32 OK...if you are still with me, let's look at what happens when an IPv4/8 packet enters a large ISP's network that supports a gateway to the IPv8 world. In this scheme that ISP's routers look at the 16+ASN and find that they have a specific route to a gateway to the IPv8 network. The packet gets routed there and stripped of the IPv4 header and sent along with the 3+8+32 addressing. Note that many ISPs can use the SAME 16+ASN address as long as they dump the packet on to the IPv8 network. Once that happens, that ISP has done its job as an IPv4 core operator. If the ISP does not have the specific information about that 16+ASN address, then the IPv4/8 packet gets routed on the global IPv4 core and eventually makes its way to the router or host that supports that address and that machine handles the gateway to the IPv8 network. There of course is a huge performance difference in each scenario. In the first case the ISP is smart enough to have that specific 16+ASN routed directly to their gateway. Large companies can pay key ISPs in certain areas to trap those addresses and make sure that their packets get this special handling. This is a revenue opportunity for ISPs and large back-bone providers. Returning to the concept of an IP address as a opaque handle, one can see that in these scenarios the 16+ASN component of the 75 bit IPv4/8 address is not really a routable address in the current view of IPv4. Instead, it can become an index or handle which is used to identify the proper IPv4/8 gateway to use on the local machine. Now...you might be asking, how does the "system" come up with these 16+ASN values to glue on the front of the 3+8+32 packets ? In the system that I am working on, the answer is...the IPv4 DNS...in other words, if you are sitting on the outside of the IPv4 core transport and you have 3+8+32 addresses, you ask the DNS to give you a "route" or "handle" which is a good place to send 3+8 traffic. The DNS returns a 32 bit 16+ASN value and that is used in the first 32 bits of the 75 bit address. Via the DNS, various 16+ASN values can be returned and of course, time, and caching and the dynamics of the changing network come into play. All the people sitting on the outside "see" are the 3+8+32 bit addresses. The IPv4 core provides the DNS and the 16+ASN based transport. In this way, we allow the core to evolve to be a rock-solid fault-resilent network run by people like yourselves, and a new Address Management scheme can build around the edges using familiar technologies and varying degrees of service and reliability with the core largely transparent from a day to day operational point of view... Thanks for your time... Jim Fleming Unir Corporation IBC, Tortola, BVI

2 1

Re: BGP/Multihoming
by Howard C. Berkowitz 09 Nov '97

09 Nov '97

url not found http://ds.internic.net/internet/drafts/draft-berkowitz-multirqmt-00.txt OOPS! That should be, http://ds.internic.net/internet-drafts/draft-berkowitz-multirqmt-00.txt On Sat, 8 Nov 1997, Howard C. Berkowitz wrote: > I've posted an Internet Draft intended to help clarify some confusing > alternatives that CID students often ask. Discussions on the NANOG mailing > list, as well as my student questions, suggested to me there might be a > need for a tutorial at a different level of abstraction than the specific > technique discussions that are available. > > It's not intended to show how, for example, to do BGP multihoming. It's > intended to help someone, especially an end user organization, decide what > the problem is they are trying to solve. Once they know that, the next > step will be selecting DNS-based methods, and/or routing-based methods > using BGP or IGPs. Comments very welcome, especially in the DNS area. > > My plan is to submit this to the IDR WG at the IETF in December, but it's > an individual contribution at this point. > > > To Be Multihomed: Requirements & Definitions > draft-berkowitz-multirqmt-00.txt > > You can FTP or HTTP it from: > > ds.internic.net/internet/drafts/draft-berkowitz-multirqmt-00.txt > > > 2. Abstract > > As organizations find their Internet connectivity increasingly critical > to their mission, they seek ways of making that connectivity more > robust. The term ''multi-homing'' often is used to describe means of > fault-tolerant connection. Unfortunately, this term covers a variety of > mechanisms, including naming/directory services, routing, and physical > connectivity. This memorandum presents a systematic way to define the > requirement for resilience, and a taxonomy for describing mechanisms to > achieve it. Multiple mechanisms may be appropriate for specific > situations, including DNS, BGP, etc. > > >

1 0

Re: BGP/Multihoming
by Howard C. Berkowitz 08 Nov '97

08 Nov '97

I've posted an Internet Draft intended to help clarify some confusing alternatives that CID students often ask. Discussions on the NANOG mailing list, as well as my student questions, suggested to me there might be a need for a tutorial at a different level of abstraction than the specific technique discussions that are available. It's not intended to show how, for example, to do BGP multihoming. It's intended to help someone, especially an end user organization, decide what the problem is they are trying to solve. Once they know that, the next step will be selecting DNS-based methods, and/or routing-based methods using BGP or IGPs. Comments very welcome, especially in the DNS area. My plan is to submit this to the IDR WG at the IETF in December, but it's an individual contribution at this point. To Be Multihomed: Requirements & Definitions draft-berkowitz-multirqmt-00.txt You can FTP or HTTP it from: ds.internic.net/internet/drafts/draft-berkowitz-multirqmt-00.txt 2. Abstract As organizations find their Internet connectivity increasingly critical to their mission, they seek ways of making that connectivity more robust. The term ''multi-homing'' often is used to describe means of fault-tolerant connection. Unfortunately, this term covers a variety of mechanisms, including naming/directory services, routing, and physical connectivity. This memorandum presents a systematic way to define the requirement for resilience, and a taxonomy for describing mechanisms to achieve it. Multiple mechanisms may be appropriate for specific situations, including DNS, BGP, etc.

1 0

Re: New MAE-EAST
by Al Roethlisberger 08 Nov '97

08 Nov '97

At 08:33 PM 11/5/97 -0500, you wrote: > > Paul, > > I have not spoken with you before, so I do not know if your > posting below is meant in a literal, nonfacetious manner. > >> > With all of the problems with MAE-EAST..... >> > >> > Any plans from anyone to create a ATM exchange point in the DC area? > > For what it's worth, I do understand that there is a plan to create > an ATM exchange point in the DC area, at speeds exceeding those > currently available. > >> Given the latency we've seen over some ATM backbones, > > The latency increased in network areas that are switched is generally > (by all but the zealots) given to be less than that of comparable > layer three data moving topologies. > > The latency induced by several providers claiming an ATM backbone > is generally attributable to an error: they leave off one important > word -- shared -- . The latency about which I assume you speak is > caused by large amounts of queuing. This queuing is demanded by network > oversubscription. The latency introduced by the oversubscription > is consistent with any oversold network. > Perhaps he is referring to latencies that some beleive is incurred as ATM 'packet shredding' when applied to typical data distributions encountered on the Internet that fall between the 53byte ATM cell size and any even multiple thereof? Some reports that I have seen show a direct disavantage for data where a large portion of 64byte TCP ACKS, etc. are inefficiently split among two 53byte ATM cells, wasting a considerable amount of 'available' bandwidth. i.e. one 64byte packet is SARd into two 53byte ATM cells, wasting 42bytes of space. If a large portion of Internet traffic followed this model, ATM may not be a good solution. I am not an authority on this position, so feel free to dispute, but perhaps that is one latency factor to which he was referring?

6 5

Re: BGP/Multihoming
by Paul Ferguson 08 Nov '97

08 Nov '97

Here is a good reference/place to start: http://www.netaxs.com/~freedman/multi.html - paul At 11:48 AM 11/6/97 +0800, Michael R. Poyaoan wrote: > >The diagram below describes our current set-up: > >* We have two default routes via BGP with MCI (L1 and L2) for outgoing > traffic. >* The two MCI links are configured to load share incoming traffic thru the > use of MEDs. > > AS701 > +--------+ > | UUNet | > +--------+ > | > AS3561 | > +-------+ +--------+ > | MCI | | UNA | AS10275 > +-------+ +--------+ > | | | > | | | > | | | > L1| |L2 L3| > | | AS6648 | > | | +----------+ | > | +---| | | > | | Sky |-----+ > +------| | > +----------+ > >Questions: > >1. How can I use the third link for default routes? Is static routing > the only solution? > >2. Is it possible to load-share outgoing traffic between two different > ASN's? How? > >3. How can I unclude the third link for load-sharing incoming traffic? > >Please reply privately. > >Thanks, >--------------------------------------------------------------------------- >Michael R. Poyaoan email: mrp(a)skyinet.net >Network Operations Center voice: +63 2 411-2005 >Sky Internet, Inc. fax: +63 2 411-2003 >--------------------------------------------------------------------------- > > >

3 2

Announcing The New "MAE-EAST"
by Kent W. England 07 Nov '97

07 Nov '97

At 12:46 PM 11/5/97 -0800, Adam Hersh wrote: >With all of the problems with MAE-EAST..... > >Any plans from anyone to create a ATM exchange point in the DC area? > >-Adam Hersh > > In the true MAE spirit, I rented a parking place right next to the door to MAE-East. I've parked a UHaul trailer in that space with a really big Ethernet switch on it. Power comes from an extension cord to the ceiling light. Since they never turn off the lights, I have 24x7 power available. Ventilation comes from passing traffic and I have a backup fan in my truck. Aircraft avoidance is made possible by rapid mobility (I keep the motor on my pickup running.) Forklift upgrades are entirely avoided since I already have a pickup truck. Marketing is simple. "Everyone you never heard of is already connected to Kent's Trailer Exchange." If we decide we don't like the MAE-East garage we can simply move it, if your drop cables are long enough. I avoid latency problems by running the switch at faster than light speeds. There is no packet shredding at Kent's Trailer Exchange, although from time to time I rewrite packets and turn all the IP options on, just for fun. Statistics are quite easy too. I've already published the traffic growth charts for the next 12 months. see http://www.6SigmaNets.com/trailer-exchange/business-plan/index.html In short Kent's Trailer Exchange has everything you could want in a slapped-together public exchange point. Next time you leave MAE-East, drag a fiber drop on your way out the door and meet me at the trailer. We'll have you up and running in a giffy. Oh, and bring a cup of hot coffee. It's getting damned cold in the garage this time of year. --Kent President, CEO, Chairman, Chief Architect, Webmaster & Publicist Kent's Trailer Exchange An Instant Idea Brought to you by Six Sigma Networks

3 2

Re: Cyberpromotions plans to acquire or merge with a national ISP?
by Sean Donelan 07 Nov '97

07 Nov '97

>Sorry Randy, there's nothing in this you can cut or paste into your Cisco. >But I think that peering with a Cyberpromotions-partnered ISP would be a >huge operational problem based on reports of AGIS's experiences with them, >and I wanted to give everyone a heads-up that Cyberpromotions appears not >to be ready to fold up their tent and stop spamming us all quite yet. Quoting a phone company interconnection agreement: "The Telephone Company will administer its network to ensure the provision of acceptable service levels to all telecommunications users of the Telephone Company's network services. The Telephone Company maintains the right to apply protective controls on any traffic that it carries over its network in order to prevent unsatisfactory performance to other users." Time to talk to the lawyers again, sigh... > says three compaines are being considered, and all have peering > agreements through 2006 or 2008. "That allows us time to make this Since almost all peering agreements are covered by NDA's, who in the know could refute him. Hint: Does a 10 year peering agreement sound too good to be true? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities
by csilva＠notes.cc.bellcore.com 07 Nov '97

07 Nov '97

carl ford at bellcore is doing more work on this, please e-mail him for more info.... carl silva 908-699-7850 To: Alan Gebele/Bellcore@Bellcore, Carl S. Ford/Bellcore@Bellcore, Carl L. Silva/Bellcore@Bellcore cc: From: Luis D. Arango/Bellcore Date: 11/06/97 04:44:34 PM Subject: Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities Folks, As expected, fyi, rave review from the net community. Lou To: tli @ juniper.net cc: ferguson @ cisco.com, nanog @ merit.edu (bcc: Luis D. Arango/Bellcore) From: kc @ nlanr.net Date: 11/06/97 05:41:46 AM PST Subject: Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities > The operative concept in this paper is 'telephone networks'. > > "Architectural Solutions to Internet Congestion Based On > SS7 and Intelligent Network Capabilities" I particularly liked the myopic use of the term "Internet Congestion". And here I thought that they had a solution for MAE-East.... ;-) I think the paper would have been more accurately titled: "Kludges to get around modems that don't say goodbye." or "We never should have introduced flat rate local dialing. What now?" ;-) ;-) tony -- i almost went catatonic when i tried to read that paper -- check out sentence number One: The explosive growth of the internet has created problems for the Public Switched Telephone Network (PSTN), which for the forseeable future will provide the majority of users with internet access via dialup modems. i love how their phrasing it like they have this acute perception about the market demands. as though we're all still using modems by choice. as though THEY aren't the ones limiting us to this silly analog crap, despite that they already have perfectly high quality dedicated copper pairs into customer premises. the only reason Anyone is still using a modem is cause the PSTN can't seem to Get With The Program and learn how to speak Internet (speak it, hell, they can't even Spell it with a capital I in this paper. i think we should all lowercase pstn from now on.) (ok so that made less sense coming from me. whatever.) if it weren't so depressing it would be amusing, the attitude throughout this paper: that the PSTN views Internet traffic as something to quarantine off to its own network (keep it away from the precious lucrative pstn) this paper provides no architectural solution to, nor even insight into, Internet congestion. not even solutions that could clearly increase RBOC revenues (what morons) instead it draws Magic Sphere around the telephony network, shielding it from the Horrible Intimidating Internet, without any consideration of how they might be able to participate in evolving the Internet efficaciously. ok so maybe we weren't expecting some huge breakthrough from them, but did they have to so *Vividly* confirm my worst fears about the prevailing archaic pstn mindset. my favorite part was one of their possible solutions for how to divert circuit calls to ISPs based on some numbering scheme: to obtain all ISP and on-line service provider (OSP) telephone numbers, and configure office-based 'triggers' for these numbers. oh yeah. that'll work. all the phone numbers of all the ISPs. yum. the boggling part is that they're *already* openly assuming the need for an additional packet switched network No Matter What. and the pstn has already dedicated Always-On copper lines from customers to COs -- so their plan is to do some heuristics on the signals coming in from the copper pair, and turn it into a transient fixed bandwidth circuit. brilliant leap of logic right into the abyss, how did they manage that. can't they come up with a more broken model? (no, i don't want to know) i just don't see what's so repulsive to them about just building a PSI(nternet)N, colocating routers, then using the already dedicated circuits to customer premises to access it. (i guess that's what @home thought too; they seem to have at least gotten that part right) they're adding so much Kruft to their system just to avoid moving to a more capable one there is something so Deeply Wrong with this picture where's Kuhn when you need him maybe we should get michael moore to do a movie about it (i know, you all were planning to wait for the movie rather than read that article anyway. wise souls.) k

1 0

BGP/Multihoming
by Michael R. Poyaoan 07 Nov '97

07 Nov '97

The diagram below describes our current set-up: * We have two default routes via BGP with MCI (L1 and L2) for outgoing traffic. * The two MCI links are configured to load share incoming traffic thru the use of MEDs. AS701 +--------+ | UUNet | +--------+ | AS3561 | +-------+ +--------+ | MCI | | UNA | AS10275 +-------+ +--------+ | | | | | | | | | L1| |L2 L3| | | AS6648 | | | +----------+ | | +---| | | | | Sky |-----+ +------| | +----------+ Questions: 1. How can I use the third link for default routes? Is static routing the only solution? 2. Is it possible to load-share outgoing traffic between two different ASN's? How? 3. How can I unclude the third link for load-sharing incoming traffic? Please reply privately. Thanks, --------------------------------------------------------------------------- Michael R. Poyaoan email: mrp(a)skyinet.net Network Operations Center voice: +63 2 411-2005 Sky Internet, Inc. fax: +63 2 411-2003 ---------------------------------------------------------------------------

2 1

Cyberpromotions plans to acquire or merge with a national ISP?
by Paul A Vixie 07 Nov '97

07 Nov '97

Background: AGIS cut them off, they're suing AGIS, they're also making noises about starting their own backbone. In a USA Today article (05 Nov) they got more specific about their plans. Sorry Randy, there's nothing in this you can cut or paste into your Cisco. But I think that peering with a Cyberpromotions-partnered ISP would be a huge operational problem based on reports of AGIS's experiences with them, and I wanted to give everyone a heads-up that Cyberpromotions appears not to be ready to fold up their tent and stop spamming us all quite yet. Best quote from below: "AGIS engineers expressed skepticism that a deal like the one Wallace describes would be possible; even if one of the smaller backbone companies agreed to team up with him, backbones must negotiate to exchange traffic at "peering points" and many would refuse." "But Wallace's partner in the venture, Walt Rines, another e-mail marketer and president of Quantum Communications of Stratham, N.H., says three compaines are being considered, and all have peering agreements through 2006 or 2008. "That allows us time to make this thing happen so everybody's happy," he says. "We know things have to change." ------- Forwarded Message Newsgroups: news.admin.net-abuse.email Subject: USA Today Article..... Date: Thu, 06 Nov 1997 06:21:51 GMT OK, for those who couldn't or didn't want to get the November 5, 1997 USA Today article on Scamford...here are some excerpts. Section D, page 4D. Two articles by Leslie Miller, one doesn't give credit. A big picture of Scamford sitting on the floor of his office, he's holding a mail box with the letter EMAIL on the side. He is surrounded by computer equipment and cheap church dinner looking tables. "On-line lament: Deliver us from junk email" Talks about hijack servers, AOL lawsuits.... A real good tidbit here, something most predicted about the USA Today survey.. "Despite the annoyance, many users (55% in a Harris Survey in April) think spam is no big deal. "Just hit the delete button," said numerous respondents to a recent informal servey on USA TODAY's Web site." "Despised 'Spam King' sends no regrets" "He expects to sell more than 2 million in marketing-related products this year. And though temporarily sidelined, he says he's within days of announcing a deal that will give him "ownership and control" of one of the 20 or so providers whose networks make up the "backbone" of the Internet. The agreement will allow his company "to connect without fear of getting the lines turned off." "AGIS engineers expressed skepticism that a deal like the one Wallace describes would be possible; even if one of the smaller backbone companies agreed to team up with him, backbones must negotiate to exchange traffic at "peering points" and many would refuse." "But Wallace's partner in the venture, Walt Rines, another e-mail marketer and president of Quantum Communications of Stratham, N.H., says three compaines are being considered, and all have peering agreements through 2006 or 2008. "That allows us time to make this thing happen so everybody's happy," he says. "We know things have to change." [rest of article skipped] ------- End of Forwarded Message

2 1