- NANOG - lists.nanog.org

ICANN registrar supporting v6 glue?
by Barrett Lyon 02 Jul '07

02 Jul '07

Apparently GoDaddy does not support v6 glue for their customers, who does? I don't think requiring dual-stack v6 users perform v4 queries to find AAAA records is all that great. Any input would be helpful, -Barrett

15 28

RE: Thoughts on best practice for naming router infrastructure in DNS
by Neil J. McRae 02 Jul '07

02 Jul '07

I remember in the past an excellent system using Sesame Street characters names.

7 7

The Choice: IPv4 Exhaustion or Transition to IPv6
by JORDI PALET MARTINEZ 02 Jul '07

02 Jul '07

Hi all, I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies. http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004 I guess this could be useful in order to understand possible implications of modifying existing policies, or setting up new ones, or even just to create some debate about those changes. The document was completed last April, but didn't had the time to tidy up until a few days ago. Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

37 78

APRICOT 2008: Call for Papers
by Gaurab Raj Upadhaya 02 Jul '07

02 Jul '07

Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) Taipei, Taiwan 20 - 29 February 2008 http://www.apricot2008.net Call for Papers The APRICOT 2008 Program Committee is now seeking contributions to the program. This is the main call for Presentations & Tutorials for APRICOT 2008, so that we can finalize the program. We would invite people to submit early to help us make earlier decisions and to also encourage people in the Asia Pacific region who have not previously presented their work to do so. We are looking for people and proposals that would : * Offer a technical tutorial on an appropriate topic; and/or * Participate in the technical conference sessions as a speaker; and/or * Convene and chair a Birds of a Feather (BOF) session. Please submit online at http://submission.apricot.net/paper/user/login.php?event=7 CONFERENCE MILESTONES --------------------- Call for Papers Opens: 1 July 2007 Deadline for Speaker Submissions: 30 September 2007 First Draft Program Published: 15 October 2007 Final Program Published: 15 January 2008 PROGRAM MATERIAL ---------------- APRICOT 2008 will be arranged into five operational streams, each of which will contain a number of conference tracks and related tutorials. This streamed approach is designed to foster operational communities within the Asia Pacific region. Each stream will take place in the same area providing opportunity for people do further discuss and network with peers. Streams for APRICOT 2008 are: 1. Service Provider Operations : Routing and Access IPv4 and IPv6 Routing, APNIC Routing and IPv6 Technical SIG, MPLS, Backbone operations, Wireless, WiMax, Metro Ethernet, DSL, Broadband access aggregation. 2. Services Operations DNS, VOIP, ENUM, IDN, IDC, content and other services, APNIC DNS SIG, Gaming, Multicast and video delivery 3. Security Operations NSP-Sec, DDoS, Security Operations, Anti-SPAM, Anti-Malware. 4. Internet Provider Relationships IXP Operations, Peering, APNIC IX SIG. 5. APNIC Stream APNIC's NIR, Database, and Policy SIGs. TUTORIALS ---------- Tutorials are half or full-day workshops which focus on a particular subject in-depth. Half day will be presented by a single Instructor, or a Full day tutorial may be presented by a team of two instructors working together. Tutorial Instructors are encouraged to also sign up to be a Speaker in the Technical Conference Program as well. You can sign up to give a tutorial and/or conference session presentation by following the instructions at the end of this message for signing up as a speaker or instructor. Tutorial topics which have successful in the past, or have been requested for this year are: - Network security, IPSec, Auditing/Forensics, DDoS Mitigation, VoIP Security - Address planning, conservation, responsibility and migration to IPv6 - High performance IP backbone routing and management - BGP MultiHoming - MPLS - IPv6 implementation - Network planning, management and traffic engineering - Internet exchanges, construction, peering and collocation - Operations, NOC, Helpdesk and other support aspects - BIND, DNSSEC, Split Horizon DNS, and Reverse and multilingual DNS - Broadband first/last mile access technologies - Mobile and wireless technologies - Content, Applications, streaming and multimedia infrastructure - VoIP, Unified messaging, scaling e-mail infrastructure, Asterisk, etc. - Hosted Essential Services (mail, DNS, etc), Server scaling, Open source The program committee will consider proposals for tutorials in any of these areas, and also in new areas. There will be two days of Tutorials. Tutorials last 1/2 day or a full day and can cater to beginner through to advanced audiences. Tutorial days are typically split into four 1.5 hour sessions. If you have an idea for a tutorial subject that is not listed, please feel free to submit it to us. TECHNICAL CONFERENCE SESSIONS ----------------------------- The Main Conference Program for 2008 will be made up of two days, with three streams each day. In addition there will be a colocated meetings of the Asian Broadband Summit and the Asia Pacific IPv6 Task Force. The Asia Pacific Top Level Domain (APTLD) will also hold their members meetings during APRICOT. Each stream will consist of four 1.5 hour sessions, with each having three or four presentations. This allows 20-30mins per presenter. Presentation longer then 25 minutes should be submitted as tutorials. Sessions are chaired by persons of appropriate expertise in the subject matter of the session and will include ample time for questions from the audience. Successful presentations from past APRICOTs have covered topics relevant to current operational deployments or new technologies not yet in wide deployment. Proposals for conference presentations are invited for topics fitting into the six streams outlined above. If you would like to give a presentation at one or more of the sessions, follow the instructions at the end of this message for signing up as a speaker or instructor. PEERING ---------- If you are an ISP or Content Provider that can share some experiences peering in Asia and abroad, please consider contributing an abstract for the Peering track in the Inter Provider Relationship stream. Given that this track has been highly popular, with enough support this will evolve into the Asian version of the Global Peering Forum. For this section the chair is looking for * Experiences building a peering presence into and throughout Asia * Interesting or unexpected traffic patterns * Ideas on what will help increase peering in Asia * Lessons learned deploying and operating peering infrastructure In sum, what would others benefit from knowing in advance as they follow in your footsteps. If you have some operations experiences to share, please submit it online following the procedure outlined below. Alternatively, send a note to bill.norton(a)gmail.com with the subject: "APRICOT 2008 Peering Track Idea". LIGHTNING TALKS ---------------- After the successful introductions of Lightning talks at APRICOT 2007, we will continue with it. Call for papers for Lightning talks will be made during APRICOT, and will be limited to participants of the conference. CFP SUBMISSION -------------- When considering a presentation or tutorial, remember that the APRICOT audience is mainly comprised of technical network operators and engineers with a wide range of experience levels from beginners to multi-year experience. There is a strong orientation to offer core skills and basic knowledge in the tutorials and to address issues relevant to the day-to-day operations of ISPs and network operators over the next 12 - 18 months in the conference sessions. The deadline for submissions is 30 September, 2007. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. Final slides are to be provided by 15 January, 2008. While the majority of speaking slots will be submitted by 30 September 2007, a limited number of slots may be available for presentations that are exceptionally timely, important, or of critical operational importance. Please submit online at http://submission.apricot.net/paper/user/login.php?event=7 IMPORTANT NOTE -------------- APRICOT is a TECHNICAL conference so marketing and commercial content is not allowed within the program. The program committee is charged with maintaining the technical standard of APRICOT, and will therefore not accept inappropriate materials. It is expected that the presenter be a technical person and not a sales or marketing person. The audience is extremely technical and expects that the speakers are themselves very knowledgeable. All sessions provide time for questions, so presenters should expect technical questions and be prepared to deliver insightful and technically deep responses. FUNDING AND SUPPORT ------------------- 'APRICOT is a not-for-profit event that tries to keep the cost to attendees low so we are unable to pay the travel costs of speakers. Speakers from developing countries may be eligible for the APRICOT Fellowship Program which provides basic assistance to successful fellows to cover local living and registration expenses associated with attending the conference.' More information on the APRICOT Fellowship program can be found at the APRICOT 2008 website at http://www.apricot2008.net/ Accepted tutorial speakers will receive complimentary registration to both the tutorials and conference. SUBMISSION DETAILS ------------------ If you would like to be considered as a tutorial instructor, session speaker, or a convener of a BOF, please fill in the form at http://submission.apricot.net/ More information on the conference is available at http://www.apricot2008.net/ Thanks. APRICOT Program Committee

