November 2004 - Test - lists.nanog.org

Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI prefix [Re: who gets a /32)
by Brandon Butterworth 26 Nov '04

26 Nov '04

> An end site is defined as an end user ... Legal people make a lot from interpreting such documents so it's best not to stare too long at them. > As such, it appears to be a catch 22. If your organization has transit > and PA space, apparently, as I read the policy, that would preclude you > from qualifying as an LIR Anyone starting out will be an end site, if that meant you could only ever be an end site then there'd be nothing but end sites. Skip to the not an end site section and meet those requirements instead. > I think we definitely need > to review v6 allocation policy and improve its consistency and ability > to meet the needs of the community if v6 is to make real progress towards > broad adoption. I think working on the technical deficiences others have outlined would help more. brandon

2 1

RE: Best way to get of Bogon list?
by Majid Farid 26 Nov '04

26 Nov '04

Jon, I will lend you the IP list I have so far. IBM is top of the list for sure :) The bogon entry was removed in Aug for 72.0.0.0/8 yet people haven't revisited to update the filters. Changes in version 2.5 (02 AUG 2004) 71/8 and 72/8 allocated to ARIN (AUG 2004). Removed from the bogon lists. Thanks for all the response people. -- Majid. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jon Lewis Sent: Thursday, November 25, 2004 10:30 PM To: nanog(a)merit.edu Subject: Re: Best way to get of Bogon list? On Fri, 26 Nov 2004, Suresh Ramasubramanian wrote: > I hate to say it, but that is the only way. > > You aren't dealing with a single bogon blocking list, you're dealing with a > whole lot of providers who are way behind the times and you just have to go on > contacting them one at a time. Its not even just providers. If it were, it'd be relatively easy to just find and call each NOC. You're likely to have bogon issues with few large providers. It's mostly smaller providers and end user networks...some of which are quite large or high profile. Do what I did and give people a way to test connectivity from both affected and unaffected space and setup a 'hall of shame' page listing the IPs/networks that are behind broken filters. If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

2 1

Re: who gets a /32 [Re: IPV6 renumbering painless?]
by Paul Vixie 25 Nov '04

25 Nov '04

> > you are drastically misunderstanding my hopes, my goals, and my role. > > Please explain them then. briefly, because i consider myself off-topic and sue probably does also. the problem statement answered by the ipngwg was wrong. they thought they were supposed to "solve the shortage of address space problem", but that wasn't the most serious problem then (and is not now). the right problem statement would be to "solve the shortage of PORTABLE address space problem". note the insertion of the word "portable" before "address space". the big problem in 1992 and the big problem now is that a wal-mart corporate desktop will either have an ambigious address (behind a NAT), or a hard-to-renumber isp-price-locked address (provider assigned), or a takes-a-slot-in-the-global routing-table address (provider independent). three strikes and you're out! none of those three things is acceptable, not even as a compromise. i have not looked in on the multi6 wg this year. my bad. perhaps you've come up with a fourth alternative, or a way of softening one of the three existing alternatives to the point where its benefits outweigh its costs. but everything i've actually looked at either resolves the cost/benefit in favour of some minority of which neither isc nor wal-mart is a part, or which would have been equally applicable to ipv4 such that all we needed was the gimmick itself, not 128-bit addresses, if only we'd been willing to pay this much pain back before ipngwg's work was complete. ipng needed rapid renumbering, including renumbering tcp endpoints realtime and including multihoming where you can add and delete PA interface addresses whe way commercial RAID vendors add and delete disk drives. the people in putative "charge" of this said either (a) they didn't agree, (b) they didn't understand, or (c) they didn't have time to add more requirements. now it's 2004 and lo and behold, the problems of 1992 are still with us, but now we have better terminology to describe them. you can be locked into a provider's pricing and service quality; or you can run NAT; or you can find a way to get your own slot in the global routing table. we have the same shortage of portable addresses now that we had in 1992, even though we have increased the overall supply of address space by a factor of 2**96. if multi6 offers a fourth alternative, it would probably also have worked with ipv4, in which case why did we spend years working on 128-bit addressing? i strongly believe that the isp community who pays ARIN's bills will decide that the best way to grow the industry is to let folks like ford and wal-mart have their own /32's, and that there will be a spectrum of r e n u m b e r i n g d i f f i c u l t y easy--------------------------moderate------------------------impossible with PA+NAT on the left (home dsl, cable); wal-mart and ford on the right with endsystem PI, and folks like isc in the middle, doing some kind of multi6 thing, whose costs while high will be lower than the renumbering penalty. since the arin BoT has no policy formation role, i'm expecting to be able to voice an opinion that weighs exactly as much as everybody else's, and to vote ultimately on whatever the policy formation function comes up with. so there. those are my views. aren't you glad you asked? > It's wrong if these issues that have global impact are decided regionally. yes. i understand that the acid rain people, the ozone layer people, the ice cap people, the whale people, and the ocean oxygen level people, all have that same complaint. human nature on a grand scale isn't always pretty.

