November 1997 - Test - lists.nanog.org

IPv8
by Dave Geurs 09 Nov '97

09 Nov '97

Folks, All this talk about IPv8. A liitle background check says that v8 is already spoken for. Jim needs to get a real number if he wants to go through with his charade. Sorry for continuing this, put it's time this stuff was at least acknowledged as bogus to the core. ============== VERSION NUMBERS In the Internet Protocol (IP) [RFC791] there is a field to identify the version of the internetwork general protocol. This field is 4 bits in size. Assigned Internet Version Numbers Decimal Keyword Version References ------- ------- ------- ---------- 0 Reserved [JBP] 1-3 Unassigned [JBP] 4 IP Internet Protocol [RFC791,JBP] 5 ST ST Datagram Mode [RFC1190,JWF] 6 IPv6 Internet Protocol version 6 [Deering] 7 TP/IX TP/IX: The Next Internet [RXU] 8 PIP The P Internet Protocol [PXF] 9 TUBA TUBA [RXC] 10-14 Unassigned [JBP] 15 Reserved [JBP] REFERENCES [RFC791] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream Protocol, Version 2 (ST-II)", RFC 1190, CIP Working Group, October 1990. PEOPLE [JPB] Jon Postel <postel(a)isi.edu> [JWF] Jim Forgie <FORGIE(a)XN.LL.MIT.ED> [RH6] Robert Hinden <Hinden(a)ENG.SUN.COM> [RXU] Robert Ullmann <ariel(a)world.std.com> [PXF] Paul Francis <francis(a)cactus.ntt.jp> [RXC] Ross Callon <callon(a)wellfleet.com> [Deering] Steve Deering, <deering(a)parc.xerox.com>, March 1995. Regards, Dave

1 0

Looking at IP Addresses Differently
by Jim Fleming 09 Nov '97

09 Nov '97

It seems that most people look at IP addresses as hardware-like, host identifiers, that are close to the "assembly language level" of the Internet, if there was such a thing. In an expanded address space, it can help to look at IP addresses as "opaque handles". In other words, they are just numbers that are passed around in the huge distributed computer system called the IPv4 Internet core. Low-level routers just happen to agree that they should advance packets in certain directions based on the values of those numbers. Routers are sort of like dumb ALUs that do not contribute much to the computation being done. If you look at packets with extended addresses, it is very much like moving from 8086 real mode addressing to 386 segmented or 486 virtual memory addressing. The addresses become logical offsets and less tied to the hardware routers. This is especially true, if new address spaces are arranged around the edges and the core is simply used for transport. With this arrangement, the task of the core is to look at the extended addressing bits and move the packets from one side of the core to the other as quickly as possible. The opaque 32 bit handles only become interesting once the packet gets to a destination where it is unwrapped for "execution"...using the ALU and distributed CPU metaphor. Now, with extended address bits the focus shifts from the 32 bit handles to the extra bits and the way they come about. In the IPv8 Plan, 2,048 TLD Authorities are tasked with being the keeper of the 11 extended address bits. Each authority can have a different Address Management plan and the 32 bit handles can have very different meanings depending on the agreements between the parties that use these extended addresses. The Address Management plan may not have anything to do with the low-level details of routing, especially across the IPv4 core. In some cases there may be very little routing that occurs based on the 32 bit handle once the packet traverses the IPv4 core. In the IPv8 Plan, the assumption is that the IPv4 core provides reliable 32 bit routing and DNS. The DNS can be used to dynamically discover which IPv4 addresses should be used as ports for tunnels from one side of the core to another. This is handled based on look-ups using the extended address bits, not the 32 bit handles. This is why it is useful to tie a TLD to the extended address bits and why with 11 bits, there can be 2,048 TLDs. For most of the TLDs, the Address Management plan or the "addressing mode", using CPU terms, would naturally be "real mode" (i.e. the 32 bit handle is indeed a host address and routing is normal). As people begin to do more research with true object-oriented platforms distributed on a large scale, other addressing modes and Address Management plans can be developed. The DNS can once again be used to encode the PSW of the TLD. The Program Status Word can indicate which addressing mode is being used and other global information. This allows for variety in the number and types of modes allowed and the mode can be controlled globally. In summary, if one looks at a packet with an IPv8 43 bit address, they have to look at the 11 extended address bits and they have to map those to a particular TLD which in turn can be used to discover the addressing mode in use which determines how those extended address bits are used. In most cases, the 11 bits are used to traverse the core and the 32 bits are used to route from there, in other cases more interesting uses can be developed for the 32 bit quanitities which many people view as IP addresses, but which will eventually become opaque handles. Jim Fleming Unir Corporation IBC, Tortola, BVI

1 0

BGP4 code source
by salnot patrice 09 Nov '97

09 Nov '97

Hello, I'd like to know where i can find the code source of BGP4 for freebsd or linux . Thanks.

1 0

IPv4 + IPv8 Addressing
by Jim Fleming 08 Nov '97

08 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 08 Nov '97

08 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