1 0

RE: issues Level3 versus rest of the world?, looks good from Berlin...
by Security Admin (NetSec) 01 Jul '07

01 Jul '07

Looks good from berlin too: Show Level 3 (Berlin, Germany) Traceroute to 64.26.31.117 1 ae-31-55.ebr1.Berlin1.Level3.net (4.68.108.158) 4 msec ae-31-51.ebr1.Berlin1.Level3.net (4.68.108.30) 0 msec ae-31-53.ebr1.Berlin1.Level3.net (4.68.108.94) 0 msec 2 ae-3.ebr2.Dusseldorf1.Level3.net (4.69.133.146) 12 msec 16 msec 20 msec 3 ae-3.ebr2.Dusseldorf1.Level3.net (4.69.133.146) 16 msec 20 msec 16 msec 4 ae-2.ebr2.Frankfurt1.Level3.net (4.69.132.138) 16 msec 24 msec 16 msec 5 ae-2.ebr2.Frankfurt1.Level3.net (4.69.132.138) 20 msec 16 msec 20 msec 6 ae-2.ebr2.Paris1.Level3.net (4.69.132.141) 36 msec 24 msec 32 msec 7 ae-2.ebr2.Paris1.Level3.net (4.69.132.141) 36 msec 36 msec 36 msec 8 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) 108 msec ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 112 msec ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 116 msec 9 ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 112 msec 108 msec 108 msec 10 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 120 msec 124 msec 124 msec 11 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 128 msec 128 msec 124 msec 12 ae-5-5.car1.Tampa1.Level3.net (4.69.133.49) 140 msec 136 msec 164 msec 13 ae-5-5.car1.Tampa1.Level3.net (4.69.133.49) 136 msec 140 msec 136 msec 14 e1-11-level3.co2.tpax.as30217.net (4.71.0.10) 140 msec 140 msec 140 msec 15 e1-11-level3.co2.tpax.as30217.net (4.71.0.10) 136 msec PROGRESS-TE.car3.Tampa1.Level3.net (4.71.0.18) 136 msec e1-11-level3.co2.tpax.as30217.net (4.71.0.10) 136 msec 16 64.26.31.117 [AS30217 {DESYNC}] 140 msec 140 msec 140 msec c/o http://lg.level3.net/traceroute/traceroute.cgi?site=ber1&target=64.26.31.117 -- This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.com

