- Test - lists.nanog.org

RE: why use IPv6, was: Lazy network operators
by Michel Py 19 Apr '04

19 Apr '04

> Patrick W.Gilmore wrote: > The point still stands - without real multi-homing > so I do not have to be dependent upon a single > vendor, IPv6 is simply not an option. > Quick Meta-Question: Why was was this even > considered when v6 was being engineered? Yes, although the magnitude of the problem has been way underestimated. Most people did not understand that it had to be built and validated both in the core of the protocol and in policies; collectively they promised to fix the problem "next year" and never delivered. Same as easy renumbering, WRT to multihoming IPv6 has run on vaporware for years. > Are the people who started the v6 movement > really that out-of-touch with reality? Some are, and some are not. Generally speaking, too many people had little experience with network operations, some had experience with little relevance to the real world with sheltered networks such as research. This is a generic structural issue though, same as hunger in the world and spam: no silver bullet. Retrospectively speaking, I'm not even sure less people out-of-touch with reality in the initial phases would have changed much. > Or were they arrogant enough to believe they > could limit control to a few entities and the > user base would just go along with it? To a large extent, no. Although it is true that a few people from large operators did see early on the advantages of "lock-in" addressing, the fact of the matter is that a small routing table had the favors of lots of people. 10 years ago, the big picture of the Internet was quite different than it is today and the renumbering issues were not nearly as complex as they are today. Michel.

1 0

SANOG IV, Kathmandu, Nepal, 23-30 July 2004
by Joe Abley 19 Apr '04

19 Apr '04

[forwarded on behalf of the organisers] --- SANOG IV 23-30 July, 2004 Kathmandu, Nepal SANOG IV Program and Registration Announcement South Asian Network Operators Group (SANOG) IV program and agenda are now published on http://www.sanog.org/sanog4/. The registration has also now been opened. SANOG IV is being held at the Radisson Hotel in Kathmandu, Nepal from 23-30 July, 2004. You can refer to www.sanog.org for details. Program and Agenda: SANOG IV program incorporates the following Three hands-on workshops: 23-27 July, 2004 - Open Source IP Services for ISP, by NSRC - ISP Routing Workshop, by Cisco - DNS / DNSSec Workshop, by APNIC Eight Tutorials 28-29 July, 2004 - Anti-SPAM tutorial - Juniper Routing Workshop - VOIP technology and SIP Deployment - Internet Routing Registry Tutorial - Internet Exchange Point - Exim Mail Server - PGP mini Tutorial - APNIC Internet Resource Management Four Birds-of-a-Feather : 28-20 July, 2004 - Internet Exchange Point - ISP/NSP Security - West Asia BoF - PGP Key-Signing Party Full Day Conference Program : 30 July, 2004 - Regional Updates - Routing Practices - Application Deployment - Security Additional Programs: (28-30 July, 2004) - APCAUCE tutorials and meeting - APNIC Regional policy update - APNIC and RIPE NCC hostmaster Consultation - Regional Telecom/Internet Policy Session We expect a huge turn out from the region at this SANOG meeting owing to the popularity at previous meets. We also welcome participants from West Asia, with the newly established collaboration with the RIPE NCC. With the co-hosting of APCAUCE meeting, we also expect a larger participation from the entire Asia Pacific region. We hope you would be able to make it to this meeting. The meeting is open to everyone from the operational community, and thus anyone who needed a reason to visit Kathmandu now has one. You can register for SANOG by sending in the form available at www.sanog.org/sanog4. Online registration will open in May.

2 1

RE: Microsoft XP SP2 (was Re: Lazy network operators - NOT)
by Michel Py 19 Apr '04

19 Apr '04

> Sean Donelan > Should ISPs start requiring their users to install Windows XP SP2? Most of those of us that work with m$ products on a daily basis are not too hot about installing beta code in production. A week after m$ releases it, and after carefully listening to the volume of screams coming from the street, we shall see. Michel.

1 0

RE: why use IPv6, was: Lazy network operators
by Michel Py 18 Apr '04

18 Apr '04

