- NANOG - lists.nanog.org

CHOCOLATE HEAVEN!!!
by eman＠ghostly.net 11 Sep '97

11 Sep '97

Death By Chocolate Cookies Be careful when you eat these cookies... Because they melt in your hands, not in your mouth! For the recipe: Send $2.00 and a self addressed stamped envelope (or email address) to: Innovative Concepts Attn: Nicole PO Box 2471 Carmichael, CA 95609-2471

1 0

Re: not rewriting next-hop, pointing default, ...
by Sean M. Doran 11 Sep '97

11 Sep '97

Scott Huddle <huddle(a)mci.net> writes: > This is yet another problem/opportunity, in that providers want/need > to implement policies (such as no default, or only accept traffic > from the following ASs, or only accept traffic for the following ASs, > or consistent announcement) that are are difficult to enforce and/or > automatically measure/detect with today's technology. > > Router/switch vendors and potential interconnect > providers take note! In fact, OFRV has taken note. :-) Remember that rate limiting exists and is workable. You should be able to rate limit now based on MAC address. Yakov Rekhter and others correctly observed some time ago that it is possible to forge MAC addresses to get around this. Enter the wonderful world of mixing RPF with rate limiting. Gee, that IP address shouldn't have come from you, so I'll toss it through the "not in profile" rule. Then you either play fascist and drop not in profile traffic or you play Dave Clark and set off alarm bells and drop any such traffic if there is congestion. I actually like the latter approach somewhat more (go figure). My implementation idea was to give any particular peer at a public exchange point a particular amount of "free" bandwidth, perhaps 1.5Mbps or so across a FDDI, and declare anything more than that "out of profile", and pass the traffic through a queue against which one would apply aggressive wred killing off anything that didn't look like well-behaved TCP. Then if there was still lots of traffic, one could begin negotiating terms for increasing the "floor" bandwidth. This has several advantages. Firstly, you can avoid completely or at least minimize the effects of overbooking your connection to any given public interconnect, no matter what the implementation is. (This is effectively like using an ATM fabric and carefully laying out VCs, only it probably works better :) ). Secondly, a tariff for bandwidth settlements is much easier when you can actually limit the bandwidth. I belive more than one provider is doing this now. (We are.) Moreover the rate limiting code is rather clever in that you can apply different dampening for different traffic profiles. You essentially want to be able to do something like this: -- if destination is me, use "peer" profile -- if destination is a peer of mine, use "transit" profile where the peer and transit profiles might be: -- drop or -- pass only N bits/second, M packets/second with varying values for N and M, and likely higher prices for higher values of N and M in the transit profile and possibly in the peer profile. Answering the questions, "is this for me" vs "is this for a peer" is apparently about to become much easier. :-) A long time ago I thought this was pretty clever, now I think this kind of rate limiting is absolutely essential. > > a senior engineer at a well-known provider just pointed out to us that > > a weenie provider at mae-east was > > o not rewriting next-hop > > o sending our routes to others > > o sending others' routes to us > > o likely pointing default at us Gee this sounds awfully familiar :( So, the "others" you don't peer with who are sending you traffic fall into the "drop" profile based on MAC address or RPF or some other mechanism (offline talk if you like). This was the original impetus for suggesting rate limiting to Fred Baker (to whom I am eternally indebted for having gotten it implemented pretty quickly), since this sort of things was happening to Sprint quite alot... > > when the larger providers decline to peer with the smaller, there is a sad > > reason. traceroute -g is your friend. That too. It is particularly enlightening to traceroute -g towards a network that is not in anyone's routing tables, to see if you are really being defaulted towards of if someone is simply providing transit and exploiting the next hop is on same LIS mechanism. Sean.

1 0

Re: not rewriting next-hop, pointing default, ...
by rja＠corp.home.net 11 Sep '97

11 Sep '97

On Sep 11 15:23, Randy Bush wrote: } Subject: Re: not rewriting next-hop, pointing default, ... % I also think it may be time we refuse to peer with anyone % who inhibits LSR, as it seems that validation is now mandatory. % I think we should be sending out a "LSR is mandatory" notice % to our peers. Comments? LSR is actually a significant security issue. So, while I do understand and am sympathetic to the operational debugging issues that LSR addresses, I think that requiring a peer to enable LSR more than 2 hops inside their network from the outside world is unreasonable. In a world where SSH were available in cisco routers and/or IPsec were more widely deployed, I might have different views. However, we are where we are. Regards, Ran rja(a)home.net

