July 2005 - Test - lists.nanog.org

EP.NET 198.32.0.0/16 assignments and bogon filters
by Joe Abley 11 Jul '05

11 Jul '05

Since I've just run into the second of these in as many weeks, I thought this was perhaps worth a mail to the list. EP.NET assign netblocks from 198.32/16 to various Internet infrastructure providers, including exchange points and prominent (e.g. ccTLD) nameservers. And maybe other things, for all I know, ask Bill, but definitely not just for exchange points. I realise that answers from the usual whois servers in response to questions within this netblock may not make this obvious. Many ISPs have import policies which reject exchange point blocks from external peers, for which there are many fine and logical arguments. Several of those ISPs reject "198.32.0.0/16 le 24" as part of that policy, however, believing that 198.32.0.0/16 is only used for exchange point assignments. 198.32.0.0/16 is used for other things, too. Not just exchange points. People who need to block exchange point blocks in their import policy would do well to enumerate the specific subnets of 198.32.0.0/16 which are used at exchange points they connect to, rather than denying all routes covered by the /16. Examples of nameservers that fall victim to over-zealous filtering of 198.32/16 assignments are as follows (these are just those present as glue in the root zone): [jabley@halibut]% dig @192.5.5.241 . axfr | grep 198.32 NS1.DNS.AQ. 172800 IN A 198.32.71.12 MZIZI.KENIC.OR.KE. 172800 IN A 198.32.67.9 FLAG.EP.NET. 172800 IN A 198.32.4.13 L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12 NS1.2DAY.CO.NZ. 172800 IN A 198.32.66.12 [jabley@halibut]% If you can't traceroute to those nameservers, it would be great if you could patch up your import filters so that they become reachable to your users and customers. [ISC doesn't use any EP.NET netblocks, but we have friends who do.]

2 1

Re: OMB: IPv6 by June 2008
by Alexei Roudnev 10 Jul '05

10 Jul '05

LC can hold only 20,000 ACTIVE routes., and ask central system if it needs more., How many ACTIVE routes are used in any CORE router? 0.1% or CORE? 2% of CORE? Again, today it is not technical issue anymore. ----- Original Message ----- From: Syed Junaid Farooqi To: Christopher L. Morrow Cc: Alexei Roudnev ; NANOG ; Brad Knowles Sent: Saturday, July 09, 2005 1:02 AM Subject: Re: OMB: IPv6 by June 2008 Christopher L. Morrow wrote: randy already asked for a kibosh on the lunacy here... I agree, it'd be nice, but... On Fri, 8 Jul 2005, Alexei Roudnev wrote: You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms. and routing vendor's haven't already done some optomizing you think? They sure have, let me explain a bit - Optimization here can be is Route table optimization, forwarding table optimization and the actual forwarding lookup paradigm. But having the best and most opitmized algorithm makes no difference if there is not enough memory on the Line Card, having said that - 1G to 2G mem is something that is already supported by a few vendors - on the Line cards and 2G and above on the Processors (route processor..?) On the other hand - what's wrong with 4Gb on line card in big core router? oh, please please name the router vendor that has 4gb of 'ram' (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one? One wonders why that is? If the solution were as simple as: "Joe, add 1.21jigawatts of memory to the linecard so we can support +1M routes" Don't you think the vendor would have done this to get people to stop bitching at them? Now, now, The RAM mentioned in terms of Gb should not be thought, even inadvertently, to have something to do with TCAM/fpga/asic - Memory here can be divided in to 1. forwarding memory , 2. Line card CPU memory, 3. TCAM memory (damn costly stuff ) And as for the number of routes to be support -Right now venodrs do support close to 500K routes - ask me to name the vendor (notice i did not say Vendors here) and i will be happy to name.But, yes to do something like 1M routes - ahem mighty tricky stuff aint it, but, does any one have 1M active routes in his table as of today (notice how iam trying to evade commenting ;) you cant haul me for saying this) It's cheap enough, even today. And we have not 1,000,000 routes yet. In YOUR network you don't... I'd venture to guess there are quite a few very large networks with +1M routes in them today. remember though, I'm the chemical engineer... and I was trained to MAKE the crack cocaine... 1M routes, BGP is hope so - and not on a single box i suppose so. come on, 1M + active routes- it sure would be a killing on the box. Chemical engineer you say, what a wonderfull world - Iam a pharmacist- fully trained to give an anitdote to cocaine addicts. CIAO

3 2

Re: The whole alternate-root ${STATE}horse
by James R. Cutler 10 Jul '05

10 Jul '05

Servers and zones are part of the physical instancing of DNS roots. The definition of the root precedes the instance. In short, the definition of a naming structure is disjoint from the delivery and usage of that structure, be it servers and zones or whatever. Regarding the separation of servers and zones, this is already common practice. BIND provides a good example of this. With BIND, one can serve an arbitrary set of zones from an arbitrary set of servers, subject to the ability to do zone transfers. So there is obvious separation. Cutler At 11:35 PM 7/9/2005, Jay R. Ashworth wrote: On Sat, Jul 09, 2005 at 06:08:25PM -0400, James R. Cutler wrote: > Actually, many naming and addressing management experts consider that > the existence of a root defines a unique namespace. The existence of a root *zone* yes. We really should separate root *servers* from *root* zones. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me - James R. Cutler james.cutler(a)consultant.com

1 0

RE: DNS .US outage
by Church, Chuck 10 Jul '05

10 Jul '05

Thanks. Didn't have any *NIX boxes laying around to 'dig' any deeper. When I checked networksolutions' whois for neosystems.us and state.ny.us , both returned: " We are unable to process your request at this time. Please try again later." Figured something was up. But when I tried nslookup with a server on yet a 4th ISP just now, it worked ok. Thanks again. Chuck -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com] Sent: Thursday, July 07, 2005 12:34 AM To: Church, Chuck Cc: nanog(a)merit.edu Subject: Re: DNS .US outage On 07/07/05, Church, Chuck <cchurch(a)netcogov.com> wrote: > > Anyone else having issues with .US right now (~12AM EST)? NSlookup, etc > show various .us destinations as unknown domains... > nslookup is not the best tool to troubleshoot dns issues works for me though - suresh@frodo 10:02:22 [~]$ dig us NS ; <<>> DiG 8.3 <<>> us NS ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; us, type = NS, class = IN ;; ANSWER SECTION: us. 1d23h59m46s IN NS A.GTLD.BIZ. us. 1d23h59m46s IN NS B.GTLD.BIZ. us. 1d23h59m46s IN NS C.GTLD.BIZ. ;; Total query time: 3 msec ;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1 ;; WHEN: Thu Jul 7 10:02:25 2005 ;; MSG SIZE sent: 20 rcvd: 76 and a random .us domain - suresh@frodo 10:02:25 [~]$ dig help.us ; <<>> DiG 8.3 <<>> help.us ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; help.us, type = A, class = IN ;; ANSWER SECTION: help.us. 58m46s IN A 66.98.178.79 ;; Total query time: 2 msec ;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1 ;; WHEN: Thu Jul 7 10:03:30 2005 ;; MSG SIZE sent: 25 rcvd: 41 -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

9 8

Fwd: [IGOVAP] A plan to hostile take over .ID domain management
by ops.lists＠gmail.com 09 Jul '05

09 Jul '05

An interesting situation here. Budi operates ID-CERT, and has been ccTLD manager since 1997. APJII is the ISP association of Indonesia, have been a registrar so far. Apparently, according to this email, they also want to be registry, and perhaps also get NIR status, as they would like to allocate IP addresses for Indonesia. I can understand where they are coming from though - their membership is basically all the ISPs in Indonesia, plus cellular carriers, telcos etc. The current ccTLD management (Budi) seems to have decided that the best way to resist what looks like, from this email, a nasty turf war, is to turn the issue into an international one. Email below that he sent ccTLDs, IANA and ICANN, and then forwarded to the igovap(a)lists.apdip.net asiapac i-governance mailing list. regards --srs >Date: Fri, 8 Jul 2005 19:11:09 +0700 >From: Budi Rahardjo <rahard(a)gmail.com> >To: igovap(a)lists.apdip.net >Subject: [IGOVAP] A plan to hostile take over .ID domain management >List-Id: UNDP-APDIP Discussion Forum on Priorities in Internet Governance for > theAsia-Pacific Region <igovap.lists.apdip.net> >List-Archive: <http://lists.apdip.net/pipermail/igovap> > >Just FYI. >It's a sad day for me :( > >-- budi > > > >Domain Management Issues in Indonesia. >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >Dear ccTLDs, IANA, and ICANN, >I would like report the .ID domain management issues. >Originally, I was hoping that these issues could be resolved >elegantly, locally. But, I think that these issues will continue. >So, please bear with this long explanation. > >Short summary >=-=-=-=-=-=-= >APJII (the association of ISP in Indonesia) is trying to takeover >the .ID domain management in Indonesia. They have tried and will try >everything to take over. > >Long description >=-=-=-=-=-=-=-=-= >I've been managing the .ID domain since the end of 1997. >At that time, nobody wanted to run the domain management. > >First of all, a brief description of how we run things. >To run the .ID domain, I am assisted by several domain admins. >Each of these domain admins is responsible for second level >domains. For example, there is a domain admin for AC.ID, >then there is also a different domain admin for CO.ID, etc. >These domain admins are volunteered based. >(None get paid, except for the CO.ID admin who is also helping >the day to day operation.) >All of this was done informally. I am personally responsible >for everything. We use "IDNIC" as the name of our operation. > >There is a fee to register a domain, except for sch.id, go.id, >and mil.id (which is allocated for schools, government, and military >- they are free). >Most of the domains are registered with one time fee, except >for web.id which has a yearly fee. In the future we would like >to implement a yearly fee to make sure that there are no dead >domains (domains that are not used at all). >Billing was outsourced to APJII (the association of Indonesian ISP). > >To serve the domain users better, we are now in the process >of using registrar-registry, just like gTLDs. >We would like to be the registry and stick with >policy and backend. Whereas registrars are doing the business. > >To implement this concept we have to formalized the organization. >We decided to create a formal entity, which consists of all >the domain admins (the de facto operational). This organization >is a non-profit oriented. We are in the process of discussing the >by-laws publicly (through open mailing list). > >Now... the issues. >----------------- > >APJII (the associations of ISP) feels that they are being left out. >They insisted that they should be part of the registry (AND >registrar). They do not like the registrar-registry concept. >So, they sent mails. > >1. First mail stated that we cannot use the word / brand "IDNIC" > anymore since they have trademarked the name IDNIC. (in 1998) > (Yes, they have done this without my knowledge. > It is a stab in my back.) >2. They will use the name IDNIC to serve IP allocation and > AS numbers, which they are doing right now. > (Note: apparently, this is ) > >We have no choice but to stop using the name IDNIC in our services. >We are now using "ccTLD-ID" as our name. >(And we have changed IANA database.) >We move forward with our registrar-registry programme. >Currently, we have selected 5 registrars. > >The next letter was a threat to sue me. > >A couple of months ago, APJII have an election and new officials >were announced. As part of the election process, they also have programme. >To my disbelieve, one of the programme was to create an entity >called IDNIC that manages IP numbers *AND* domain name. >I have no doubt that they will send a letter to ICANN to redelegate >that mandate to them. >Since this is their internal organization issue, I could not >(and would not) do anything. But I have to give you a warning. > >A few days ago, they went to the Government and asked the Gov >to support APJII (or they use the name ID-NIC) as the domain >management in Indonesia. >Now, I am pretty sure APJII will send an email to IANA/ICANN as well, >asking for a redelegation to them. > > >Just to give everybody a head start. > > >Regards >-- Budi Rahardjo >_______________________________________________ >IGOVAP mailing list >IGOVAP(a)lists.apdip.net >http://lists.apdip.net/mailman/listinfo/igovap

1 0

Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
by Brad Knowles 09 Jul '05

09 Jul '05

At 9:43 AM -0400 2005-07-05, Jay R. Ashworth wrote: >> Moreover, most of them are unlikely to be >> willing to just live with the problem, if no other suitable technical >> solution can be found. Instead, they'll believe the sales pitch of >> someone else who says that they can fix the problem, even if that's >> not technically possible. > > Well they might. Well, actually, poorly they might. > > But that argument seems to play right *to* the alt-root operators, > since the "fix" is to switch your customer resolvers to point to one of > them. I disagree. The problem is that there are too many alternatives. > (Assuming, of course, they stay supersets of ICANN, and don't > get at cross-purposes with one another.) The problem is that they are pretty much guaranteed to get at cross-purposes. > In fact, merging them at your > resolvers might be the best solution. I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant. The alternative roots will always be marginal, at best. The problem is that while they are marginal, they can still create serious problems for the rest of us. > But Steve's approach doesn't seem to *me* to play in that direction. > Am I wrong? I'm not sure I understand which Steve you're talking about. Do you mean Steve Gibbard, in his post dated Sun, 3 Jul 2005 22:20:13 -0700 (PDT)? If so, then each country running their own alternative root won't solve the problem of data leaking through the edges. People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods. The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root. -- Brad Knowles, <brad(a)stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

12 29

Re: OMB: IPv6 by June 2008
by Alexei Roudnev 09 Jul '05

09 Jul '05

No one real DOS attack can create traffic, sugnificant for core routers (except one - two worm cases when millions of computers generated random traffic). I do not see a problem there. All problems you are talking about are resolved in modern CPU industry, resolved in modern servers, Router vendors just never had such task. Notice, that modern routers are MORE THEN anough for modern Internet. If routing tables grouth 10 times, routers will follow this trend without sugnificant difficulties. IPv6 looks exactly as ASN.1 - when Telco created it many years ago, they attempted to pack everything into very slow 9600 bandwidth. Result - when you see it in H.323 today, running on 100Mbit links, it's all unnecessary (and it explains why SIP substitutes H.323, even if it never used excellent ASN.1 packing schema /do not bite me, there are many other reasons, of course/). The same here. Many many years ago it looks as CIDR is 100% required and as MH can not be achieved for small companies and that we must limit Internet size to 100,000 routes. Today, we have much more, and do not foresee any problem related to route table sizes. I am not saying that Ipv4 mh approach is excellent, but I do not see anyone, who proved that it could not work in future networks, instead of twisty and tricky IPv6 addressing schema without MH at all. (Of course, it all will result in the same trick - every smalll entity in IPv6 will have it's own PI address block, no one idiot will be able to live with constant renumbering they proposed to use. Just wait 2 - 10 years and you will see). ----- Original Message ----- From: "Dave Andersen" <dga(a)cs.cmu.edu> To: "Alexei Roudnev" <alex(a)relcom.net>; "Syed Junaid Farooqi" <syedjunaid(a)hotpop.com>; "Christopher L. Morrow" <christopher.morrow(a)mci.com> Cc: "NANOG" <nanog(a)merit.edu>; "Brad Knowles" <brad(a)stop.mail-abuse.org> Sent: Saturday, July 09, 2005 11:34 AM Subject: Re: OMB: IPv6 by June 2008 > A cache-based architecture of the sort you describe is prone to thrashing > under weird traffic patterns (such as those introduced by DoS attacks...). > There's something to be said for having routers that can forward at or near > line-rate regardless of the traffic patterns, packet sizes, etc. If you're > holding 1% of your routing table in core, and it takes you several packet > transmissions worth of time to go off-card to fetch different routing > entries, you have a pretty serious problem. > > Thankfully, nobody ever tries to scan the entire 'net, causing major > thrashing in lookup tables. [...] > > Also, keep in mind that memory is either big and cheap -- in which case > you're creating a size problem for routers that already take up enormous > amounts of space -- or small, fast, and very expensive. Memory, > particularly static ram, is also a power hog. Todays BFRs dissipate about > as much power as my electric stove on full blast. > > If there are architectural solutions that can reduce the cost, size, and > power consumption of routers while simultaneously providing improved > availability, it seems silly to ignore them. > > -d > > ----- Original Message ----- > From: Alexei Roudnev > To: Syed Junaid Farooqi ; Christopher L. Morrow > Cc: NANOG ; Brad Knowles > Sent: Saturday, July 09, 2005 1:42 PM > Subject: Re: OMB: IPv6 by June 2008 > > > LC can hold only 20,000 ACTIVE routes., and ask central system if it needs > more., How many ACTIVE routes are used in any CORE router? > 0.1% or CORE? 2% of CORE? > > Again, today it is not technical issue anymore. > ----- Original Message ----- > From: Syed Junaid Farooqi > To: Christopher L. Morrow > Cc: Alexei Roudnev ; NANOG ; Brad Knowles > Sent: Saturday, July 09, 2005 1:02 AM > Subject: Re: OMB: IPv6 by June 2008 > > > Christopher L. Morrow wrote: > randy already asked for a kibosh on the lunacy here... I agree, it'd be > nice, but... > > On Fri, 8 Jul 2005, Alexei Roudnev wrote: > > > You do not need to - any router have only `1 - 10% of all routing table > active, and it is always possible to optimize these alghoritms. > > > > and routing vendor's haven't already done some optomizing you think? > > > They sure have, let me explain a bit - Optimization here can be is Route > table optimization, forwarding table optimization and the actual forwarding > lookup paradigm. > But having the best and most opitmized algorithm makes no difference if > there is not enough memory on the Line Card, having said that - 1G to 2G mem > is something that is already supported by a few vendors - on the Line cards > and 2G and above on the Processors (route processor..?) > > > On the other hand - what's wrong with 4Gb on line card in big core router? > > > oh, please please name the router vendor that has 4gb of 'ram' > (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one? > One wonders why that is? If the solution were as simple as: "Joe, add > 1.21jigawatts of memory to the linecard so we can support +1M routes" > Don't you think the vendor would have done this to get people to stop > bitching at them? > > > Now, now, The RAM mentioned in terms of Gb should not be thought, even > inadvertently, to have something to do with TCAM/fpga/asic - > Memory here can be divided in to 1. forwarding memory , 2. Line card CPU > memory, 3. TCAM memory (damn costly stuff ) > > And as for the number of routes to be support -Right now venodrs do support > close to 500K routes - ask me to name the vendor (notice i did not say > Vendors here) and i will be happy to name.But, yes to do something like 1M > routes - ahem mighty tricky stuff aint it, but, does any one have 1M active > routes in his table as of today (notice how iam trying to evade commenting > ;) you cant haul me for saying this) > > > It's cheap enough, even today. And we have not 1,000,000 routes yet. > > > > In YOUR network you don't... I'd venture to guess there are quite a few > very large networks with +1M routes in them today. > > remember though, I'm the chemical engineer... and I was trained to MAKE > the crack cocaine... > > > 1M routes, BGP is hope so - and not on a single box i suppose so. come on, > 1M + active routes- it sure would be a killing on the box. > > Chemical engineer you say, what a wonderfull world - Iam a pharmacist- > fully trained to give an anitdote to cocaine addicts. > > CIAO >

1 0

Re: mh (RE: OMB: IPv6 by June 2008)
by Fergie (Paul Ferguson) 09 Jul '05

09 Jul '05

Dave, I'd have to counter with "the assumption that NATs are going away with v6 is a rather risky assumption." Or perhaps I misunderstood your point... $.02, - ferg -- Dave Crocker <dhc2(a)dcrocker.net> wrote: [re: shim6] the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

14 20

OT? /dev/null 5.1.1 email
by Jim Popovitch 08 Jul '05

08 Jul '05

<disclaimer> I know this is an email-only question, however the value of the feedback from NANOG is greater than elsewhere, imho. </disclaimer> Should undeliverable email (5.1.1, User unknown) be directed to /dev/null rather than responded to? I was always under the impression that it was nice to respond with a polite message, however these days it seems that 95% of the polite responses are going to 5.1.1 addresses themselves. Tia, -Jim P.

17 28

New IANA IPv6 allocation for APNIC (2400:2000::/19)
by Doug Barton 08 Jul '05

08 Jul '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /19 block to APNIC: ~ 2400:2000::/19 APNIC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-unicast-address-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCzvPowtDPyTesBYwRAlciAKCeR86MJyCmtjbP/MxviXIM6yT8ugCeL9XJ vPlR8n8sUyDaEEnsXIFm5zE= =/Kd+ -----END PGP SIGNATURE-----

1 0