5 5

Best way to get of Bogon list?
by Majid Farid 25 Nov '04

25 Nov '04

Good Day, I have question for the list what would be best/fastest way to get off bogon list. Arin allocated us a /19 2 months ago (72.1.192.0/19) We find that a lot of providers aren't accepting the BGP advertisements for that block because the block 72.0.0.0/8 was on bogon list. Thanks. Regards, Majid Farid ISP Specialist Telecom Ottawa Limited. majidfarid(a)telecomottawa.com [P] 613.225.4631 ext 7220 [F] 613.225.0636

2 1

RE: ULA and RIR cost-recovery
by Owen DeLong 24 Nov '04

24 Nov '04

>> Well... I'm saying, at least, that I'd rather change the RIR policy and >> work >> in an open and consistent manner based on input from the operational >> community and other stakeholders than have the IETF start setting >> allocation >> policy for PI space while pretending that isn't what is happening. If >> the IETF wants to set such a policy for UGA, then, fine, let's do that. >> However, >> pretending that it's not globally routable and trying to use that as an >> excuse to slide this into position is a fallacy that ignores the real >> world >> implications. > > ULAs are clearly routable over whatever scope people decide to. This was > also true of the SiteLocal prefix that ULAs are replacing. The only > difference is that ULAs have explicit text to avoid routing ambiguity > where SL didn't. I argued against deprecating SL partly on the basis that > it had the potential for ambiguity which would be a disincentive for > grey-market PI use. I understand and agree with your point about them > being a potential problem, but that potential is easily mitigated by > providing an economically viable alternative. > I was also opposed to deprecating SL on the same basis. However, just because SL was deprecated doesn't make me think ULA is a good idea. If we're going to have PI space, we should have PI space. Dividing it up into multiple classes based on how much you paid to register it doesn't make sense to me. > None of the organizations that are getting long IPv4 allocations will > qualify for an IPv6 prefix. There is an implicit concession that it is too > late to close the barn door for IPv4, but for IPv6 it is currently locked > tight by those that want to maintain control. > I don't believe that to be true. I think that a reasonable allocation policy for PI space in v6 would move forward in ARIN. I think that the recent adoption of 2002-3 and 2003-15 is evidence that the makeup and participation in ARIN has shifted. I also think that you underestimate the number of people who believe that PI space should be the norm, not the exception, and, that failure of v6 WG to address this in a meaningful way is not a good thing for v6 future. > Multi-homing is only one reason for PI space, and people get so hung up on > that one that they forget that the simple ability to change providers > without massive effort is just as important. > Changing providers without massive effort can be accomplished through a number of other methods. Multihoming is the more generic case. > Failure is too strong a term, but it is true that work is not complete. > The issue is many assumptions have been made at all layers of the system > about the alignment of all those characteristics, so just ripping them > out doesn't really solve anything more than the routing problem. Even if > the multi6 follow-on groups come up with a technical approach that splits > the functions, all the rest of the infrastructure will need to adapt and > that will take much longer than rolling out IPv6. > I do not believe that the v6 protocol will ever actually address those issues. Most of the necessary foundation for addressing them has been removed (A6, DNAME, mandatory autoconf). Agreed on the latter half, that's why I think that IPv6 should have addressed these early on and built those capabilities into the migration process. Adding them as hacks later has most of the disadvantages and reasons that they haven't been added to v4. That is why I chose the term failure. > Making a change that intentionally breaks fundamental assumptions will > meet much greater deployment resistance than something that intentionally > minimized such changes. Call the intentional minimization a failure if you > must, but from my perspective the only real failure will be to let the > Internet collapse into something less capable of delivering end user > services than X.25 was. > Here, we probably end up agreeing to disagree. I think that we could have built v6 to break the fundamental assumptions in such a way that the impact of those breaks was minimized. Yes, there would be deployment resistance, but, I don't think significantly more than exists for current v6. Owen

1 0

RE: ULA and RIR cost-recovery
by Owen DeLong 24 Nov '04

24 Nov '04