2 1

issues Level3 versus rest of the world?
by Peter Dambier 01 Jul '07

01 Jul '07

I cannot http 64.26.31.117 traceroute to 64.26.31.117 (64.26.31.117), 30 hops max, 40 byte packets 1 krzach.peter-dambier.de (192.168.48.2) 1.022 ms 1.499 ms 1.685 ms 2 * * * 3 217.0.78.58 75.464 ms 83.260 ms 91.327 ms 4 f-ea5.F.DE.net.DTAG.DE (62.154.16.161) 108.374 ms 108.407 ms 116.207 ms 5 Te-4-4.car2.Frankfurt1.Level3.net (4.68.110.253) 134.233 ms * * 6 * * ae-32-54.ebr2.Frankfurt1.Level3.net (4.68.118.126) 160.320 ms 7 ae-1-100.ebr1.Frankfurt1.Level3.net (4.69.132.125) 154.145 ms 171.149 ms ae-2.ebr2.Paris1.Level3.net (4.69.132.141) 171.099 ms 8 ae-5.ebr2.Washington1.Level3.net (4.69.132.113) 148.639 ms ae-2.ebr2.Paris1.Level3.net (4.69.132.141) 148.567 ms ae-5.ebr2.Washington1.Level3.net (4.69.132.113) 166.351 ms 9 ae-5.ebr2.Washington1.Level3.net (4.69.132.113) 184.331 ms 184.365 ms 188.637 ms 10 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 188.671 ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 217.410 ms ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 217.444 ms 11 ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 233.065 ms * * 12 ae-78.ebr2.Atlanta2.Level3.net (4.69.134.53) 233.085 ms * * 13 * * * 14 ae-5-5.car1.Tampa1.Level3.net (4.69.133.49) 180.572 ms 180.581 ms ae-13-13.car3.Tampa1.Level3.net (4.69.133.54) 196.538 ms 15 ae-13-13.car3.Tampa1.Level3.net (4.69.133.54) 196.572 ms e1-11-level3.co2.tpax.as30217.net (4.71.0.10) 205.242 ms 220.799 ms 16 PROGRESS-TE.car3.Tampa1.Level3.net (4.71.0.18) 220.834 ms e1-3.dr2.as30217.net (84.40.24.42) 227.636 ms PROGRESS-TE.car3.Tampa1.Level3.net (4.71.0.18) 235.616 ms 17 e1-3.dr2.as30217.net (84.40.24.42) 174.951 ms 64.26.31.117 183.360 ms 190.007 ms At the same time 205.189.71.34 cannot ftp me although I can ssh him. traceroute to echnaton.serveftp.com (62.227.219.14), 30 hops max, 38 byte packets 1 205.189.71.253 (205.189.71.253) 0.241 ms 0.220 ms 0.227 ms 2 ge-5-2-234.ipcolo1.Amsterdam1.Level3.net (212.72.46.165) 0.735 ms 1.051 ms 0.981 ms 3 ae-0-51.mp1.Amsterdam1.Level3.net (4.68.120.1) 1.233 ms 0.952 ms 1.229 ms 4 as-0-0.mp1.Hamburg1.Level3.net (4.68.128.34) 9.234 ms as-0-0.mp2.Hamburg1.Level3.net (4.68.128.30) 9.231 ms as-0-0.mp1.Hamburg1.Level3.net (4.68.128.34) 9.117 ms 5 so-10-0.hsa2.Hamburg1.Level3.net (4.68.115.241) 9.182 ms 8.868 ms so-2-0.hsa2.Hamburg1.Level3.net (4.68.115.253) 9.107 ms 6 HH-EB1.HH.DE.net.dtag.de (4.68.127.242) 9.621 ms 9.706 ms 9.476 ms 7 217.5.68.82 (217.5.68.82) 15.605 ms 15.901 ms 15.724 ms 8 217.0.78.57 (217.0.78.57) 18.219 ms 17.031 ms 16.874 ms 9 * * * ... All they have in common is Level3 and we have a blue moon today. It is a couple of people distributed over the globe who complained. Kind regards Peter and Karin Dambier -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter(a)peter-dambier.de mail: peter(a)echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/

