AS7018 (ATT) bgp contact needed
Could someone from AS7018 (ATT) please contact me about a route you are originating that is hijacking/blackholing traffic? The route is: 66.235.248.0/22 - Kevin
Re: request for help w/ ATT and terminology
Mike Donahue wrote: Hi. I'm by no means an ip/networking expert, and we're having some difficulty communicating with the boffins at ATT. Any input/advice/translation would be appreciated. We own our own class C netblock. Our previous provider, Sprint, had no problem adding it to their network/advertising it (that circuit is now disconnected). We've started using an ATT colo facility, and we're having a lot of trouble trying to get ATT to do the same thing there that Sprint was able to do for us. ATT is refusing to advertise our netblock/path it to our cabinet unless we have an AS number. ARIN has refused to give us one on the grounds (rightly so) that we're not multi-homed. muli-homing is one way to justify an ASN, unique routing policy is the other. Your directly assigned /24 could be a reason to have a unique routing policy, especially if your upstreams are unwilling to originate it from their ASN(s). You may want to re-apply for an ASN and explain that you will be announcing your directly assigned block in section 14 of the template. - Kevin
Re: v6 subnet size for DSL leased line customers
Christopher Morrow wrote: RA/Autoconf won't work at all for some folks with deployed server infra, all they want is a method to get a static addr on a box and route properly. Perhaps RA gets them the 'route properly' part easily enough but I can imagine places where that is even turned off. I think it would be great to be able to do hybrids with RA for other situations where a shotgun approach is ok but I do not think we will want to use that in server environments. Hopefully vrrpv6 will work with RA turned completely off. - Kevin
Re: v6 subnet size for DSL leased line customers
Iljitsch van Beijnum wrote: On 24 dec 2007, at 20:00, Kevin Loch wrote: RA/Autoconf won't work at all for some folks with deployed server infra, That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers. Hopefully vrrpv6 will work with RA turned completely off. With router advertisements present you don't need VRRP because you have dead neighbor detection. And that helps the hosts on the same l2 segment that need different gateways how? Or hosts with access to multiple l2 segments with different gateways? RA is a shotgun. All hosts on a segment get the same gateway. I have no idea what a host on multiple segments with different gateways would do. Hosting environments can get complex thanks to customer requirements and baggage from previous migrations. Load balancer and VPN configurations are common culprits but there are also cases where servers need different gateways for routing policy reasons. All of this is easily accommodated with static gateways and the redundancy provided by vrrpv4. Please don't take that away from us. Migration to v6 will be difficult enough without subtracting functionality from our existing tools. Other than that I look forward to seeing what wonderful things we can do with RA to simplify things in cases where shotgun == ok. - Kevin
Re: Route table growth and hardware limits...talk to the filter
Stephen Sprunk wrote: Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not worthy of a slot in the DFZ by denying them PI space. Not true, there is an ARIN policy that allows you to get a /24 from one of your providers even if you only need 1 IP address: NPRM 4.2.3.6 This policy allows a downstream customer's multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements. http://www.arin.net/policy/nrpm.html - Kevin
Re: TCP congestion
Iljitsch van Beijnum wrote: How exactly are you going to get out-of-order packets over a single link? There is a once popular router that has been known to do that in some configurations due to multiple paths within the device. - Kevin
Re: that 4byte ASN you were considering...
Randy Bush wrote: - 'Canonical representation of 4-byte AS numbers ' draft-michaelson-4byte-as-representation-01.txt as an Informational RFC and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing? Using '.' as a delimiter will be somewhat annoying when used in regular expressions and likely to induce errors. Would '-' be a better choice? - Kevin
Re: shim6 @ NANOG (forwarded note from John Payne)
Kevin Day wrote: If you include Web hosting company in your definition of ISP, that's not true. Unless you're providing connectivity to 200 or more networks, you can't get a /32. If all of your use is internal(fully managed hosting) or aren't selling leased lines or anything, you are not considered an LIR by the current IPv6 policies. Leased lines are not required. You can assign a /48 to any separate organization you provide connectivity to even if they are colocated. A business model where you don't assign /48's to any customers does seem to preclude being an LIR. Web hosting companies that do assign /48's to some customers would qualify. Even the proposed ARIN 2006-4 assignment policy for end sites doesn't help a lot of small to mid sized hosting companies. For that, to just get a /48, you need to already have a /19 or larger, and be using 80% of that. That's 6553 IPs being utilized. If you're running a managed hosting company (name based vhosts) and deploying 1 IP per web server, you're pretty huge before you've hit 6553 devices. Even assuming 20% of that is wasted, you're still talking about more than 5000 servers. 40 1U servers per rack, you need to have 125 racks of packed to the gills servers before you'd qualify for PI space. That excludes every definition I have of small-to-medium in the hosting arena. The latest revision of 2005-1 is also on the table. It would allow for a /48 assignment for any organization that qualifies for IPv4 space, (even /22). Name based virtual hosting is not required either. You don't get PI space, and Shim6 is looking like your only alternative for multihoming. We are only limited by our own imaginations and and by what actually works. This is a hard problem to solve and the solution doesn't have to come from the IETF. - Kevihn
Re: do bogon filters still help?
Florian Weimer wrote: * Pim van Pelt: Hi, here's a member of 'the folks at bit.nl'. Just a quick note to say that we have been sourcing IPv4 packets from 192.88.99.1 at a rate of 2.000 to 10.000 packets per second since early 2003, so I'm guessing we have sent some 750.000 billion packets by now. And this is just so wrong. You should use an address you own as a source address. Otherwise, packets tend to get dropped by filters. Wouldn't you expect to see packets return from the same address you send them to? ICMP and stateful firewalls work much better that way. Our 6to4 relay also soucres packets from 192.88.99.1, it seems to work best that way. Don't filter 192.88.99.1 in any direction unless you want to break 6to4. If you want to limit your exposure you could allow only proto 41 and icmp packets and not break it. If you have native IPv6 on your network you could run a local 6to4 relay for your customers and filter 192.88.99.0/24 to/from your peers. - Kevin
Re: Deploying IPv6 in a datacenter (Was: Awful quiet?)
Kevin Day wrote: 9) Once we started publishing records for a few sites, we started getting complaints from some users that they couldn't reach the sites. It is possible that a broken 6to4 relay somewhere was causing problems. Running your own local 6to4 relay (rfc3068) will improve performance and reduce the chances of going through a broken one. FWIW, I have been running some records for almost a year on some revenue generating sites without any reachability complaints or drop in traffic. I do run a local 6to4 relay though. I know this is still a hot topic and several proposals are being passed around to resolve some of these issues, but it seems like I *lose* functionality with IPv6 that I have with IPv4, mostly due to the don't deaggregate your allocation mantra, and how far the bar was raised to get PI space. It sounds like you are an existing ISP in the ARIN reigon. If so then you qualify for a /32 allocation. Let us know if you have any problems getting one. For non-ISP's, the policy is still being worked out. See the ARIN ppml list for discussion. As for deaggregation, it is not recommended because some filter (/48's) and some don't which results in sub-optimal paths, but it can be done depending on what your peers will accept. - Kevin
Re: Deploying IPv6 in a datacenter (Was: Awful quiet?)
Kevin Day wrote: We wouldn't have met the proposed 2005-1 requirements for a /44 (we don't come close to 100,000 devices), and lose functionality if we're required to advertise it through a single aggregated address. The high requirements of the current 2005-1 were so thoroughly rejected at the last ARIN meeting that it will probably return closer to the original 2005-1 at the next meeting. Something like if you have an IPv4 assignment/allocation from ARIN you can get an end site assignement. There was also a suggestion to eliminate the single aggregate announcement requirement from both end-site and ISP sections. - Kevin
Re: a record?
Jeroen Massar wrote: Enjoy scanning, even I and I guess the rest of this list will be long time retired and sipping pina coladas and other good stuff (hot chocolate milk with whipcream and baileys anyone? :) in hawaii or some other heavenly place the day that the hardware and pipes are available to scan a single /64 efficiently. There is no need to scan an entire /64. Lists of known hosts can be scanned for sparse addresses. Lists of known/likely subnets can be scanned for common human numbering patterns (think servers). Chances are good that every IPv6 node that talks to untrusted nodes will end up on one or more 31337 host lists. - Kevin
Re: classful routes redux
Bill Woodcock wrote: On Wed, 2 Nov 2005, Fred Baker wrote: While I think /32, /48, /56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again. It's not quite the same as classful addressing in IPv4. There is no definition of prefix length by address range. At the RIR-ISP level It is actually CIDR with a minimum allocation size that intentionally covers 95+% of applicants. Shorter allocations of various sizes are made based on justification. An extra 1-3 bits is even reserved around each allocation for future growth. The same thing applies to End sites. You can get a /47 or shorter with justification. It's might be rare but it is possible. I think the goal was to avoid making multiple non-aggregatable allocations as is done with IPv4. An alternative would be to allocate based on initial need but still reserve a much larger prefix for future growth. This would avoid the illusion of fixed sizes and carry less risk of unused space. Is that worth the extra RIR effort? Maybe, maybe not. - Kevin
Re: IPv6 news
Paul Jakma wrote: And 6to4 obviously won't fly for long after the 4 tank runs dry. Hopefully it won't need to at that point as it is only intended as a transitional step. I like the simplicity of 6to4 and the way it preserves end-to-end addresses. If only there was a way to adapt it's stateless automatic tunneling to solve the IPv6 multihoming/PI problem. I took a quick hack at it and the result is interesting though far from perfect: http://kl.net/ipv6/pi-in-6.txt - Kevin
Re: IPv6 daydreams
Mark Smith wrote: We didn't get 48 bits because we needed them (although convenience is a need, if it wasn't we'd still be hand winding our car engines to start them ). We got them because it made doing other things much easier, such as (near) guarantees of world wide unique NIC addresses, allowing plug-and-play, at least a decade before the term was invented. This is not a scientific opinion but I think you can pick a random host id from 32 bit space on most lans without having to retry very often. - Kevin
Re: IPv6 and BGP
Mike Hyde wrote: On the subject of ipv6, is there currently any way to multi-home with IPv6 yet? There has always been a way to multihome in IPv6. Announce a prefix to two or more providers. As with IPv4, YMMV. There is a proposal to allow direct IPv6 end site assignments that will be considered at the upcoming ARIN meeting: http://www.arin.net/policy/proposals/2005_1.html Note that it has been revised since the previous ARIN meeting. The size for qualifying is still being debated and I hope that anyone interested in this topic will make their views known on the ARIN ppml list or at the meeting. - Kevin
Re: IPv6 news
Randy Bush wrote: and don't you just love the suggestions of natting v6? No, but I would like to see consumer routers support rfc3068 (automatic 6to4 tunneling) by default when there is no native IPv6 access service. If we could convince manufacturers that rfc3068 is NAT for ipv6 they'll probably jump right on it :) - Kevin
Re: Level 3's side of the story
Richard A Steenbergen wrote: Certainly these are high-margin but low-bandwidth customers, maybe with enough complaints Cogent will be willing to stick them on a smaller seperate ASN which is willing to buy transit. Does anyone have reachability data for c-root during this episode? I wonder if they made separate arrangements for that or are planning to make arrangements for phase 2. - Kevin
Re: IPv6 Address Planning
Roy Badami wrote: And on that vein perhaps it's prudent for people using network prefixes longer than /64 to take care to ensure that the bit positions in the IPv6 address that should correspond to the u and g bits in the modified EUI-64 interface ID (according to RFC 3513) are both set to Is there any known use for those bits? - Kevin
Re: OMB: IPv6 by June 2008
Todd Underwood wrote: where is the service that is available only on IPv6? i can't seem to find it. A better question would be What services does the competition offer via IPv6? If the answer is none then how long will that situation last? What point along the adoption curve do you want to be? manually configured tunnels forver! There are fully native IPv6 networks here in the US, large and small. Most exchange points support native IPv6. I'm sure most netowrk operators on this list could connect natively with minimal effort. Tunnels serve a useful purpose when dealing with networks you don't control, just like VPN's. Most of the operational problems in IPv6 today involve intentionally broken routing policies, not tunnels. - Kevin
Re: Problems with NS*.worldnic.com
Suresh Ramasubramanian wrote: I'd say fix the resolver to not try resolve v6 where there exists no v6 connectivity I'd say fix the broken v6 connectivity. - Kevin
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: But to consider a /40 minimum allocation size, you'd be saying that you thought a table containing O(1e12) discrete destinations Except that we are talking about allocations out of 2001::/16 which yeilds a about 1e7 prefixes, not subtracting the huge chunks taken by /32 allocations. The idea with using a /16 for initial allocations is that we don't screw up the entire /0 before we know what we are doing. In the scope of a /16, I think /32 and /40 allocations are sized appropriately. The real question is why exchange points and root servers are allocated /48's. It would make sense to use a different prefix length to reduce the temptation for other /48's to pollute the table.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: i think all oldtimers are skewed. growth in number of enterprises will be of the small kind where renumbering isn't so painful. exceptions where there is enough size to make renumbering painful won't overflow the routing table the way the ipv4 swamp threatened to do back in the days of 64MB RP cards. Here is a possible multi level solution for end sites and non /32 qualifiers: - Sites that dual-home use alternate path encoding with PA /48's - Sites that tirpple home do the same but get PA /40's to make up for the loss of site subnet bits in tripple mode. - Sites that multihome 4 ways or more get a PI /40 - Large sites with more than X devices get a PI /40 if at least (dual|tripple)homed to avoid massive renumbering/provider lock-in. This would set the bar high enough to limit routing table growth while allocating PI space to those who need it the most. -- Kevin Loch
Re: Stupid Ipv6 question...
Leo Bicknell wrote: With the exception of auto-configuration, I have yet to see any IPv6 gear that cares about prefix length. Configuring a /1 to a /128 seems to work just fine. If anyone knows of gear imposing narrower limits on what can be configured I'd be facinated to know about them. 64 bit prefixes are the mattress tags of IPv6 interfaces. -- Kevin Loch
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Stephen Sprunk wrote: According to multi6, you will get PA space from each of your ISPs and overlay a prefix from each on every subnet. I'll save y'all another rant on the workability of that model... FWIW, I have submitted an I-D for a method that does not require overlay prefixes, extra routing table entries or globally unique AS's: http://www.ietf.org/internet-drafts/draft-loch-multi6-alternate-path-encoding-01.txt Note: bit order notation is apparently reversed from I-D standards and will be fixed in the -02 version. Any comments or suggestions would be appreciated (off-list). -- Kevin Loch
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: either of these limitations... o A maximum of two alternate networks (for a total of three networks) can be encoded on a single unicast address. o Renumbering when changing networks is not eliminated and is actually made worse because changing any of the networks requires renumbering. Worse yet, even changing the routing preference between the the networks requires renumbering. ...is fatal to this approach. Fatal in that it does not address the needs of major multihomers like ISC. Certainly not fatal to the millions of small to mid sized networks that could benefit from multihoming to two or three providers. For those networks this method would be at least as good and easy as it is today with IPv4, plus the benefits of not polluting the global routing table, consuming unique AS numbers or requiring convoluted application or protocol tricks. In fact anyone could do simple multihoming. Just get a second connection and set your interface addresses accdordingly. Networks that need to multihome to more than three networks would likely qualify for IPv6 PI space anyway (as ISC did and still does). There is a range of large purely end site networks that would not qualify for PI space and would need more multihoming support than this method provides. In those cases it would be necessary to use more advanced (read: complicated) technology. As we have seen, the advanced methods come with their share of limitations too. I don't think we are going to find a one size fits all solution to IPv6 multihoming. As for renumbering, we all know that will be solved by some form of address translation (like it or not). -- Kevin Loch
Re: AOL web troubles.. New AOL speedup seems to be a slowdown
Nicole wrote: In the past few days our AOL users have been reporting serious problems Several Brickshelf users have complained about the new blurry images problem using AOL. I have not heard any reports of broken images or upload problems yet. Kevin Loch I
Re: VeriSign Capitulates
... in an attempt to assert a dubious right to regulate non-registry services. This explains everything. They don't believe the stability of com and net are in any way related to their registry duties. That quote alone should be sufficient to deny them custody of com and net.
Re: Verisign Responds
Daniel Karrenberg wrote: What else does the IETF need to do here? Recognize the legacy status of certain zones and establish strict criteria for making configuration changes to them. This would be in addition to any guidance for all zones with delegations. KL
Are Wildcards another Y2K?
One thing that Y2K taught us was that programmers do some really stupid things with hard coded this should never occur naturally values. The year '99' was used to trigger all kinds of interesting things like erasing backup tapes, destroying inventory and worse. It is not implausible that someone has hard coded an asdfjlkl.com type domain somewhere important. The effects of such errors are not always immediately visible as they were with the spam filters. The problem is that the COM zone is part of the largest legacy software system the world has ever seen. Configuration changes to it affect virtually every application that uses DNS. How many lines of code is that? Hundreds of millions? Billions? Any configuration change to the legacy zones should be made only after careful consideration, with a strong prejudice to do nothing. Because V$ is downplaying the seriousness of this problem, many (most) won't audit their systems to see how it might be affected by this. I hope V$ is prepared to take responsibility for whatever breaks. I hope DOD/FBI/DHS aren't expecting a stable COM zone. I guess we'll find out the next time a terrorist buys a plane ticket or 1000 lbs of fertilizer using a bogus email address. KL
Re: What *are* they smoking?
- Original Message - From: Patrick W. Gilmore [EMAIL PROTECTED] Date: Monday, September 15, 2003 7:34 pm Subject: Re: What *are* they smoking? No, it accepts if the from domain exists - but only if it *REALLY* exists. Anyone want to guess what happens to all those from addresses it captures?
Re: RPC errors and latest worm
- Original Message - From: Scott Fendley [EMAIL PROTECTED] Date: Monday, August 11, 2003 7:49 pm Subject: Re: RPC errors and latest worm * Close port 135/tcp (and if possible 135-139, 445 and 593) . Is there a Windows service that uses port 136, or was it included because it's easier to type than 135, 137-139? KL
Re: State Super-DMCA Too True
- Original Message - From: William Allen Simpson [EMAIL PROTECTED] Date: Sunday, March 30, 2003 9:39 am Subject: Re: State Super-DMCA Too True (b) Conceal the existence or place of origin or destination of any telecommunications service. [no encryption, no steganography, no remailers, no NAT, no tunnels] [no Kerberos, no SSH, no IPSec, no SMTPTLS] place of origin or destination could mean street address, not IP address or email address. In the context of the rest of the law, it is likely they meant physical location. Especially since it refers to service and not just telecommunications. KL
Re: State Super-DMCA Too True
- Original Message - From: Jack Bates [EMAIL PROTECTED] Date: Sunday, March 30, 2003 0:22 am Subject: Re: State Super-DMCA Too True (Some DSL/cable companies try to charge per machine, and record the machine address of the devices connected.) And to use NAT to circumvent this should be illegal. It is theft of service. The ISP has the right to setup a business model and sell as it wishes. Technology has allowed ways to bypass or steal extra service. This law now protects the ISP. There will be some ISPs that continue to allow and support NAT. If you can tell the difference between NAT and non-NAT traffic you don't need this law. If you can't, the law is completely unenforcable. The same goes for VPN's. So what's the point other than to discourage good business models? KL
Re: 69/8...this sucks
Stephen J. Wilcox wrote: I repeat my suggestion that a number of DNS root-servers or gtld-servers be renumbered into 69/8 space. If the DNS breaks for these neglected networks, I suspect they will quickly get enough clue to fix their ACLs. Nice idea in principal (from a purist point of view) but its not practical, I hope your not serious..! How about making *temporary* allocations to content providers who vounteer to move some/all content to net-69? Use an initial page on your regular net to alert users to contact their ISP and have them fix their bogon filter if the below link doesn't work. If done right, it might speed up the clean-up. The only problem would be finding volunteers with sufficient traffic who are willing to break their site. I could do this on some of my sites. They're not Ebay, but they do get hit from about 40K unique IP's per day, with a very global distribution. If ARIN is interested, contact me privately. KL
Re: bulk email
Lionel wrote: On Mon, 22 Apr 2002 11:53:58 +0100, James Cronin [EMAIL PROTECTED] wrote: [opt-in bulk email] Has anyone ever actually come across such a contract in real life or are they just urban myths? Urban myth. If you make damn sure that you clearly mark your bulk mail with the website/organisation at which your user subscibed, you record the *way* they subscribed[0], you should be fine. It's also vitally important that you respond promptly to email that arrives at your domain's 'abuse@' address. [0] Eg: IP address time stamp from when they hit the 'subscribe me' button on a web form, copy of the signed paper form they sent in, etc. AND send a verification email with a clearly marked confirmation url that they must hit to actually be subscribed. Without successful confirmation, no further email should be sent. KL