> william(at)elan.net wrote: > Like what? 128bit ip addresses so we don't run out 10 years from now? Maybe. Given the current stockpiling plus the extension of IPv4 to 32 bits to 48 bits (32 bits+port) that shortage that we have heard for the last 10 years would happen any time soon might not even be an issue. > Or ability to do QoS PtP over internet? Nothing to do with IPv6. > Or security that is built in and not part of additional layer? What about security that we have heard for the last 10 years will be built-in and still is not, when we use IPSEC for IPv4 daily even across NAT? > we just need to put more effort on things like > multihoming support for ipv6 Kind of ironic this is addressed to _me_ > continuing ipv4 for next 100 years is not an option in my view Not in mine either but it's not an excuse to defend a failure. I know lots of people that could have done without the mandatory ISDN upgrade; as of myself I intend not to spend millions on IPv6 upgrades to get the same brilliant success ISDN had reaching each home and each office in America. Michel.

1 0

flat ascii, please
by Paul Vixie 18 Apr '04

18 Apr '04

this gibberish... >Spamming is pervasive mainly due to the inattention or failure to enforc= e=0D >acceptable use policies by the service provider. =0D =0D ...is unreadable, and so is... <DIV>>Spamming is pervasive mainly due to the inattention or failure t= o enforce</DIV> <DIV>>acceptable use policies by the service provider.  </DI= V></DIV> <DIV> </DIV> ...this. if you're on this mailing list, please configure your user interface to output 79-column ascii card images, with no =foo or html. if or when nanog@ moves to a different format, it'll likely be jabber rather than html or richtext. -- Paul Vixie

1 0

Re: Lazy network operators - NOT
by Dr. Jeffrey Race 18 Apr '04

18 Apr '04

On Sun, 18 Apr 2004 14:01:45 -0400 (Eastern Daylight Time), Jerry Eyers wrote: >>Spamming is pervasive mainly due to the inattention or failure to enforce > >>acceptable use policies by the service provider. > >I must point out that this statement is just flat wrong. It's flat right. See documentation at <http://www.camblab.com/nugget/spam_03.pdf>

1 0

Re: Lazy network operators - NOT
by Dr. Jeffrey Race 18 Apr '04

18 Apr '04

On 18 Apr 2004 06:13:35 +0000, Paul Vixie wrote: >The new motto here is: "Blackhole 'em all and let market forces sort 'em out." Hooray. May Comcast rot in hell. They are completely irresponsible. Don't even send an auto-ignore message. Jeffrey Race

1 0

Re: Lazy network operators - NOT
by Paul Vixie 18 Apr '04

18 Apr '04

> > ... Margin pressure makes it impossible for most "broadband" service > > providers to even catalogue known-defect customer systems or process > > complaints about them. > > What is the estimated cost per subscriber of such an operation in your > opinion and where should it be to make it feasible? Off-the-shelf > automation can accomplish this for pennies per subscriber per month, > keeping the catalogs up to date and informing users automatically. let me drive deeper into what i mean by "margin pressure". it means every penny-per-month has already been allocated ("pre-spent") and if some group (like the abuse desk if there even is one) wants even one of those pennies- per-month then they will need SVP approval, which they aren't going to get. > After deployment there is a smallish support burst, but after the levels of > infection plummet and stay at levels two orders of magnitude lower than > prior situation, queues will shorten and customers will be significantly > more happy. you know that, and i know that, and we agree on that. but the SVP in question does not know that and cannot be convinced of that. this short sightedness used to be a uniquely US/Canada business phenomenon but i now see that we've exported it to europe and are working hard to get it into asia and latin america now. if you want an SVP to say yes, then to cover their own ass they have to be able to prove that revenue will increase in the medium/long term or that costs will increase in the short term. your story -- which i agree with -- is that at a slight cost increase in the short term they can reduce costs in the medium/long term. that won't fly, anywhere in the world that "broadband" has taken hold. "revenue neutral, cost increase" is many words as that SVP will be able to speak before they're standing on a street corner selling pencils (...again). > I would expect the community who uses similar blackhole criteria as you to > be fairly insignificant to the spammers revenue stream. So the stream must > be cut at the source, not just fending off the 1% somewhere. you are all going to have to do this. questions which remain are: (1) will we each maintain our own private list of broadband networks or will there be a good/fast/cheap/global aggregator of such information? and (2) what is the magnitude and slope of the volume-over-time of spam-from-"broadbanders" that will make the average edge/customer e-mail relay operator do as i've done? and (3) when or if IETF MARID ever produces results, will they be useful/relevant and if so will they cause people to relax their "broadband" filters or will other forms of unwanted traffic (that MARID doesn't police) have risen to the point where "it isn't just spam any more, sorry."?