--On Wednesday, November 24, 2004 11:40 -0800 Tony Hain <alh-ietf(a)tndh.net> wrote: > Owen DeLong wrote: >> > I have never been a fan of the registered ULAs, and have argued against >> > the IETF's attempts to state specific monetary values or lifetime >> > practice as a directive to the RIRs; but I am equally bothered by the >> > thought that the operator community would feel a need to fight against >> > something that really doesn't impact them. >> >> Perhaps it is because in the perception of the operator community, we do >> not believe it will not impact us. The reality is that once registered >> ULAs >> become available, the next and obvious step will be enterprises that >> receive >> them demanding that their providers route them. Economic pressure will >> override IETF ideal, and, operator impact is the obvious result. > > This argument is basically saying that the RIR membership knows it is > forcing allocation policies that are counter to the market demand. The > only way ULAs could be considered for grey market PI use is due to lack > of any alternative mechanism to meet the real customer requirement for > independence. > Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. > The current problem is that the RIR membership has self-selected to a > state where they set policies that ensure the end customer has no > alternative except to be locked into their provider's address space. > Everyone acknowledges that the demand for PI space is real while > simultaneously refusing to seriously deal with it (and the > re-architecting of fundamental assumptions about the Internet effort of > multi6, while serious, is not a short term solution). > This is absolutely not true. RIPE allocates /24s and smaller. I don't know APNICs current MAU. ARIN will allocate /22s and will probably consider smaller allocations either at the next meeting or the one after that. > My to-do list for the next couple of weeks has an item to ask for a BoF at > the next IETF on an interim moderately aggregatible PI approach. I cc'd > the Internet ADs since this is as good a time as any to start the > process. I have a proposal on the table, but I care more about a real > solution than I do about that specific approach. At the same time I > continue to get comments like: 'Your geographic addressing proposal > (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty > much ideal, really)', so it probably makes a good starting point for > discussion. > Agreed. I'd like to see a real solution that allows any organization that wants to multihome to get PI space or have us solve the underlying problems so that address portability becomes irrelevant (better, I think, in the long term). As I see it, IP Addresses are currently used for the following purposes: Destination Endpoint Identifier (resolvable by requiring a solid directory service) Source Endpoint Identifier (mostly doesn't matter when this changes) Source Endpoint Authentication (this is bad and we should be using something better that actually identifies the host (or better yet in most cases, user) in a meaningful way) Host authorization (Same issue(s) as previous statement) Portion of Service authorizatoin decisions (again, same issues as previous two) In the early days of the ipng working group, there was hope that v6 would solve these issues. Sadly, after rejecting TUBA because it didn't solve these things, v6 has devolved into a similar failure. Owen

2 1

RADB question
by Paul Ryan 24 Nov '04

24 Nov '04

Just a quick question regarding RADB - how are you guys dealing with abuse complaints sent to the "radb-notify" or "radb-maint" e-mail addresses. I have some ideas but wanted to get a concensus from the commmunity ... Thoughts anyone ????? Regards, Paul

2 1

Looking for AT&T abuse_rbl contact
by D. Campbell MacInnes 24 Nov '04

24 Nov '04

Can anyone who is or has a good contact at the abuse_rbl desk at att.net please contact me offlist? (This is regarding their email blacklists). Abuse_rbl(a)att.net, abuse_rbl(a)abuse-att.net, and abuse(a)att.net are all known and have proved ineffective. Thank you in advance. --Campbell

1 0

Need help on process netflow sampling data
by Joe Shen 24 Nov '04

24 Nov '04

Hi, I'm trying to analize our egree router traffic by using flow-tools and CUFlow. There are three edge routers: two Juniper M160 and one Cisco GSR. All of them are set up to sample outgoing interfaces. With Juniper M160, I set up forwarding-option as: ============================= forwarding-options { sampling { input { family inet { rate 500; } } output { cflowd 10.101.172.20 { port 2055; version 5; } } } } so-6/0/0 { description "Outgoing 2.5G POS"; unit 0 { family inet { filter { input netflow-sj; output netflow-sj; } address *.*.*.110/30; } } } ==================== With Cisco GSR I configed: ====================== ip flow-export source Loopback0 ip flow-export version 5 origin-as ip flow-export destination 10.101.172.20 2055 ip flow-sampling-mode packet-interval 500 ip flow-aggregation cache as interface GigabitEthernet5/0 description To_Other-AS ip address 10.96.117.250 255.255.255.252 no ip directed-broadcast ip route-cache flow sampled ==================== To my understanding, they should work the same way as : sampling every 500 packets in both in & out directions. I set up CUFlow.cf to work with Sampling rate 500, but when I try to graph data with its cgi scripts, i found CUFlow show a wrong bit rate with GSR ( 10Gbps for two GE ), while there is much differnt in application analysis. Is my understanding of "sampled netflow" correct? Is there anybody could do some help with netflow data processing ? each word will be highly appreciated Regards Joe __________________________________________________ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com

1 0

Re: Frame-Relay reliability (was Re: who gets a /32)
by Christopher L. Morrow 23 Nov '04

23 Nov '04

On Tue, 23 Nov 2004, Sean Donelan wrote: > On Mon, 22 Nov 2004, Christopher L. Morrow wrote: > > > Yeah right. That's why Worldcom's frame-relay network was "unusable" for > > > about 10 days and took out part of the Chicago Board of Trade elecronic > > > trading system. > > > > and to be fair it might have actually been MCI's network at that time, > > with name changes though I'm losing track... not EVERYTHING is worldcom's > > fault :) > It was 100% Worldcom. The old MCI people at the time repeatedly pointed > out that the MCI frame-relay network (also owned by Worldcom at the time) > wasn't effected. a kind outside poster set me straight about the Frame outage... apparently everything IS worldcom's fault! :) So, sorry for the confusion.

1 0