3 3

not rewriting next-hop, pointing default, ...
by Randy Bush 11 Sep '97

11 Sep '97

a senior engineer at a well-known provider just pointed out to us that a weenie provider at mae-east was o not rewriting next-hop o sending our routes to others o sending others' routes to us o likely pointing default at us their noc phone was answered by a modem. we suspended peering with them and wrote to their noc. we got back a snotty message. we have ceased peering with them. we installed packet filters. our traffic on the east fddi dropped noticeably. when the larger providers decline to peer with the smaller, there is a sad reason. traceroute -g is your friend. randy

2 1

NATs and addressing
by Sean M. Doran 11 Sep '97

11 Sep '97

Ok so this turns NANOG into Big-Internet... mutter... but it's more interesting than television, and people here really ought to be thinking about things like this anyway. Oh yeah, I just realized I can add an ob. ops. postscript. So there. Nyah. Michael Dillon <michael(a)priori.net> writes: > If you use NAT and renumbering technologies then you > don't give a darn what your IP address is or who gave it > to you as long as it is globally routable. No, all you care about is that two endpoints can talk to each other. You emphatically must NOT care what your IP address is, as you say, but this also means that you must not care about the scope of the address itself, nor about the scope of its routability. In any piece of the evolving Internet, a datagram may undergo transformation from one address to another. In some cases it may undergo transformation into a prefix which is expressly not globally routable (e.g., an RFC 1918 address), yet which is routable within the scope of the address's visibilty. That is, between any pair or cluster of NATs (for instance, at the edges of a network) you require routability of all addresses valid within the scope delineated by those NATs. Outside that scope, the addresses (and indeed the protocol(s) under the end-to-end protocol) may be undefined. > Routing problems involve how to design, manage and operate this internal > traffic distribution hierarchy and are essentially engineering problems, > not policy problems or social problems. I think that the desire for > portable address space is not a routing problem. PI space is already being remapped by NATs around the world; the next steps in the evolution of the Internet seek to push that remapping closer to the edge of the PI space, so that the PI addresses ultimately are visible only within the administrative scope of the user of the PI addresses. This done, the whole PI vs PA address argument will simply cease to be relevant, and the principal flaw of the post-CIDR IPv4 addressing scheme will be no more. Note that scoping address meaning within a subset of the global topology also increases the address lifetime of IPv4 itself substantially, even ignoring such things as overloading single addresses and the like. The one piece that is unfortunately missing is more an API issue than anything else, and that is that getservbyname(3) should take an FQDN as a third argument and should find its answer in the DNS rather than in /etc/services (hi Paul). Sean. P.S.: The neat thing about this is that suddenly no operator really would need to worry much about ARIN and addressing politics, since addresses would only be valid within paritcular scopes, which could be the individual provider or a collection of providers, with or without downstream customers. (I hope there is no operator who thinks that killing off silly addressing politics and the endless arguments about filtering and so forth would be a Bad Thing.)

1 0

Re: not rewriting next-hop, pointing default, ...
by Scott Huddle 11 Sep '97

11 Sep '97

This is yet another problem/opportunity, in that providers want/need to implement policies (such as no default, or only accept traffic from the following ASs, or only accept traffic for the following ASs, or consistent announcement) that are are difficult to enforce and/or automatically measure/detect with today's technology. Router/switch vendors and potential interconnect providers take note! -scott Randy Bush <randy(a)psg.com> wrote > > a senior engineer at a well-known provider just pointed out to us that > a weenie provider at mae-east was > o not rewriting next-hop > o sending our routes to others > o sending others' routes to us > o likely pointing default at us > > their noc phone was answered by a modem. we suspended peering with them and > wrote to their noc. we got back a snotty message. we have ceased peering > with them. > > we installed packet filters. our traffic on the east fddi dropped > noticeably. > > when the larger providers decline to peer with the smaller, there is a sad > reason. traceroute -g is your friend. > > randy >