2 2

RE: issues Level3 versus rest of the world?
by Security Admin (NetSec) 01 Jul '07

01 Jul '07

<<I cannot http 64.26.31.117>> But I can :) .... 4 9 ms 9 ms 8 ms f1.ba01.b002698-1.lax01.atlas.cogentco.com [38.112.9.189] 5 8 ms 8 ms 9 ms g2-3.core01.lax01.atlas.cogentco.com [66.250.12.129] 6 17 ms 9 ms 8 ms t8-1.mpd01.lax01.atlas.cogentco.com [154.54.1.102] 7 136 ms 206 ms 212 ms t7-1.mpd02.sfo01.atlas.cogentco.com [154.54.6.30] 8 21 ms 19 ms 20 ms v3498.mpd01.sjc03.atlas.cogentco.com [154.54.6.234] 9 21 ms 21 ms 20 ms 64.132.69.17 10 23 ms 21 ms 21 ms core-02-so-1-0-0-0.okld.twtelecom.net [64.129.248.16] 11 81 ms 79 ms 79 ms dist-01-so-0-0-0-0.tamq.twtelecom.net [66.192.243.17] 12 98 ms 232 ms 179 ms 66.192.247.163 13 94 ms 94 ms 93 ms 66.193.50.238 14 94 ms 95 ms 93 ms e1-3.dr2.as30217.net [84.40.24.42] 15 94 ms 93 ms 93 ms 64.26.31.117 Level3 can too, c/o http://lg.level3.net/traceroute/traceroute.cgi?site=sjo1&target=64.26.31.117 Show Level 3 (San Jose, CA) Traceroute to 64.26.31.117 1 vlan52.csw2.SanJose1.Level3.net (4.68.123.62) 12 msec vlan51.csw1.SanJose1.Level3.net (4.68.123.30) 0 msec vlan52.csw2.SanJose1.Level3.net (4.68.123.62) 0 msec 2 ae-63-63.ebr3.SanJose1.Level3.net (4.69.134.225) 4 msec ae-73-73.ebr3.SanJose1.Level3.net (4.69.134.229) 0 msec ae-63-63.ebr3.SanJose1.Level3.net (4.69.134.225) 0 msec 3 ae-2.ebr3.LosAngeles1.Level3.net (4.69.132.10) 20 msec 16 msec 20 msec 4 ae-78.ebr2.LosAngeles1.Level3.net (4.69.135.13) 16 msec 20 msec 16 msec 5 ae-3.ebr3.Dallas1.Level3.net (4.69.132.78) 40 msec 52 msec 56 msec 6 ae-68.ebr1.Dallas1.Level3.net (4.69.135.1) 40 msec 44 msec 56 msec 7 ae-7-7.car2.Tampa1.Level3.net (4.69.133.41) 64 msec 64 msec 68 msec 8 ae-23-23.car3.Tampa1.Level3.net (4.69.133.62) 64 msec 68 msec 76 msec 9 PROGRESS-TE.car3.Tampa1.Level3.net (4.71.0.18) 64 msec e1-11-level3.co2.tpax.as30217.net (4.71.0.10) 64 msec PROGRESS-TE.car3.Tampa1.Level3.net (4.71.0.18) 64 msec 10 e1-3.dr2.as30217.net (84.40.24.42) [AS30217 {DESYNC}] 64 msec 64 msec 68 msec 11 64.26.31.117 [AS30217 {DESYNC}] 64 msec 64 msec 68 msec ...... Do you multihome? If not, you should. SecAdmin -- This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.com