1 0

Re: Lazy network operators
by Paul Vixie 18 Apr '04

18 Apr '04

> > preventing DDoS and IP source address forgery each also break what the > > IAB calls "the end-to-end model". > > How so? I was thinking of RFC 1958: An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. While this is given as an argument in favour of datagrams (vs. circuits) as the best transport model, any stateful NAT or firewall violates it, any router or loadbalancer flow-quota violates it, and pretty much anything that can be done to protect against DDoS violates it. I misspoke when I said that preventing IP source address forgery violates it. > > (dunno if you heard, but in spite of 128 bits of address space, the > > enterprise user community is now asking for IPv6 NAT.) > > I hadn't, pointer please? <http://www.acu.rl.ac.uk/msn2003/Talks/TimChown.pdf> comes to mind. but moreso the folks looking at deployment who absolutely don't want another IPv4-like lockin, where provider-assigned addresses mean a huge renumbering effort in order to change upstreams, and the expectation that globally routeable address blocks will not be available, or will not be cost effective, for enterprise or small-ISP use. nowadays ietf is working on what they call NAT-PT as a "transition" strategy, with a new set of heads stuffed into the same old sand, whereby the designers think that network owners are only going to use it until the ipv6 transition is complete. it ain't so. ipv4 CIDR was absolutely necessary to grow the internet, and the wayback designers who thought that 12 million class C nets could ever have been instantiated and routed were obviously not thinking about scale. but ipv4 CIDR also had the effect of making end users fear their provider- assigned IP addresses, and the real incentive for ipv4 NAT deployment wasn't a lack of ipv4 address space but rather a lack of interest in provider-assigned ("lockin") addressing. it's still quite astounding to me that when we finish deploying ipv6 we'll still have provider assigned addresses that customers are afraid to use beyond the edge of their campus, and we'll still have the age-old tension between "i could get global routing for that address block" and "i could qualify with my RIR to obtain that address block (and afford the fees)". anyway, there will absolutely be NAT in ipv6 enterprise networks, but the reason for it won't be a shortage of globally unique address space.

5 4

Monitoring dark address space?
by David A.Ulevitch 18 Apr '04

18 Apr '04

NANOG, I was wondering how many of you are running some sort of detection tool on "dark address" space on your network? In an effort to curb malicious outbound non-spoofed traffic from "owned" client machines I think one of the easiest methods we have is to look for scans in what should be dead space. The source-address spoofed traffic is easy to drop, the "legal" traffic is a bit more complex and I'm looking for non-inline methods of curbing this traffic. My questions are: 1) Are you doing this and if so, what tools are you using? Some sort of simple listening device with thresholds would probably do the trick if one machine monitored an entire /24 or some random /32's out of a /16. 2) What techniques seem to be better? Monitoring an entire /24 or picking a distributed selection of IPs from a /16? (using a /24 or /25 is much easier on the administrative end of things from where I sit...) 3) What sort of threshold metrics for considering something to be malicious have you found to be good? (ports/second, ip/second, etc) 4) Are there downsides to this (aside from false positives, which would hopefully be rare in truly dark address space). Off-list replies are fine and I'll summarize after a few days. thanks, davidu ---------------------------------------------------- David A. Ulevitch - Founder, EveryDNS.Net Washington University in St. Louis http://david.ulevitch.com -- http://everydns.net ----------------------------------------------------

4 4