2 1

Re: too many routes
by Sean M. Doran 11 Sep '97

11 Sep '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > Perhaps I misunderstood Sanjay, Sean, but I believe his concern was > that the addresses _not be the property of an upstream (ie: backbone) > provider_ to provide flexibility of connection choice. Welcome to the new Internet, which is being built. Two of the fundamental concepts that are important: -- IP addresses are not forever -- IP addresses are not end-to-end I think most people have bought into the concept of renumbering, and hopefully are realizing that the temporary nature of IP addresses could involve changes during the lifetime of a series of transactions at higher protocol levels. NAT and ALG demonstrate the second point right now, and are only crude to the extent that there are crufty protocols which were designed without any flexibility whatsoever in the two new fundamental concepts above, and a series of NAT and NAT-like gateways could conceivably already lead to changes in the IP addresses observed to be in use across segments of the path between two communicating endpoints. Combining the two concepts is very important, and this is essentially the next big step in the ongoing merge of routing equipment with address translating equipment. Ideally this will be done at a huge scale as well as at a small scale. So, to tackle the small-scale problem you refer to, the general idea is that you have multiple outward-facing addresses, one per provider, from each provider's PA address space. As providers come and go talking of Michaelangelo, you simply add or delete outward-facing addresses from the DNS advertisements your NAT generates. Your inward-facing port address of the NAT and all the behind-the-NAT addresses should never need to change, provided you do a decent job of assignment (or employ NATs internally :) ). The tricky part is the first fundamental part of the new Internet architecture, and that is changing addresses while conversations are in progress. Unfortunately IPv4/TCP both have poor facilities for supporting this without cooperation from higher-level protocols, and the current set of higher-level protocols are often wed to the idea of an end-to-end unchanging IP address. Sigh. However, NAT designers have some clever temporary hacks while a cleaner set of solutions are being looked into. These hacks generally involve tunnels, as I pointed out in a message I wrote just recently. > NAT will not solve this problem; it resides at too low a level of the > theoretical architecture, being used primarily to avoid renumbering of > internetworks. This isn't a network numbering problem, it's a routing > problem. The address at the transport layer (i.e., the IP address) is utterly and indivisibly wed to the local routing scheme at any point in any topology. Renumbering one endpoint of a connection on the fly when you have multiple outgoing addresses tho choose from (in the case of a multihomed endpoint with PA addresses from each upstream connection) directly influences how the rest of the world will route the other endpoint's traffic. This is a feature of NAT, not a side-effect. It is also a crucial feature in the new Internet. IPv4ever (well until we get proper endpoint identifiers and variable-length transport addresses so we don't have to emulate a decently scalable transport protocol using NAT). Sean.

1 0

IP b/w out of NA
by Hank Nussbacher 11 Sep '97

11 Sep '97

Is there any place I can find more info about the aggregate IP b/w out of North America? How many OC-3s to Europe and to Japan? Is there 600Mb/sec of b/w from NA to Europe? Any help and pointers appreciated. Thanks, Hank

1 0

Re: Flamed for off topic...
by Sean M. Doran 11 Sep '97

11 Sep '97

"Neil J. McRae" <neil(a)domino.org> writes: > What list is that then Michael? Shhh, Neil, you know it's not nice to undermine people's carefully crafted veneers of omniscience. Sean.

5 4

RE: too many routes
by Chris A. Icide 11 Sep '97

11 Sep '97

> L2 switches are available today that reliably receive OC-12 SONET > circuits. > > These can be disaggregated into OC3 ATM pipes that can be fed into > many routers with proven technology and reliability. Granted, the > disproportionality of the edge ckts to the backbone ckts provides > for interesting flow aggregation dynamics, but it does work. > > Your disdain for ATM does not stop its existence and use by the > larger NSPs. > Just think, there are people out there "throwing away" an oc-3 worth of bandwidth to IP over ATM overhead. Must be nice to live in a world of capitalization where one could do such a thing. We use ATM for two reasons, 1) it's still significantly cheaper than long-haul circuits of the same capacity, 2) it provides some interesting abilites that are only now beginning to show up in the mainstream IP hardware. -- additional commentary by yours truly removed by BS filter -- - Chris

1 0