1 0

Cable-Tying with Waxed Twine
by Dan Mahoney, System Admin 01 Jul '07

01 Jul '07

Hey all, This seems a wee bit off topic, but definitely relates to network operations (somewhere below layer 1) and I can't think of a better place to ask. Upon leaving a router at telx and asking one of their techs to plug in the equipment for me, I came back to find all my cat5 cables neatly tied with some sort of waxed twine, using an interesting looping knot pattern that repeated every six inches or so using a single piece of string. For some reason, I found this trick really cool. I have tried googling for the method, (it's apparently standard, I've seen it in play elsewhere), and for the type of twine, but had little luck. I was wondering if any of the gurus out there would care to share what this knot-pattern is actually called, and/or if there's a (illustrated) howto somewhere? -Dan "Tired of getting scratched up by jagged cable ties" Mahoney -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

21 20

Re: The Choice: IPv4 Exhaustion or Transition to IPv6
by Brandon Butterworth 30 Jun '07

30 Jun '07

> I'm working on it ... But I think it will be really difficult to capture in > a couple of pages what the document try to explain ! A. v4 runs out, use v6 or similar B. not run out of v4 The detail of A and B may safely be debated by all for some time as nobody knows what will happen, feel free to speculate wildly (with a nod to Deep Thought) brandon

2 1

Thoughts on best practice for naming router infrastructure in DNS
by Olsen, Jason 29 Jun '07

29 Jun '07

I've found myself with a few spare cycles and have decided to put them towards addressing a pet peeve I frequently encounter here: the complete state of chaois that is the naming in DNS for our network infrastructure. There are mismatched forward and reverse entries, no designated subdomain for WAN or LAN gear, there are records that remained after equipment was retired, etc. The single biggest area of offense is in the naming for our routing gear. I attribute this to the fact that routers commonly have a greater number of IP addresses associated with them than, say, your average edge switch. I'm still doing some digging around the 'net as well as the NANOG archives (the document from Rutger's at http://www-td.rutgers.edu/documentation/Reference/RUNet_Network_Device_N aming_Convention/ provided a great example that I'm considering following) but I thought I'd toss it out on the list for a bit of insight into what's being done today as opposed to five years ago. There seems to be two general practices that are used when naming routers in DNS. The first is to describe the location, equipment, interface and interface number on the equipment in the hostname, matching that to a designated subdomain that describes the function (WAN routing, LAN switching, etc). Something like "corp-wan1-gige0-0.wan.example.com" would be used to describe interface Gi0/0 on WAN router #1 at the corporate office and "dpg-mu1.wan.example.com" would describe the Multilink1 interface on the DuPage location's only WAN router. The upside to this methodology is that techs and users alike can see useful information when doing a traceroute, etc. The downside is that if your router has a dozen interfaces you end up with two dozen records (12 forward, 12 reverse) associated with the device that must be maintained. Additionally, the moment you upgrade an interface you have to change the two corresponding records to reflect the new IP or interface type (FastE to GigE, for example). The other style I've seen is to use one generic name, such as "corp-wan1.wan.example.com" for the first WAN router and "corp-core1.lan.example.com" for the first core router, make the FQDN resolve to a loopback or similarly unchanging IP and for every interface that carries an IP address just have the address reverse to that single generic FQDN. This is generally simpler to maintain and is given praise because it's less likely to confuse NMS applications like OpenView Network Node Manager -- on the downside you lose a lot of potentially useful information. Neither one of these seems well-equipped to deal with "virtual" interfaces such as an ethernet interface that is VRRP or HSRP'd between two routers (eg x.x.x.10 is your "virtual" IP for the subnet's gateway, router 1 has physical interface IP of x.x.x.8 and router 2 has x.x.x.9). So, what practices do you folks follow? What are the up and downsides you encounter? -JFO Jason "Feren" Olsen DeVry University

9 9