From joelja at bogus.com Thu Oct 1 02:12:03 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 01 Oct 2009 00:12:03 -0700 Subject: NANOG 47 PGP signing party. Message-ID: <4AC45643.3050708@bogus.com> Just a quick note, The generally thrice annual NANOG pgp key signing party will be making an appearance at NANOG 47. The keysigning sessions are going to be held during the morning breaks of the general session, and will be location TDB. If there is interest we'll invite the various CA cert notaries to join in the fun. If you plan to participate, please add your key to the keyring at: http://biglumber.com/x/web?ev=97301 Then come to one or both sessions with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. While printouts will probably be available at the sessions, feel free to add your key to the keyring right up to the time of the last keysigning event. Thanks Joel From dmm at 1-4-5.net Thu Oct 1 13:02:29 2009 From: dmm at 1-4-5.net (David Meyer) Date: Thu, 1 Oct 2009 11:02:29 -0700 Subject: [NANOG-announce] Heads up -- NANOG 47 upcoming dates of interest Message-ID: <20091001180229.GA15538@1-4-5.net> Folks, The NANOG PC is in the process of finalizing an exciting agenda for NANOG 47, so look for that over the next couple of days. In addition, note that registration rate will be going up on 10/03/2009 (from $US 525.00 to $US 600.00), so register now! See you all in Dearborn. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From boyadjiev at cnci.co.jp Fri Oct 2 01:22:09 2009 From: boyadjiev at cnci.co.jp (Nick Boyadjiev) Date: Fri, 2 Oct 2009 15:22:09 +0900 Subject: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? In-Reply-To: References: <6348c7fd0908171311h2936e6bfifcfd684205befbaf@mail.gmail.com> <20090817214840.GA76062@gweep.net> Message-ID: Dear Colleagues, Sorry for the late response. The problem was due to faulty firmware on one of our Alaxala routers. We resolved the problem the same day (Aug. 18) by downgrading firmware. For more details, please see Alaxala page here (English): http://www.alaxala.com/en/information/20090827.html If you have filters etc. blocking AS9354, please remove them. Thank you, Nick Boyadjiev AS9354 Nagoya JAPAN From ml at kenweb.org Fri Oct 2 06:23:00 2009 From: ml at kenweb.org (ML) Date: Fri, 02 Oct 2009 07:23:00 -0400 Subject: Cogent leaking /32s? Message-ID: <4AC5E294.9050302@kenweb.org> I received an alert from Cyclops telling me a probe in AS513 had seen a /32 that I announce to Cogent for one of our BGP sessions. Did anyone else see this? From zak at yellowfiber.net Fri Oct 2 07:54:43 2009 From: zak at yellowfiber.net (Zak Thompson) Date: Fri, 2 Oct 2009 08:54:43 -0400 Subject: Cogent leaking /32s? In-Reply-To: <4AC5E294.9050302@kenweb.org> References: <4AC5E294.9050302@kenweb.org> Message-ID: <872A476DA517EE428312FB7D5FF284BA4FF7AD@rstexchange02.yellowfiber.net> We had a problem with cogent about a year ago. Somehow.. cymru was announcing a /32 of ours and black holing it for whatever reason. It was removed but wasn't happy that cogent was allowing cymru to do this sort of action. To this date we do not have a valid reason from cogent on why they allowed this to happen. Cheers, Zak Thompson -----Original Message----- From: ML [mailto:ml at kenweb.org] Sent: Friday, October 02, 2009 7:23 AM To: nanog at nanog.org Subject: Cogent leaking /32s? I received an alert from Cyclops telling me a probe in AS513 had seen a /32 that I announce to Cogent for one of our BGP sessions. Did anyone else see this? From jgreco at ns.sol.net Fri Oct 2 08:27:30 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Oct 2009 08:27:30 -0500 (CDT) Subject: Cogent leaking /32s? In-Reply-To: <872A476DA517EE428312FB7D5FF284BA4FF7AD@rstexchange02.yellowfiber.net> from "Zak Thompson" at Oct 02, 2009 08:54:43 AM Message-ID: <200910021327.n92DRU6W065916@aurora.sol.net> > We had a problem with cogent about a year ago. Somehow.. cymru was > announcing a /32 of ours and black holing it for whatever reason. It > was removed but wasn't happy that cogent was allowing cymru to do this > sort of action. To this date we do not have a valid reason from cogent > on why they allowed this to happen. Of course, if it was accidental, then there wouldn't be a "valid reason" why "they allowed." It could be more helpful to indicate what they did tell you. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From drew.linsalata at gmail.com Fri Oct 2 10:25:13 2009 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Fri, 2 Oct 2009 11:25:13 -0400 Subject: Problems with 7132 in Connecticut? Message-ID: <7820B5A0-8D6A-42BB-878F-84AF3BAFE2CE@gmail.com> We're getting a slew of complaints from folks on SNET DSL links in Connecticut that can't reach two of our prefixes. If anyone at AS 7132 is listening and willing to contact me off-list, I can fill you in. The usual support channels aren't yielding much at the moment. Is anyone else seeing this? From swmike at swm.pp.se Fri Oct 2 10:36:23 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 2 Oct 2009 17:36:23 +0200 (CEST) Subject: Cogent leaking /32s? In-Reply-To: <4AC5E294.9050302@kenweb.org> References: <4AC5E294.9050302@kenweb.org> Message-ID: On Fri, 2 Oct 2009, ML wrote: > I received an alert from Cyclops telling me a probe in AS513 had seen a /32 > that I announce to Cogent for one of our BGP sessions. > > Did anyone else see this? Are you relying on the /24 filtering "everybody" does, or did you announce it to them with NO-EXPORT set? -- Mikael Abrahamsson email: swmike at swm.pp.se From cluestore at gmail.com Fri Oct 2 10:54:13 2009 From: cluestore at gmail.com (Clue Store) Date: Fri, 2 Oct 2009 10:54:13 -0500 Subject: Cogent leaking /32s? In-Reply-To: References: <4AC5E294.9050302@kenweb.org> Message-ID: <580af3b90910020854n223f5e34pea6ef3c0b8826214@mail.gmail.com> Yes, I absolutely love the /24 filtering "everybody" does. Internet littering at its best. http://thyme.apnic.net/current/data-badpfx-nos Clue On Fri, Oct 2, 2009 at 10:36 AM, Mikael Abrahamsson wrote: > On Fri, 2 Oct 2009, ML wrote: > > I received an alert from Cyclops telling me a probe in AS513 had seen a /32 >> that I announce to Cogent for one of our BGP sessions. >> >> Did anyone else see this? >> > > Are you relying on the /24 filtering "everybody" does, or did you announce > it to them with NO-EXPORT set? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > From r.hyunseog at ieee.org Fri Oct 2 11:01:07 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Fri, 02 Oct 2009 11:01:07 -0500 Subject: Cogent leaking /32s? In-Reply-To: <872A476DA517EE428312FB7D5FF284BA4FF7AD@rstexchange02.yellowfiber.net> References: <4AC5E294.9050302@kenweb.org> <872A476DA517EE428312FB7D5FF284BA4FF7AD@rstexchange02.yellowfiber.net> Message-ID: <4AC623C3.7090408@ieee.org> If there is DDoS attack going on from/to specific /32, sometimes they do that to avoid too much overload for the network. Cogent should give the answer for what's going on. Alex Zak Thompson wrote: > We had a problem with cogent about a year ago. Somehow.. cymru was > announcing a /32 of ours and black holing it for whatever reason. It > was removed but wasn't happy that cogent was allowing cymru to do this > sort of action. To this date we do not have a valid reason from cogent > on why they allowed this to happen. > > Cheers, > Zak Thompson > > > > -----Original Message----- > From: ML [mailto:ml at kenweb.org] > Sent: Friday, October 02, 2009 7:23 AM > To: nanog at nanog.org > Subject: Cogent leaking /32s? > > I received an alert from Cyclops telling me a probe in AS513 had seen a > /32 that I announce to Cogent for one of our BGP sessions. > > Did anyone else see this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From cscora at apnic.net Fri Oct 2 13:45:18 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Oct 2009 04:45:18 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200910021845.n92IjIIY028017@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 03 Oct, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 299282 Prefixes after maximum aggregation: 140261 Deaggregation factor: 2.13 Unique aggregates announced to Internet: 148558 Total ASes present in the Internet Routing Table: 32294 Prefixes per ASN: 9.27 Origin-only ASes present in the Internet Routing Table: 28065 Origin ASes announcing only one prefix: 13702 Transit ASes present in the Internet Routing Table: 4229 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 31 Max AS path prepend of ASN (45127) 27 Prefixes from unregistered ASNs in the Routing Table: 529 Unregistered ASNs in the Routing Table: 123 Number of 32-bit ASNs allocated by the RIRs: 289 Prefixes from 32-bit ASNs in the Routing Table: 205 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 199 Number of addresses announced to Internet: 2109742304 Equivalent to 125 /8s, 192 /16s and 28 /24s Percentage of available address space announced: 56.9 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 79.1 Total number of prefixes smaller than registry allocations: 144036 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 71662 Total APNIC prefixes after maximum aggregation: 25237 APNIC Deaggregation factor: 2.84 Prefixes being announced from the APNIC address blocks: 68081 Unique aggregates announced from the APNIC address blocks: 30363 APNIC Region origin ASes present in the Internet Routing Table: 3810 APNIC Prefixes per ASN: 17.87 APNIC Region origin ASes announcing only one prefix: 1047 APNIC Region transit ASes present in the Internet Routing Table: 590 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 31 Number of APNIC addresses announced to Internet: 461477152 Equivalent to 27 /8s, 129 /16s and 149 /24s Percentage of available APNIC address space announced: 78.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 126890 Total ARIN prefixes after maximum aggregation: 66668 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 101368 Unique aggregates announced from the ARIN address blocks: 38486 ARIN Region origin ASes present in the Internet Routing Table: 13250 ARIN Prefixes per ASN: 7.65 ARIN Region origin ASes announcing only one prefix: 5126 ARIN Region transit ASes present in the Internet Routing Table: 1295 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 706349696 Equivalent to 42 /8s, 26 /16s and 10 /24s Percentage of available ARIN address space announced: 61.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 68650 Total RIPE prefixes after maximum aggregation: 40215 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 62331 Unique aggregates announced from the RIPE address blocks: 41788 RIPE Region origin ASes present in the Internet Routing Table: 13533 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7052 RIPE Region transit ASes present in the Internet Routing Table: 2037 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 399867584 Equivalent to 23 /8s, 213 /16s and 126 /24s Percentage of available RIPE address space announced: 74.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 25750 Total LACNIC prefixes after maximum aggregation: 6325 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24046 Unique aggregates announced from the LACNIC address blocks: 13497 LACNIC Region origin ASes present in the Internet Routing Table: 1187 LACNIC Prefixes per ASN: 20.26 LACNIC Region origin ASes announcing only one prefix: 382 LACNIC Region transit ASes present in the Internet Routing Table: 193 Average LACNIC Region AS path length visible: 4.2 Max LACNIC Region AS path length visible: 30 Number of LACNIC addresses announced to Internet: 66579712 Equivalent to 3 /8s, 247 /16s and 237 /24s Percentage of available LACNIC address space announced: 66.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5885 Total AfriNIC prefixes after maximum aggregation: 1548 AfriNIC Deaggregation factor: 3.80 Prefixes being announced from the AfriNIC address blocks: 4279 Unique aggregates announced from the AfriNIC address blocks: 1536 AfriNIC Region origin ASes present in the Internet Routing Table: 322 AfriNIC Prefixes per ASN: 13.29 AfriNIC Region origin ASes announcing only one prefix: 95 AfriNIC Region transit ASes present in the Internet Routing Table: 65 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12557312 Equivalent to 0 /8s, 191 /16s and 156 /24s Percentage of available AfriNIC address space announced: 37.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1766 6995 456 Korea Telecom (KIX) 17488 1475 135 142 Hathway IP Over Cable Interne 4755 1256 292 144 TATA Communications formerly 9583 1102 87 531 Sify Limited 4134 1010 18168 391 CHINANET-BACKBONE 18101 979 204 33 Reliance Infocom Ltd Internet 7545 885 198 100 TPG Internet Pty Ltd 9829 805 625 20 BSNL National Internet Backbo 24560 774 285 164 Bharti Airtel Ltd., Telemedia 4808 762 1518 181 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4163 3626 313 bellsouth.net, inc. 4323 3692 1037 384 Time Warner Telecom 1785 1758 714 138 PaeTec Communications, Inc. 7018 1522 5859 1054 AT&T WorldNet Services 20115 1475 1475 669 Charter Communications 6478 1413 279 301 AT&T Worldnet Services 2386 1320 656 950 AT&T Data Communications Serv 3356 1227 10963 435 Level 3 Communications, LLC 11492 1130 208 12 Cable One 22773 1111 2604 70 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 494 93 203 Evolva Telecom 3292 446 1900 393 TDC Tele Danmark 35805 442 40 5 United Telecom of Georgia 12479 426 578 6 Uni2 Autonomous System 702 423 1822 341 UUNET - Commercial IP service 9198 381 138 12 Kazakhtelecom Data Network Ad 8866 356 110 21 Bulgarian Telecommunication C 3301 352 1428 309 TeliaNet Sweden 3320 352 7067 303 Deutsche Telekom AG 3215 348 3128 110 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1480 2899 245 UniNet S.A. de C.V. 10620 1007 227 98 TVCABLE BOGOTA 28573 758 639 86 NET Servicos de Comunicao S.A 7303 650 343 99 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 475 310 61 Instituto Costarricense de El 11172 440 99 70 Servicios Alestra S.A de C.V 14117 436 29 11 Telefonica del Sur S.A. 7738 427 858 29 Telecomunicacoes da Bahia S.A 6471 421 96 31 ENTEL CHILE S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 981 188 7 TEDATA 24863 935 96 65 LINKdotNET AS number 3741 272 856 234 The Internet Solution 2018 192 187 118 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 139 14 6 Ci Telecom Autonomous system 33776 125 7 11 Starcomms Nigeria Limited 24835 123 46 9 RAYA Telecom - Egypt 5536 122 8 13 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4163 3626 313 bellsouth.net, inc. 4323 3692 1037 384 Time Warner Telecom 4766 1766 6995 456 Korea Telecom (KIX) 1785 1758 714 138 PaeTec Communications, Inc. 7018 1522 5859 1054 AT&T WorldNet Services 8151 1480 2899 245 UniNet S.A. de C.V. 17488 1475 135 142 Hathway IP Over Cable Interne 20115 1475 1475 669 Charter Communications 6478 1413 279 301 AT&T Worldnet Services 2386 1320 656 950 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3692 3308 Time Warner Telecom 1785 1758 1620 PaeTec Communications, Inc. 17488 1475 1333 Hathway IP Over Cable Interne 4766 1766 1310 Korea Telecom (KIX) 8151 1480 1235 UniNet S.A. de C.V. 11492 1130 1118 Cable One 6478 1413 1112 AT&T Worldnet Services 4755 1256 1112 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1111 1041 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:24 /11:63 /12:176 /13:354 /14:628 /15:1199 /16:10668 /17:4847 /18:8372 /19:17493 /20:20889 /21:20988 /22:27160 /23:26806 /24:156790 /25:924 /26:1078 /27:558 /28:172 /29:40 /30:15 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2696 4163 bellsouth.net, inc. 4323 2351 3692 Time Warner Telecom 4766 1439 1766 Korea Telecom (KIX) 17488 1237 1475 Hathway IP Over Cable Interne 1785 1224 1758 PaeTec Communications, Inc. 11492 1056 1130 Cable One 18566 1043 1062 Covad Communications 9583 954 1102 Sify Limited 10620 913 1007 TVCABLE BOGOTA 8452 909 981 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:227 12:2148 13:7 15:22 16:3 17:5 20:36 24:1168 32:52 34:2 38:601 40:97 41:1707 43:1 44:2 46:1 47:16 52:6 55:2 56:2 57:25 58:613 59:642 60:450 61:1077 62:1015 63:2008 64:3708 65:2400 66:4109 67:1791 68:964 69:2765 70:576 71:154 72:1658 73:2 74:1954 75:181 76:349 77:873 78:581 79:394 80:898 81:808 82:505 83:429 84:522 85:1003 86:382 87:666 88:387 89:1495 90:62 91:2578 92:408 93:1235 94:1184 95:1106 96:170 97:270 98:310 99:30 109:44 110:212 111:445 112:139 113:146 114:262 115:354 116:1111 117:549 118:328 119:773 120:136 121:780 122:1287 123:787 124:1047 125:1350 128:221 129:216 130:129 131:425 132:75 133:10 134:181 135:42 136:241 137:166 138:177 139:85 140:442 141:121 142:381 143:333 144:349 145:48 146:387 147:168 148:549 149:209 150:149 151:181 152:215 153:156 154:2 155:271 156:167 157:307 158:101 159:354 160:291 161:168 162:270 163:172 164:279 165:520 166:475 167:377 168:792 169:168 170:474 171:43 172:2 173:420 174:359 175:1 178:1 180:39 182:1 186:138 187:156 188:1055 189:601 190:3114 192:5776 193:4260 194:3285 195:2746 196:1142 198:3555 199:3354 200:5209 201:1343 202:7851 203:8247 204:3936 205:2199 206:2428 207:2970 208:3983 209:3487 210:2564 211:1130 212:1615 213:1623 214:157 215:39 216:4423 217:1332 218:413 219:449 220:1132 221:443 222:318 End of report From hiersd at gmail.com Fri Oct 2 14:50:40 2009 From: hiersd at gmail.com (David Hiers) Date: Fri, 2 Oct 2009 12:50:40 -0700 Subject: Route to 208.71.177.15, 208.71.179.10 Message-ID: <2873f3700910021250n60deb12cr8d59834792a40076@mail.gmail.com> Is anyone having trouble routing to 208.71.177.15 or 208.71.179.10? Can't get there from 65.59.112.0/24 in Chicago. David From scott.wolfe at cybera.net Fri Oct 2 15:00:36 2009 From: scott.wolfe at cybera.net (Scott Wolfe) Date: Fri, 2 Oct 2009 15:00:36 -0500 Subject: New England Fairpoint Issues Message-ID: <48FAC036AD7B7642BB2944FB9AE674A305C2A8ED@EXCHANGE.nashville.cybera.net> Anyone from Fairpoint on this list know of any issues with DSL subscribers in the New England area? We lost visibility of our customers using Fairpoint, but I'm still receiving routes from our peering partners. Scott Wolfe Cybera, Inc From christopher.j.pilkington at gmail.com Fri Oct 2 15:00:35 2009 From: christopher.j.pilkington at gmail.com (Christopher J. Pilkington) Date: Fri, 2 Oct 2009 16:00:35 -0400 Subject: BGP or MPLS issue AT&T in New York? Message-ID: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> Anyone notice anything bizarre with AT&T in New York? We had our cage at 811 10th Avenue (advertised by AS7018) unreachable from several other providers for about 20 minutes, it just recently came back. At the same time, we lost MPLS service (not link, forwarding across the cloud) at another site with AT&T. Both issues resolved simultaneously. Just curious... Chris From hiersd at gmail.com Fri Oct 2 15:03:02 2009 From: hiersd at gmail.com (David Hiers) Date: Fri, 2 Oct 2009 13:03:02 -0700 Subject: Route to 208.71.177.15, 208.71.179.10 In-Reply-To: References: <2873f3700910021250n60deb12cr8d59834792a40076@mail.gmail.com> Message-ID: <2873f3700910021303u7b1d5240p64578b95cdd98d93@mail.gmail.com> Something seems to be flapping at the IP layer. BGP is steady, but IP reachablity is intermittent, irrespective of using L3 or VZN for out outbound path. David On Fri, Oct 2, 2009 at 12:58 PM, Tatsuya Kawasaki wrote: > We are in DC area, we lost connection to several site including to > India. > > Tatsuya > > > Tatsuya Kawasaki > 703.469.1311 (24x7) > > -----Original Message----- > From: David Hiers [mailto:hiersd at gmail.com] > Sent: Friday, October 02, 2009 3:51 PM > To: nanog at nanog.org > Subject: Route to 208.71.177.15, 208.71.179.10 > > Is anyone having trouble routing to 208.71.177.15 or 208.71.179.10? > > Can't get there from 65.59.112.0/24 in Chicago. > > David > > This electronic message and all attachments transmitted with it may contain confidential and legally privileged information belonging to the sender. ?Please visit http://www.fbrcapitalmarkets.com/disclosures2.asp for important related disclosures, by either following the attached hyperlink or copying and pasting the URL into your internet browser. > > From dstorandt at teljet.com Fri Oct 2 15:06:31 2009 From: dstorandt at teljet.com (David Storandt) Date: Fri, 2 Oct 2009 16:06:31 -0400 Subject: New England Fairpoint Issues In-Reply-To: <48FAC036AD7B7642BB2944FB9AE674A305C2A8ED@EXCHANGE.nashville.cybera.net> References: <48FAC036AD7B7642BB2944FB9AE674A305C2A8ED@EXCHANGE.nashville.cybera.net> Message-ID: We lost our OC3 to Verizon Business in Boston. All of the BGP routes were still flowing to us, causing routing black holes. We had to kill the BGP session on our end. Our VoIP phone provider, based in Boston also with a Verizon Business pipe, also had a call queue that was completely stuffed. Not sure if other providers are affected. On Fri, Oct 2, 2009 at 4:00 PM, Scott Wolfe wrote: > Anyone from Fairpoint on this list know of any issues with DSL > subscribers in the New England area? > > We lost visibility of our customers using Fairpoint, but I'm still > receiving routes from our peering partners. > > Scott Wolfe > Cybera, Inc > > > > -- Dave Storandt CTO TelJet Longhaul LLC 45 Krupp Dr. Williston, VT 05495 802-922-9503 (new DID) 802-238-9596 (cell) dstorandt at teljet.com From scott.wolfe at cybera.net Fri Oct 2 15:07:07 2009 From: scott.wolfe at cybera.net (Scott Wolfe) Date: Fri, 2 Oct 2009 15:07:07 -0500 Subject: New England Fairpoint Issues In-Reply-To: <4AC65CAA.8050101@gmail.com> References: <48FAC036AD7B7642BB2944FB9AE674A305C2A8ED@EXCHANGE.nashville.cybera.net> <4AC65CAA.8050101@gmail.com> Message-ID: <94B4D3FF-B051-4A4A-83B1-0E240D4F9B41@cybera.net> Looks like our sites are back as well. -Scott W On Oct 2, 2009, at 3:04 PM, "Josh Cheney" wrote: > Scott Wolfe wrote: >> Anyone from Fairpoint on this list know of any issues with DSL >> subscribers in the New England area? > > In New England, on a Verizon Business T1 (Fairpoint is the ILEC), > and we just had some connectivity issues that lasted about 30 min. > They seem to be resolved now. > > Josh > -- > Josh Cheney > josh.cheney at gmail.com > http://www.joshcheney.com From tkawasaki at fbr.com Fri Oct 2 15:07:24 2009 From: tkawasaki at fbr.com (Tatsuya Kawasaki) Date: Fri, 2 Oct 2009 16:07:24 -0400 Subject: BGP or MPLS issue AT&T in New York? In-Reply-To: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> Message-ID: We are here in DC with VZ, we lost connection to a few sites including to India. Tatsuya Tatsuya Kawasaki 703.469.1311 (24x7) -----Original Message----- From: Christopher J. Pilkington [mailto:christopher.j.pilkington at gmail.com] Sent: Friday, October 02, 2009 4:01 PM To: nanog at nanog.org Subject: BGP or MPLS issue AT&T in New York? Anyone notice anything bizarre with AT&T in New York? We had our cage at 811 10th Avenue (advertised by AS7018) unreachable from several other providers for about 20 minutes, it just recently came back. At the same time, we lost MPLS service (not link, forwarding across the cloud) at another site with AT&T. Both issues resolved simultaneously. Just curious... Chris This electronic message and all attachments transmitted with it may contain confidential and legally privileged information belonging to the sender. Please visit http://www.fbrcapitalmarkets.com/disclosures2.asp for important related disclosures, by either following the attached hyperlink or copying and pasting the URL into your internet browser. From scott.wolfe at cybera.net Fri Oct 2 15:09:05 2009 From: scott.wolfe at cybera.net (Scott Wolfe) Date: Fri, 2 Oct 2009 15:09:05 -0500 Subject: New England Fairpoint Issues In-Reply-To: References: <48FAC036AD7B7642BB2944FB9AE674A305C2A8ED@EXCHANGE.nashville.cybera.net> Message-ID: Thanks for the update. -Scott W On Oct 2, 2009, at 3:06 PM, "David Storandt" wrote: > We lost our OC3 to Verizon Business in Boston. All of the BGP routes > were still flowing to us, causing routing black holes. We had to kill > the BGP session on our end. > > Our VoIP phone provider, based in Boston also with a Verizon Business > pipe, also had a call queue that was completely stuffed. Not sure if > other providers are affected. > > > On Fri, Oct 2, 2009 at 4:00 PM, Scott Wolfe > wrote: >> Anyone from Fairpoint on this list know of any issues with DSL >> subscribers in the New England area? >> >> We lost visibility of our customers using Fairpoint, but I'm still >> receiving routes from our peering partners. >> >> Scott Wolfe >> Cybera, Inc >> >> >> >> > > > > -- > Dave Storandt > CTO > TelJet Longhaul LLC > 45 Krupp Dr. > Williston, VT 05495 > 802-922-9503 (new DID) > 802-238-9596 (cell) > dstorandt at teljet.com From hiersd at gmail.com Fri Oct 2 15:09:59 2009 From: hiersd at gmail.com (David Hiers) Date: Fri, 2 Oct 2009 13:09:59 -0700 Subject: BGP or MPLS issue AT&T in New York? In-Reply-To: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> References: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> Message-ID: <2873f3700910021309w40d2f04dmd3cc2a5e5b13fa7d@mail.gmail.com> We're getting weird approachability issues on some of out networks, losing IP path without BGP changes. On Fri, Oct 2, 2009 at 1:00 PM, Christopher J. Pilkington wrote: > Anyone notice anything bizarre with AT&T in New York? ?We had our cage > at 811 10th Avenue (advertised by AS7018) unreachable from several > other providers for about 20 minutes, it just recently came back. > > At the same time, we lost MPLS service (not link, forwarding across > the cloud) at another site with AT&T. ?Both issues resolved > simultaneously. > > Just curious... > Chris > > From maillist at webjogger.net Fri Oct 2 15:10:08 2009 From: maillist at webjogger.net (Adam Greene) Date: Fri, 02 Oct 2009 16:10:08 -0400 Subject: BGP or MPLS issue AT&T in New York? In-Reply-To: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> References: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> Message-ID: <4AC65E20.70503@webjogger.net> This just in from outages at outages.org:. Seems to be related to issues a number of people are experiencing ... ------------------------------------------------------------------------ We just opened a ticket with Verizon and were informed of outages for Verizon on East Coast. -----Original Message----- From: outages-bounces at outages.org [mailto:outages-bounces at outages.org] On Behalf Of Joseph Jackson Sent: Friday, October 02, 2009 3:46 PM To: outages at outages.org Subject: [outages] Verizon west coast outage? Anyone seeing packet loss going through .so-6-0-0.xt1.lax7.alter.net for hosts on Verizon but on the East Coast dying? Have a prefix that isn't available if data comes into Verizon on the west coast only. Joseph _______________________________________________ outages mailing list outages at outages.org https://puck.nether.net/mailman/listinfo/outages _______________________________________________ ------------------------------------------------------------------------ On 10/2/2009 4:00 PM, Christopher J. Pilkington wrote: > Anyone notice anything bizarre with AT&T in New York? We had our cage > at 811 10th Avenue (advertised by AS7018) unreachable from several > other providers for about 20 minutes, it just recently came back. > > At the same time, we lost MPLS service (not link, forwarding across > the cloud) at another site with AT&T. Both issues resolved > simultaneously. > > Just curious... > Chris > > > > > From josh.cheney at gmail.com Fri Oct 2 15:03:54 2009 From: josh.cheney at gmail.com (Josh Cheney) Date: Fri, 02 Oct 2009 16:03:54 -0400 Subject: New England Fairpoint Issues In-Reply-To: <48FAC036AD7B7642BB2944FB9AE674A305C2A8ED@EXCHANGE.nashville.cybera.net> References: <48FAC036AD7B7642BB2944FB9AE674A305C2A8ED@EXCHANGE.nashville.cybera.net> Message-ID: <4AC65CAA.8050101@gmail.com> Scott Wolfe wrote: > Anyone from Fairpoint on this list know of any issues with DSL > subscribers in the New England area? In New England, on a Verizon Business T1 (Fairpoint is the ILEC), and we just had some connectivity issues that lasted about 30 min. They seem to be resolved now. Josh -- Josh Cheney josh.cheney at gmail.com http://www.joshcheney.com From kwallace at pcconnection.com Fri Oct 2 15:16:02 2009 From: kwallace at pcconnection.com (Wallace Keith) Date: Fri, 2 Oct 2009 16:16:02 -0400 Subject: BGP or MPLS issue AT&T in New York? In-Reply-To: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> References: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB106864D58@MKA134.pcc.int> -----Original Message----- From: Christopher J. Pilkington [mailto:christopher.j.pilkington at gmail.com] Sent: Friday, October 02, 2009 4:01 PM To: nanog at nanog.org Subject: BGP or MPLS issue AT&T in New York? Anyone notice anything bizarre with AT&T in New York? We had our cage at 811 10th Avenue (advertised by AS7018) unreachable from several other providers for about 20 minutes, it just recently came back. At the same time, we lost MPLS service (not link, forwarding across the cloud) at another site with AT&T. Both issues resolved simultaneously. Just curious... Chris In addition to Verizon Business ip issues, we lost an AT&T private line at the same time, but it has come back up. Fiber cut or power somewhere? This was at 15:17 Eastern.. -Keith From seph at directionless.org Fri Oct 2 15:19:08 2009 From: seph at directionless.org (seph) Date: Fri, 02 Oct 2009 16:19:08 -0400 Subject: Cogent leaking /32s? In-Reply-To: <4AC5E294.9050302@kenweb.org> (ml@kenweb.org's message of "Fri, 02 Oct 2009 07:23:00 -0400") References: <4AC5E294.9050302@kenweb.org> Message-ID: ML writes: > I received an alert from Cyclops telling me a probe in AS513 had seen > a /32 that I announce to Cogent for one of our BGP sessions. > > Did anyone else see this? cyclops alerted me that the /32s my routers use got announced. I'm still tying to figure out what's up. They're not routes I announce, and as far as I can tell, they were announced with a cern next hop. seph From jfalling at g4.net Fri Oct 2 15:22:37 2009 From: jfalling at g4.net (Jeremy Falling) Date: Fri, 02 Oct 2009 16:22:37 -0400 Subject: BGP or MPLS issue AT&T in New York? In-Reply-To: <2873f3700910021309w40d2f04dmd3cc2a5e5b13fa7d@mail.gmail.com> References: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> <2873f3700910021309w40d2f04dmd3cc2a5e5b13fa7d@mail.gmail.com> Message-ID: <1254514957.598.88.camel@localhost> We are in NH and I'm seeing issues with L3 and uunet. BGP seems fine but our customers have having issues connecting to us from other providers. Jeremy On Fri, 2009-10-02 at 13:09 -0700, David Hiers wrote: > We're getting weird approachability issues on some of out networks, > losing IP path without BGP changes. > > > > On Fri, Oct 2, 2009 at 1:00 PM, Christopher J. Pilkington > wrote: > > Anyone notice anything bizarre with AT&T in New York? We had our cage > > at 811 10th Avenue (advertised by AS7018) unreachable from several > > other providers for about 20 minutes, it just recently came back. > > > > At the same time, we lost MPLS service (not link, forwarding across > > the cloud) at another site with AT&T. Both issues resolved > > simultaneously. > > > > Just curious... > > Chris > > > > > From hiersd at gmail.com Fri Oct 2 15:25:41 2009 From: hiersd at gmail.com (David Hiers) Date: Fri, 2 Oct 2009 13:25:41 -0700 Subject: BGP or MPLS issue AT&T in New York? In-Reply-To: <0E8773C725A1674E9F7B35EABB5EEEB106864D58@MKA134.pcc.int> References: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> <0E8773C725A1674E9F7B35EABB5EEEB106864D58@MKA134.pcc.int> Message-ID: <2873f3700910021325l4b517356s5a833d7fe6174c4@mail.gmail.com> We're back up now. On Fri, Oct 2, 2009 at 1:16 PM, Wallace Keith wrote: > > -----Original Message----- > From: Christopher J. Pilkington [mailto:christopher.j.pilkington at gmail.com] > Sent: Friday, October 02, 2009 4:01 PM > To: nanog at nanog.org > Subject: BGP or MPLS issue AT&T in New York? > > Anyone notice anything bizarre with AT&T in New York? ?We had our cage > at 811 10th Avenue (advertised by AS7018) unreachable from several > other providers for about 20 minutes, it just recently came back. > > At the same time, we lost MPLS service (not link, forwarding across > the cloud) at another site with AT&T. ?Both issues resolved > simultaneously. > > Just curious... > Chris > > In addition to Verizon Business ip issues, we lost an AT&T private line at the same time, but it has come back up. Fiber cut or power somewhere? > This was at 15:17 Eastern.. > > -Keith > From peter at peter-dambier.de Fri Oct 2 15:29:33 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Fri, 02 Oct 2009 22:29:33 +0200 Subject: Route to 208.71.177.15, 208.71.179.10 In-Reply-To: <2873f3700910021250n60deb12cr8d59834792a40076@mail.gmail.com> References: <2873f3700910021250n60deb12cr8d59834792a40076@mail.gmail.com> Message-ID: <4AC662AD.8070507@peter-dambier.de> Seen from a dtag.de customer traceroute to 208.71.179.10 (208.71.179.10), 64 hops max, 40 byte packets 1 yttrium.anul.nsa (7.19.30.39) 3 ms 0 ms 0 ms 2 217.0.116.228 (217.0.116.228) 45 ms 47 ms 48 ms 3 217.0.78.58 (217.0.78.58) 46 ms 45 ms 46 ms 4 217.239.40.70 (217.239.40.70) 139 ms 135 ms 136 ms 5 62.156.128.110 (62.156.128.110) 140 ms 137 ms 138 ms 6 sl-crs2-dc-0-1-0-0.sprintlink.net (144.232.19.231) 139 ms sl-crs2-dc-0-13-0-0.sprintlink.net (144.232.25.14) 142 ms 138 ms 7 sl-crs1-atl-0-9-2-0.sprintlink.net (144.232.24.54) 161 ms 160 ms sl-crs2-atl-0-8-0-1.sprintlink.net (144.232.8.160) 160 ms 8 sl-st21-atl-1-0-0.sprintlink.net (144.232.18.135) 157 ms 158 ms sl-st21-atl-0-0-0.sprintlink.net (144.232.20.117) 163 ms 9 sl-xocomm-190550-0.sprintlink.net (144.223.7.110) 156 ms 158 ms 157 ms 10 te-4-1-0.rar3.atlanta-ga.us.xo.net (207.88.12.129) 152 ms 152 ms 153 ms 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) [MPLS: Label 25315 Exp 0] 161 ms 164 ms 159 ms 12 te-3-0-0.rar3.nyc-ny.us.xo.net (207.88.12.73) [MPLS: Label 28026 Exp 0] 165 ms 163 ms 165 ms 13 65.106.1.93.ptr.us.xo.net (65.106.1.93) 161 ms 160 ms 158 ms 14 p0-0-0.MAR2.NYC-NY.us.xo.net (65.106.3.50) 164 ms 163 ms 162 ms 15 p15-0.chr1.nyc-ny.us.xo.net (207.88.86.170) 158 ms 158 ms 163 ms 16 ip65-46-73-34.z73-46-65.customer.algx.net (65.46.73.34) 163 ms 163 ms 160 ms 17 * * * 18 * * * traceroute to 208.71.177.15 (208.71.177.15), 64 hops max, 40 byte packets 1 yttrium.anul.nsa (7.19.30.39) 1 ms 0 ms 0 ms 2 217.0.116.228 (217.0.116.228) 48 ms 46 ms 53 ms 3 217.0.78.54 (217.0.78.54) 47 ms 47 ms 47 ms 4 * f-ea5-i.F.DE.NET.DTAG.DE (62.154.16.161) 49 ms 47 ms 5 te-4-4.car2.Frankfurt1.Level3.net (4.68.110.253) 168 ms 55 ms 56 ms 6 vlan89.csw3.Frankfurt1.Level3.net (4.68.23.190) 56 ms 56 ms 58 ms 7 ae-82-82.ebr2.Frankfurt1.Level3.net (4.69.140.25) 58 ms 57 ms 58 ms 8 ae-44-44.ebr2.Washington1.Level3.net (4.69.137.62) 139 ms ae-41-41.ebr2.Washington1.Level3.net (4.69.137.50) 138 ms ae-42-42.ebr2.Washington1.Level3.net (4.69.137.54) 137 ms 9 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) 136 ms 144 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 144 ms 10 ae-84-84.ebr4.Washington1.Level3.net (4.69.134.185) 145 ms ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 146 ms ae-64-64.ebr4.Washington1.Level3.net (4.69.134.177) 145 ms 11 ae-3-3.ebr1.NewYork1.Level3.net (4.69.132.94) 138 ms 136 ms 138 ms 12 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 146 ms ae-91-91.csw4.NewYork1.Level3.net (4.69.134.78) 139 ms ae-71-71.csw2.NewYork1.Level3.net (4.69.134.70) 147 ms 13 ae-2-79.edge1.NewYork1.Level3.net (4.68.16.78) 137 ms ae-1-69.edge1.NewYork1.Level3.net (4.68.16.14) 202 ms ae-4-99.edge1.NewYork1.Level3.net (4.68.16.206) 140 ms 14 PEER-1-NETW.edge1.NewYork1.Level3.net (4.78.132.66) 139 ms 138 ms 138 ms 15 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 138 ms 136 ms 136 ms 16 10ge.xe-0-0-0.nyc-telx-dis-1.peer1.net (216.187.115.165) 139 ms 138 ms 138 ms 17 64.34.62.4 (64.34.62.4) 139 ms 146 ms 140 ms 18 * * * 19 * * * No, I cannot see them either. Peter David Hiers wrote: > Is anyone having trouble routing to 208.71.177.15 or 208.71.179.10? > > Can't get there from 65.59.112.0/24 in Chicago. > > David -- 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 at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From m.hallgren at free.fr Fri Oct 2 15:35:41 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Fri, 02 Oct 2009 22:35:41 +0200 Subject: Cogent leaking /32s? In-Reply-To: <580af3b90910020854n223f5e34pea6ef3c0b8826214@mail.gmail.com> References: <4AC5E294.9050302@kenweb.org> <580af3b90910020854n223f5e34pea6ef3c0b8826214@mail.gmail.com> Message-ID: <1254515741.14249.80.camel@home> Le vendredi 02 octobre 2009 ? 10:54 -0500, Clue Store a ?crit : > Yes, I absolutely love the /24 filtering "everybody" does. Internet > littering at its best. > > http://thyme.apnic.net/current/data-badpfx-nos Yes, nice... mh > Clue > On Fri, Oct 2, 2009 at 10:36 AM, Mikael Abrahamsson wrote: > > > On Fri, 2 Oct 2009, ML wrote: > > > > I received an alert from Cyclops telling me a probe in AS513 had seen a /32 > >> that I announce to Cogent for one of our BGP sessions. > >> > >> Did anyone else see this? > >> > > > > Are you relying on the /24 filtering "everybody" does, or did you announce > > it to them with NO-EXPORT set? > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From m.hallgren at free.fr Fri Oct 2 15:37:32 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Fri, 02 Oct 2009 22:37:32 +0200 Subject: Cogent leaking /32s? In-Reply-To: <4AC623C3.7090408@ieee.org> References: <4AC5E294.9050302@kenweb.org> <872A476DA517EE428312FB7D5FF284BA4FF7AD@rstexchange02.yellowfiber.net> <4AC623C3.7090408@ieee.org> Message-ID: <1254515852.14249.82.camel@home> Le vendredi 02 octobre 2009 ? 11:01 -0500, Alex H. Ryu a ?crit : > If there is DDoS attack going on from/to specific /32, sometimes they do > that to avoid too much overload for the network. > Cogent should give the answer for what's going on. Generally, such is kept in-AS (null-routing or routing to some other sink of choice). mh > > Alex > > Zak Thompson wrote: > > We had a problem with cogent about a year ago. Somehow.. cymru was > > announcing a /32 of ours and black holing it for whatever reason. It > > was removed but wasn't happy that cogent was allowing cymru to do this > > sort of action. To this date we do not have a valid reason from cogent > > on why they allowed this to happen. > > > > Cheers, > > Zak Thompson > > > > > > > > -----Original Message----- > > From: ML [mailto:ml at kenweb.org] > > Sent: Friday, October 02, 2009 7:23 AM > > To: nanog at nanog.org > > Subject: Cogent leaking /32s? > > > > I received an alert from Cyclops telling me a probe in AS513 had seen a > > /32 that I announce to Cogent for one of our BGP sessions. > > > > Did anyone else see this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From seph at directionless.org Fri Oct 2 15:48:27 2009 From: seph at directionless.org (seph) Date: Fri, 02 Oct 2009 16:48:27 -0400 Subject: Cogent leaking /32s? In-Reply-To: (seph@directionless.org's message of "Fri, 02 Oct 2009 16:19:08 -0400") References: <4AC5E294.9050302@kenweb.org> Message-ID: I called cogent. Best guess is that they leaked the /32 announcements that people do for the peer a/b stuff. They normally filter them, and don't have any recommendation about whether or not to set no export. seph seph writes: > ML writes: > >> I received an alert from Cyclops telling me a probe in AS513 had seen >> a /32 that I announce to Cogent for one of our BGP sessions. >> >> Did anyone else see this? > > cyclops alerted me that the /32s my routers use got announced. I'm still > tying to figure out what's up. They're not routes I announce, and as far > as I can tell, they were announced with a cern next hop. > > seph From cidr-report at potaroo.net Fri Oct 2 17:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Oct 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200910022200.n92M01Or079117@wattle.apnic.net> BGP Update Report Interval: 24-Sep-09 -to- 01-Oct-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 45161 3.3% 118.2 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS9531 28945 2.1% 5789.0 -- GEDU-AS-KR Kwangju City Office Of Education 3 - AS6298 27085 2.0% 49.5 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 4 - AS35805 19455 1.4% 44.2 -- UTG-AS United Telecom AS 5 - AS8452 13685 1.0% 13.8 -- TEDATA TEDATA 6 - AS1659 11291 0.8% 34.4 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 7 - AS17488 9677 0.7% 6.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 8 - AS6389 8046 0.6% 1.9 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 9 - AS4323 7738 0.6% 1.8 -- TWTC - tw telecom holdings, inc. 10 - AS24863 7552 0.6% 8.0 -- LINKdotNET-AS 11 - AS29049 7334 0.5% 24.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 12 - AS9829 6764 0.5% 8.3 -- BSNL-NIB National Internet Backbone 13 - AS17819 6609 0.5% 48.6 -- ASN-EQUINIX-AP Equinix Asia Pacific 14 - AS7552 6291 0.5% 20.4 -- VIETEL-AS-AP Vietel Corporation 15 - AS5050 6165 0.5% 362.6 -- PSC-EXT - Pittsburgh Supercomputing Center 16 - AS12479 6025 0.4% 13.5 -- UNI2-AS Uni2 Autonomous System 17 - AS8151 5935 0.4% 4.0 -- Uninet S.A. de C.V. 18 - AS7018 5913 0.4% 3.9 -- ATT-INTERNET4 - AT&T WorldNet Services 19 - AS680 5664 0.4% 20.8 -- DFN-IP service X-WiN 20 - AS4249 5620 0.4% 30.9 -- LILLY-AS - Eli Lilly and Company TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9531 28945 2.1% 5789.0 -- GEDU-AS-KR Kwangju City Office Of Education 2 - AS48728 4236 0.3% 1059.0 -- VODAFONEQATAR Vodafone Qatar Q.S.C. 3 - AS49517 1615 0.1% 807.5 -- TEIKHOS-AS Teikhos 4 - AS43880 787 0.1% 787.0 -- LITECH-AS Laboratory of Information Technologies LLC 5 - AS26414 535 0.0% 535.0 -- LVCINT - LVC International, LLC 6 - AS3 472 0.0% 143.0 -- MINDSPEED-AS Mindspeed Technologies Ukraine LLC 7 - AS44194 471 0.0% 471.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 8 - AS38467 390 0.0% 390.0 -- DBAMOYLAN-TRANSIT-AS-AP DBA Moylan 9 - AS8668 2572 0.2% 367.4 -- TELONE-AS TelOne Zimbabwe P/L 10 - AS5050 6165 0.5% 362.6 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - AS30969 5332 0.4% 333.2 -- TAN-NET TransAfrica Networks 12 - AS37077 312 0.0% 312.0 -- AAUN-NG 13 - AS48106 284 0.0% 284.0 -- VLAN-AS SPD Kirichok 14 - AS16309 266 0.0% 266.0 -- EEA-AS SPD Efendeev AS 15 - AS32666 1058 0.1% 264.5 -- CWRU-AS-1 - Case Western Reserve University 16 - AS43864 252 0.0% 252.0 -- INTEGRA-MEDIA-AS Integra-Media Ltd 17 - AS36239 249 0.0% 249.0 -- EXIGEN-CANADA - Exigen Canada 18 - AS36979 223 0.0% 223.0 -- FBN-AS 19 - AS38510 223 0.0% 223.0 -- DEPTAN-AS-ID DEPARTEMEN PERTANIAN REPUBLIK INDONESIA 20 - AS22917 1278 0.1% 213.0 -- INFOCHANNEL - InfoChannel Ltd. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 6115 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 210.218.64.0/19 5789 0.4% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 3 - 211.253.68.0/22 5789 0.4% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 4 - 211.253.72.0/21 5789 0.4% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 5 - 210.217.224.0/19 5789 0.4% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 6 - 210.218.0.0/18 5789 0.4% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 7 - 88.204.221.0/24 5005 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 95.59.1.0/24 4967 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 89.218.218.0/23 4873 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 89.218.220.0/23 4869 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - 95.59.2.0/23 4865 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 12 - 95.59.4.0/22 4861 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 13 - 92.46.244.0/23 4860 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 14 - 95.59.3.0/24 4856 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 15 - 95.59.8.0/23 4855 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 16 - 84.1.45.0/24 3066 0.2% AS41313 -- NOVATEL-AS Novatel Bulgaria 17 - 192.12.120.0/24 2520 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 18 - 85.60.208.0/21 2445 0.2% AS12479 -- UNI2-AS Uni2 Autonomous System 19 - 202.177.223.0/24 2323 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 20 - 85.60.208.0/22 2316 0.2% AS12479 -- UNI2-AS Uni2 Autonomous System Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 2 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Oct 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200910022200.n92M00Vn079110@wattle.apnic.net> This report has been generated at Fri Oct 2 21:11:14 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-09-09 304228 184042 26-09-09 304528 184193 27-09-09 304266 184691 28-09-09 304424 184785 29-09-09 304436 185224 30-09-09 304636 185372 01-10-09 304812 185629 02-10-09 304773 186030 AS Summary 32456 Number of ASes in routing system 13810 Number of ASes announcing only one prefix 4305 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89615104 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 02Oct09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 304879 185978 118901 39.0% All ASes AS6389 4164 325 3839 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4305 1681 2624 61.0% TWTC - tw telecom holdings, inc. AS4766 1881 580 1301 69.2% KIXS-AS-KR Korea Telecom AS17488 1475 283 1192 80.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1062 10 1052 99.1% COVAD - Covad Communications Co. AS22773 1111 75 1036 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1758 816 942 53.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1479 570 909 61.5% Uninet S.A. de C.V. AS4755 1256 392 864 68.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18101 979 129 850 86.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1034 230 804 77.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS10620 1015 213 802 79.0% TV Cable S.A. AS6478 1413 624 789 55.8% ATT-INTERNET3 - AT&T WorldNet Services AS8452 981 269 712 72.6% TEDATA TEDATA AS3356 1228 522 706 57.5% LEVEL3 Level 3 Communications AS4804 680 90 590 86.8% MPX-AS Microplex PTY LTD AS4808 762 188 574 75.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 773 205 568 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 651 99 552 84.8% Telecom Argentina S.A. AS9498 649 107 542 83.5% BBIL-AP BHARTI Airtel Ltd. AS11492 1131 590 541 47.8% CABLEONE - CABLE ONE, INC. AS22047 545 18 527 96.7% VTR BANDA ANCHA S.A. AS7018 1523 1055 468 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS17908 496 58 438 88.3% TCISL Tata Communications AS17676 562 125 437 77.8% GIGAINFRA Softbank BB Corp. AS5668 799 364 435 54.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS4780 563 144 419 74.4% SEEDNET Digital United Inc. AS28573 759 350 409 53.9% NET Servicos de Comunicao S.A. AS7011 1023 616 407 39.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7738 427 29 398 93.2% Telecomunicacoes da Bahia S.A. Total 36484 10757 25727 70.5% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.72.112.0/20 AS19166 66.6.80.0/20 AS23350 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 74.120.160.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.161.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.162.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.163.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.164.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.165.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.166.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.167.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.168.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.169.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.170.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.171.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.172.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.173.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.174.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.175.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 78.152.32.0/19 AS5580 ATRATOIP-AS Atrato IP Networks 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 96.8.127.0/24 AS19166 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 186.8.64.0/18 AS19422 Telefonica Moviles del Uruguay SA 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 193.34.199.0/24 AS20686 BISPING Bisping & Bisping GmbH & Co. KG 196.6.108.0/24 AS5713 SAIX-NET 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.162.0/24 AS4841 202.140.168.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK Wind International Services SA (previously known as M-LINK) 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.24.192.0/20 AS10397 SINGLEPIPE - SinglePipe Communications, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ras at e-gerbil.net Fri Oct 2 17:17:47 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 2 Oct 2009 17:17:47 -0500 Subject: Cogent leaking /32s? In-Reply-To: <580af3b90910020854n223f5e34pea6ef3c0b8826214@mail.gmail.com> References: <4AC5E294.9050302@kenweb.org> <580af3b90910020854n223f5e34pea6ef3c0b8826214@mail.gmail.com> Message-ID: <20091002221747.GW51443@gerbil.cluepon.net> On Fri, Oct 02, 2009 at 10:54:13AM -0500, Clue Store wrote: > Yes, I absolutely love the /24 filtering "everybody" does. Internet > littering at its best. > > http://thyme.apnic.net/current/data-badpfx-nos There is no rule that says you have to filter at /24, or that no other network may ever advertise something longer. This issue is probably best expressed as "you are highly unlikely to have full global Internet reachability if you announce something longer than a /24", not "you are highly unlikely to have anyone accept your announcement if it are longer than a /24". -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sethm at rollernet.us Fri Oct 2 18:29:25 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 02 Oct 2009 16:29:25 -0700 Subject: Minimum IPv6 size Message-ID: <4AC68CD5.2070909@rollernet.us> Since we're on the topic of what's commonly accepted in IPv4 land (a /24), what's the story in IPv6 land? It seems to me that a /32 is a fur sure thing, but others will accept down to a /48, too. ~Seth From oberman at es.net Fri Oct 2 18:43:14 2009 From: oberman at es.net (Kevin Oberman) Date: Fri, 02 Oct 2009 16:43:14 -0700 Subject: Minimum IPv6 size In-Reply-To: Your message of "Fri, 02 Oct 2009 16:29:25 PDT." <4AC68CD5.2070909@rollernet.us> Message-ID: <20091002234314.695091CC0E@ptavv.es.net> > Date: Fri, 02 Oct 2009 16:29:25 -0700 > From: Seth Mattinen > > Since we're on the topic of what's commonly accepted in IPv4 land (a > /24), what's the story in IPv6 land? It seems to me that a /32 is a fur > sure thing, but others will accept down to a /48, too. Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be "legal": /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From cabenth at gmail.com Fri Oct 2 19:02:18 2009 From: cabenth at gmail.com (eric clark) Date: Fri, 2 Oct 2009 17:02:18 -0700 Subject: BGP or MPLS issue AT&T in New York? In-Reply-To: <2873f3700910021325l4b517356s5a833d7fe6174c4@mail.gmail.com> References: <6004a3f50910021300n7b4e7930l936b288dfc05b48@mail.gmail.com> <0E8773C725A1674E9F7B35EABB5EEEB106864D58@MKA134.pcc.int> <2873f3700910021325l4b517356s5a833d7fe6174c4@mail.gmail.com> Message-ID: <5b602b520910021702o6da3677frb8c98fa271cab7b3@mail.gmail.com> A friend of mine has services on through yieldbook (in new York) that he accesses from Santa Barbara. He noticed he couldn't get to them around 2pm via his Cox cable inet link, dieing after gar9.n54ny.ip.AT&T.net (12.122.131.245), but from his Verizon link, he had no issues. The problem persists currently. On Friday, October 2, 2009, David Hiers wrote: > We're back up now. > > > > On Fri, Oct 2, 2009 at 1:16 PM, Wallace Keith wrote: >> >> -----Original Message----- >> From: Christopher J. Pilkington [mailto:christopher.j.pilkington at gmail.com] >> Sent: Friday, October 02, 2009 4:01 PM >> To: nanog at nanog.org >> Subject: BGP or MPLS issue AT&T in New York? >> >> Anyone notice anything bizarre with AT&T in New York? ?We had our cage >> at 811 10th Avenue (advertised by AS7018) unreachable from several >> other providers for about 20 minutes, it just recently came back. >> >> At the same time, we lost MPLS service (not link, forwarding across >> the cloud) at another site with AT&T. ?Both issues resolved >> simultaneously. >> >> Just curious... >> Chris >> >> In addition to Verizon Business ip issues, we lost an AT&T private line at the same time, but it has come back up. Fiber cut or power somewhere? >> This was at 15:17 Eastern.. >> >> -Keith >> > > From owen at delong.com Fri Oct 2 21:02:40 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Oct 2009 19:02:40 -0700 Subject: Minimum IPv6 size In-Reply-To: <4AC68CD5.2070909@rollernet.us> References: <4AC68CD5.2070909@rollernet.us> Message-ID: <02FFE0A3-E540-4346-BE9A-EA7BB5C71110@delong.com> Given that ARIN issues /48s to multihomed end users, I think it would be wise to accept them. Owen On Oct 2, 2009, at 4:29 PM, Seth Mattinen wrote: > Since we're on the topic of what's commonly accepted in IPv4 land (a > /24), what's the story in IPv6 land? It seems to me that a /32 is a > fur > sure thing, but others will accept down to a /48, too. > > ~Seth From sethm at rollernet.us Fri Oct 2 21:08:55 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 02 Oct 2009 19:08:55 -0700 Subject: Minimum IPv6 size In-Reply-To: <02FFE0A3-E540-4346-BE9A-EA7BB5C71110@delong.com> References: <4AC68CD5.2070909@rollernet.us> <02FFE0A3-E540-4346-BE9A-EA7BB5C71110@delong.com> Message-ID: <4AC6B237.6040507@rollernet.us> Owen DeLong wrote: > Given that ARIN issues /48s to multihomed end users, I think it would > be wise to accept them. > True, although 2620:0::/23 is still a black hole for some. When did ARIN start using it, 2007? ~Seth From sethm at rollernet.us Fri Oct 2 22:33:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 02 Oct 2009 20:33:20 -0700 Subject: Help: Verizon Account Manager Message-ID: <4AC6C600.5010704@rollernet.us> This isn't an IP-related call for help, but hopefully someone on here from Verizon is listening or knows someone who can help me. On May 5 I was in touch with account manager J from Verizon who quoted me and set me up with an Ethernet-delivered circuit. The order was placed with implementations manager N. Somewhere during the time it took them between May and July to install the fiber, N dropped off the face of the earth. I asked J WTF is going on and I was put in touch with new implementations manager B who actually managed to finish the job. Turn up time came and - guess what - someone had failed to enter the details of the order (or whatever) between May and August and I didn't get what I ordered. So I tried to call J. Surprise, J's number goes to someone totally different. Many weeks of confusing calls later I finally managed to find J's boss (which is fun because I'm not an active customer yet) and confirmed that J is not there anymore somewhere between Sept 4 and Sept 6. He gave me contact info for my supposed replacement, but they have yet to answer or return even one of my daily calls for a week. I did get a survey for my not-install, gave it horrible marks and checked "please contact me", but nobody has. I've tried every phone number and email address I can get my hands on for the last month with no results. I don't have an account manager. Can anyone help? ~Seth From ml at kenweb.org Fri Oct 2 22:36:45 2009 From: ml at kenweb.org (ML) Date: Fri, 02 Oct 2009 23:36:45 -0400 Subject: Cogent leaking /32s? In-Reply-To: <20091002221747.GW51443@gerbil.cluepon.net> References: <4AC5E294.9050302@kenweb.org> <580af3b90910020854n223f5e34pea6ef3c0b8826214@mail.gmail.com> <20091002221747.GW51443@gerbil.cluepon.net> Message-ID: <4AC6C6CD.10508@kenweb.org> Richard A Steenbergen wrote: > On Fri, Oct 02, 2009 at 10:54:13AM -0500, Clue Store wrote: >> Yes, I absolutely love the /24 filtering "everybody" does. Internet >> littering at its best. >> >> http://thyme.apnic.net/current/data-badpfx-nos > > There is no rule that says you have to filter at /24, or that no other > network may ever advertise something longer. This issue is probably best > expressed as "you are highly unlikely to have full global Internet > reachability if you announce something longer than a /24", not "you are > highly unlikely to have anyone accept your announcement if it are longer > than a /24". > Just to clarify it was a /32 for Cogent A/B peering. When I set it up they didn't recommend setting no-export. From randy at psg.com Fri Oct 2 22:54:44 2009 From: randy at psg.com (Randy Bush) Date: Sat, 03 Oct 2009 12:54:44 +0900 Subject: Help: Verizon Account Manager In-Reply-To: <4AC6C600.5010704@rollernet.us> References: <4AC6C600.5010704@rollernet.us> Message-ID: > On May 5 I was in touch with account manager J from Verizon who quoted > me and set me up with an Ethernet-delivered circuit. The order was > placed with implementations manager N. Somewhere during the time it took > them between May and July to install the fiber, N dropped off the face > of the earth. I asked J WTF is going on and I was put in touch with new > implementations manager B who actually managed to finish the job. Turn > up time came and - guess what - someone had failed to enter the details > of the order (or whatever) between May and August and I didn't get what > I ordered. So I tried to call J. Surprise, J's number goes to someone > totally different. Many weeks of confusing calls later I finally managed > to find J's boss (which is fun because I'm not an active customer yet) > and confirmed that J is not there anymore somewhere between Sept 4 and > Sept 6. He gave me contact info for my supposed replacement, but they > have yet to answer or return even one of my daily calls for a week. I > did get a survey for my not-install, gave it horrible marks and checked > "please contact me", but nobody has. I've tried every phone number and > email address I can get my hands on for the last month with no results. > > I don't have an account manager. Can anyone help? what does route views say? randy From henry at AegisInfoSys.com Sat Oct 3 00:36:16 2009 From: henry at AegisInfoSys.com (Henry Yen) Date: Sat, 3 Oct 2009 01:36:16 -0400 Subject: [trivial] anyone at gblx with email clue? Message-ID: <20091003013616.V2401@AegisInfoSys.com> Extract: > This is the Postfix program at host sec.phx.gblx.net. > > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > The Postfix program > > : can't create user output file > > --4F8461C0F1.1254547841/sec.phx.gblx.net > Content-Description: Delivery report > Content-Type: message/delivery-status > > Reporting-MTA: dns; sec.phx.gblx.net > X-Postfix-Queue-ID: 4F8461C0F1 > X-Postfix-Sender: rfc822; henry at AegisInfoSys.com > Arrival-Date: Fri, 2 Oct 2009 22:30:41 -0700 (MST) > > Final-Recipient: rfc822; abuse at sec.phx.gblx.net > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; can't create user output file > > --4F8461C0F1.1254547841/sec.phx.gblx.net > Content-Description: Undelivered Message > Content-Type: message/rfc822 > > Received: from smtp1.phx.gblx.net (smtp1.phx.gblx.net [64.208.25.103]) > by sec.phx.gblx.net (Postfix) with ESMTP id 4F8461C0F1 > for ; Fri, 2 Oct 2009 22:30:41 -0700 (MST) > Received: (from daemon at localhost) > by smtp1.phx.gblx.net (8.11.2/8.11.2) id n935Ufr02845 > for ; Sat, 3 Oct 2009 05:30:41 GMT -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From morrowc.lists at gmail.com Sat Oct 3 01:03:37 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 3 Oct 2009 02:03:37 -0400 Subject: Help: Verizon Account Manager In-Reply-To: References: <4AC6C600.5010704@rollernet.us> Message-ID: <75cb24520910022303o26fb6242y5495796de936d928@mail.gmail.com> On Fri, Oct 2, 2009 at 11:54 PM, Randy Bush wrote: >> On May 5 I was in touch with account manager J from Verizon who quoted >> I don't have an account manager. Can anyone help? is this for 19262 type services? 701-type services? private services? you may have luck, for 701-type services, with the generic support number... for the others I don't know :( 19262 is horrendous for customer support experiences (for me and everyone else i know that has to deal with it) > what does route views say? :) 'no route to sales folk' I never had good luck,m as an employee trying to bring business in, in getting sales folk to help me... i doubt it's changed drastically since then. -chris From sethm at rollernet.us Sat Oct 3 01:18:58 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 02 Oct 2009 23:18:58 -0700 Subject: Help: Verizon Account Manager In-Reply-To: <75cb24520910022303o26fb6242y5495796de936d928@mail.gmail.com> References: <4AC6C600.5010704@rollernet.us> <75cb24520910022303o26fb6242y5495796de936d928@mail.gmail.com> Message-ID: <4AC6ECD2.8020508@rollernet.us> Christopher Morrow wrote: > On Fri, Oct 2, 2009 at 11:54 PM, Randy Bush wrote: >>> On May 5 I was in touch with account manager J from Verizon who quoted >>> I don't have an account manager. Can anyone help? > > is this for 19262 type services? 701-type services? private services? > > you may have luck, for 701-type services, with the generic support > number... for the others I don't know :( 19262 is horrendous for > customer support experiences (for me and everyone else i know that has > to deal with it) It's 701. Trying to add them to my upstream mix, nothing exciting or exotic. Calling the generic number is like they spin a wheel to transfer me to someone who wonders how in the world I got their number, if they pick up. >> what does route views say? > > :) 'no route to sales folk' > > I never had good luck,m as an employee trying to bring business in, in > getting sales folk to help me... i doubt it's changed drastically > since then. > My next tactic is to have some friends who have time on their hands to call them every day until someone is able to help. ~Seth From jhma at mcvax.org Sat Oct 3 03:27:27 2009 From: jhma at mcvax.org (James Aldridge) Date: Sat, 03 Oct 2009 09:27:27 +0100 Subject: Minimum IPv6 size In-Reply-To: <20091002234314.695091CC0E@ptavv.es.net> References: <20091002234314.695091CC0E@ptavv.es.net> Message-ID: <8D752E651844BEF62C9B02C9@dhcp-194.ripeadm.ripe.net> --On 2 October 2009 16:43:14 -0700 Kevin Oberman wrote: > Depends on the address space it is assigned from. Most specify a maximum > prefix length of 32, but the micro-allocations and the allocations for > PI dual-homing are /48. > We consider the following to be "legal": > /* global unicast allocations */ > route-filter 2001::/16 prefix-length-range /19-/35; > /* 6to4 prefix */ > route-filter 2002::/16 prefix-length-range /16-/16; > /* RIPE allocations */ > route-filter 2003::/18 prefix-length-range /19-/32; > /* APNIC allocations */ > route-filter 2400::/12 prefix-length-range /13-/32; > /* ARIN allocations */ > route-filter 2600::/12 prefix-length-range /13-/32; > /* ARIN allocations */ > route-filter 2610::/23 prefix-length-range /24-/32; > /* LACNIC allocations */ > route-filter 2800::/12 prefix-length-range /13-/32; > /* RIPE allocations */ > route-filter 2A00::/12 prefix-length-range /13-/32; > /* AfriNIC allocations */ > route-filter 2C00::/12 prefix-length-range /13-/32; > /* APNIC PI allocations */ > route-filter 2001:0DF0::/29 prefix-length-range /40-/48; > /* AFRINIC PI allocations */ > route-filter 2001:43F8::/29 prefix-length-range /40-/48; > /* ARIN PI allocations */ > route-filter 2620::/23 prefix-length-range /40-/48; > /* ARIN Micro-allocations */ > route-filter 2001:0500::/24 prefix-length-range /44-/48; > > This means accepting prefixes ARIN says we should not, but ARIN does not > set our routing policy and I will be on a panel on that issue at NANOG in > Dearborn later this month. It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) James From leo.vegoda at icann.org Sat Oct 3 05:01:42 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sat, 3 Oct 2009 03:01:42 -0700 Subject: Minimum IPv6 size In-Reply-To: <8D752E651844BEF62C9B02C9@dhcp-194.ripeadm.ripe.net> References: <20091002234314.695091CC0E@ptavv.es.net> <8D752E651844BEF62C9B02C9@dhcp-194.ripeadm.ripe.net> Message-ID: On Oct 3, 2009, at 1:28 AM, "James Aldridge" wrote: [...] > It might be worth relaxing filtering within 2001::/16. The RIPE NCC > appears to be making /48 PI assignments from within 2001:678::/29 > (e.g. the > RIPE Meeting next week will be using 2001:67c:64::/48) Why the whole /16 rather than just that /29 and a few other blocks set aside for /48s? There are a lot of /48s in a /16, so protecting against someone accidentally deaggregating their allocated /32 into / 48s seems legitimate. Regards, Leo From jhma at mcvax.org Sat Oct 3 07:58:21 2009 From: jhma at mcvax.org (James Aldridge) Date: Sat, 03 Oct 2009 13:58:21 +0100 Subject: Minimum IPv6 size In-Reply-To: References: <20091002234314.695091CC0E@ptavv.es.net> <8D752E651844BEF62C9B02C9@dhcp-194.ripeadm.ripe.net> Message-ID: <3E095B25DFDA9BCE52F9793E@dhcp-194.ripeadm.ripe.net> --On 3 October 2009 03:01:42 -0700 Leo Vegoda wrote: > On Oct 3, 2009, at 1:28 AM, "James Aldridge" wrote: >> It might be worth relaxing filtering within 2001::/16. The RIPE NCC >> appears to be making /48 PI assignments from within 2001:678::/29 >> (e.g. the >> RIPE Meeting next week will be using 2001:67c:64::/48) > > Why the whole /16 rather than just that /29 and a few other blocks set > aside for /48s? There are a lot of /48s in a /16, so protecting > against someone accidentally deaggregating their allocated /32 into / > 48s seems legitimate. Indeed. By "within 2001::/16" I was just pointing out that, not having the definitive list, there were some blocks "within 2001::/16" which require a longer prefix. James From brandon at rd.bbc.co.uk Sat Oct 3 08:52:19 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 3 Oct 2009 14:52:19 +0100 (BST) Subject: Minimum IPv6 size Message-ID: <200910031352.OAA05408@sunf10.rd.bbc.co.uk> > > It might be worth relaxing filtering within 2001::/16. The RIPE NCC > > appears to be making /48 PI assignments from within 2001:678::/29 > > (e.g. the > > RIPE Meeting next week will be using 2001:67c:64::/48) > > Why the whole /16 rather than just that /29 and a few other blocks set > aside for /48s? Indeed, and why jumble these up, there's enough space to keep different allocation types separate and have no confusion with just a few trivial filters, universally deployed, which I suggest is the only way to stop degeneration. If one ISP deviates it creates pressure on others to accept the same. Then we're heading for another v4 mess as people will continuously push the boundary. > There are a lot of /48s in a /16, so protecting > against someone accidentally deaggregating their allocated /32 into / > 48s seems legitimate. And some will deaggregate to protect against others advertising more specifics brandon From rsk at gsp.org Sat Oct 3 10:11:46 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 3 Oct 2009 11:11:46 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <75cb24520909151822j5d833b3byadd05b585a5a3543@mail.gmail.com> References: <4AAFAC5C.8040008@gmail.com> <30570.1253046202@turing-police.cc.vt.edu> <75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com> <1A445928-4413-463D-B438-FF4C19BE8B40@zaidali.com> <75cb24520909151822j5d833b3byadd05b585a5a3543@mail.gmail.com> Message-ID: <20091003151146.GA25418@gsp.org> On Tue, Sep 15, 2009 at 09:22:02PM -0400, Christopher Morrow wrote: > > build expertise on managing it. If you go to SpamHaus you will see a major > > ISP and their netblocks listed and associated with known spammers. What is > > this ISP doing about this? Nothing! ?My guess is that they look at their > > 'nothing' that you can see? or nothing? or something you can't see or > that's taking longer than you'd expect/like? There certainly are bad > actors out there, but I think the majority are doing things to keep > clean, perhaps not in the manner you would like (or the speed you > would like or with as much public information as you'd like). [ engage cynical mode] It's the responsibilty of all operations to ensure that they're not persistent or egregious sources of abuse. *Some* operations handle that reasonably well, but unfortunately many do not -- which is why there are now hundreds of blacklists (of varying intent, design, operation, and so on). If ISPs et.al. were doing their jobs properly, there would be no need for any of these to exist. But they're not, which is why so many people have taken the time and trouble to create them. Overall ISP performance in re abuse handling is miserable and has been for many years, and that includes everything from a lack of even perfunctory due diligence ("30 seconds with Google") to failure to handle the abuse role address properly and promptly to alarming naivete' ("what did you THINK they were doing with an entire /24 full of nonsense domain names?") to deployment of "anti-spam" measures that make the problem worse and inflict abuse on third parties to... This is hardly surprising: there are few, if any, consequences for doing so, and of course it's far more profitable to not just turn a blind eye to abuse (which used to be common) but moreso these days to actively assist in it with a smile and a wink and a hand extended for the payoff, while simultaneously making a public show of "deep concern" and issuing press releases that say "We take the X problem seriously..." and participating in working groups that studiously avoid the actual problems -- or better yet, which invite well-known/long-time abusers to have a seat at the table. ---Rsk From bicknell at ufp.org Sat Oct 3 14:35:03 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 3 Oct 2009 12:35:03 -0700 Subject: Minimum IPv6 size In-Reply-To: References: <20091002234314.695091CC0E@ptavv.es.net> <8D752E651844BEF62C9B02C9@dhcp-194.ripeadm.ripe.net> Message-ID: <20091003193503.GA88477@ussenterprise.ufp.org> In a message written on Sat, Oct 03, 2009 at 03:01:42AM -0700, Leo Vegoda wrote: > Why the whole /16 rather than just that /29 and a few other blocks set > aside for /48s? There are a lot of /48s in a /16, so protecting > against someone accidentally deaggregating their allocated /32 into / > 48s seems legitimate. Our track record of keeping up with these lists as in industry in IPv4 is pretty poor, I see no reason to think IPv6 is any better. The more restrictive, the greater the chance of inadvertently filtering something you should not. The problem of a peer deaggregating too many routes to you is better handled with max-prefix settings. We've had this technology for a long time, and if you're really concerned about getting an extra 10k routes from a peer use max-prefix, not some draconian, static, never updated prefix filter. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From ge at linuxbox.org Sat Oct 3 14:41:46 2009 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 03 Oct 2009 21:41:46 +0200 Subject: Dutch ISPs to collaborate and take responsibility for botted clients Message-ID: <4AC7A8FA.80007@linuxbox.org> The story is covered by PC mag: ------- ... major Dutch ISPs have agreed to share information and establish a common set of rules for responding to users infected with malware, especially those in botnets. The agreement, called a "treaty" by locals, involves 14 ISPs covering 98% of the market. A major reason ISPs are hesitant to take deliberate measures against such systems is that they are afraid that disconnecting users and making them spend time and money cleaning up their systems will only drive them into the hands of competitors. And the support process itself is expensive, probably wiping out the profit from that user. But with such high coverage of the market users may not have permissive alternatives. This will be an interesting phenomenon to watch. If it is successful perhaps it could work here too." ------- I couldn't find the story in English in a version that did not link to my original post, I waited a few days to see if anyone else picks it up, as I don't want yet another self-promotion fight. No one I found in under 2 minutes on Google did, so this second-hand link should do. http://blogs.pcmag.com/securitywatch/2009/09/dutch_isps_sign_anti-botnet_tr.php Enjoy, Gadi. From Shawn.Somers at gmail.com Sat Oct 3 15:37:09 2009 From: Shawn.Somers at gmail.com (Shawn Somers) Date: Sat, 03 Oct 2009 13:37:09 -0700 Subject: Request for Contact Message-ID: <4AC7B5F5.8050603@gmail.com> Can an EchoStar admin contact Me off-list? I'm seeing a routing loop at ECHOSTAR.edge1.SaltLakeCity1.Level3.net Shawn Somers (425) 405-0263 From oberman at es.net Sat Oct 3 16:01:18 2009 From: oberman at es.net (Kevin Oberman) Date: Sat, 03 Oct 2009 14:01:18 -0700 Subject: Minimum IPv6 size In-Reply-To: Your message of "Sat, 03 Oct 2009 09:27:27 BST." <8D752E651844BEF62C9B02C9@dhcp-194.ripeadm.ripe.net> Message-ID: <20091003210118.4F5981CC0E@ptavv.es.net> > Date: Sat, 03 Oct 2009 09:27:27 +0100 > From: James Aldridge > > --On 2 October 2009 16:43:14 -0700 Kevin Oberman wrote: > > Depends on the address space it is assigned from. Most specify a maximum > > prefix length of 32, but the micro-allocations and the allocations for > > PI dual-homing are /48. > > We consider the following to be "legal": > > /* global unicast allocations */ > > route-filter 2001::/16 prefix-length-range /19-/35; > > /* 6to4 prefix */ > > route-filter 2002::/16 prefix-length-range /16-/16; > > /* RIPE allocations */ > > route-filter 2003::/18 prefix-length-range /19-/32; > > /* APNIC allocations */ > > route-filter 2400::/12 prefix-length-range /13-/32; > > /* ARIN allocations */ > > route-filter 2600::/12 prefix-length-range /13-/32; > > /* ARIN allocations */ > > route-filter 2610::/23 prefix-length-range /24-/32; > > /* LACNIC allocations */ > > route-filter 2800::/12 prefix-length-range /13-/32; > > /* RIPE allocations */ > > route-filter 2A00::/12 prefix-length-range /13-/32; > > /* AfriNIC allocations */ > > route-filter 2C00::/12 prefix-length-range /13-/32; > > /* APNIC PI allocations */ > > route-filter 2001:0DF0::/29 prefix-length-range /40-/48; > > /* AFRINIC PI allocations */ > > route-filter 2001:43F8::/29 prefix-length-range /40-/48; > > /* ARIN PI allocations */ > > route-filter 2620::/23 prefix-length-range /40-/48; > > /* ARIN Micro-allocations */ > > route-filter 2001:0500::/24 prefix-length-range /44-/48; > > > > This means accepting prefixes ARIN says we should not, but ARIN does not > > set our routing policy and I will be on a panel on that issue at NANOG in > > Dearborn later this month. > > > It might be worth relaxing filtering within 2001::/16. The RIPE NCC > appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the > RIPE Meeting next week will be using 2001:67c:64::/48) Looks like we need to relax 2001:678::/29 a bit, but I am not sure that we will open up the entire /16. I already have such for ARIN, AfriNIC, and APNIC. Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From seitz at strato-rz.de Sat Oct 3 16:29:41 2009 From: seitz at strato-rz.de (Christian Seitz) Date: Sat, 03 Oct 2009 23:29:41 +0200 Subject: Minimum IPv6 size In-Reply-To: <20091003210118.4F5981CC0E@ptavv.es.net> References: <20091003210118.4F5981CC0E@ptavv.es.net> Message-ID: <4AC7C245.80008@strato-rz.de> Hello, Kevin Oberman wrote: >> Date: Sat, 03 Oct 2009 09:27:27 +0100 >> From: James Aldridge >> >> --On 2 October 2009 16:43:14 -0700 Kevin Oberman wrote: >>> Depends on the address space it is assigned from. Most specify a maximum >>> prefix length of 32, but the micro-allocations and the allocations for >>> PI dual-homing are /48. >>> We consider the following to be "legal": >>> /* global unicast allocations */ >>> route-filter 2001::/16 prefix-length-range /19-/35; >>> /* 6to4 prefix */ >>> route-filter 2002::/16 prefix-length-range /16-/16; >>> /* RIPE allocations */ >>> route-filter 2003::/18 prefix-length-range /19-/32; >>> /* APNIC allocations */ >>> route-filter 2400::/12 prefix-length-range /13-/32; >>> /* ARIN allocations */ >>> route-filter 2600::/12 prefix-length-range /13-/32; >>> /* ARIN allocations */ >>> route-filter 2610::/23 prefix-length-range /24-/32; >>> /* LACNIC allocations */ >>> route-filter 2800::/12 prefix-length-range /13-/32; >>> /* RIPE allocations */ >>> route-filter 2A00::/12 prefix-length-range /13-/32; >>> /* AfriNIC allocations */ >>> route-filter 2C00::/12 prefix-length-range /13-/32; >>> /* APNIC PI allocations */ >>> route-filter 2001:0DF0::/29 prefix-length-range /40-/48; >>> /* AFRINIC PI allocations */ >>> route-filter 2001:43F8::/29 prefix-length-range /40-/48; >>> /* ARIN PI allocations */ >>> route-filter 2620::/23 prefix-length-range /40-/48; >>> /* ARIN Micro-allocations */ >>> route-filter 2001:0500::/24 prefix-length-range /44-/48; >>> >>> This means accepting prefixes ARIN says we should not, but ARIN does not >>> set our routing policy and I will be on a panel on that issue at NANOG in >>> Dearborn later this month. >> >> It might be worth relaxing filtering within 2001::/16. The RIPE NCC >> appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the >> RIPE Meeting next week will be using 2001:67c:64::/48) > > Looks like we need to relax 2001:678::/29 a bit, but I am not sure that > we will open up the entire /16. I already have such for ARIN, AfriNIC, > and APNIC. > > Is there some central repository for information on this? We usually > seem to find out about such changes out of the ARIN region a bit after > the fact. each RIR has an overview of their managed address space with the longest prefixes they are assigning/allocating from their ranges. I currently use those overviews to build IPv6 BGP filters manually. If you build very strict filters, you have to check the overviews more often as with loose filters. https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html http://www.arin.net/reference/ip_blocks.html http://www.arin.net/reference/micro_allocations.html http://www.apnic.net/db/min-alloc.html http://lacnic.net/en/registro/index.html http://www.afrinic.net/Registration/resources.htm There ist also a loose and a strict filter recommendation by Gert Doering [1], but the strict filter is very strict at the moment. It allows only /48s from RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also assignes /47 or /46 from this range. Also there should be some deaggregation allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for some reason, because he cannot get a second /32, he should be able to use (eg.) 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 prefixes, but I would accept prefixes up to a /36. [1] http://www.space.net/~gert/RIPE/ipv6-filters.html Regards, Christian Seitz From oberman at es.net Sat Oct 3 17:00:48 2009 From: oberman at es.net (Kevin Oberman) Date: Sat, 03 Oct 2009 15:00:48 -0700 Subject: Minimum IPv6 size In-Reply-To: Your message of "Sat, 03 Oct 2009 23:29:41 +0200." <4AC7C245.80008@strato-rz.de> Message-ID: <20091003220048.9F42A1CC2E@ptavv.es.net> > Date: Sat, 03 Oct 2009 23:29:41 +0200 > From: Christian Seitz > > Hello, > > Kevin Oberman wrote: > >> Date: Sat, 03 Oct 2009 09:27:27 +0100 > >> From: James Aldridge > >> > >> --On 2 October 2009 16:43:14 -0700 Kevin Oberman wrote: > >>> Depends on the address space it is assigned from. Most specify a maximum > >>> prefix length of 32, but the micro-allocations and the allocations for > >>> PI dual-homing are /48. > >>> We consider the following to be "legal": > >>> /* global unicast allocations */ > >>> route-filter 2001::/16 prefix-length-range /19-/35; > >>> /* 6to4 prefix */ > >>> route-filter 2002::/16 prefix-length-range /16-/16; > >>> /* RIPE allocations */ > >>> route-filter 2003::/18 prefix-length-range /19-/32; > >>> /* APNIC allocations */ > >>> route-filter 2400::/12 prefix-length-range /13-/32; > >>> /* ARIN allocations */ > >>> route-filter 2600::/12 prefix-length-range /13-/32; > >>> /* ARIN allocations */ > >>> route-filter 2610::/23 prefix-length-range /24-/32; > >>> /* LACNIC allocations */ > >>> route-filter 2800::/12 prefix-length-range /13-/32; > >>> /* RIPE allocations */ > >>> route-filter 2A00::/12 prefix-length-range /13-/32; > >>> /* AfriNIC allocations */ > >>> route-filter 2C00::/12 prefix-length-range /13-/32; > >>> /* APNIC PI allocations */ > >>> route-filter 2001:0DF0::/29 prefix-length-range /40-/48; > >>> /* AFRINIC PI allocations */ > >>> route-filter 2001:43F8::/29 prefix-length-range /40-/48; > >>> /* ARIN PI allocations */ > >>> route-filter 2620::/23 prefix-length-range /40-/48; > >>> /* ARIN Micro-allocations */ > >>> route-filter 2001:0500::/24 prefix-length-range /44-/48; > >>> > >>> This means accepting prefixes ARIN says we should not, but ARIN does not > >>> set our routing policy and I will be on a panel on that issue at NANOG in > >>> Dearborn later this month. > >> > >> It might be worth relaxing filtering within 2001::/16. The RIPE NCC > >> appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the > >> RIPE Meeting next week will be using 2001:67c:64::/48) > > > > Looks like we need to relax 2001:678::/29 a bit, but I am not sure that > > we will open up the entire /16. I already have such for ARIN, AfriNIC, > > and APNIC. > > > > Is there some central repository for information on this? We usually > > seem to find out about such changes out of the ARIN region a bit after > > the fact. > > each RIR has an overview of their managed address space with the longest > prefixes they are assigning/allocating from their ranges. I currently use those > overviews to build IPv6 BGP filters manually. If you build very strict filters, > you have to check the overviews more often as with loose filters. > > https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html > http://www.arin.net/reference/ip_blocks.html > http://www.arin.net/reference/micro_allocations.html > http://www.apnic.net/db/min-alloc.html > http://lacnic.net/en/registro/index.html > http://www.afrinic.net/Registration/resources.htm > > There ist also a loose and a strict filter recommendation by Gert Doering [1], > but the strict filter is very strict at the moment. It allows only /48s from > RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also > assignes /47 or /46 from this range. Also there should be some deaggregation > allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for > some reason, because he cannot get a second /32, he should be able to use (eg.) > 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 > prefixes, but I would accept prefixes up to a /36. > > [1] http://www.space.net/~gert/RIPE/ipv6-filters.html Thanks for the AfriNIC URL. I did had not seen that page. I'm pretty sure that the PI space was not declared last time I looked for something. We do allow deaggregation of all space to /35. That is three bits allowing for 8 different announcements. We are always re-evaluating this policy and it is quite possible that it will be moved to a /36 in the future. We also are considering loosening the PI down to /50 or even /52. I really can't see much justification to go beyond that at this time. No matter how hard people try, I am sure that we will need to continue to broaden filters and expand the route tables. I belive that, in the long run (and not very long) the only solution will be some kind of locator/identifier separation which has the potential to control the size of the RIB and FIB for a very long time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From beckman at angryox.com Sat Oct 3 17:18:10 2009 From: beckman at angryox.com (Peter Beckman) Date: Sat, 3 Oct 2009 18:18:10 -0400 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: <4AC7A8FA.80007@linuxbox.org> References: <4AC7A8FA.80007@linuxbox.org> Message-ID: On Sat, 3 Oct 2009, Gadi Evron wrote: > The story is covered by PC mag: Thanks for the article Gadi. Honestly, I wish both my personal ISP and one of my business ISPs would do this. Though I have the technical ability to monitor my outgoing connections for such things, it's not a trivial task and requires resources I've decided not to invest in, namely a Linux PC running as my gateway with yet more software (OS, monitoring tools, etc) I need to secure and keep updated. For me to be thrilled about my ISPs monitoring my connection for "bad behavior," the ISP should: * Quickly notify the customer about the problem via email and phone * Offer the ability to view the evidence of the "bad behavior," accessible on the ISP network via the web so it can be viewed whether the connection is active or blocked, to help determine which host(s) is/are responsible * Clearly classify the type of "bad behavior" and offer both free and paid alternatives to potentially rectify the problem for those less technically inclined to self-solve the issue * Provide a short period of time (3 days) after notification and before disconnect to give an opportunity to fix the issue without service interruption * Offer a simple, automated way to get the connection re-tested and unblocked immediately (within 15 minutes) using a web service accessible even if the connection is blocked This would make me happy. What would make me angry is if they: * Simply turn the connection off with little or no notice * Provide no notification of what happened or why * Offer no evidence of why they turned the connection off to help debug * Force the customer to call customer service to ask for a retest or reconnect * Have the reconnect take multiple hours/days once approved If done right, such a treaty here in the US and elsewhere thing would be a major win for the Internet. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From shawn.marck at blacklotus.net Sat Oct 3 19:10:57 2009 From: shawn.marck at blacklotus.net (Shawn Marck) Date: Sat, 3 Oct 2009 17:10:57 -0700 Subject: Request for Contact - Verizon AS19262 Message-ID: Can admin from Verizon AS19262 contact me off-list? Changes to our AS are not reaching Verizon AS19262. Thanks, -- Shawn Marck, shawn.marck at blacklotus.net From deleskie at gmail.com Sat Oct 3 19:19:40 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Sun, 4 Oct 2009 00:19:40 +0000 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients Message-ID: <1691607441-1254615583-cardhu_decombobulator_blackberry.rim.net-358579366-@bda023.bisx.prod.on.blackberry> Sounds great but who cover the costs? ------Original Message------ From: Peter Beckman To: Gadi Evron Cc: NANOG Subject: Re: Dutch ISPs to collaborate and take responsibility for bottedclients Sent: Oct 3, 2009 7:18 PM On Sat, 3 Oct 2009, Gadi Evron wrote: > The story is covered by PC mag: Thanks for the article Gadi. Honestly, I wish both my personal ISP and one of my business ISPs would do this. Though I have the technical ability to monitor my outgoing connections for such things, it's not a trivial task and requires resources I've decided not to invest in, namely a Linux PC running as my gateway with yet more software (OS, monitoring tools, etc) I need to secure and keep updated. For me to be thrilled about my ISPs monitoring my connection for "bad behavior," the ISP should: * Quickly notify the customer about the problem via email and phone * Offer the ability to view the evidence of the "bad behavior," accessible on the ISP network via the web so it can be viewed whether the connection is active or blocked, to help determine which host(s) is/are responsible * Clearly classify the type of "bad behavior" and offer both free and paid alternatives to potentially rectify the problem for those less technically inclined to self-solve the issue * Provide a short period of time (3 days) after notification and before disconnect to give an opportunity to fix the issue without service interruption * Offer a simple, automated way to get the connection re-tested and unblocked immediately (within 15 minutes) using a web service accessible even if the connection is blocked This would make me happy. What would make me angry is if they: * Simply turn the connection off with little or no notice * Provide no notification of what happened or why * Offer no evidence of why they turned the connection off to help debug * Force the customer to call customer service to ask for a retest or reconnect * Have the reconnect take multiple hours/days once approved If done right, such a treaty here in the US and elsewhere thing would be a major win for the Internet. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- Sent from my BlackBerry device on the Rogers Wireless Network From brandon at rd.bbc.co.uk Sat Oct 3 20:28:54 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 4 Oct 2009 02:28:54 +0100 (BST) Subject: Minimum IPv6 size Message-ID: <200910040128.CAA11324@sunf10.rd.bbc.co.uk> > Is there some central repository for information on this? We usually > seem to find out about such changes out of the ARIN region a bit after > the fact. Have we not learnt from v4? If there are to be filters then they should be defined once and never changed as people will fail to update If a different allocation requirement arises then start a new prefix (v6 is big enough to handle this) and define its filter once. Do not allocate it from an existing range and expect people to adjust their filters. brandon From mpetach at netflight.com Sat Oct 3 22:19:24 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 3 Oct 2009 20:19:24 -0700 Subject: Minimum IPv6 size In-Reply-To: <200910040128.CAA11324@sunf10.rd.bbc.co.uk> References: <200910040128.CAA11324@sunf10.rd.bbc.co.uk> Message-ID: <63ac96a50910032019o39112e27j9cf672812cdbf560@mail.gmail.com> On Sat, Oct 3, 2009 at 6:28 PM, Brandon Butterworth wrote: > > Is there some central repository for information on this? We usually > > seem to find out about such changes out of the ARIN region a bit after > > the fact. > > Have we not learnt from v4? > > If there are to be filters then they should be defined once and never > changed as people will fail to update > Yay! We can return to classful routing again. That sure worked out well for us the first time around. ^_^; > If a different allocation requirement arises then start a new prefix > (v6 is big enough to handle this) and define its filter once. Do not > allocate it from an existing range and expect people to adjust their > filters. > So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. *removes tongue from cheek* > brandon > > Matt From raymond at prolocation.net Sun Oct 4 04:21:40 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sun, 4 Oct 2009 11:21:40 +0200 (CEST) Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <1691607441-1254615583-cardhu_decombobulator_blackberry.rim.net-358579366-@bda023.bisx.prod.on.blackberry> References: <1691607441-1254615583-cardhu_decombobulator_blackberry.rim.net-358579366-@bda023.bisx.prod.on.blackberry> Message-ID: Hi! > Sounds great but who cover the costs? > If done right, such a treaty here in the US and elsewhere thing would be a > major win for the Internet. The ISP's will pick up the costs. A cleaner customer base is also a win for them. First implementations wont be next week however but the start is beeing made. Bye, Raymond. From raymond at prolocation.net Sun Oct 4 04:26:20 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sun, 4 Oct 2009 11:26:20 +0200 (CEST) Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: <4AC7A8FA.80007@linuxbox.org> References: <4AC7A8FA.80007@linuxbox.org> Message-ID: Hi! > A major reason ISPs are hesitant to take deliberate measures against such > systems is that they are afraid that disconnecting users and making them > spend time and money cleaning up their systems will only drive them into the > hands of competitors. And the support process itself is expensive, probably > wiping out the profit from that user. But with such high coverage of the > market users may not have permissive alternatives. > > This will be an interesting phenomenon to watch. If it is successful perhaps > it could work here too." > ------- > > I couldn't find the story in English in a version that did not link to my > original post, I waited a few days to see if anyone else picks it up, as I > don't want yet another self-promotion fight. No one I found in under 2 > minutes on Google did, so this second-hand link should do. > > http://blogs.pcmag.com/securitywatch/2009/09/dutch_isps_sign_anti-botnet_tr.php This is rather old news btw, the convernant was signed < 14 Aug. The ISP's that signed are : Alice, Het Net, InterNLnet, KPN, Luna NL, Concepts ICT, Online, Solcon, Tele2, Telfort, UPC, Xenosite, XS4ALL en Ziggo This is certainly not 98% of the NL marked as they claim. But who cares its a nice initiative. Bye, Raymond. From leo.vegoda at icann.org Sun Oct 4 06:32:44 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sun, 4 Oct 2009 04:32:44 -0700 Subject: Minimum IPv6 size In-Reply-To: <63ac96a50910032019o39112e27j9cf672812cdbf560@mail.gmail.com> Message-ID: On 03/10/2009 8:19, "Matthew Petach" wrote: [...] > So, if I need to break up my /32 into 4 /34s to cover different geographical > regions, I should instead renumber into a new range set aside for /34s > and give back the /32? Sure seems like a lot of extra overhead. > Perhaps we should give everyone an allocation out of each filter > range, so that they can simply number from the appropriately-classed > range; when you apply for space, you'd get a /32, a /33, a /34, a /35, > a /36, etc. all from the appropriate, statically defined ranges. I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. Regards, Leo From owen at delong.com Sun Oct 4 06:33:43 2009 From: owen at delong.com (Owen DeLong) Date: Sun, 4 Oct 2009 04:33:43 -0700 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: References: <4AC7A8FA.80007@linuxbox.org> Message-ID: On Oct 3, 2009, at 3:18 PM, Peter Beckman wrote: > On Sat, 3 Oct 2009, Gadi Evron wrote: > >> The story is covered by PC mag: > > Thanks for the article Gadi. Honestly, I wish both my personal ISP > and > one of my business ISPs would do this. Though I have the technical > ability to monitor my outgoing connections for such things, it's not a > trivial task and requires resources I've decided not to invest in, > namely > a Linux PC running as my gateway with yet more software (OS, > monitoring > tools, etc) I need to secure and keep updated. > > For me to be thrilled about my ISPs monitoring my connection for "bad > behavior," the ISP should: > > * Quickly notify the customer about the problem via email and phone Agreed > * Offer the ability to view the evidence of the "bad behavior," > accessible on the ISP network via the web so it can be viewed > whether > the connection is active or blocked, to help determine which > host(s) > is/are responsible Agreed > * Clearly classify the type of "bad behavior" and offer both free > and > paid alternatives to potentially rectify the problem for those > less > technically inclined to self-solve the issue Definitely. > * Provide a short period of time (3 days) after notification and > before > disconnect to give an opportunity to fix the issue without > service > interruption Uh... Here I differ. The rest of the internet should put up with the abuse flowing out of your network for 3 days to avoid disruption to you? Why? Sorry, if you have a customer who is sourcing malicious activity, whether intentional or by accident, I believe the ISP should take whatever action is necessary to stop the outflow of that malicious behavior as quickly as possible while simultaneously making all reasonable effort to contact the customer in question. The ISP should take the minimum action necessary to stop the outflow, so, if the traffic is sourced from a single host, that host could be filtered/blocked. If the traffic can be classified more tightly (i.e. certain ports, etc., then that classification should be used). This minimizes disruption to the customer, but, still preserves the ISPs obligation to the rest of the internet. When you connect to a community resource like the internet, you have an inherent obligation not to source malicious activity. When you provide services to downstream customers, you are not relieved of that responsibility just because you accepted the malicious activity from them rather than originating it yourself. > * Offer a simple, automated way to get the connection re-tested and > unblocked immediately (within 15 minutes) using a web service > accessible even if the connection is blocked > Either a web interface or even a telephonic process. It doesn't necessarily need to be automated, but, it shouldn't be a 3 day wait for a technician to get back to you. It should definitely be a pretty rapid process once the abuse is resolved. > This would make me happy. > > What would make me angry is if they: > > * Simply turn the connection off with little or no notice They should not turn the connection off unless it is absolutely necessary. See above. > * Provide no notification of what happened or why Absolutely agree here. > * Offer no evidence of why they turned the connection off to help > debug Yep. > * Force the customer to call customer service to ask for a retest > or > reconnect I don't really see a problem with this, so long as customer service is responsive to such a call. > * Have the reconnect take multiple hours/days once approved Agreed: the reconnect process should be very quick once the abuse is resolved. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From rsk at gsp.org Sun Oct 4 07:35:01 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 4 Oct 2009 08:35:01 -0400 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: References: <4AC7A8FA.80007@linuxbox.org> Message-ID: <20091004123458.GA25333@gsp.org> On Sun, Oct 04, 2009 at 04:33:43AM -0700, Owen DeLong wrote: > Uh... Here I differ. The rest of the internet should put up with > the abuse flowing out of your network for 3 days to avoid disruption > to you? Why? Sorry, if you have a customer who is sourcing malicious > activity, whether intentional or by accident, I believe the ISP should > take whatever action is necessary to stop the outflow of that malicious > behavior as quickly as possible while simultaneously making all reasonable > effort to contact the customer in question. Exactly correct. The number one priority, which trumps all others, is making the abuse stop. Yes, there are many other things that can and should be done, but that's the first one. Let me also point out that there's a problem with offering simple, automated removal (as was suggested in the message that you replied to): resident malware on abuse-sourcing zombies will very quickly be reprogrammed to avail itself of that mechanism (on a per-ISP basis if necessary, if this becomes widespread). So there should be no automated removal process: the intervention of humans should be required, doubly so as in most cases the putative/former owner of the infected system is unaware of any of this. ---Rsk From brandon at rd.bbc.co.uk Sun Oct 4 10:16:59 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 4 Oct 2009 16:16:59 +0100 (BST) Subject: Minimum IPv6 size Message-ID: <200910041516.QAA21389@sunf10.rd.bbc.co.uk> > > If there are to be filters then they should be defined once and never > > changed as people will fail to update > > Yay! We can return to classful routing again. That sure worked out well > for us the first time around. ^_^; We have already, all we're discussing now is if we do a better job of implementing it. Classful suffered from lack of space in each range and too coarse a set of fixed ranges, all fixable in v6 so perhaps it's not so bad? > So, if I need to break up my /32 into 4 /34s to cover different geographical > regions, I should instead renumber into a new range set aside for /34s > and give back the /32? And what if you need a few /48's, then you're open to others advertising some of yours too. With no organised mechanism of communicating acceptable prefix lengths to all routers [1] then we either do nothing and let anarchy rule, do something that overly constrains or do half the job and have both problems. > Perhaps we should give everyone an allocation out of each filter > range, so that they can simply number from the appropriately-classed > range; when you apply for space, you'd get a /32, a /33, a /34, a /35, > a /36, etc. all from the appropriate, statically defined ranges. > > *removes tongue from cheek* What would be most efficient for all? Semi classful or not I don't mind but it does seem pointless to have been going round the same circle for so many years. brandon [1] sbgp would be secure anarchy From beckman at angryox.com Sun Oct 4 13:55:24 2009 From: beckman at angryox.com (Peter Beckman) Date: Sun, 4 Oct 2009 14:55:24 -0400 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: References: <4AC7A8FA.80007@linuxbox.org> Message-ID: On Sun, 4 Oct 2009, Owen DeLong wrote: >> * Provide a short period of time (3 days) after notification and before >> disconnect to give an opportunity to fix the issue without service >> interruption > > Uh... Here I differ. The rest of the internet should put up with the abuse > flowing out of your network for 3 days to avoid disruption to you? Why? > Sorry, if you have a customer who is sourcing malicious activity, whether > intentional or by accident, I believe the ISP should take whatever action > is necessary to stop the outflow of that malicious behavior as quickly > as possible while simultaneously making all reasonable effort to contact > the customer in question. Yeah, after a few people privately emailed me regarding the same, the short period of time should be thrown out, for the good of the rest of the 'net. The "short period" was initially intended for infections that were not active or immediately impacting, but were detected to be infected none-the-less. Assuming active "bad behavior" immediate disconnect is prudent and wise. As our ability to remotely detect virus and trojans improves, I suspect such an ISP-provided service would as well. >> * Offer a simple, automated way to get the connection re-tested and >> unblocked immediately (within 15 minutes) using a web service >> accessible even if the connection is blocked >> > Either a web interface or even a telephonic process. It doesn't necessarily > need to be automated, but, it shouldn't be a 3 day wait for a technician > to get back to you. It should definitely be a pretty rapid process once > the abuse is resolved. Agreed. Another emailer mentioned that it's not always simple to determine if the abuse is resolved or not, nor is it easy to explain this to a non-technical customer in a way that makes them happy with their service being cut off. However it is ignorance and lack of maintenance that makes viruses and botnets so prevelant that it may just be time to bite the bullet and force users to learn how to maintain their machines. >> * Force the customer to call customer service to ask for a retest or >> reconnect > I don't really see a problem with this, so long as customer service is > responsive to such a call. I like self-service. If it is 3am and staff is not available, making the process automated would be ideal. If the staff is 24/7, agreed. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From cluestore at gmail.com Sun Oct 4 14:49:42 2009 From: cluestore at gmail.com (Clue Store) Date: Sun, 4 Oct 2009 14:49:42 -0500 Subject: OT: iPhone Problems Message-ID: <580af3b90910041249g60383960k281f6d456c188534@mail.gmail.com> Mine's rebooted at leat 3 times a day sine the upgrade :( What ever happened to quality control.... http://discussions.apple.com/thread.jspa?threadID=2152619&tstart=0 From morrowc.lists at gmail.com Sun Oct 4 15:03:44 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Oct 2009 16:03:44 -0400 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: References: <4AC7A8FA.80007@linuxbox.org> Message-ID: <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> On Sun, Oct 4, 2009 at 2:55 PM, Peter Beckman wrote: > ?service being cut off. ?However it is ignorance and lack of maintenance > ?that makes viruses and botnets so prevelant that it may just be time to > ?bite the bullet and force users to learn how to maintain their machines. because this works so well with: 1) cars 2) home-security 3) personal security wandering around cities/towns I note that I'm not particularly against any of the proposal, just the 'people need a drivers license to get on the interwebz'... it's been tried many times before, always without success. I would also point out that Qwest does this walled-garden approach for their customers (have been for at least 5 years now? DonS at qwest could clarify) and they've seen success with it. Aliant in .ca also has some fairly aggressive anti-malware works installed. There are places where this sort of thing works well, planned and engineered properly. I think Qwest, at least, made some of their reasoning and design/goals publicly available for a time as well. -Chris From ge at linuxbox.org Sun Oct 4 15:20:09 2009 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 04 Oct 2009 22:20:09 +0200 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> References: <4AC7A8FA.80007@linuxbox.org> <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> Message-ID: <4AC90379.1070401@linuxbox.org> Christopher Morrow wrote: > I would also point out that Qwest does this walled-garden approach for > their customers (have been for at least 5 years now? DonS at qwest could > clarify) and they've seen success with it. Aliant in .ca also has some > fairly aggressive anti-malware works installed. There are places > where this sort of thing works well, planned and engineered properly. > I think Qwest, at least, made some of their reasoning and design/goals > publicly available for a time as well. I think Jonathan Curtis did something similar at Bell, but I only spoke with him about it for a couple of second two years ago, as Rio was rather distracting. So am unsure. Apparently, marketing departments like the idea of being able to send customers that need to pay them to a walled garden. It also saves on tech support costs. Security being the main winner isn't the main supporter of the idea at some places. Gadi. From cburwell at gmail.com Sun Oct 4 15:38:00 2009 From: cburwell at gmail.com (Chris Burwell) Date: Sun, 4 Oct 2009 16:38:00 -0400 Subject: OT: iPhone Problems In-Reply-To: <580af3b90910041249g60383960k281f6d456c188534@mail.gmail.com> References: <580af3b90910041249g60383960k281f6d456c188534@mail.gmail.com> Message-ID: MMS or quaility control: pick one! :) On 10/4/09, Clue Store wrote: > Mine's rebooted at leat 3 times a day sine the upgrade :( > > What ever happened to quality control.... > > http://discussions.apple.com/thread.jspa?threadID=2152619&tstart=0 > -- Sent from my mobile device From ken.gilmour at gmail.com Sun Oct 4 15:50:17 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 4 Oct 2009 14:50:17 -0600 Subject: ICETel Costa Rica BGP Engineers Message-ID: <5b6f80200910041350x571f1049j92a48209f07246e@mail.gmail.com> Hi there, Is there anyone from ICETel in Costa Rica who speaks English on this list? I need to discuss some BGP stuff and my Spanish is not the best. Failing that, anyone from RACSA or other major ISP in CR will do. Thanks! Ken From oberman at es.net Sun Oct 4 18:49:22 2009 From: oberman at es.net (Kevin Oberman) Date: Sun, 04 Oct 2009 16:49:22 -0700 Subject: Minimum IPv6 size In-Reply-To: Your message of "Sun, 04 Oct 2009 04:32:44 PDT." Message-ID: <20091004234922.93E141CC0E@ptavv.es.net> > From: Leo Vegoda > Date: Sun, 4 Oct 2009 04:32:44 -0700 > > On 03/10/2009 8:19, "Matthew Petach" wrote: > > [...] > > > So, if I need to break up my /32 into 4 /34s to cover different geographical > > regions, I should instead renumber into a new range set aside for /34s > > and give back the /32? Sure seems like a lot of extra overhead. > > Perhaps we should give everyone an allocation out of each filter > > range, so that they can simply number from the appropriately-classed > > range; when you apply for space, you'd get a /32, a /33, a /34, a /35, > > a /36, etc. all from the appropriate, statically defined ranges. > > I think ARIN proposal 2009-5 > (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with > the situation you describe. I understand that it's on the agenda for the > meeting in Dearborn. I don't think so. I believe the statement is not in regard to separate, discrete networks bu to a network with a national footprint which must deaggregate to do traffic engineering by region. Item 2 clearly makes 2009-5 non-applicable to this case. This issue will be discussed in a Mark Kosters moderated panel at NANOG in Dearborn. Hey, why not attend both meetings? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From barton at gnaps.com Sun Oct 4 19:07:00 2009 From: barton at gnaps.com (Barton F Bruce) Date: Sun, 4 Oct 2009 20:07:00 -0400 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> Message-ID: <20AFD779C33D40A489AC7AEC37752F44@bvsupport> > Exactly correct. The number one priority, which trumps all others, > is making the abuse stop. Yes, there are many other things that can > and should be done, but that's the first one. Stopping the abuse is fine, but cutting service to the point that a family using VOIP only for their phone service can't call 911 and several children burn to death could bring all sorts of undesirable regulation let alone the bad press and legal expenses. From ge at linuxbox.org Sun Oct 4 19:33:29 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 05 Oct 2009 02:33:29 +0200 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <20AFD779C33D40A489AC7AEC37752F44@bvsupport> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> Message-ID: <4AC93ED9.5080909@linuxbox.org> Barton F Bruce wrote: > Stopping the abuse is fine, but cutting service to the point that a family > using VOIP only for their phone service can't call 911 and several children > burn to death could bring all sorts of undesirable regulation let alone the > bad press and legal expenses. While a legitimate concern it's also a red herring, as it's a technical problem looking for a technical solution. Gadi. From nils.kolstein at sscplus.nl Mon Oct 5 01:58:35 2009 From: nils.kolstein at sscplus.nl (Nils Kolstein) Date: Mon, 5 Oct 2009 08:58:35 +0200 (CEST) Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <20AFD779C33D40A489AC7AEC37752F44@bvsupport> Message-ID: <1600878806.165421254725915850.JavaMail.root@webmail> > > Exactly correct. The number one priority, which trumps all others, > > is making the abuse stop. Yes, there are many other things that > can > > and should be done, but that's the first one. > > Stopping the abuse is fine, but cutting service to the point that a > family > using VOIP only for their phone service can't call 911 and several > children > burn to death could bring all sorts of undesirable regulation let > alone the > bad press and legal expenses. As far as the Ducth situation with one of the largest providers (KPN) goes this is solved by using a seperate VLAN for VOIP traffic. Only the data VLAN is being "blocked" or actually policy routed towards a walled garden in which users are able to clean themselves up. -- Nils Kolstein SSCPlus From leo.vegoda at icann.org Mon Oct 5 02:13:03 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 5 Oct 2009 00:13:03 -0700 Subject: Minimum IPv6 size In-Reply-To: <20091004234922.93E141CC0E@ptavv.es.net> Message-ID: On 04/10/2009 4:49, "Kevin Oberman" wrote: [...] >>> So, if I need to break up my /32 into 4 /34s to cover different geographical >>> regions, I should instead renumber into a new range set aside for /34s >>> and give back the /32? Sure seems like a lot of extra overhead. >>> Perhaps we should give everyone an allocation out of each filter >>> range, so that they can simply number from the appropriately-classed >>> range; when you apply for space, you'd get a /32, a /33, a /34, a /35, >>> a /36, etc. all from the appropriate, statically defined ranges. >> >> I think ARIN proposal 2009-5 >> (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with >> the situation you describe. I understand that it's on the agenda for the >> meeting in Dearborn. > > I don't think so. I believe the statement is not in regard to separate, > discrete networks bu to a network with a national footprint which must > deaggregate to do traffic engineering by region. Item 2 clearly makes > 2009-5 non-applicable to this case. I thought that "Geographic distance and diversity between networks" covered the case above but I could well be wrong. > This issue will be discussed in a Mark Kosters moderated panel at NANOG > in Dearborn. Hey, why not attend both meetings? I won't be there in person but look forward to watching the video feed. Regards, Leo From rsk at gsp.org Mon Oct 5 06:59:36 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 5 Oct 2009 07:59:36 -0400 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <20AFD779C33D40A489AC7AEC37752F44@bvsupport> References: <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> Message-ID: <20091005115936.GA21475@gsp.org> On Sun, Oct 04, 2009 at 08:07:00PM -0400, Barton F Bruce wrote: >> Exactly correct. The number one priority, which trumps all others, >> is making the abuse stop. Yes, there are many other things that can >> and should be done, but that's the first one. > > Stopping the abuse is fine, but cutting service to the point that a family > using VOIP only for their phone service can't call 911 and several children > burn to death could bring all sorts of undesirable regulation let alone the > bad press and legal expenses. First, this is fear-mongering. By this argument, we should do nothing, ever, because we cannot know that seconds after taking whatever action we take, Something Terrible could happen. Second, a compromised system no longer belongs to its putative user(s): it's not under their control. It's thus a huge reach to presume that it will, whether "we" take any action or not, do what the people who used to own it (and likely think they still do) expect it to. In other words, just as likely as the scenario you outline, is the scenario where the VOIP call doesn't go through because the new owner of the system would prefer that it spend its cycles and bandwidth sending spam. ---Rsk From lee at asgard.org Mon Oct 5 07:32:17 2009 From: lee at asgard.org (Lee Howard) Date: Mon, 5 Oct 2009 08:32:17 -0400 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> References: <4AC7A8FA.80007@linuxbox.org> <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> Message-ID: <000501ca45b7$e08932e0$a19b98a0$@org> > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Sunday, October 04, 2009 4:04 PM > To: Peter Beckman > Cc: NANOG > Subject: Re: Dutch ISPs to collaborate and take responsibility for botted clients > > On Sun, Oct 4, 2009 at 2:55 PM, Peter Beckman wrote: > > > ?service being cut off. ?However it is ignorance and lack of maintenance > > ?that makes viruses and botnets so prevelant that it may just be time to > > ?bite the bullet and force users to learn how to maintain their machines. > > because this works so well with: > > 1) cars > 2) home-security > 3) personal security wandering around cities/towns > > I note that I'm not particularly against any of the proposal, just the > 'people need a drivers license to get on the interwebz'... it's been > tried many times before, always without success. I'm trying to understand your analogy, but it's hidden in the sarcasm. Your assertion is that education (and you've decided to include licensing, for some reason) of drivers and the rest is ineffective? You're not opposed to user education, you just believe it's useless because it will only reduce, not eliminate, badness? Lee From jason at i6ix.com Mon Oct 5 08:27:03 2009 From: jason at i6ix.com (Jason Bertoch) Date: Mon, 05 Oct 2009 09:27:03 -0400 Subject: Verizon Southeast Network Map Message-ID: <4AC9F427.2020409@i6ix.com> We're considering adding a Verizon connection to our network in Florida, so I've been looking unsuccessfully for a map of Verizon's fiber network in the southeast to verify that I'll have diverse paths with my other providers. Does anyone know if such a map exists in a public location? From justin at justinshore.com Mon Oct 5 09:04:12 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 05 Oct 2009 09:04:12 -0500 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: <4AC90379.1070401@linuxbox.org> References: <4AC7A8FA.80007@linuxbox.org> <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> <4AC90379.1070401@linuxbox.org> Message-ID: <4AC9FCDC.9060709@justinshore.com> Gadi Evron wrote: > Apparently, marketing departments like the idea of being able to send > customers that need to pay them to a walled garden. It also saves on > tech support costs. Security being the main winner isn't the main > supporter of the idea at some places. I would love to do this both for non-pays and security incidents. I'd like to do something similar to let customers update their provisioning information for static IP changes so cable source verify doesn't freak out. Unfortunately I haven't been able to find any open source tools to do this. I can't even think of commercial ones off the top of my head. It's a relatively simple concept. Some measure of integration into the DHCP provisioning system(s) would be needed to properly route the customer's traffic to the walled garden and only to the walled garden. Once the problem is resolved the walled garden fixes the DHCP so the customer can once again pull a public IP and possibly flushes ARP caches if your access medium makes that a problem to be dealt with. I would think that the walled garden portion could be handled well-enough with Squid and some custom web programming to perform tasks to reverse the provisioning issues. I'm sure people have written internal solutions for SPs before but I haven't found anyone that has made that into an OSS project and put it on the Web. I'd love to make this a project but there is little financial gain to my small SP so if it costs much money it won't get management support. Justin From leigh.porter at ukbroadband.com Mon Oct 5 09:45:33 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 05 Oct 2009 15:45:33 +0100 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: <4AC9FCDC.9060709@justinshore.com> References: <4AC7A8FA.80007@linuxbox.org> <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> <4AC90379.1070401@linuxbox.org> <4AC9FCDC.9060709@justinshore.com> Message-ID: <4ACA068D.2050607@ukbroadband.com> Justin Shore wrote: > Gadi Evron wrote: >> Apparently, marketing departments like the idea of being able to send >> customers that need to pay them to a walled garden. It also saves on >> tech support costs. Security being the main winner isn't the main >> supporter of the idea at some places. > > I would love to do this both for non-pays and security incidents. I'd > like to do something similar to let customers update their > provisioning information for static IP changes so cable source verify > doesn't freak out. Unfortunately I haven't been able to find any open > source tools to do this. I can't even think of commercial ones off > the top of my head. > > It's a relatively simple concept. Some measure of integration into > the DHCP provisioning system(s) would be needed to properly route the > customer's traffic to the walled garden and only to the walled garden. > Once the problem is resolved the walled garden fixes the DHCP so the > customer can once again pull a public IP and possibly flushes ARP > caches if your access medium makes that a problem to be dealt with. > > I would think that the walled garden portion could be handled > well-enough with Squid and some custom web programming to perform > tasks to reverse the provisioning issues. I'm sure people have > written internal solutions for SPs before but I haven't found anyone > that has made that into an OSS project and put it on the Web. I'd > love to make this a project but there is little financial gain to my > small SP so if it costs much money it won't get management support. > > Justin > There is all sorts of kit that will do this for you, Ellacoya, Redback etc. They all have APIs and all work well. The customer keeps their public IP address, but you can then make it belong to another virtual router instance, or you can apply certain firewall/ACL/policy rules to it. For example, my Ellacoyas will, for a walled customer, deny traffic to anything but the walled garden hosts and will then route any port 80 traffic to my proxy server that re-directs it all to a walled garden web server. Then soon as they hand over their payment details and we take payment, a request is sent to the Ellacoya to remove the restrictions. Lovaly. -- Leigh From leland at taranta.discpro.org Mon Oct 5 09:46:48 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Mon, 05 Oct 2009 16:46:48 +0200 Subject: operations contact @ facebook? Message-ID: <1254754008.4530.4.camel@leland-gandi> Hi All, Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Thanks in advance. Leland Vandervort Director, Technical Operations Gandi SAS Paris t: +33 1 70 39 37 59 m: +33 6 31 15 15 07 From patrick at ianai.net Mon Oct 5 09:57:28 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Oct 2009 10:57:28 -0400 Subject: operations contact @ facebook? In-Reply-To: <1254754008.4530.4.camel@leland-gandi> References: <1254754008.4530.4.camel@leland-gandi> Message-ID: <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: > Would anyone happen to have an operations contact at Facebook by > anychance? Our systems are being overwhelmed by a facebook > application > that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. -- TTFN, patrick [*] No, I do not work for FB. From abalashov at evaristesys.com Mon Oct 5 10:10:34 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 05 Oct 2009 11:10:34 -0400 Subject: operations contact @ facebook? In-Reply-To: <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> References: <1254754008.4530.4.camel@leland-gandi> <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> Message-ID: <4ACA0C6A.3070103@evaristesys.com> Patrick W. Gilmore wrote: > On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: > >> Would anyone happen to have an operations contact at Facebook by >> anychance? Our systems are being overwhelmed by a facebook application >> that we were neither aware of nor condoned. > > Clearly I do not have all the information, so please forgive me for > being confused. But since when do I[*] have to ask you before I put an > application on my server? If FB put an application on your server, that > seems like something you should have known up front. The original poster is from Paris. Do consider the possibility that there are different jurisdictional rules or service terms in force from your own. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From lists at mtin.net Mon Oct 5 10:11:21 2009 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 05 Oct 2009 11:11:21 -0400 Subject: operations contact @ facebook? In-Reply-To: <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> Message-ID: We have had issues with a FB application basically doing a DOS against a network. This was not on our servers but somewhere out there on the Internet. It was an application that was going rogue. It was talking to several of our user?s using this application. FaceBook caught it and made the developer fix the App. I am sure we were not the only ones seeing the issue. Justin From: "Patrick W. Gilmore" Date: Mon, 5 Oct 2009 10:57:28 -0400 To: NANOG list Subject: Re: operations contact @ facebook? On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: > Would anyone happen to have an operations contact at Facebook by > anychance? Our systems are being overwhelmed by a facebook > application > that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. -- TTFN, patrick [*] No, I do not work for FB. From leland at taranta.discpro.org Mon Oct 5 09:59:50 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Mon, 05 Oct 2009 16:59:50 +0200 Subject: operations contact @ facebook? In-Reply-To: <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> References: <1254754008.4530.4.camel@leland-gandi> <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> Message-ID: <1254754790.4530.6.camel@leland-gandi> The application is not being hosted on the VPS servers, but rather on the mutualised blog platform and is impacting on other customers of this platform. We have VPS services available for the app developer in question to host his application on should he desire to do so. Leland On Mon, 2009-10-05 at 10:57 -0400, Patrick W. Gilmore wrote: > On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: > > > Would anyone happen to have an operations contact at Facebook by > > anychance? Our systems are being overwhelmed by a facebook > > application > > that we were neither aware of nor condoned. > > Clearly I do not have all the information, so please forgive me for > being confused. But since when do I[*] have to ask you before I put > an application on my server? If FB put an application on your server, > that seems like something you should have known up front. > From jlewis at lewis.org Mon Oct 5 10:15:07 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 5 Oct 2009 11:15:07 -0400 (EDT) Subject: operations contact @ facebook? In-Reply-To: <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> References: <1254754008.4530.4.camel@leland-gandi> <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> Message-ID: On Mon, 5 Oct 2009, Patrick W. Gilmore wrote: > On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: > >> Would anyone happen to have an operations contact at Facebook by >> anychance? Our systems are being overwhelmed by a facebook application >> that we were neither aware of nor condoned. > > Clearly I do not have all the information, so please forgive me for being > confused. But since when do I[*] have to ask you before I put an application > on my server? If FB put an application on your server, that seems like > something you should have known up front. Sounds like it's an app on facebook that's causing unexpected access to something on their systems...perhaps kind of like being /.'d ? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jgreco at ns.sol.net Mon Oct 5 10:18:45 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 5 Oct 2009 10:18:45 -0500 (CDT) Subject: operations contact @ facebook? In-Reply-To: <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> from "Patrick W. Gilmore" at Oct 05, 2009 10:57:28 AM Message-ID: <200910051518.n95FIjgK070452@aurora.sol.net> > On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: > > > Would anyone happen to have an operations contact at Facebook by > > anychance? Our systems are being overwhelmed by a facebook > > application > > that we were neither aware of nor condoned. > > Clearly I do not have all the information, so please forgive me for > being confused. But since when do I[*] have to ask you before I put > an application on my server? If FB put an application on your server, > that seems like something you should have known up front. That's far from the only possibility. The ability of a site such as FB to generate an inadvertent but effective DDoS against a smaller site in a variety of ways is quite significant, and depending on the specifics, failure to mitigate such damage once being made aware of it could even open one up to penalties under regional computer crime laws... of course, that's making a bit of a jump and some assumptions, but it is certainly a different possibility from the one you suggest. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bbillon-ml at splio.fr Mon Oct 5 10:18:21 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Mon, 05 Oct 2009 17:18:21 +0200 Subject: operations contact @ facebook? In-Reply-To: <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> References: <1254754008.4530.4.camel@leland-gandi> <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> Message-ID: <4ACA0E3D.9070107@splio.fr> I guess the facebook app allows any FB user to check availability of domain names or to request Gandi's whois database. From what I saw, FB people do not check every applications neither before or after publication. And that could create some issues out there. Patrick W. Gilmore a ?crit : > On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: > >> Would anyone happen to have an operations contact at Facebook by >> anychance? Our systems are being overwhelmed by a facebook application >> that we were neither aware of nor condoned. > > Clearly I do not have all the information, so please forgive me for > being confused. But since when do I[*] have to ask you before I put > an application on my server? If FB put an application on your server, > that seems like something you should have known up front. > From streiner at cluebyfour.org Mon Oct 5 10:31:59 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 5 Oct 2009 11:31:59 -0400 (EDT) Subject: operations contact @ facebook? In-Reply-To: <1254754008.4530.4.camel@leland-gandi> References: <1254754008.4530.4.camel@leland-gandi> Message-ID: On Mon, 5 Oct 2009, Leland Vandervort wrote: > Would anyone happen to have an operations contact at Facebook by > anychance? Our systems are being overwhelmed by a facebook application > that we were neither aware of nor condoned. You might be able to reach the right people at ops at facebook.com jms From bjohnson at drtel.com Mon Oct 5 10:27:59 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 5 Oct 2009 10:27:59 -0500 Subject: ISP customer assignments Message-ID: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> >From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? Thank you. - Brian From streiner at cluebyfour.org Mon Oct 5 10:40:44 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 5 Oct 2009 11:40:44 -0400 (EDT) Subject: Verizon Southeast Network Map In-Reply-To: <4AC9F427.2020409@i6ix.com> References: <4AC9F427.2020409@i6ix.com> Message-ID: On Mon, 5 Oct 2009, Jason Bertoch wrote: > We're considering adding a Verizon connection to our network in Florida, so > I've been looking unsuccessfully for a map of Verizon's fiber network in the > southeast to verify that I'll have diverse paths with my other providers. > Does anyone know if such a map exists in a public location? I haven't seen one, but I'd imagine they have a route that parallels I-95 through Jacksonville to Miami and maybe one that runs up the gulf side via Tampa. Not sure about route diversity in the panhandle but I'd bet there would be at least some for Tallahassee and Pensacola. That might be something that a VZB account manager could provide after the execution of an appropriately flavored NDA. jms From leland at taranta.discpro.org Mon Oct 5 10:36:13 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Mon, 05 Oct 2009 17:36:13 +0200 Subject: operations contact @ facebook? In-Reply-To: References: <1254754008.4530.4.camel@leland-gandi> Message-ID: <1254756973.4530.19.camel@leland-gandi> Thanks Justin... will give it a shot; hopefully they're relatively rapid :) Leland On Mon, 2009-10-05 at 11:31 -0400, Justin M. Streiner wrote: > On Mon, 5 Oct 2009, Leland Vandervort wrote: > > > Would anyone happen to have an operations contact at Facebook by > > anychance? Our systems are being overwhelmed by a facebook application > > that we were neither aware of nor condoned. > > You might be able to reach the right people at ops at facebook.com > > jms From sethm at rollernet.us Mon Oct 5 10:38:11 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 05 Oct 2009 08:38:11 -0700 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> Message-ID: <4ACA12E3.5020600@rollernet.us> Brian Johnson wrote: >>From what I can tell from an ISP perspective, the design of IPv6 is for > assignment of a /64 to an end user. Is this correct? Is this how it is > currently being done? If not, where am I going wrong? > The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth From a.harrowell at gmail.com Mon Oct 5 11:06:46 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 5 Oct 2009 17:06:46 +0100 Subject: operations contact @ facebook? In-Reply-To: <1254756973.4530.19.camel@leland-gandi> References: <1254754008.4530.4.camel@leland-gandi> <1254756973.4530.19.camel@leland-gandi> Message-ID: <200910051706.47216.a.harrowell@gmail.com> This is a classic case of one of the problems of the increasingly numerous and powerful Web dev platforms - as you let other people either control your app through an API, or even write code that executes on the server-side, you're increasing the cycles available to an attacker. It's similar to the dns reflector attack. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From bjohnson at drtel.com Mon Oct 5 11:08:30 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 5 Oct 2009 11:08:30 -0500 Subject: ISP customer assignments In-Reply-To: <4ACA12E3.5020600@rollernet.us> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> Message-ID: <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That?s the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? - Brian > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Monday, October 05, 2009 10:38 AM > To: nanog at nanog.org > Subject: Re: ISP customer assignments > > Brian Johnson wrote: > >>From what I can tell from an ISP perspective, the design of IPv6 is > for > > assignment of a /64 to an end user. Is this correct? Is this how it > is > > currently being done? If not, where am I going wrong? > > > > The most common thing I see is /64 if the end user only needs one > subnet, /56 if they need more than one. > > ~Seth From cabo at tzi.org Mon Oct 5 11:18:12 2009 From: cabo at tzi.org (Carsten Bormann) Date: Mon, 5 Oct 2009 18:18:12 +0200 Subject: ISP customer assignments In-Reply-To: <4ACA12E3.5020600@rollernet.us> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> Message-ID: On Oct 5, 2009, at 17:38, Seth Mattinen wrote: > The most common thing I see is /64 if the end user only needs one > subnet, /56 if they need more than one. Brrzt, wrong. Neither the end user nor you know the answer to that question! So the only sensible thing is to always give them a /56. (Actually, the IPv6 address architecture design was to give them a / 48. Think about it: We will run out of MAC addresses before we run out of those. But some people can't manage the cognitive dissonance coming from an address starving IPv4 world and then "wasting" all these 2^80 addresses. My parents, who grew up around WW2, were that way, too, and never could unlearn their "saving" habits. So the current "wise" thing is to allocate a /56, "wasting" only 2^72 addresses per customer. The only way back to a connected Internet.) Gruesse, Carsten From nick at foobar.org Mon Oct 5 11:19:21 2009 From: nick at foobar.org (Nick Hilliard) Date: Mon, 05 Oct 2009 17:19:21 +0100 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> Message-ID: <4ACA1C89.6070901@foobar.org> On 05/10/2009 17:08, Brian Johnson wrote: > So a customer with a single PC hooked up to their broad-band connection > would be given 2^64 addresses? > > I realize that this is future proofing, but OMG! That?s the IPv4 > Internet^2 for a single device! No, for a single LAN. > Am I still seeing/reading/understanding this correctly? more-or-less. Can I suggest you read: http://en.wikipedia.org/wiki/IPv6 Think of ipv6 not as 128 bits of address space, but more as a addressing system with a globally unique host part and 2^64 possible subnets. In this respect it's substantially different to ipv4. Nick From trejrco at gmail.com Mon Oct 5 11:20:37 2009 From: trejrco at gmail.com (TJ) Date: Mon, 5 Oct 2009 12:20:37 -0400 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> Message-ID: <71bfd60c0910050920x1c1e837bx7854562acec54bcc@mail.gmail.com> Yes, each and every network segment (especially multi-access ones) should be /64s. Regardless of the types of machines, speed of link, etc. It is an entirely different model of addressing, whose name just happens to start with IP ... /TJ On Mon, Oct 5, 2009 at 12:08 PM, Brian Johnson wrote: > So a customer with a single PC hooked up to their broad-band connection > would be given 2^64 addresses? > > I realize that this is future proofing, but OMG! That?s the IPv4 Internet^2 > for a single device! > > Am I still seeing/reading/understanding this correctly? > > - Brian > > > -----Original Message----- > > From: Seth Mattinen [mailto:sethm at rollernet.us] > > Sent: Monday, October 05, 2009 10:38 AM > > To: nanog at nanog.org > > Subject: Re: ISP customer assignments > > > > Brian Johnson wrote: > > >>From what I can tell from an ISP perspective, the design of IPv6 is > > for > > > assignment of a /64 to an end user. Is this correct? Is this how it > > is > > > currently being done? If not, where am I going wrong? > > > > > > > The most common thing I see is /64 if the end user only needs one > > subnet, /56 if they need more than one. > > > > ~Seth > > -- /TJ From sethm at rollernet.us Mon Oct 5 11:31:17 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 05 Oct 2009 09:31:17 -0700 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> Message-ID: <4ACA1F55.8040904@rollernet.us> Carsten Bormann wrote: > On Oct 5, 2009, at 17:38, Seth Mattinen wrote: > >> The most common thing I see is /64 if the end user only needs one >> subnet, /56 if they need more than one. > > Brrzt, wrong. Neither the end user nor you know the answer to that > question! > > So the only sensible thing is to always give them a /56. I'm just relating what's common *right now*, not what I would do personally. ~Seth From fw at deneb.enyo.de Mon Oct 5 11:37:02 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 05 Oct 2009 16:37:02 +0000 Subject: IPv6 peering between Internet2 and Hurricane Electric Message-ID: <87eiph6bm9.fsf@mid.deneb.enyo.de> It seems to be down, based on and trying to get a traceroute to he.net/2001:470:0:76::2 from the SEAT location. BGP seems to be up, though. Shouldn't this cause quite a few problems for Internet2 downstreams? (We received a report from an academic site in Brazil that some security.debian.org IPv6 instances are inaccessible, that's why I looked.) What's the best way to help the SPs involved to get this resolved? From patrick at ianai.net Mon Oct 5 11:50:02 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Oct 2009 12:50:02 -0400 Subject: operations contact @ facebook? In-Reply-To: <4ACA0C6A.3070103@evaristesys.com> References: <1254754008.4530.4.camel@leland-gandi> <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> <4ACA0C6A.3070103@evaristesys.com> Message-ID: On Oct 5, 2009, at 11:10 AM, Alex Balashov wrote: > Patrick W. Gilmore wrote: >> On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: >>> Would anyone happen to have an operations contact at Facebook by >>> anychance? Our systems are being overwhelmed by a facebook >>> application >>> that we were neither aware of nor condoned. >> Clearly I do not have all the information, so please forgive me for >> being confused. But since when do I[*] have to ask you before I >> put an application on my server? If FB put an application on your >> server, that seems like something you should have known up front. > > The original poster is from Paris. Do consider the possibility that > there are different jurisdictional rules or service terms in force > from your own. I certainly did not. And I would suggest we refuse to do so as an industry. The UN lists 192 countries, and there are several others (e.g. Vatican City, Scotland, etc.) which others may count. Many of these have provinces or states or whatever, and almost all have cities, towns, counties, etc., each of which may have its own laws & regulations. Operationally speaking (see, this is on-topic :), trying to consider every single one of those possible laws, rules, social norms, preferences, political slants, religious authorities, and whatever else may come into the mix when putting an object or code onto the Internet is simply not possible. Giving in to it, even a little bit, leads to ridiculous restrictions and stifling of many things on the 'Net. We should all push back HARD whenever someone over here tries to tell someone over there what to do. The OP responded with a quite reasonable answer (shared infrastructure) that had nothing to do with local jurisdiction. That is an operational issue. What laws your country, province, county, town, or church has set up for you should have zero operational impact on me if my gear is not in the same place. And maybe someday we can even get away from that whole "in the same place" idea. (Hey, one can dream.) -- TTFN, patrick From herrin-nanog at dirtside.com Mon Oct 5 11:58:08 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 5 Oct 2009 12:58:08 -0400 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> Message-ID: <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson wrote: > From what I can tell from an ISP perspective, the design of IPv6 is for > assignment of a /64 to an end user. Is this correct? Is this how it is > currently being done? If not, where am I going wrong? No. A /64 is one *subnet*. Essentially the standard, static size for any Ethernet LAN. For a customer, the following values are more appropriate: /128 - connecting exactly one computer. Probably only useful for your dynamic dialup customers. Any always-on or static-IP customer should probably have a CIDR block. /48 - current ARIN/IETF recommendation for a downstream customer connecting more than one computer unless that customer is large enough to need more than 65k LANs. /56 - in some folks opinion, slightly more sane than assigning a 65k subnets and bazillions of addresses to a home hobbyist with half a dozen PC's. /60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation, handling multiple routes when the customer grows, not matching the standard /64 subnet size and a myriad other obscure issues. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wavetossed at googlemail.com Mon Oct 5 12:07:53 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Mon, 5 Oct 2009 18:07:53 +0100 Subject: ISP customer assignments In-Reply-To: <4ACA1C89.6070901@foobar.org> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <4ACA1C89.6070901@foobar.org> Message-ID: <877585b00910051007y5770271aj65b7e51d180e8295@mail.gmail.com> > more-or-less. Can I suggest you read: > > http://en.wikipedia.org/wiki/IPv6 > > Think of ipv6 not as 128 bits of address space, but more as a addressing > system with a globally unique host part and 2^64 possible subnets. In this > respect it's substantially different to ipv4. And after reading Wikipedia, follow it up with ARIN's http://www.getipv6.info wiki site. --Michael Dillon From abalashov at evaristesys.com Mon Oct 5 12:10:05 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 05 Oct 2009 13:10:05 -0400 Subject: operations contact @ facebook? In-Reply-To: References: <1254754008.4530.4.camel@leland-gandi> <52EA9FE2-E35F-49E2-A02A-1FAD6B20EDC9@ianai.net> <4ACA0C6A.3070103@evaristesys.com> Message-ID: <4ACA286D.7010104@evaristesys.com> Patrick W. Gilmore wrote: > On Oct 5, 2009, at 11:10 AM, Alex Balashov wrote: >> Patrick W. Gilmore wrote: >>> On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: >>>> Would anyone happen to have an operations contact at Facebook by >>>> anychance? Our systems are being overwhelmed by a facebook application >>>> that we were neither aware of nor condoned. >>> Clearly I do not have all the information, so please forgive me for >>> being confused. But since when do I[*] have to ask you before I put >>> an application on my server? If FB put an application on your >>> server, that seems like something you should have known up front. >> >> The original poster is from Paris. Do consider the possibility that >> there are different jurisdictional rules or service terms in force >> from your own. > > I certainly did not. And I would suggest we refuse to do so as an > industry. > > The UN lists 192 countries, and there are several others (e.g. Vatican > City, Scotland, etc.) which others may count. Many of these have > provinces or states or whatever, and almost all have cities, towns, > counties, etc., each of which may have its own laws & regulations. > > Operationally speaking (see, this is on-topic :), trying to consider > every single one of those possible laws, rules, social norms, > preferences, political slants, religious authorities, and whatever else > may come into the mix when putting an object or code onto the Internet > is simply not possible. Giving in to it, even a little bit, leads to > ridiculous restrictions and stifling of many things on the 'Net. We > should all push back HARD whenever someone over here tries to tell > someone over there what to do. > > The OP responded with a quite reasonable answer (shared infrastructure) > that had nothing to do with local jurisdiction. That is an operational > issue. What laws your country, province, county, town, or church has set > up for you should have zero operational impact on me if my gear is not > in the same place. > > And maybe someday we can even get away from that whole "in the same > place" idea. (Hey, one can dream.) That is a very fair point. I cannot come up with any appealing counterarguments. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From bjohnson at drtel.com Mon Oct 5 13:10:15 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 5 Oct 2009 13:10:15 -0500 Subject: ISP customer assignments In-Reply-To: <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> Message-ID: <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> What would be "wrong" with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is. - Brian > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William > Herrin > Sent: Monday, October 05, 2009 11:58 AM > To: Brian Johnson > Cc: nanog at nanog.org > Subject: Re: ISP customer assignments > > On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson > wrote: > > From what I can tell from an ISP perspective, the design of IPv6 is > for > > assignment of a /64 to an end user. Is this correct? Is this how it > is > > currently being done? If not, where am I going wrong? > > No. A /64 is one *subnet*. Essentially the standard, static size for > any Ethernet LAN. For a customer, the following values are more > appropriate: > > /128 - connecting exactly one computer. Probably only useful for your > dynamic dialup customers. Any always-on or static-IP customer should > probably have a CIDR block. > > /48 - current ARIN/IETF recommendation for a downstream customer > connecting more than one computer unless that customer is large enough > to need more than 65k LANs. > > /56 - in some folks opinion, slightly more sane than assigning a 65k > subnets and bazillions of addresses to a home hobbyist with half a > dozen PC's. > > /60 - the smallest amount you should allocate to a downstream customer > with more than one computer. Anything smaller will cost you extra > management overhead from not matching the nibble boundary for RDNS > delegation, handling multiple routes when the customer grows, not > matching the standard /64 subnet size and a myriad other obscure > issues. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From cra at WPI.EDU Mon Oct 5 13:13:59 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 5 Oct 2009 14:13:59 -0400 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> Message-ID: <20091005181359.GP25513@angus.ind.WPI.EDU> On Mon, Oct 05, 2009 at 01:10:15PM -0500, Brian Johnson wrote: > What would be "wrong" with using a /64 for a customer who only has a > local network? Most home users won't understand what a subnet is. IPv6 CPE's may be designed to get one subnet per physical media via DHCPv6-PD, so for example wireless and wired may be different subnets. Really, /56 is the way to go for residential assignments. From lists at quux.de Mon Oct 5 13:18:23 2009 From: lists at quux.de (Jens Link) Date: Mon, 05 Oct 2009 20:18:23 +0200 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> (Brian Johnson's message of "Mon\, 5 Oct 2009 11\:08\:30 -0500") References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> Message-ID: <87k4z91z80.fsf@laphroiag.quux.de> "Brian Johnson" writes: > So a customer with a single PC hooked up to their broad-band connection > would be given 2^64 addresses? > > I realize that this is future proofing, but OMG! That?s the IPv4 > Internet^2 for a single device! Most people will have more than one device. And there is no NAT as you know it from IPv4 (and hopefully there never will be. I had to troubleshoot a NAT related problem today and it wasn't fun.[1]) And I want more than one network I want to have a firewall between my fridge and my file server. > Am I still seeing/reading/understanding this correctly? RFC 3177 suggest a /48. Forget about IPv4 when assigning IPv6 Networks to customers. Think big an take a one size fits all(most) customers approach. Assign a /48 or /56 to your customers and they will never ask you about additional IPs again. This make Documentation relay easy. ;-) cheers Jens [1] Everybody who claims that NAT is easy should have his or her head examined. -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From bzs at world.std.com Mon Oct 5 13:23:52 2009 From: bzs at world.std.com (Barry Shein) Date: Mon, 5 Oct 2009 14:23:52 -0400 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <4AC93ED9.5080909@linuxbox.org> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> Message-ID: <19146.14776.366948.254906@world.std.com> Perhaps someone has said this but a potential implementation problem in the US are anti-trust regulations. Sure, they may come around to seeing it your way since the intent is so good but then again "we all decided to get together and blacklist customers who..." is not a great elevator pitch to an attorney-general no matter how good the intent. Obviously there are ways around that (e.g., it's ok to do credit checks) but one has to be up-front and get approval. I'm just sayin': a) consult with legal counsel before doing anything in "collusion" with competitors. b) this is probably not for smaller ISPs until the legal way is cleared by those with plenty of money for lawyering and lobbying. (I did say "IN THE USA", right?) -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jgreco at ns.sol.net Mon Oct 5 13:35:08 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 5 Oct 2009 13:35:08 -0500 (CDT) Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> from "Brian Johnson" at Oct 05, 2009 11:08:30 AM Message-ID: <200910051835.n95IZ8Wt079490@aurora.sol.net> > So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? > > I realize that this is future proofing, but OMG! That???s the IPv4 Internet^2 for a single device! > > Am I still seeing/reading/understanding this correctly? The fact that you could use it for a single device is irrelevant. We have learned the problems imposed by the shortsightedness of IPv4. You're already given 65536 ports for your IPv4 device. OMG, you do not /really/ need that many for a single device! This issue has been hashed over many times. Stop thinking IPv4, where bits are in sufficiently short supply that we "feel" assignment of any extra space is "waste." Start thinking IPv6, where bits are in such great supply that it makes sense to think about stuff like making sure delegations are sufficiently large that your typical ASN isn't having to advertise a hundred prefixes of cobbled-together-over-the-years space, that NAT can be purged from the face of the earth, etc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From web at typo.org Mon Oct 5 13:34:51 2009 From: web at typo.org (Wayne E. Bouchard) Date: Mon, 5 Oct 2009 11:34:51 -0700 Subject: ISP customer assignments In-Reply-To: <87k4z91z80.fsf@laphroiag.quux.de> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> Message-ID: <20091005183451.GA53850@typo.org> On Mon, Oct 05, 2009 at 08:18:23PM +0200, Jens Link wrote: > "Brian Johnson" writes: > > > So a customer with a single PC hooked up to their broad-band connection > > would be given 2^64 addresses? > > > > I realize that this is future proofing, but OMG! That?s the IPv4 > > Internet^2 for a single device! > > Most people will have more than one device. And there is no NAT as you > know it from IPv4 (and hopefully there never will be. I had to > troubleshoot a NAT related problem today and it wasn't fun.[1]) > > And I want more than one network I want to have a firewall between my > fridge and my file server. > > > Am I still seeing/reading/understanding this correctly? > > RFC 3177 suggest a /48. > > Forget about IPv4 when assigning IPv6 Networks to customers. Think big an > take a one size fits all(most) customers approach. Assign a /48 or /56 to > your customers and they will never ask you about additional IPs > again. This make Documentation relay easy. ;-) > > cheers > > Jens Am I the only one that finds this problematic? I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying "oh, lets just put a /64 on every interface" pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good. Lets think longer term... IPv4 is several decades old now and still in use. If IPv6 lasts another 50 years before someone decides that it needs a redo, with current practices, what will things look like? Consider the population at that point and consider the number of interfaces as more and more devices become IP enabled. "wireless" devices have their own issues to content with (spectrum being perhaps the biggest limiter) so wired devices will always be around. That means physical interfaces and probably multiple LANs in each residence. I can see where each device may want its own LAN and will talk to components of itself using IP internally, perhaps even having a valid reason for having these individual components publically addressable. Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.) -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From herrin-nanog at dirtside.com Mon Oct 5 13:37:49 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 5 Oct 2009 14:37:49 -0400 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> Message-ID: <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> On Mon, Oct 5, 2009 at 2:10 PM, Brian Johnson wrote: > What would be "wrong" with using a /64 for a customer who only has a > local network? Most home users won't understand what a subnet is. It's a question of convenience... your customers', but more importantly yours. Every time you have to deviate from your default, whatever default you pick, that's an extra overhead cost you have to bear. Absent a compelling reason not to, you should structure your default choice so that it accommodates as many customers as possible. There are too many good reasons why someone might want to use two subnets with two different security policies and not enough reasons (zero in fact) why it would help you to give them less subnets than the 16 in a /60. > So a customer with a single PC hooked up to their broad-band > connection would be given 2^64 addresses? > I realize that this is future proofing, but OMG! That?s the IPv4 > Internet^2 for a single device! Some clever guy figured out that if you use 64 bits you can write algorithms that automatically assign an interface's IP address based on its MAC address without having to arp for it. Since the details of IPv6 were not yet firmly fixed at that point and ram is cheap, why not add an extra 64 bits for that very convenient improvement? This is called "stateless autoconfiguration." Some even more clever guy figured out that if the first clever guy's strategy is used, it becomes a trivial matter to track someone online... based on the last 64 bits of their IP address which will remain static for the life of the hardware they use regardless of where they connect to the 'net. Given this rather blatent weakness and given that you still need DHCP to assign DNS resolvers and the like, stateless autoconfiguration will probably end up being a waste. That's unfortunate, but look at it this way: the important part is not how many addresses are wasted, it's how many addresses are usable. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From smb at cs.columbia.edu Mon Oct 5 13:38:50 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 5 Oct 2009 14:38:50 -0400 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> Message-ID: <06662651-0E15-401D-9300-8716A2DA8E64@cs.columbia.edu> On Oct 5, 2009, at 2:10 PM, Brian Johnson wrote: > What would be "wrong" with using a /64 for a customer who only has a > local network? Most home users won't understand what a subnet is. They probably don't -- but some appliance they buy might. Maybe some home "family-oriented" box will put the kids' machines on a separate VLAN, to permit rate-limiting, port- and destination-filtering, time- of-day limits, etc. In the past, I had to do similar things -- no AIM during homework hours, no file-sharing -- to the point that I had four subnets in my house (wireless, teen-net, workVPN, and backbone/ parents). I don't expect the average consumer to set up something like that, but I sure wouldn't be surprised at appliances that did. --Steve Bellovin, http://www.cs.columbia.edu/~smb From bdavis at Fairpoint.com Mon Oct 5 13:46:08 2009 From: bdavis at Fairpoint.com (Davis, Bill (Manchester, NH)) Date: Mon, 5 Oct 2009 13:46:08 -0500 Subject: FairPoint New England Internet Access issues. Message-ID: <1C118F225B16B9428361BFFC521B7E8501D24A86@ksdcmail.fairpoint.com> Oct 2, 2009: Verizon identified it largest CORE Juniper router was creating issues for all of it peering points to New York and Boston having said that all of FairPoint's DIA, DSL, Fast customer had intermittent issues accessing the internet partial service was restored after Verizon reroute part of FairPoint traffic. Verizon was able to replace the Juniper router and restore full service around 1:45 PM EDT October 3rd 2009. Bill Davis William P. Davis - Director IT Network FairPoint Communications | 900 Elm St., Manchester, NH 03101 | bdavis at fairpoint.com 620-339-4786 office | 309-696-0299 Cell _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From jgreco at ns.sol.net Mon Oct 5 14:10:59 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 5 Oct 2009 14:10:59 -0500 (CDT) Subject: ISP customer assignments In-Reply-To: <20091005183451.GA53850@typo.org> from "Wayne E. Bouchard" at Oct 05, 2009 11:34:51 AM Message-ID: <200910051910.n95JAxAI080749@aurora.sol.net> > Am I the only one that finds this problematic? No, but most of the people who find this "problematic" haven't done any looking into the matter. > I mean, the whole point > of moving to a 128 bit address was to ensure that we would never again > have a problem of address depletion. Now I'm not saying that this puts > us anywhere in that boat (yet) but isn't saying "oh, lets just put a > /64 on every interface" pretty well ignoring the lessons of the last > 20 years? Surely a /96 or even a /112 would have been just as good. No, it wouldn't have been. The sheer usefulness of having things like stateless autoconfig for many trivial applications should not be underestimated. > Lets think longer term... IPv4 is several decades old now and still in > use. If IPv6 lasts another 50 years before someone decides that it > needs a redo, with current practices, what will things look like? > Consider the population at that point and consider the number of > interfaces as more and more devices become IP enabled. "wireless" > devices have their own issues to content with (spectrum being perhaps > the biggest limiter) so wired devices will always be around. That > means physical interfaces and probably multiple LANs in each > residence. I can see where each device may want its own LAN and will > talk to components of itself using IP internally, perhaps even having > a valid reason for having these individual components publically > addressable. Do some math, then. A /64 handles a single network. An essentially infinite number of devices can live within that space, though there are practical limits. You might realistically have a network for your light switches and a network for your A/V gear. You seem to anticipate that, so let's just say we agree, but I'm going to make a big whopper claim and say that we should delegate /48 to end users. This means each user could have up to 65,536 /64's. While I can daydream about scenarios that would eat up a significant fraction of those subnets, I have to also concede that consolidation is probably possible. Population today is about 7 billion. A fairly aggressive long range report by the UN puts population in 2300 as high as maybe 40 billion, or about six times our current population. Let's just pretend we had the 40 billion today. To come up with 40 billion unique /48 allocations, we'd need almost 36 bits. Of course, this assumes that you can sequentially allocate them. More realistic scenarios suggest that you'd have several bits worth of sparseness. Maybe 40 bits. Okay, 40 bits is close to 48 bits. But we're not delegating /48's to everyone (yet) and we don't have 40 billion people on the planet. > Like I said, I'm not necessarily saying we're going to find ourselves > in that boat again but it does seem as though more thought is > required. (And yes, I fully realize the magnitude of 2^64. I also > fully realize how quickly inexhaustable resources become rationable.) People HAVE done the thought. They've thought about it and argued it back and forth for years. This isn't a good place to continue to beat the discolored spot where the dead horse formerly lay; there are some discussions in the NANOG archives as it stands. It's mostly only those who are steeped in the IPv4 thinking and who haven't done the math are concerned about /64's. And note that you're *free* to go allocate a /96 or a /112 to your devices if you really want to do the manual configuration. What's required is for you to do the thinking as to whether or not it is worth it to paddle furiously against the current to save a resource that is in no short supply. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jfbeam at gmail.com Mon Oct 5 15:43:16 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 05 Oct 2009 16:43:16 -0400 Subject: ISP customer assignments In-Reply-To: <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> Message-ID: [here we go again] On Mon, 05 Oct 2009 14:37:49 -0400, William Herrin wrote: > Some clever guy figured out that ... why not > add an extra 64 bits for that very convenient improvement? This is > called "stateless autoconfiguration." Except that "clever guy" was in fact an idiot blinded by idealism. Not only did he fail to see the security implications of having a fixed address, but he'd apparently spent his entire life under a rock, on an island, on another planet... he completely ignored the fact that people were using DHCP [formerly known as BOOTP] (and have been now for over a decade) to provide machines with FAR MORE than just an address. A machine needs more than just an address to be useful -- something IPv6 users learn very quickly after turning off IPv4 and it's DHCP learned info. > Some even more clever guy figured out that if the first clever guy's > strategy is used, it becomes a trivial matter to track someone > online... ... > stateless autoconfiguration will probably end up being a waste. It's ALWAYS been a waste. All these supposed "clever guys" failed to learn from the mistakes that preceded them and have doomed us to repeat them... ICMP router discovery (technology abandoned so long ago, I'd forgotten about it), RARP, bootp, dhcp. SLAAC loops us back around to the beginning. Only this time, it's inescapable: I still have to have something on the network spewing RAs for the sole purpose of telling everything to use DHCP instead; there's a hard "class" boundary smack in the middle of a "classless network" because these "clever guys" were lazy and didn't want to figure out ways to avoid address collisions. (something modern IPv6 stacks do by default for privacy -- randomly generated addresses have to be tested for uniqueness.) --Ricky From tjc at ecs.soton.ac.uk Mon Oct 5 16:09:34 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 5 Oct 2009 22:09:34 +0100 Subject: ISP customer assignments In-Reply-To: <20091005183451.GA53850@typo.org> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <20091005210934.GG7015@login.ecs.soton.ac.uk> Message-ID: On Mon, Oct 05, 2009 at 11:34:51AM -0700, Wayne E. Bouchard wrote: > > Am I the only one that finds this problematic? I mean, the whole point > of moving to a 128 bit address was to ensure that we would never again > have a problem of address depletion. Now I'm not saying that this puts > us anywhere in that boat (yet) but isn't saying "oh, lets just put a > /64 on every interface" pretty well ignoring the lessons of the last > 20 years? Surely a /96 or even a /112 would have been just as good. The current guidance applies only to one /3 out of eight. Different rules could be applied to the others. > Like I said, I'm not necessarily saying we're going to find ourselves > in that boat again but it does seem as though more thought is > required. (And yes, I fully realize the magnitude of 2^64. I also > fully realize how quickly inexhaustable resources become rationable.) As it happens, Windows boxes now generate random interface IDs (not based on MACs), which could have easily been 32 bits with the default subnet 96 bits long, rather than 64 bits. But we are where we are and we do have interesting ideas like CGAs as a result. -- Tim From dwhite at olp.net Mon Oct 5 16:13:37 2009 From: dwhite at olp.net (Dan White) Date: Mon, 5 Oct 2009 16:13:37 -0500 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> Message-ID: <20091005211337.GP5403@dan.olp.net> On 05/10/09?16:43?-0400, Ricky Beam wrote: > [here we go again] > > On Mon, 05 Oct 2009 14:37:49 -0400, William Herrin > wrote: >> Some clever guy figured out that ... why not >> add an extra 64 bits for that very convenient improvement? This is >> called "stateless autoconfiguration." > > Except that "clever guy" was in fact an idiot blinded by idealism. Not > only did he fail to see the security implications of having a fixed > address, but he'd apparently spent his entire life under a rock, on an a publicly routeable stateless auto configured address is no less secure than a publicly routeable address assigned by DHCP. Security is, and should be, handled by other means. > island, on another planet... he completely ignored the fact that people > were using DHCP [formerly known as BOOTP] (and have been now for over a > decade) to provide machines with FAR MORE than just an address. A That's what stateless DHCP does. >> Some even more clever guy figured out that if the first clever guy's >> strategy is used, it becomes a trivial matter to track someone >> online... ... >> stateless autoconfiguration will probably end up being a waste. > > It's ALWAYS been a waste. All these supposed "clever guys" failed to > learn from the mistakes that preceded them and have doomed us to repeat > them... ICMP router discovery (technology abandoned so long ago, I'd > forgotten about it), RARP, bootp, dhcp. SLAAC loops us back around to > the beginning. Only this time, it's inescapable: I still have to have > something on the network spewing RAs for the sole purpose of telling > everything to use DHCP instead; there's a hard "class" boundary smack in > the middle of a "classless network" because these "clever guys" were lazy > and didn't want to figure out ways to avoid address collisions. I don't understand. You're saying you have overlapping class boundaries in your network? > (something modern IPv6 stacks do by default for privacy -- randomly > generated addresses have to be tested for uniqueness.) -- Dan White BTC Broadband From owenc at hubris.net Mon Oct 5 16:20:44 2009 From: owenc at hubris.net (Chris Owen) Date: Mon, 5 Oct 2009 16:20:44 -0500 Subject: ISP customer assignments In-Reply-To: <20091005184356.GA54050@typo.org> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <289980C1-5681-4EEA-9D9C-89BFF3715E7E@ksip.net> <20091005184356.GA54050@typo.org> Message-ID: On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: > Whenever you declare something to be "inexhasutable" all you do is > increase demand. Eventually you reach a point where you realize that > there is, in fact, a limit to the inexhaustable resource. This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. 2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume everyone might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000. Chris ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net ------------------------------------------------------------------------- From dwhite at olp.net Mon Oct 5 16:28:57 2009 From: dwhite at olp.net (Dan White) Date: Mon, 5 Oct 2009 16:28:57 -0500 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <289980C1-5681-4EEA-9D9C-89BFF3715E7E@ksip.net> <20091005184356.GA54050@typo.org> Message-ID: <20091005212857.GQ5403@dan.olp.net> On 05/10/09?16:20?-0500, Chris Owen wrote: > On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: > >> Whenever you declare something to be "inexhasutable" all you do is >> increase demand. Eventually you reach a point where you realize that >> there is, in fact, a limit to the inexhaustable resource. > > This is where I think there is a major disconnect on IPv6. The size of > the pool is just so large that people just can't wrap their heads around > it. I think another disconnect is our understanding and expectations of addressing needs with IPv6. The challenge of IPv6 address assignment is to predict what home and enterprise networks will look like in 10, 20 or more years. Do we want to implement an assignment method of conservation based on what we know and understand today, that maximizes the lifetime of IPv6? Or do we want to use an approach that maximizes its usefulness (and the utility of the internet) over the next 50 years? -- Dan White BTC Broadband From bmanning at vacation.karoshi.com Mon Oct 5 16:32:03 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Oct 2009 21:32:03 +0000 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <289980C1-5681-4EEA-9D9C-89BFF3715E7E@ksip.net> <20091005184356.GA54050@typo.org> Message-ID: <20091005213203.GB3136@vacation.karoshi.com.> considered top posting to irritate a few folks, decided not to. On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: > On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: > > >Whenever you declare something to be "inexhasutable" all you do is > >increase demand. Eventually you reach a point where you realize that > >there is, in fact, a limit to the inexhaustable resource. > > This is where I think there is a major disconnect on IPv6. The size > of the pool is just so large that people just can't wrap their heads > around it. > > 2^128 is enough space for every man, woman and child on the planet to > have around 4 billion /64s to themselves. Even if we assume everyone > might possibly need say 10 /64s per person that still means we are > covered until the population hits around 2,600,000,000,000,000,000. > > Chris > here, you expose a hidebound bias to 20th century networking. please remember that - with few exceptions - people network at a very different level than machines. people don't need IP addresses - computing nodes that want to communicate do. Just for grins, put a unique IPv6 address in every active RFID tag. ... and remember that there are RFID printers that can put 18 tags on a single A4 sheet. Numbers will become disposible, like starbucks coffee cups and MCD's bigmac containers. --bill From dhetzel at gmail.com Mon Oct 5 16:47:12 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 5 Oct 2009 17:47:12 -0400 Subject: ISP customer assignments In-Reply-To: <20091005213203.GB3136@vacation.karoshi.com.> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <289980C1-5681-4EEA-9D9C-89BFF3715E7E@ksip.net> <20091005184356.GA54050@typo.org> <20091005213203.GB3136@vacation.karoshi.com.> Message-ID: <7db2dcf90910051447r5bd7e42fja0b750dceb8d764@mail.gmail.com> The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a little less than 6x10^24Kg. 2^128 is around 3.4x10^38. So in a flat address space we have about one IPV6 address for every 20,000Kg in the galaxy or for every 20 picograms in the earth... One would hope it would last for a while :) On Mon, Oct 5, 2009 at 5:32 PM, wrote: > > considered top posting to irritate a few folks, decided not to. > > > On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: > > On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: > > > > >Whenever you declare something to be "inexhasutable" all you do is > > >increase demand. Eventually you reach a point where you realize that > > >there is, in fact, a limit to the inexhaustable resource. > > > > This is where I think there is a major disconnect on IPv6. The size > > of the pool is just so large that people just can't wrap their heads > > around it. > > > > 2^128 is enough space for every man, woman and child on the planet to > > have around 4 billion /64s to themselves. Even if we assume everyone > > might possibly need say 10 /64s per person that still means we are > > covered until the population hits around 2,600,000,000,000,000,000. > > > > Chris > > > > here, you expose a hidebound bias to 20th century networking. > please remember that - with few exceptions - people network > at a very different level than machines. people don't need > IP addresses - computing nodes that want to communicate do. > > Just for grins, put a unique IPv6 address in every active RFID > tag. ... and remember that there are RFID printers that can > put 18 tags on a single A4 sheet. Numbers will become disposible, > like starbucks coffee cups and MCD's bigmac containers. > > --bill > > From joelja at bogus.com Mon Oct 5 16:49:39 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 05 Oct 2009 14:49:39 -0700 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> Message-ID: <4ACA69F3.8030604@bogus.com> Brian Johnson wrote: > So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? No, that's a single subnet, typically they should be assigned more than that. > I realize that this is future proofing, but OMG! That?s the IPv4 Internet^2 for a single device! > > Am I still seeing/reading/understanding this correctly? > > - Brian > >> -----Original Message----- >> From: Seth Mattinen [mailto:sethm at rollernet.us] >> Sent: Monday, October 05, 2009 10:38 AM >> To: nanog at nanog.org >> Subject: Re: ISP customer assignments >> >> Brian Johnson wrote: >>> >From what I can tell from an ISP perspective, the design of IPv6 is >> for >>> assignment of a /64 to an end user. Is this correct? Is this how it >> is >>> currently being done? If not, where am I going wrong? >>> >> The most common thing I see is /64 if the end user only needs one >> subnet, /56 if they need more than one. >> >> ~Seth > From wavetossed at googlemail.com Mon Oct 5 17:06:21 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Mon, 5 Oct 2009 23:06:21 +0100 Subject: ISP customer assignments In-Reply-To: <20091005212857.GQ5403@dan.olp.net> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <289980C1-5681-4EEA-9D9C-89BFF3715E7E@ksip.net> <20091005184356.GA54050@typo.org> <20091005212857.GQ5403@dan.olp.net> Message-ID: <877585b00910051506p1480822cx42ad31497b6e7401@mail.gmail.com> >> This is where I think there is a major disconnect on IPv6. ? The size of >> the pool is just so large that people just can't wrap their heads around it. Why bother wrapping your head around it? Do you count how many computers are in your house? Did you remember to count the CPU inside the PC keyboards? Does it matter? IPv6 addresses are not for you, they are not for your house, and they are not for your network. IPv6 addresses are for network interfaces, physical and virtual, and these interfaces are free to use multiple IPv6 addresses at the same time for various reasons. Why even try to count that unless you are a protocol designer? Fact is that IPv6 is dead simple. You, the ISP, get a /32 from ARIN unless you are really big. You give your customers a /48. If you have a really, really big number of really small (consumer) customers, then you can add another level of complexity and give them a /56. Every time you set up a new network segment (broadcast domain) you assign it a /64. All /64s in one building should really be out of the same /48 unless you are segregating internal use networks from transit service networks, in which case there would be two /48s for the building. Forget counting bits except between /32 and /48 for your ISP business and between /48 and /64 for your network building business. --Michael Dillon From bmanning at vacation.karoshi.com Mon Oct 5 17:05:23 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Oct 2009 22:05:23 +0000 Subject: ISP customer assignments In-Reply-To: <7db2dcf90910051447r5bd7e42fja0b750dceb8d764@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <289980C1-5681-4EEA-9D9C-89BFF3715E7E@ksip.net> <20091005184356.GA54050@typo.org> <20091005213203.GB3136@vacation.karoshi.com.> <7db2dcf90910051447r5bd7e42fja0b750dceb8d764@mail.gmail.com> Message-ID: <20091005220523.GA3549@vacation.karoshi.com.> well - if we are presuming a -FLAT- space, then IPv4 will last a great deal longer than 2011. and tell your vendors to pump up the CAM/ARP table sizes ... and bring back the ARP storms of the 1980s. (who owns the vitalink codes base anyway?) --bill On Mon, Oct 05, 2009 at 05:47:12PM -0400, Dorn Hetzel wrote: > The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a > little less than 6x10^24Kg. > > 2^128 is around 3.4x10^38. > So in a flat address space we have about one IPV6 address for every 20,000Kg > in the galaxy or for every 20 picograms in the earth... > > One would hope it would last for a while :) > > On Mon, Oct 5, 2009 at 5:32 PM, wrote: > > > > > considered top posting to irritate a few folks, decided not to. > > > > > > On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: > > > On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: > > > > > > >Whenever you declare something to be "inexhasutable" all you do is > > > >increase demand. Eventually you reach a point where you realize that > > > >there is, in fact, a limit to the inexhaustable resource. > > > > > > This is where I think there is a major disconnect on IPv6. The size > > > of the pool is just so large that people just can't wrap their heads > > > around it. > > > > > > 2^128 is enough space for every man, woman and child on the planet to > > > have around 4 billion /64s to themselves. Even if we assume everyone > > > might possibly need say 10 /64s per person that still means we are > > > covered until the population hits around 2,600,000,000,000,000,000. > > > > > > Chris > > > > > > > here, you expose a hidebound bias to 20th century networking. > > please remember that - with few exceptions - people network > > at a very different level than machines. people don't need > > IP addresses - computing nodes that want to communicate do. > > > > Just for grins, put a unique IPv6 address in every active RFID > > tag. ... and remember that there are RFID printers that can > > put 18 tags on a single A4 sheet. Numbers will become disposible, > > like starbucks coffee cups and MCD's bigmac containers. > > > > --bill > > > > From Valdis.Kletnieks at vt.edu Mon Oct 5 17:35:09 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Oct 2009 18:35:09 -0400 Subject: ISP customer assignments In-Reply-To: Your message of "Mon, 05 Oct 2009 16:13:37 CDT." <20091005211337.GP5403@dan.olp.net> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> Message-ID: <174173.1254782109@turing-police.cc.vt.edu> On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said: > a publicly routeable stateless auto configured address is no less > secure than a publicly routeable address assigned by DHCP. Security is, and > should be, handled by other means. The problem is user tracking and privacy. RFC4941's problem statement: Addresses generated using stateless address autoconfiguration [ADDRCONF] contain an embedded interface identifier, which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. The correlation can be performed by o An attacker who is in the path between the node in question and the peer(s) to which it is communicating, and who can view the IPv6 addresses present in the datagrams. o An attacker who can access the communication logs of the peers with which the node has communicated. Since the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. This document proposes a solution to this issue by generating interface identifiers that vary over time. Note that an attacker, who is on path, may be able to perform significant correlation based on o The payload contents of the packets on the wire o The characteristics of the packets such as packet size and timing Use of temporary addresses will not prevent such payload-based correlation. (end quote) Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at work, at a hotel, and a few other places, you'll get a whole raft of answers which will be very hard to cross-corrolate. But if all those places did IPv6 autoconfig, the correlation would be easy, because my address would always end in 215:c5ff:fec8:334e - and no other users should have those last 64 bits. Amazingly enough, some people think making it too easy to Big-Brother you is a security issue... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Mon Oct 5 17:47:29 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Oct 2009 15:47:29 -0700 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> Message-ID: <7D41DD1D-5918-460B-872F-1977850D6903@delong.com> It's very likely that they won't understand, won't have to, and will still need them. Let's face it, most customer's don't know what an IP address is, really, but, they still need them and they still use them all the time. It is, as someone else stated, very likely that there will be home routers that have multiple zones on multiple interfaces each of which gets a different /64 from a /56 or /48 handed to it by the upstream DHCP-PD box. Owen On Oct 5, 2009, at 11:10 AM, Brian Johnson wrote: > What would be "wrong" with using a /64 for a customer who only has a > local network? Most home users won't understand what a subnet is. > > - Brian > > >> -----Original Message----- >> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of > William >> Herrin >> Sent: Monday, October 05, 2009 11:58 AM >> To: Brian Johnson >> Cc: nanog at nanog.org >> Subject: Re: ISP customer assignments >> >> On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson >> wrote: >>> From what I can tell from an ISP perspective, the design of IPv6 is >> for >>> assignment of a /64 to an end user. Is this correct? Is this how it >> is >>> currently being done? If not, where am I going wrong? >> >> No. A /64 is one *subnet*. Essentially the standard, static size for >> any Ethernet LAN. For a customer, the following values are more >> appropriate: >> >> /128 - connecting exactly one computer. Probably only useful for your >> dynamic dialup customers. Any always-on or static-IP customer should >> probably have a CIDR block. >> >> /48 - current ARIN/IETF recommendation for a downstream customer >> connecting more than one computer unless that customer is large >> enough >> to need more than 65k LANs. >> >> /56 - in some folks opinion, slightly more sane than assigning a 65k >> subnets and bazillions of addresses to a home hobbyist with half a >> dozen PC's. >> >> /60 - the smallest amount you should allocate to a downstream >> customer >> with more than one computer. Anything smaller will cost you extra >> management overhead from not matching the nibble boundary for RDNS >> delegation, handling multiple routes when the customer grows, not >> matching the standard /64 subnet size and a myriad other obscure >> issues. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com >> bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 From dwhite at olp.net Mon Oct 5 17:55:35 2009 From: dwhite at olp.net (Dan White) Date: Mon, 5 Oct 2009 17:55:35 -0500 Subject: ISP customer assignments In-Reply-To: <174173.1254782109@turing-police.cc.vt.edu> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <174173.1254782109@turing-police.cc.vt.edu> Message-ID: <20091005225534.GU5403@dan.olp.net> On 05/10/09?18:35?-0400, Valdis.Kletnieks at vt.edu wrote: >On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said: > >> a publicly routeable stateless auto configured address is no less >> secure than a publicly routeable address assigned by DHCP. Security is, and >> should be, handled by other means. > >The problem is user tracking and privacy. > >Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at >work, at a hotel, and a few other places, you'll get a whole raft of answers >which will be very hard to cross-corrolate. But if all those places did >IPv6 autoconfig, the correlation would be easy, because my address would >always end in 215:c5ff:fec8:334e - and no other users should have those >last 64 bits. All of the items in the above list are true of DHCP. The only difference is how long that correlation will be taking place. You're likely to keep using the same addresses at each site (unless the DHCP server is configured not to). DHCP servers themselves tend to re-hand out addresses based on seeing the same MAC address. Is it really a secure approach to depend on how often you go mobile? Random address assignment *is* auto configuration (well, a modified form of it). That seems to be much better. -- Dan White BTC Broadband From owen at delong.com Mon Oct 5 17:55:02 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Oct 2009 15:55:02 -0700 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <19146.14776.366948.254906@world.std.com> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <19146.14776.366948.254906@world.std.com> Message-ID: On Oct 5, 2009, at 11:23 AM, Barry Shein wrote: > > Perhaps someone has said this but a potential implementation problem > in the US are anti-trust regulations. Sure, they may come around to > seeing it your way since the intent is so good but then again "we all > decided to get together and blacklist customers who..." is not a great > elevator pitch to an attorney-general no matter how good the intent. > That's not what is being discussed from my understanding. From my understanding, the intent is to share names of known abusers and data necessary to help in tracking DDOS. I don't believe that any ISP is expected to necessarily take any particular action determined by the group with respect to the list of names they are given. I do think that it is reasonable to have an agreement among an industry organization or collaboration which states that ISPs which determine that abuse is being sourced from one of their customers (either through their own processes or by notification from another participant) should be expected to take the necessary steps to mitigate that abuse from exiting said ISPs autonomous system. > Obviously there are ways around that (e.g., it's ok to do credit > checks) but one has to be up-front and get approval. > I don't think that's true. I think that as long as your privacy policy and terms of service state that you will share certain information with other operators regarding abuse complaints and (possibly) abusive activities, you are free to share that information. Having a coalition rule that says any member must refuse to service any party on the list would be an anti-trust violation. Having a list, alone, without any rules about how the list is used, is not an anti-trust violation. Just like agreeing ahead of time on the price of gas amongst multiple competitors is an anti-trust violation, posting the price of gas at your service stations is not. Modifying your price to match the price across the street also is not. > I'm just sayin': > > a) consult with legal counsel before doing anything in "collusion" > with competitors. > Definitely. > b) this is probably not for smaller ISPs until the legal way is > cleared by those with plenty of money for lawyering and lobbying. > I'm not so sure that is true, but, they should seek good legal counsel about whatever they plan to do regardless of size. Owen From web at typo.org Mon Oct 5 18:09:40 2009 From: web at typo.org (Wayne E. Bouchard) Date: Mon, 5 Oct 2009 16:09:40 -0700 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <19146.14776.366948.254906@world.std.com> Message-ID: <20091005230940.GA55612@typo.org> On Mon, Oct 05, 2009 at 03:55:02PM -0700, Owen DeLong wrote: > > On Oct 5, 2009, at 11:23 AM, Barry Shein wrote: > > > > >Perhaps someone has said this but a potential implementation problem > >in the US are anti-trust regulations. Sure, they may come around to > >seeing it your way since the intent is so good but then again "we all > >decided to get together and blacklist customers who..." is not a great > >elevator pitch to an attorney-general no matter how good the intent. > > > That's not what is being discussed from my understanding. > > From my understanding, the intent is to share names of known > abusers and data necessary to help in tracking DDOS. > > I don't believe that any ISP is expected to necessarily take any > particular action determined by the group with respect to the > list of names they are given. > > I do think that it is reasonable to have an agreement among > an industry organization or collaboration which states that > ISPs which determine that abuse is being sourced from one of > their customers (either through their own processes or by > notification from another participant) should be expected to > take the necessary steps to mitigate that abuse from exiting > said ISPs autonomous system. In a way, this is kind of like stores keeping a list of bad check writers. The whole information sharing thing can get more than a little touchy from a legal perspective. Then again, an independant database could also be viewed as a sort of internet credit agency. Stuff in a name, get a score back and certain flags and make your judgement based on that. "I'm sorry, I can't give you an email account. Your internet-karma rating came back below our minimum levels." -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From owen at delong.com Mon Oct 5 18:05:06 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Oct 2009 16:05:06 -0700 Subject: ISP customer assignments In-Reply-To: <20091005183451.GA53850@typo.org> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> Message-ID: On Oct 5, 2009, at 11:34 AM, Wayne E. Bouchard wrote: > On Mon, Oct 05, 2009 at 08:18:23PM +0200, Jens Link wrote: >> "Brian Johnson" writes: >> >>> So a customer with a single PC hooked up to their broad-band >>> connection >>> would be given 2^64 addresses? >>> >>> I realize that this is future proofing, but OMG! That?s the IPv4 >>> Internet^2 for a single device! >> >> Most people will have more than one device. And there is no NAT as >> you >> know it from IPv4 (and hopefully there never will be. I had to >> troubleshoot a NAT related problem today and it wasn't fun.[1]) >> >> And I want more than one network I want to have a firewall between my >> fridge and my file server. >> >>> Am I still seeing/reading/understanding this correctly? >> >> RFC 3177 suggest a /48. >> >> Forget about IPv4 when assigning IPv6 Networks to customers. Think >> big an >> take a one size fits all(most) customers approach. Assign a /48 or / >> 56 to >> your customers and they will never ask you about additional IPs >> again. This make Documentation relay easy. ;-) >> >> cheers >> >> Jens > > Am I the only one that finds this problematic? I mean, the whole point > of moving to a 128 bit address was to ensure that we would never again > have a problem of address depletion. Now I'm not saying that this puts > us anywhere in that boat (yet) but isn't saying "oh, lets just put a > /64 on every interface" pretty well ignoring the lessons of the last > 20 years? Surely a /96 or even a /112 would have been just as good. > Nope.... It really isn't. If we wanted to do that, then, IPv6 would probably have 64-bit addressing, instead of 128-bit, and, you'd have 32 bits of carrier, 16 bits of end- site, 8 bits of subnet and 8 bits of host (or something approximating that). Part of the reason that 128 bits was chosen (64 bits is FAR more than enough) was that it allowed for 64 bits of stateless auto-configuration (IEEE was already pushing EUI-64) within each network and still provided more than enough network numbers. > Lets think longer term... IPv4 is several decades old now and still in > use. If IPv6 lasts another 50 years before someone decides that it > needs a redo, with current practices, what will things look like? OK. > Consider the population at that point and consider the number of > interfaces as more and more devices become IP enabled. "wireless" > devices have their own issues to content with (spectrum being perhaps > the biggest limiter) so wired devices will always be around. That The planet's sustainable population is not likely to exceed 10 billion. (However, current growth is approximately 80 million per year, so, our current 6 billion + 80 million * 50 = 4 billion still puts us at around 10 billion, so, it should be a safe number even if we throw sustainability out the window). IPv6 offers us 32 bits of provider units == 4 billion providers. Each provider can serve 65,536 customer units which gives us the ability to support 281,474,976,710,656, or, about 281 trillion customers. Each customer unit gets 65,536 subnets to do with as they like and they still have 64 bits on each subnet. > means physical interfaces and probably multiple LANs in each > residence. I can see where each device may want its own LAN and will > talk to components of itself using IP internally, perhaps even having > a valid reason for having these individual components publically > addressable. > It's OK. We can do it. We will still have addresses to spare even in 50 years, even with that. > Like I said, I'm not necessarily saying we're going to find ourselves > in that boat again but it does seem as though more thought is > required. (And yes, I fully realize the magnitude of 2^64. I also > fully realize how quickly inexhaustable resources become rationable.) > Well... There is a safety valve. We are only issuing from 1/8th of the current address space at this time. If we run that out before we expect to and it becomes clear that there is a need to allocate differently, we can begin doing that from the next 1/8th without any real changes to the protocol or router software. Really, it's OK. Owen From Robert.E.VanOrmer at frb.gov Mon Oct 5 18:41:08 2009 From: Robert.E.VanOrmer at frb.gov (Robert.E.VanOrmer at frb.gov) Date: Mon, 5 Oct 2009 19:41:08 -0400 Subject: ISP customer assignments Message-ID: The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste. Food for thought... >Message: 3 >Date: Mon, 5 Oct 2009 17:47:12 -0400 >From: Dorn Hetzel >Subject: Re: ISP customer assignments >To: bmanning at vacation.karoshi.com >Cc: NANOG list >Message-ID: > <7db2dcf90910051447r5bd7e42fja0b750dceb8d764 at mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a >little less than 6x10^24Kg. > > 2^128 is around 3.4x10^38. >So in a flat address space we have about one IPV6 address for every 20,000Kg >in the galaxy or for every 20 picograms in the earth... > >One would hope it would last for a while :) > >On Mon, Oct 5, 2009 at 5:32 PM, wrote: > >> >> considered top posting to irritate a few folks, decided not to. >> >> >> On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: >> > On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: >> > >> > >Whenever you declare something to be "inexhasutable" all you do is >> > >increase demand. Eventually you reach a point where you realize that >> > >there is, in fact, a limit to the inexhaustable resource. >> > >> > This is where I think there is a major disconnect on IPv6. The size >> > of the pool is just so large that people just can't wrap their heads >> > around it. >> > >> > 2^128 is enough space for every man, woman and child on the planet to >> > have around 4 billion /64s to themselves. Even if we assume everyone >> > might possibly need say 10 /64s per person that still means we are >> > covered until the population hits around 2,600,000,000,000,000,000. >> > >> > Chris >> > >> >> here, you expose a hidebound bias to 20th century networking. >> please remember that - with few exceptions - people network >> at a very different level than machines. people don't need >> IP addresses - computing nodes that want to communicate do. >> >> Just for grins, put a unique IPv6 address in every active RFID >> tag. ... and remember that there are RFID printers that can >> put 18 tags on a single A4 sheet. Numbers will become disposible, >> like starbucks coffee cups and MCD's bigmac containers. >> >> --bill >> >> From nanog at daork.net Mon Oct 5 18:43:58 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 6 Oct 2009 12:43:58 +1300 Subject: Dutch ISPs to collaborate and take responsibility for botted clients In-Reply-To: <4AC9FCDC.9060709@justinshore.com> References: <4AC7A8FA.80007@linuxbox.org> <75cb24520910041303y6c89685bwb50f4ca86e597296@mail.gmail.com> <4AC90379.1070401@linuxbox.org> <4AC9FCDC.9060709@justinshore.com> Message-ID: <8E625710-6003-417B-8D2A-1433DD825251@daork.net> On 6/10/2009, at 3:04 AM, Justin Shore wrote: > Gadi Evron wrote: >> Apparently, marketing departments like the idea of being able to >> send customers that need to pay them to a walled garden. It also >> saves on tech support costs. Security being the main winner isn't >> the main supporter of the idea at some places. > > I would love to do this both for non-pays and security incidents. > I'd like to do something similar to let customers update their > provisioning information for static IP changes so cable source > verify doesn't freak out. Unfortunately I haven't been able to find > any open source tools to do this. I can't even think of commercial > ones off the top of my head. > > It's a relatively simple concept. Some measure of integration into > the DHCP provisioning system(s) would be needed to properly route > the customer's traffic to the walled garden and only to the walled > garden. Once the problem is resolved the walled garden fixes the > DHCP so the customer can once again pull a public IP and possibly > flushes ARP caches if your access medium makes that a problem to be > dealt with. > > I would think that the walled garden portion could be handled well- > enough with Squid and some custom web programming to perform tasks > to reverse the provisioning issues. I'm sure people have written > internal solutions for SPs before but I haven't found anyone that > has made that into an OSS project and put it on the Web. I'd love > to make this a project but there is little financial gain to my > small SP so if it costs much money it won't get management support. Do you currently drop them in to a VRF to get them to the Internet? If so, do that, but a different VRF for the walled garden. -- Nathan Ward From mike at mtcc.com Mon Oct 5 18:50:15 2009 From: mike at mtcc.com (Michael Thomas) Date: Mon, 05 Oct 2009 16:50:15 -0700 Subject: ISP customer assignments In-Reply-To: References: Message-ID: <4ACA8637.2010005@mtcc.com> On 10/05/2009 04:41 PM, Robert.E.VanOrmer at frb.gov wrote: > The address space is daunting in scale as you have noted, but I don't see > any lessons learned in address allocation between IPv6 and IPv4. Consider > as a residential customer, I will be provided a /64, which means each > individual on Earth will have roughly 1 billion addresses each. > Organizations will be provided /48s or smaller, but given the current > issues with routing /48's globally, I think you will find more > organizations fighting for /32s or smaller... so what once was a > astonomical number of addresses that one cannot concieve numerically, soon > becomes much smaller. I can see an IPv7 in the future, and doing it all > over again... I just hope I retire before it comes... The only difference > I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 > bit address... Just like back in the day when Class B networks were > handed out like candy, one day we will be figuring out how to put in > emergency allocations on the ARIN listserv for IPv6 because of address > exhaustion and waste. I'm perplexed. At what size address would people stop worrying about the "finite" address space? 256 bits? 1024 bits? I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more "finite" than ipv6. Mike From dga at cs.cmu.edu Mon Oct 5 18:59:47 2009 From: dga at cs.cmu.edu (David Andersen) Date: Mon, 5 Oct 2009 19:59:47 -0400 Subject: ISP customer assignments In-Reply-To: <4ACA8637.2010005@mtcc.com> References: <4ACA8637.2010005@mtcc.com> Message-ID: <71AAE0E8-43A6-4B00-8F87-8FA8F09DD91D@cs.cmu.edu> On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote: > I'm perplexed. At what size address would people stop worrying about > the "finite" address space? 256 bits? 1024 bits? > > I just don't get it. It's not like people get stressed out about > running > out of name space in English which is probably more "finite" than > ipv6. Unless you're trying to find a nice, catchy, short domain name. ;-) But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as "really big" (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace... -Dave From tony at lava.net Mon Oct 5 19:01:44 2009 From: tony at lava.net (Antonio Querubin) Date: Mon, 5 Oct 2009 14:01:44 -1000 (HST) Subject: ISP customer assignments In-Reply-To: References: Message-ID: On Mon, 5 Oct 2009, Robert.E.VanOrmer at frb.gov wrote: > The address space is daunting in scale as you have noted, but I don't see > any lessons learned in address allocation between IPv6 and IPv4. Consider A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From adrian at creative.net.au Mon Oct 5 19:09:57 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 6 Oct 2009 08:09:57 +0800 Subject: ISP customer assignments In-Reply-To: References: Message-ID: <20091006000957.GD22728@skywalker.creative.net.au> On Mon, Oct 05, 2009, Antonio Querubin wrote: > On Mon, 5 Oct 2009, Robert.E.VanOrmer at frb.gov wrote: > > >The address space is daunting in scale as you have noted, but I don't see > >any lessons learned in address allocation between IPv6 and IPv4. Consider > > A lesson learned is that thinking about address allocation is something > you do not want to spend too many precious seconds of your life on. > That's one reason why the space was designed to be so big. Being > penny-wise and pound-foolish doesn't really save you much in the IPv6 > address space. .. address aggregation? .. convergence time? I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their "local" internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it "better". adrian From owen at delong.com Mon Oct 5 19:05:57 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Oct 2009 17:05:57 -0700 Subject: ISP customer assignments In-Reply-To: References: Message-ID: <81634882-8083-443D-8548-481047009B4D@delong.com> If people start getting /32s because some ISPs are refusing to route / 48s, then, the RIRs are not doing their stewardship job correctly and we should resolve that issue. If addresses are handed out according to policies, there is more than enough space for every individual to have a /48. I think that /56s for residential customers are probably a good idea and I agree that /48s are usually excessive for residential. (a /64 is far more than a billion addresses since 32 bits if 4 billion and a /64 is whatever number 4 billion^2 works out to, basically 16 followed by lots more digits). As a residential customer, if you get a /64, then, your ISP is really limiting you in ways they should not. You should get at least a /56 in most cases. I think that comparing this to class Bs is kind of absurd, and, I think that the people talking about lessons learned haven't really analyzed the lessons very well. The argument of "lessons learned" usually centers around the idea that we should regard address space as finite and seek ways to maximize its use. The reality is that is not the best lesson. That is what you do when address space is finite and insufficient and you can't make use of extra bits to do other optimizations. Therefore, the best lesson to learn is simply that the IPv4 space was simply not large enough and that we need a much much much larger space with bits available to do other forms of optimization. IPv6 does appear to contain that lesson rather well. We have TONS of bits available on each network for host addressing. So much so that complicated bizarre subnet address calculations and DNS reverse delegation difficulties become a thing of the past (look at the hacks necessary to delegate reverse DNS to 16 different /28 customers in a /24 block, for example). In essence, a class B was equivalent to a /56 in its original form, you could carve it up into 256 /24s. In IPv6, we have plenty of space to issue /56 and even /48 networks to every small to medium business, home, etc. and still have lots left over. Large organizations and IPSs easily get /32s which each contain 65,536 /48s, so, you can divide your multi-national mega-corp into as many as 65,536 regions and give each region a /48 and still be OK. IPv6 offers so much address space that we could give every existing IPv4 user an entire IPv6 ISP allocation (no, I'm not recommending this) and still have enough /32s left over in IPv6 to give one to each ISP and large mega-corp. Lesson learned... The original address was far too small. The new address space is actually large enough that this is a pretty good guess at how to generate addresses that will be fine for decades to come and still have space left over. In fact, so much so, that, to test the theory, we're issuing 1/8th of it this way, and, if it doesn't work out as planned, we can change the allocation policies for the other 7/8ths of the space. So... Lesson learned... If we had tossed classful addressing overboard in IPv4 when we allocated 1/8th of the address space, most of the legacy /8s wouldn't be. Owen On Oct 5, 2009, at 4:41 PM, Robert.E.VanOrmer at frb.gov wrote: > The address space is daunting in scale as you have noted, but I > don't see > any lessons learned in address allocation between IPv6 and IPv4. > Consider > as a residential customer, I will be provided a /64, which means each > individual on Earth will have roughly 1 billion addresses each. > Organizations will be provided /48s or smaller, but given the current > issues with routing /48's globally, I think you will find more > organizations fighting for /32s or smaller... so what once was a > astonomical number of addresses that one cannot concieve > numerically, soon > becomes much smaller. I can see an IPv7 in the future, and doing it > all > over again... I just hope I retire before it comes... The only > difference > I can see between IPv4 and IPv6 is how much of a pain it is to type > a 128 > bit address... Just like back in the day when Class B networks were > handed out like candy, one day we will be figuring out how to put in > emergency allocations on the ARIN listserv for IPv6 because of address > exhaustion and waste. > > Food for thought... > > >> Message: 3 >> Date: Mon, 5 Oct 2009 17:47:12 -0400 >> From: Dorn Hetzel >> Subject: Re: ISP customer assignments >> To: bmanning at vacation.karoshi.com >> Cc: NANOG list >> Message-ID: >> <7db2dcf90910051447r5bd7e42fja0b750dceb8d764 at mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> The estimated mass of our galaxy is around 6x10^42Kg. The mass of >> earth > is a >> little less than 6x10^24Kg. >> >> 2^128 is around 3.4x10^38. >> So in a flat address space we have about one IPV6 address for every > 20,000Kg >> in the galaxy or for every 20 picograms in the earth... >> >> One would hope it would last for a while :) >> >> On Mon, Oct 5, 2009 at 5:32 PM, >> wrote: >> >>> >>> considered top posting to irritate a few folks, decided not to. >>> >>> >>> On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote: >>>> On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: >>>> >>>>> Whenever you declare something to be "inexhasutable" all you do is >>>>> increase demand. Eventually you reach a point where you realize >>>>> that >>>>> there is, in fact, a limit to the inexhaustable resource. >>>> >>>> This is where I think there is a major disconnect on IPv6. The >>>> size >>>> of the pool is just so large that people just can't wrap their >>>> heads >>>> around it. >>>> >>>> 2^128 is enough space for every man, woman and child on the >>>> planet to >>>> have around 4 billion /64s to themselves. Even if we assume > everyone >>>> might possibly need say 10 /64s per person that still means we are >>>> covered until the population hits around 2,600,000,000,000,000,000. >>>> >>>> Chris >>>> >>> >>> here, you expose a hidebound bias to 20th century networking. >>> please remember that - with few exceptions - people network >>> at a very different level than machines. people don't need >>> IP addresses - computing nodes that want to communicate do. >>> >>> Just for grins, put a unique IPv6 address in every active RFID >>> tag. ... and remember that there are RFID printers that can >>> put 18 tags on a single A4 sheet. Numbers will become > disposible, >>> like starbucks coffee cups and MCD's bigmac containers. >>> >>> --bill >>> >>> From jgreco at ns.sol.net Mon Oct 5 19:14:01 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 5 Oct 2009 19:14:01 -0500 (CDT) Subject: ISP customer assignments In-Reply-To: from "Robert.E.VanOrmer@frb.gov" at Oct 05, 2009 07:41:08 PM Message-ID: <200910060014.n960E1AP095142@aurora.sol.net> > The address space is daunting in scale as you have noted, but I don't see > any lessons learned in address allocation between IPv6 and IPv4. That's probably because IPv4 was a technology where the expected host address allocation strategy was (last+1) and IPv6 is a technology where the default host address allocation strategy involves shooting into an extremely extra-sparse 64-bit address space. These are incredibly different things. > Consider > as a residential customer, I will be provided a /64, which means each > individual on Earth will have roughly 1 billion addresses each. Um, no. Unless by "roughly" we use a definition where 1 is roughly equal to 18 billion. Yes, that's right, a /64 is 18 billion *billion*. Generally speaking, we shouldn't *want* end users to be provided with a single /64. The number of addresses is not the point. The idea of getting rid of the horribleness that is CIDR is the point. For example, consider the network 206.55.76.0/23. If I assign that to an Ethernet interface, I have a problem because two addresses in the middle of the network, 206.55.76.255 and 206.55.77.0, are less-than- fully-usable because stupid idiot retards out on the Internet will see that last octet and will firewall it. And by "stupid idiot retards," I don't necessarily mean end users, I mean *VENDORS*. (You know who you are.) The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc. And here's the kicker. If it /really/ bothers you, just bear in mind that having another whole 64 bits as the host space means that if ever the V6Internet is in crisis and is running out of IP space, unlike IPv4, we can "fix" that problem by changing the addressing strategy within the local AS. > Organizations will be provided /48s or smaller, but given the current > issues with routing /48's globally, I think you will find more > organizations fighting for /32s or smaller... Oh puhhhhhleeeze. Where do we get these newbies from. Part of the reason for forming a group such as NANOG was that there were lots of routing issues; we still see requests for help for that sort of stuff today on the IPv4 Internet. Anyone who remembers the fun days of the early commercial Internet would likely say that we've got it easy today. > so what once was a > astonomical number of addresses that one cannot concieve numerically, soon > becomes much smaller. I can see an IPv7 in the future, and doing it all > over again... I just hope I retire before it comes... The only difference > I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 > bit address... You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... > Just like back in the day when Class B networks were > handed out like candy, one day we will be figuring out how to put in > emergency allocations on the ARIN listserv for IPv6 because of address > exhaustion and waste. Not likely to happen in this century. One of the lessons that *was* learned was that it's better to go too big than too small. People just have a rough time visualizing how massively immense 2^128 actually is. But this discussion is really not relevant to NANOG; if you wish to fight this battle, the people with the clue-by-fours are over on the IPv6 lists. > Food for thought... Only if by "food" you mean "I went down to Lardburger and ate until I had a heart attack and died." You're not bringing anything new to the table, least of all in the fact department, which is about the only way you could manage to convince people that there's a problem. And the very thing you're complaining about would actually be the obvious safety valve if there's a problem. That immense, extremely sparse space that forms the host portion of an IPv6 address... that is where we dip into in the extremely unlikely event there's a problem. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mike at mtcc.com Mon Oct 5 19:12:23 2009 From: mike at mtcc.com (Michael Thomas) Date: Mon, 05 Oct 2009 17:12:23 -0700 Subject: ISP customer assignments In-Reply-To: <71AAE0E8-43A6-4B00-8F87-8FA8F09DD91D@cs.cmu.edu> References: <4ACA8637.2010005@mtcc.com> <71AAE0E8-43A6-4B00-8F87-8FA8F09DD91D@cs.cmu.edu> Message-ID: <4ACA8B67.4070007@mtcc.com> On 10/05/2009 04:59 PM, David Andersen wrote: > On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote: >> I'm perplexed. At what size address would people stop worrying about >> the "finite" address space? 256 bits? 1024 bits? >> >> I just don't get it. It's not like people get stressed out about running >> out of name space in English which is probably more "finite" than ipv6. > > Unless you're trying to find a nice, catchy, short domain name. ;-) > > But seriously: Many people don't seem to have good intuition about > really big numbers. Say, on the order of 2^128. The same thing comes up > in discussions about hash collisions in, e.g., content based naming with > a 160-bit namespace. I think it's because the numbers are so > astronomically big, that without some amount of math and having thought > about it with paper and pencil, people automatically scale the #s into > terms they can think of as "really big" (like, # of people on earth). So > when they think about the 128-bit namespace, they apply intuition that > works for a 35-bit namespace... Hey, that's are why logarithms are our friends :) Seriously though, when i was at that big ol' networking company, the size of the address space was so ridiculously large that hardware and software people charged with implementing it certainly had no love for it. So it's not like vendors were cheaping out or something -- it makes their life quite a bit more, uh, interesting. Ipv6 *is* what what was learned about ipv4 addresses: make the address space so astronomically large that nobody could possibly worry. Curse those logarithms on second thought. Mike From drc at virtualized.org Mon Oct 5 19:14:08 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 5 Oct 2009 17:14:08 -0700 Subject: ISP customer assignments In-Reply-To: <4ACA8637.2010005@mtcc.com> References: <4ACA8637.2010005@mtcc.com> Message-ID: I've been trying to stay out of this discussion because it is pointless, however as I can't help picking at scratching mosquito bites either... On Oct 5, 2009, at 4:50 PM, Michael Thomas wrote: > I'm perplexed. At what size address would people stop worrying about > the "finite" address space? 256 bits? 1024 bits? The issue is that given it is a _finite_ space, its longevity depends exclusively on allocation policy. Since allocation policy is determined by human decision, it is possible (albeit unlikely) that decisions will be made that will result in runout of IPv6 far sooner than one would predict given the vast size of the address space. To wit, we have already had allocations of a /13, /16s, /19s, /20s, etc., irrespective of the fact that the organizations that obtained those prefixes would likely be unable to make a dent in their allocations by the time the sun burned out (assuming they allocate in a rational fashion). Now, as an exercise to the reader, compare how many of those prefixes exist in IPv6 to how many there are in IPv4... Regards, -drc From jgreco at ns.sol.net Mon Oct 5 19:18:10 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 5 Oct 2009 19:18:10 -0500 (CDT) Subject: ISP customer assignments In-Reply-To: <20091006000957.GD22728@skywalker.creative.net.au> from "Adrian Chadd" at Oct 06, 2009 08:09:57 AM Message-ID: <200910060018.n960IBHe095277@aurora.sol.net> > On Mon, Oct 05, 2009, Antonio Querubin wrote: > > On Mon, 5 Oct 2009, Robert.E.VanOrmer at frb.gov wrote: > > > > >The address space is daunting in scale as you have noted, but I don't see > > >any lessons learned in address allocation between IPv6 and IPv4. Consider > > > > A lesson learned is that thinking about address allocation is something > > you do not want to spend too many precious seconds of your life on. > > That's one reason why the space was designed to be so big. Being > > penny-wise and pound-foolish doesn't really save you much in the IPv6 > > address space. > > .. address aggregation? > .. convergence time? > > I'm sorry, but seeing a good fraction of my local IX simply containing > a few ISP's deaggregated view of their "local" internal networks versus > a sensible allocation policy makes me cry. IPv6 may just make this > worse. IPv6 certainly won't make it "better". That would seem to be an IX administrative problem. As it stands, there are lots and lots and lots of AS's that advertise multiple blocks of space. Ideally, one would rather see a large ISP get a single delegation, rather than advertising 50 or 500. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From drc at virtualized.org Mon Oct 5 19:20:39 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 5 Oct 2009 17:20:39 -0700 Subject: ISP customer assignments In-Reply-To: <81634882-8083-443D-8548-481047009B4D@delong.com> References: <81634882-8083-443D-8548-481047009B4D@delong.com> Message-ID: Owen, On Oct 5, 2009, at 5:05 PM, Owen DeLong wrote: > If people start getting /32s because some ISPs are refusing to > route /48s, then, > the RIRs are not doing their stewardship job correctly and we should > resolve > that issue. Since when do RIRs, good stewards or not, control routing policy of ISPs? > IPv6 offers so much address space that we could give every existing > IPv4 user an entire IPv6 ISP allocation (no, I'm not recommending > this) > and still have enough /32s left over in IPv6 to give one to each ISP > and large mega-corp. Um. How many /32s are their in IPv4? How many /32s are their in IPv6? Regards, -drc From thegameiam at yahoo.com Mon Oct 5 19:22:11 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 5 Oct 2009 17:22:11 -0700 (PDT) Subject: ISP customer assignments In-Reply-To: <71AAE0E8-43A6-4B00-8F87-8FA8F09DD91D@cs.cmu.edu> Message-ID: <29383.63660.qm@web31803.mail.mud.yahoo.com> The fallacy here is the idea that IPv6 has a 128-bit namespace. It does not. It has two 64 bit namespaces, where one is expected to be globally unique and flat, While the other is hierarchical. IPv6 has a lot more room than v4 does, but it is worth noting Than in v4, a customer would typically use a single /32. In v6-speak, a /48 is a smaller percentage of the overall space, but it would not be prudent to view the v6-space as infinite. Remember, the value of a network increases with the number of interconnections, and those interconnections are what get numbered. All of the comparisons to atoms in the galaxy or human population are ignoring the hierarchical element of the 64-bit space. The nature of hierarchical allocations requires a Significant "burn" in terms of wasted, unusable addresses. All that said, the /64-based v6 addressing approaches are going to be with us for quite a while, so they're worth getting used to. -David Barak David Andersen wrote: > On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote: >> I'm perplexed. At what size address would people stop worrying about >> the "finite" address space? 256 bits? 1024 bits? >> >> I just don't get it. It's not like people get stressed out about running >> out of name space in English which is probably more "finite" than ipv6. > Unless you're trying to find a nice, catchy, short domain name. ;-) > But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as "really big" (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace... > -Dave From mike at mtcc.com Mon Oct 5 19:25:57 2009 From: mike at mtcc.com (Michael Thomas) Date: Mon, 05 Oct 2009 17:25:57 -0700 Subject: ISP customer assignments In-Reply-To: <20091006000957.GD22728@skywalker.creative.net.au> References: <20091006000957.GD22728@skywalker.creative.net.au> Message-ID: <4ACA8E95.9060907@mtcc.com> On 10/05/2009 05:09 PM, Adrian Chadd wrote: > On Mon, Oct 05, 2009, Antonio Querubin wrote: >> On Mon, 5 Oct 2009, Robert.E.VanOrmer at frb.gov wrote: >> >>> The address space is daunting in scale as you have noted, but I don't see >>> any lessons learned in address allocation between IPv6 and IPv4. Consider >> >> A lesson learned is that thinking about address allocation is something >> you do not want to spend too many precious seconds of your life on. >> That's one reason why the space was designed to be so big. Being >> penny-wise and pound-foolish doesn't really save you much in the IPv6 >> address space. > > .. address aggregation? > .. convergence time? > > I'm sorry, but seeing a good fraction of my local IX simply containing > a few ISP's deaggregated view of their "local" internal networks versus > a sensible allocation policy makes me cry. IPv6 may just make this > worse. IPv6 certainly won't make it "better". There's a good reason for that: ipv6 isn't intended to do anything about disaggregation. Which as you rightly point out is a problem in ipv4 too. IIRC, there was a contingent who thought that address space and aggregation needed to be considered as a single problem. They lost the argument and hence ipv6 as it is today and the previously unsolved aggregation problem... still unsolved. Mike From drc at virtualized.org Mon Oct 5 19:27:53 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 5 Oct 2009 17:27:53 -0700 Subject: (Spelling embarrassment, ignorable except for spelling pedants) Re: ISP customer assignments In-Reply-To: References: <81634882-8083-443D-8548-481047009B4D@delong.com> Message-ID: <0652340B-6F55-4607-94B0-A4E98C551AAF@virtualized.org> On Oct 5, 2009, at 5:20 PM, David Conrad wrote: > Um. How many /32s are their in IPv4? How many /32s are their in > IPv6? Of course, that should be "there" in both cases. Wow. Regards, -drc From adrian at creative.net.au Mon Oct 5 19:28:58 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 6 Oct 2009 08:28:58 +0800 Subject: ISP customer assignments In-Reply-To: <200910060018.n960IBHe095277@aurora.sol.net> References: <20091006000957.GD22728@skywalker.creative.net.au> <200910060018.n960IBHe095277@aurora.sol.net> Message-ID: <20091006002858.GE22728@skywalker.creative.net.au> On Mon, Oct 05, 2009, Joe Greco wrote: > > I'm sorry, but seeing a good fraction of my local IX simply containing > > a few ISP's deaggregated view of their "local" internal networks versus > > a sensible allocation policy makes me cry. IPv6 may just make this > > worse. IPv6 certainly won't make it "better". > > That would seem to be an IX administrative problem. Sure, if you don't want to see those local networks. But since the cost of getting from "Perth" to "! Perth" is (was?) a lot higher than what you guys even pay for international transit at non-Cogent rates, we have some sort of desire to keep as much traffic local as possible. Hence "Local only" announcements. > As it stands, there are lots and lots and lots of AS's that advertise > multiple blocks of space. Ideally, one would rather see a large ISP > get a single delegation, rather than advertising 50 or 500. .. and what about their customers with portable address space? What if every single customer decides they now want to multihome, dynamic endpoint resolution stuff (LISA?) isn't ready, and companies simply join the RIR and buy their own IP space? :) Adrian From trejrco at gmail.com Mon Oct 5 19:33:46 2009 From: trejrco at gmail.com (TJ) Date: Mon, 5 Oct 2009 20:33:46 -0400 Subject: ISP customer assignments In-Reply-To: <20091005213203.GB3136@vacation.karoshi.com.> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> <289980C1-5681-4EEA-9D9C-89BFF3715E7E@ksip.net> <20091005184356.GA54050@typo.org> <20091005213203.GB3136@vacation.karoshi.com.> Message-ID: <01fd01ca461c$aaf14e50$00d3eaf0$@com> > Just for grins, put a unique IPv6 address in every active RFID > tag. ... and remember that there are RFID printers that can > put 18 tags on a single A4 sheet. Numbers will become disposible, > like starbucks coffee cups and MCD's bigmac containers. > >--bill Ignoring the difference between a globally unique identifier and a network-connected, routeable, globally-unique identifier for just a moment ... OK, so we can print 18 tags per A4 sheet. And a single /64 gives us 18BillionBillion of these - start printing, if you so desire. Let me know when you need your next /64 :) (even assuming no reuse / overlap between different solution sets). /TJ From trejrco at gmail.com Mon Oct 5 19:40:28 2009 From: trejrco at gmail.com (TJ) Date: Mon, 5 Oct 2009 20:40:28 -0400 Subject: ISP customer assignments In-Reply-To: <174173.1254782109@turing-police.cc.vt.edu> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <174173.1254782109@turing-police.cc.vt.edu> Message-ID: <020401ca461d$9a81bc70$cf853550$@com> >On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said: > >> a publicly routeable stateless auto configured address is no less >> secure than a publicly routeable address assigned by DHCP. Security >> is, and should be, handled by other means. > >The problem is user tracking and privacy. > >RFC4941's problem statement: > > Addresses generated using stateless address autoconfiguration > [ADDRCONF] contain an embedded interface identifier, which remains > constant over time. Anytime a fixed identifier is used in multiple > contexts, it becomes possible to correlate seemingly unrelated > activity using this identifier. > > The correlation can be performed by > > o An attacker who is in the path between the node in question and > the peer(s) to which it is communicating, and who can view the > IPv6 addresses present in the datagrams. > > o An attacker who can access the communication logs of the peers > with which the node has communicated. > > Since the identifier is embedded within the IPv6 address, which is a > fundamental requirement of communication, it cannot be easily hidden. > This document proposes a solution to this issue by generating > interface identifiers that vary over time. > > Note that an attacker, who is on path, may be able to perform > significant correlation based on > > o The payload contents of the packets on the wire > > o The characteristics of the packets such as packet size and timing > > Use of temporary addresses will not prevent such payload-based > correlation. >(end quote) > >Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at >work, at a hotel, and a few other places, you'll get a whole raft of answers >which will be very hard to cross-corrolate. But if all those places did >IPv6 autoconfig, the correlation would be easy, because my address would always >end in 215:c5ff:fec8:334e - and no other users should have those last 64 bits. > >Amazingly enough, some people think making it too easy to Big-Brother you is a >security issue... Isn't this really a security by obscurity argument? Making it a bit harder for the attacker, relying on 'Eve' just not realizing who I am? Most of those concerns are in fact mitigated by a well implemented Privacy implementation ... and many of the remaining concerns do in fact apply to IPv4. Not to mention the 'higher layer' aspects. Bottom line - if you are doing something that warrants some level of privacy or protection, you should do something to ensure that level of privacy or protection - never assume you are private/secure by default. /TJ From trejrco at gmail.com Mon Oct 5 19:46:10 2009 From: trejrco at gmail.com (TJ) Date: Mon, 5 Oct 2009 20:46:10 -0400 Subject: ISP customer assignments In-Reply-To: References: Message-ID: <020501ca461e$668a66f0$339f34d0$@com> >-----Original Message----- >From: Robert.E.VanOrmer at frb.gov [mailto:Robert.E.VanOrmer at frb.gov] >Sent: Monday, October 05, 2009 7:41 PM >To: nanog at nanog.org >Subject: Re: ISP customer assignments > >The address space is daunting in scale as you have noted, but I don't see any >lessons learned in address allocation between IPv6 and IPv4. Consider as a >residential customer, I will be provided a /64, which means each individual on >Earth will have roughly 1 billion addresses each. Nope. You should get a ~/56. Even so, a /64 gives you ~18BillionBillion addresses. >Organizations will be provided /48s or smaller, but given the current issues >with routing /48's globally, I think you will find more organizations fighting >for /32s or smaller... so what once was a astonomical number of addresses that >one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 Nope, organizations will go for PI ~/48s, and Verizon will be forced to stop filtering them. Oh, and IIRC - as it stands now, IPv7-9 are already shot (similar to IPv1-3) ... so IPv10 would be next up, in a century ... or four. >in the future, and doing it all over again... I just hope I retire before it >comes... The only difference I can see between IPv4 and IPv6 is how much of a Are you retiring in the next 0-3 years? :) >pain it is to type a 128 bit address... Just like back in the day when Class B >networks were handed out like candy, one day we will be figuring out how to put >in emergency allocations on the ARIN listserv for IPv6 because of address >exhaustion and waste. As for the lessons learned - it is about scale. 32 bits isn't enough, double it 96 more times (or 32 more times for just the network side, if you prefer) and it is enough. /TJ From trejrco at gmail.com Mon Oct 5 19:50:33 2009 From: trejrco at gmail.com (TJ) Date: Mon, 5 Oct 2009 20:50:33 -0400 Subject: ISP customer assignments In-Reply-To: <20091006000957.GD22728@skywalker.creative.net.au> References: <20091006000957.GD22728@skywalker.creative.net.au> Message-ID: <020601ca461f$0356a160$0a03e420$@com> >> >The address space is daunting in scale as you have noted, but I don't >> >see any lessons learned in address allocation between IPv6 and IPv4. >> >Consider >> >> A lesson learned is that thinking about address allocation is >> something you do not want to spend too many precious seconds of your life on. >> That's one reason why the space was designed to be so big. Being >> penny-wise and pound-foolish doesn't really save you much in the IPv6 >> address space. > >.. address aggregation? >.. convergence time? > >I'm sorry, but seeing a good fraction of my local IX simply containing a few >ISP's deaggregated view of their "local" internal networks versus a sensible >allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly >won't make it "better". Is someone not making sensible use of their IPv6 allocation? Another one of the goals is to enable organization (and the Internet, prior to PI space) to be far more aggregatable. Real example: Instead of one enterprise network having 31 dis-contiguous IPv4 /16s they could get one (large) IPv6 allocation. ... With room to grow and still aggregate. PI space changes that conversation on the DFZ side back to a bit of a swamp until we get that fixed in one fashion or another ... /TJ From tdurack at gmail.com Mon Oct 5 20:01:56 2009 From: tdurack at gmail.com (Tim Durack) Date: Mon, 5 Oct 2009 21:01:56 -0400 Subject: ISP customer assignments In-Reply-To: <020601ca461f$0356a160$0a03e420$@com> References: <20091006000957.GD22728@skywalker.creative.net.au> <020601ca461f$0356a160$0a03e420$@com> Message-ID: <9e246b4d0910051801t31896afep37ebcbceb1e945be@mail.gmail.com> > Is someone not making sensible use of their IPv6 allocation? > Another one of the goals is to enable organization (and the Internet, prior > to PI space) to be far more aggregatable. > Real example: Instead of one enterprise network having 31 dis-contiguous > IPv4 /16s they could get one (large) IPv6 allocation. > ... With room to grow and still aggregate. > > > PI space changes that conversation on the DFZ side back to a bit of a swamp > until we get that fixed in one fashion or another ... > /TJ You sure you got the target right? When I look at the the last CIDR report, top-30 would give a 70% improvement in DFZ. Guess how many end users with PI are in that top 30? Tim:> From herrin-nanog at dirtside.com Mon Oct 5 20:32:10 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 5 Oct 2009 21:32:10 -0400 Subject: ISP customer assignments In-Reply-To: References: Message-ID: <3c3e3fca0910051832u198ef1aao7e29fb7603052954@mail.gmail.com> On Mon, Oct 5, 2009 at 7:41 PM, wrote: > The address space is daunting in scale as you have noted, but I don't see > any lessons learned in address allocation between IPv6 and IPv4. Robert, I would suggest that some of the lessons we learned are faulty. Maladaptive. CIDR for instance. In a classful world, folks who needed a class A got a class A and were able to announce a class A. They couldn't announce 4200 little divisions of their addresses like Bell South on last Friday's CIDR report. CIDR made today's BGP mess possible. With a larger address space, let's say 128 bits, things *could* have been partitioned in a such a way that there were enough class B's for everyone who needed more than a class C and plenty of class-A's for everyone who needed more than a class B. There's no doubt that CIDR saved the Internet. There -weren't- enough IPv4 class B's for everyone who needed more than a class C. CIDR made it possible to express ranges of class C's as a single route and that's just the start. But CIDR also created today's problems where it isn't possible to tell the difference between a route that represents a unique multihomed endpoint and routes which reflect nothing more than a bad actor making you pay his traffic engineering cost. So now Verizon is in open revolt against ARIN. They positively refuse to carry /48's from legitimately multihomed users. Eff 'em. Perhaps Verizon would sooner see IPv6 go down in flames than see their TCAMs fill up again. Who knows their reasoning? Agree or disagree, it is indeed food for thought. One thing I can say with confidence: as a community we truly haven't grasped the major implications of an address space that isn't scarce coupled with a routing table that is. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tdurack at gmail.com Mon Oct 5 20:41:19 2009 From: tdurack at gmail.com (Tim Durack) Date: Mon, 5 Oct 2009 21:41:19 -0400 Subject: ISP customer assignments In-Reply-To: <3c3e3fca0910051832u198ef1aao7e29fb7603052954@mail.gmail.com> References: <3c3e3fca0910051832u198ef1aao7e29fb7603052954@mail.gmail.com> Message-ID: <9e246b4d0910051841r3df4f629p94fcc3fbb1f758e5@mail.gmail.com> > So now Verizon is in open revolt against ARIN. They positively refuse > to carry /48's from legitimately multihomed users. Eff 'em. Perhaps > Verizon would sooner see IPv6 go down in flames than see their TCAMs > fill up again. Who knows their reasoning? > > Agree or disagree, it is indeed food for thought. One thing I can say > with confidence: as a community we truly haven't grasped the major > implications of an address space that isn't scarce coupled with a > routing table that is. Thing is, I'm an end user site. I need more that a /48, but probably less than a /32. Seeing as how we have an AS and PI, PA isn't going to cut it. What am I supposed to do? ARIN suggested creative subnetting. We pushed back and got a /41. If IPv6 doesn't scratch an itch, why bother? There are plenty of high-profile end user sites in 2620::/23. Some government (CIA), some popular (Facebook.) I don't think Verizon's stand is going to last. Tim:> From jfbeam at gmail.com Mon Oct 5 21:53:17 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 05 Oct 2009 22:53:17 -0400 Subject: ISP customer assignments In-Reply-To: <20091005225534.GU5403@dan.olp.net> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <174173.1254782109@turing-police.cc.vt.edu> <20091005225534.GU5403@dan.olp.net> Message-ID: On Mon, 05 Oct 2009 18:55:35 -0400, Dan White wrote: > All of the items in the above list are true of DHCP. ... In an IPv4 world (which is where DHCP lives), it's much MUCH harder to track assignments -- I don't share my DHCP logs with anyone, nor does anyone send theirs to me. From the perspective of remote systems (ie. not on the same network), there is about a 100% chance NAT is involved making it near impossible to individually identify a specific machine, even if it gets the same address every Tuesday when you're at Starbucks for coffee. IPv6 does away with NAT (or it's supposed to); in doing so, the veil is removed and everything that had been hidden from site is now openly displayed. If the "host" part of your address never changes, then you are instantly identifiable everywhere you go, with zero effort, forever. --Ricky From joelja at bogus.com Mon Oct 5 22:16:02 2009 From: joelja at bogus.com (joel jaeggli) Date: Mon, 05 Oct 2009 20:16:02 -0700 Subject: ISP customer assignments In-Reply-To: <9e246b4d0910051841r3df4f629p94fcc3fbb1f758e5@mail.gmail.com> References: <3c3e3fca0910051832u198ef1aao7e29fb7603052954@mail.gmail.com> <9e246b4d0910051841r3df4f629p94fcc3fbb1f758e5@mail.gmail.com> Message-ID: <4ACAB672.60908@bogus.com> Tim Durack wrote: > Thing is, I'm an end user site. I need more that a /48, but probably > less than a /32. Seeing as how we have an AS and PI, PA isn't going to > cut it. What am I supposed to do? ARIN suggested creative subnetting. > We pushed back and got a /41. If IPv6 doesn't scratch an itch, why > bother? We were assigned a /43. insofar as I can tell that's Arin policy working just fine. > There are plenty of high-profile end user sites in 2620::/23. Some > government (CIA), some popular (Facebook.) I don't think Verizon's > stand is going to last. > > Tim:> > From jfbeam at gmail.com Mon Oct 5 22:23:17 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 05 Oct 2009 23:23:17 -0400 Subject: ISP customer assignments In-Reply-To: <200910060014.n960E1AP095142@aurora.sol.net> References: <200910060014.n960E1AP095142@aurora.sol.net> Message-ID: On Mon, 05 Oct 2009 20:14:01 -0400, Joe Greco wrote: > Generally speaking, we shouldn't *want* end users to be provided with a > single /64. The number of addresses is not the point. The idea of > getting rid of the horribleness that is CIDR is the point. You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible. > The current revision of IPv6 introduces a way to nail down the boundary > between network and host. This is fantastic, from an implementation > point of view. It simplifies the design of silicon for forwarding > engines, etc. And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules. > You don't do that. Or at least, you shouldn't do that. :-) We have a > fairly reliable DNS system these days... And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. --Ricky From dougb at dougbarton.us Mon Oct 5 22:39:33 2009 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 05 Oct 2009 20:39:33 -0700 Subject: Practical numbers for IPv6 allocations Message-ID: <4ACABBF5.8030005@dougbarton.us> [ I normally don't say this, but please reply to the list only, thanks. ] I've been a member of the "let's not assume the IPv6 space is infinite" school from day 1, even though I feel like I have a pretty solid grasp of the math. Others have alluded to some of the reasons why I have concerns about this, but they mostly revolve around the concepts that the address space is not actually flat (i.e., it's going to be carved up and handed out to RIRs, LIRs, companies, individuals, etc.) and that both the people making the requests and the people doing the allocations have a WIDE (pardon the pun) variety of motivations, not all of which are centered around the greater good. I'm also concerned that the two main pillars of what I semi-jokingly refer to as the "profligate" school of IPv6 allocation actually conflict with one another (even if they both had valid major premises, which I don't think they do). On the one hand people say, "The address space is so huge, we should allocate and assign with a 50-100 year time horizon" and on the other they say, "The address space is so huge, even if we screw up 2000::/3 we have 7 more bites at the apple." I DO believe that the space is large enough to make allocation policies with a long time horizon, but relying on "trying again" if we screw up the first time has a lot of costs that are currently undefined, and should not be assumed to be trivial. It also ignores the fact that if we reduce the pool of /3s because we do something stupid with the first one we allocate from it reduces our opportunities to do "cool things" with the other 7 that we haven't even thought of yet. In regards to the first of the "profligate" arguments, the idea that we can do anything now that will actually have even a 25 year horizon is naively optimistic at best. It ignores the day-to-day realities of corporate mergers and acquisitions, residential customers changing residences and/or ISPs, the need for PI space, etc. IPv6 is not a "set it and forget it" tool any more than IPv4 is because a lot of the same realities apply to it. You also have to keep in mind that even if we could come up with a theoretically "perfect" address allocation scheme at minimum the existing space is going to be carved up 5 ways for each of the RIRs to implement. (When I was at IANA I actually proposed dividing it along the 8 /6 boundaries, which is sort of what has happened subsequently if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to LACNIC and 2c00::/12 to AfriNIC.) Since it's not germane to NANOG I will avoid rehashing the "why RA and 64-bit host IDs were bad ideas from the start" argument. :) In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. As a practical matter we're "stuck" with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a "long view" into consideration. The last time I looked into this there were several ISPs in Japan who were assigning /60s to their residential users with good success. OTOH, a /56 contains 256 /64s, which is way WAY more than enough for a residential user. The idea that a residential user needs a full /48 (65,536 /64s) is absurd. OTOH, assigning a /48 to even a fairly large commercial customer is perfectly reasonable. This would give them 256 /56 networks (which would in turn have 256 /64 networks) which should be plenty to handle the problems of multiple campuses with multiple subnets, etc. So let's assume that we'll take /56 as the standard unit of assignment to residential customers, and /48 as the standard unit of assignment to commercial customers. A /32 has 65,536 /48s in it. If your business was focused mainly on commercial customers that's not a very big pool. OTOH if your business was focused primarily on residential customers you'd have 16,777,216 /56s to work with. That's enough for even a very large regional ISP. One could also easily imagine a model where out of a /32 you carve out one /34 for /56 assignments (4,194,304) and use the other 3/4ths of the space for /48s (49,152). A really large ("national" or even "global") ISP would obviously need more space if they were going to intelligently divide up addresses on a regional basis. A /28 would have 16 /32s which should be enough for even a "very large" ISP, but let's really make sure that we cover the bases and go /24 (256 /32s). Even if you assume splitting that address space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s, and 8,388,608 /48s. There are roughly 2,097,152 /24s in 2000::/3 (I say "roughly" because I'm ignoring space that's already been carved out, like 6to4, etc.), or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that yes, we really do have "a lot" of space to work with. I also think it means that even with "a lot" of space there is no point in wasting it with foolish allocation policies that give out way more space than is realistically necessary just "because we can." I've ignored PI space up till now but I think it's reasonable for there to be a midpoint for PI somewhere between /48 and /32. Personally I think that a /40 has a nice sound to it. That's 256 /48 networks. I don't see any reason why the RIRs couldn't also agree to a /36, which would be 4,096 /48s. Even I don't see any reason why they should mess around with numbers like /41 or /43. To get back to the question that started the original thread, if I were the one who was requesting an IPv6 allocation I would use the following formula: 1 /56 per # of residential customers expected in 10 years + 1 /48 per # of business customers expected in 10 years Then assuming your current numbers are roughly 1/16th of what you hope they'll be in 10 years; when actually handing out addresses I'd give out the first /60 from each /56 to the residential customers. That way if you need to you can go back and chop up those /56s. I'd also start off handing out the first /48 out of every /44 to my commercial customers. That way they will have room to expand painlessly. This is sort of a bastardized version of the "sparse allocation" model that the RIRs have promoted. (Obviously the 1/16th number was chosen for convenience, but hopefully you get the idea of what I'm going for here.) I realize that this is quite long, so if you've gotten this far, congratulations! I hope it was useful. Doug -- Food for thought is no substitute for the real thing. -- Walt Kelly, "Potluck Pogo" From Valdis.Kletnieks at vt.edu Mon Oct 5 22:42:32 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Oct 2009 23:42:32 -0400 Subject: ISP customer assignments In-Reply-To: Your message of "Mon, 05 Oct 2009 20:40:28 EDT." <020401ca461d$9a81bc70$cf853550$@com> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <174173.1254782109@turing-police.cc.vt.edu> <020401ca461d$9a81bc70$cf853550$@com> Message-ID: <188138.1254800552@turing-police.cc.vt.edu> On Mon, 05 Oct 2009 20:40:28 EDT, TJ said: > Isn't this really a security by obscurity argument? No - security through obscurity is "security measures that only seem to work because you hope the attacker doesn't know how they are implemented". In this case, making sure somebody else can't aggregate data about you is more akin to making sure somebody else can't obtain your password. In this case, you're making it harder for the attacker because they *do* know how the security measure works - if you're IP-address hopping or using RFC4191 privacy, then they know they have to find other means to do the tracking. > Making it a bit harder > for the attacker, relying on 'Eve' just not realizing who I am? Actually, yes. If you're the type of person that is careful not to accept website cookies to prevent cross-session and even cross-website tracking, you probably don't want to make it easy for Multi-click or whoever to do their tracking by having an IP address that shouts "Hey I'm the same laptop that was in the Starbuck's in Chicago last Tuesday". That isn't making it a little harder, it's making it a *lot* harder. And there's something to be said for Eve just not realizing who I am - the only reason my father's family made it to the US was because a Soviet border guard didn't realize my grandfather was on a "take in the forest and shoot on sight" list. So sometimes being able to keep Eve from making that correlation is literally a life-or-death issue. > Most of those concerns are in fact mitigated by a well implemented Privacy > implementation Which is why I started off by mentioning RFC4191. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ggm at apnic.net Mon Oct 5 22:43:48 2009 From: ggm at apnic.net (George Michaelson) Date: Tue, 6 Oct 2009 04:43:48 +0100 Subject: Practical numbers for IPv6 allocations In-Reply-To: <4ACABBF5.8030005@dougbarton.us> References: <4ACABBF5.8030005@dougbarton.us> Message-ID: <481A4851-F1A3-4532-A7C3-C3F2A08383B2@apnic.net> > > > I realize that this is quite long, so if you've gotten this far, > congratulations! I hope it was useful. > > > Doug Well said Doug. -G From sethm at rollernet.us Mon Oct 5 23:05:35 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 05 Oct 2009 21:05:35 -0700 Subject: ISP customer assignments In-Reply-To: <4ACAB672.60908@bogus.com> References: <3c3e3fca0910051832u198ef1aao7e29fb7603052954@mail.gmail.com> <9e246b4d0910051841r3df4f629p94fcc3fbb1f758e5@mail.gmail.com> <4ACAB672.60908@bogus.com> Message-ID: <4ACAC20F.20102@rollernet.us> joel jaeggli wrote: > Tim Durack wrote: > >> Thing is, I'm an end user site. I need more that a /48, but probably >> less than a /32. Seeing as how we have an AS and PI, PA isn't going to >> cut it. What am I supposed to do? ARIN suggested creative subnetting. >> We pushed back and got a /41. If IPv6 doesn't scratch an itch, why >> bother? > > We were assigned a /43. insofar as I can tell that's Arin policy working > just fine. > Mind if I ask what is is so I can see if it's in my Verizon table? Offlist is fine, I can just post yea/nea to the list. ~Seth From morrowc.lists at gmail.com Mon Oct 5 23:43:16 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Oct 2009 00:43:16 -0400 Subject: Practical numbers for IPv6 allocations In-Reply-To: <4ACABBF5.8030005@dougbarton.us> References: <4ACABBF5.8030005@dougbarton.us> Message-ID: <75cb24520910052143o2ea6764fs7d347d10dba81a30@mail.gmail.com> On Mon, Oct 5, 2009 at 11:39 PM, Doug Barton wrote: > As a practical matter we're "stuck" with /64 as the smallest possible > network we can reliably assign. A /60 contains 16 /64s, which > personally I think is more than enough for a residential customer, > even taking a "long view" into consideration. The last time I looked > into this there were several ISPs in Japan who were assigning /60s to > their residential users with good success. OTOH, a /56 contains 256 > /64s, which is way WAY more than enough for a residential user. The > idea that a residential user needs a full /48 (65,536 /64s) is absurd. > OTOH, assigning a /48 to even a fairly large commercial customer is > perfectly reasonable. This would give them 256 /56 networks (which > would in turn have 256 /64 networks) which should be plenty to handle > the problems of multiple campuses with multiple subnets, etc. Keep in mind that not all 'fairly large enterprises' are willing to sit at a single ISP, they may have diverse offices on diverse network provider connections. They may want the easy of saying: 'All my address blocks are in 1.2.0.0/16' and not understand (or like) that they now have to deal with wierd routing and addressing problems because they can't get a /32 and break it up into /48's all over creation (different ISP's/links/etc) or deal with the split of address space they'd get from ISP /48 PA assignments. the enterprise world has changed quite a bit from IPNG's early days... Someone who runs a large Enterprise with global office locations and who's actually deploying ipv6 internally/externally ought to give a presentation at NANOG and/or IETF. I don't disagree with the math I snipped, I do appreciate you laying it out, and I don't think that there are a super large number of folks in the scenario I layed out above. I've seen quite a few at previous employers though... -Chris From eugen at imacandi.net Tue Oct 6 03:20:08 2009 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 06 Oct 2009 11:20:08 +0300 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <4AC93ED9.5080909@linuxbox.org> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> Message-ID: <4ACAFDB8.908@imacandi.net> Gadi Evron wrote: > Barton F Bruce wrote: >> Stopping the abuse is fine, but cutting service to the point that a >> family >> using VOIP only for their phone service can't call 911 and several >> children >> burn to death could bring all sorts of undesirable regulation let >> alone the >> bad press and legal expenses. > > While a legitimate concern it's also a red herring, as it's a > technical problem looking for a technical solution. > > Gadi. > I think the need for someone being able to call 911 from their VoIP outweighs your right to claim that they should be disconnected from the Internet. Besides, if that provider wants to help out, he might setup a captive portal or something with information regarding tools to clean their computer. From ge at linuxbox.org Tue Oct 6 05:06:41 2009 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 06 Oct 2009 12:06:41 +0200 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <4ACAFDB8.908@imacandi.net> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> Message-ID: <4ACB16B1.6060606@linuxbox.org> Eugeniu Patrascu wrote: > Gadi Evron wrote: >> Barton F Bruce wrote: >>> Stopping the abuse is fine, but cutting service to the point that a >>> family >>> using VOIP only for their phone service can't call 911 and several >>> children >>> burn to death could bring all sorts of undesirable regulation let >>> alone the >>> bad press and legal expenses. >> >> While a legitimate concern it's also a red herring, as it's a >> technical problem looking for a technical solution. >> >> Gadi. >> > I think the need for someone being able to call 911 from their VoIP > outweighs your right to claim that they should be disconnected from the > Internet. Again, I don't disagree, but I see it as a technical issue which is solvable. I don't see why this is THE issue. It's really just changing the subject of the discussion. > > > Besides, if that provider wants to help out, he might setup a captive > portal or something with information regarding tools to clean their > computer. > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From bjorn at mork.no Tue Oct 6 03:07:06 2009 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 06 Oct 2009 10:07:06 +0200 Subject: ISP customer assignments In-Reply-To: <200910060014.n960E1AP095142@aurora.sol.net> (Joe Greco's message of "Mon, 5 Oct 2009 19:14:01 -0500 (CDT)") References: <200910060014.n960E1AP095142@aurora.sol.net> Message-ID: <87ws39vtcl.fsf@nemi.mork.no> Joe Greco writes: > the people with the clue-by-fours are over on the IPv6 lists. They've upgraded to clue-by-six's. Not as handy, but will last longer. Bj?rn From sven at cyberbunker.com Tue Oct 6 06:41:26 2009 From: sven at cyberbunker.com (Sven Olaf Kamphuis) Date: Tue, 6 Oct 2009 11:41:26 +0000 (GMT) Subject: please leak piratebay prefix 194.71.107.0/24 Message-ID: we currently announce 194.71.107.0/24, unfortunately some of our carriers have been threattened by the illegal entertainment kartell mafia and dont really feel like relaying this prefix for us. if you do have this prefix over one of our peerings as i know many of you do, feel free to accidentially leak it to the rest of the world until something better is worked out :P (in a later stadium the old DCP AS is planned to be behind AS34109 again on its own, this is a temporary workaround) origin: AS34109 (CB3ROB / CYBERBUNKER) prefix: 194.71.107.0/24 action: leak :P if you want to "pick up" the piratebay prefix for your eyeballs you can do so by setting up peering with us at NL-IX (noc at cb3rob.net) or obtain it from several of our larger peers. -- Sven Olaf Kamphuis CB3ROB DataServices Phone: +31/87-8747479 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. From trejrco at gmail.com Tue Oct 6 06:59:46 2009 From: trejrco at gmail.com (TJ) Date: Tue, 6 Oct 2009 07:59:46 -0400 Subject: ISP customer assignments Message-ID: <71bfd60c0910060459q7ee89e38t606f8706b704fac5@mail.gmail.com> -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Most of those concerns are in fact mitigated by a well implemented Privacy > implementation Which is why I started off by mentioning RFC4191. ;) -----End Original Message----- And Vista/Win7/etc. make it even more interesting by not doing EUI64 at all. ... Hopefully they have more entropic 'random' values as well ... /TJ From trejrco at gmail.com Tue Oct 6 07:00:57 2009 From: trejrco at gmail.com (TJ) Date: Tue, 6 Oct 2009 08:00:57 -0400 Subject: Practical numbers for IPv6 allocations In-Reply-To: <4ACABBF5.8030005@dougbarton.us> References: <4ACABBF5.8030005@dougbarton.us> Message-ID: <71bfd60c0910060500n6de0615cn4ae2cbbcea15a726@mail.gmail.com> FWIW - I don't believe the two arguments are in opposition/conflict ... But totally agree with your end result of "/56s and /48s, with add'l bits held in reserve" ... /TJ On Mon, Oct 5, 2009 at 11:39 PM, Doug Barton wrote: > [ I normally don't say this, but please reply to the list only, thanks. ] > > I've been a member of the "let's not assume the IPv6 space is > infinite" school from day 1, even though I feel like I have a pretty > solid grasp of the math. Others have alluded to some of the reasons > why I have concerns about this, but they mostly revolve around the > concepts that the address space is not actually flat (i.e., it's going > to be carved up and handed out to RIRs, LIRs, companies, individuals, > etc.) and that both the people making the requests and the people > doing the allocations have a WIDE (pardon the pun) variety of > motivations, not all of which are centered around the greater good. > > I'm also concerned that the two main pillars of what I semi-jokingly > refer to as the "profligate" school of IPv6 allocation actually > conflict with one another (even if they both had valid major premises, > which I don't think they do). On the one hand people say, "The address > space is so huge, we should allocate and assign with a 50-100 year > time horizon" and on the other they say, "The address space is so > huge, even if we screw up 2000::/3 we have 7 more bites at the apple." > I DO believe that the space is large enough to make allocation > policies with a long time horizon, but relying on "trying again" if we > screw up the first time has a lot of costs that are currently > undefined, and should not be assumed to be trivial. It also ignores > the fact that if we reduce the pool of /3s because we do something > stupid with the first one we allocate from it reduces our > opportunities to do "cool things" with the other 7 that we haven't > even thought of yet. > > In regards to the first of the "profligate" arguments, the idea that > we can do anything now that will actually have even a 25 year horizon > is naively optimistic at best. It ignores the day-to-day realities of > corporate mergers and acquisitions, residential customers changing > residences and/or ISPs, the need for PI space, etc. IPv6 is not a "set > it and forget it" tool any more than IPv4 is because a lot of the same > realities apply to it. > > You also have to keep in mind that even if we could come up with a > theoretically "perfect" address allocation scheme at minimum the > existing space is going to be carved up 5 ways for each of the RIRs to > implement. (When I was at IANA I actually proposed dividing it along > the 8 /6 boundaries, which is sort of what has happened subsequently > if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to > LACNIC and 2c00::/12 to AfriNIC.) > > Since it's not germane to NANOG I will avoid rehashing the "why RA and > 64-bit host IDs were bad ideas from the start" argument. :) > > In the following I'm assuming that you're familiar with the fact that > staying on the 4-byte boundaries makes sense because it makes reverse > DNS delegation easier. It also makes the math easier. > > As a practical matter we're "stuck" with /64 as the smallest possible > network we can reliably assign. A /60 contains 16 /64s, which > personally I think is more than enough for a residential customer, > even taking a "long view" into consideration. The last time I looked > into this there were several ISPs in Japan who were assigning /60s to > their residential users with good success. OTOH, a /56 contains 256 > /64s, which is way WAY more than enough for a residential user. The > idea that a residential user needs a full /48 (65,536 /64s) is absurd. > OTOH, assigning a /48 to even a fairly large commercial customer is > perfectly reasonable. This would give them 256 /56 networks (which > would in turn have 256 /64 networks) which should be plenty to handle > the problems of multiple campuses with multiple subnets, etc. > > So let's assume that we'll take /56 as the standard unit of assignment > to residential customers, and /48 as the standard unit of assignment > to commercial customers. A /32 has 65,536 /48s in it. If your business > was focused mainly on commercial customers that's not a very big pool. > OTOH if your business was focused primarily on residential customers > you'd have 16,777,216 /56s to work with. That's enough for even a very > large regional ISP. One could also easily imagine a model where out of > a /32 you carve out one /34 for /56 assignments (4,194,304) and use > the other 3/4ths of the space for /48s (49,152). > > A really large ("national" or even "global") ISP would obviously need > more space if they were going to intelligently divide up addresses on > a regional basis. A /28 would have 16 /32s which should be enough for > even a "very large" ISP, but let's really make sure that we cover the > bases and go /24 (256 /32s). Even if you assume splitting that address > space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s, > and 8,388,608 /48s. > > There are roughly 2,097,152 /24s in 2000::/3 (I say "roughly" because > I'm ignoring space that's already been carved out, like 6to4, etc.), > or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that > yes, we really do have "a lot" of space to work with. I also think it > means that even with "a lot" of space there is no point in wasting it > with foolish allocation policies that give out way more space than is > realistically necessary just "because we can." > > I've ignored PI space up till now but I think it's reasonable for > there to be a midpoint for PI somewhere between /48 and /32. > Personally I think that a /40 has a nice sound to it. That's 256 /48 > networks. I don't see any reason why the RIRs couldn't also agree to a > /36, which would be 4,096 /48s. Even I don't see any reason why they > should mess around with numbers like /41 or /43. > > To get back to the question that started the original thread, if I > were the one who was requesting an IPv6 allocation I would use the > following formula: > > 1 /56 per # of residential customers expected in 10 years > + > 1 /48 per # of business customers expected in 10 years > > Then assuming your current numbers are roughly 1/16th of what you hope > they'll be in 10 years; when actually handing out addresses I'd give > out the first /60 from each /56 to the residential customers. That way > if you need to you can go back and chop up those /56s. I'd also start > off handing out the first /48 out of every /44 to my commercial > customers. That way they will have room to expand painlessly. This is > sort of a bastardized version of the "sparse allocation" model that > the RIRs have promoted. (Obviously the 1/16th number was chosen for > convenience, but hopefully you get the idea of what I'm going for here.) > > I realize that this is quite long, so if you've gotten this far, > congratulations! I hope it was useful. > > > Doug > > -- > > Food for thought is no substitute for the real thing. > -- Walt Kelly, "Potluck Pogo" > > > -- /TJ From bgreene at senki.org Tue Oct 6 08:04:56 2009 From: bgreene at senki.org (Barry Raveendran Greene) Date: Tue, 6 Oct 2009 06:04:56 -0700 Subject: Dutch ISPs to collaborate and take responsibilityfor bottedclients In-Reply-To: <4ACB16B1.6060606@linuxbox.org> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport><4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> <4ACB16B1.6060606@linuxbox.org> Message-ID: > > I think the need for someone being able to call 911 from their VoIP > > outweighs your right to claim that they should be disconnected from > > the Internet. > > Again, I don't disagree, but I see it as a technical issue > which is solvable. I don't see why this is THE issue. It's > really just changing the subject of the discussion. It is a technical issue that is already solved. There are deploy walled garden/quarantine systems in the US with 911 regulations which will shunt customers who are violated to a clean up section of the network. 911 and other services are not included in this shunt. The deployments are improving over time, as each operator who has deployed gains more experience. For a sample, check out: ftp://ftp-eng.cisco.com/SP-Security/Quarantine/QuaWhitePaper8.pdf And http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 From dwhite at olp.net Tue Oct 6 08:36:13 2009 From: dwhite at olp.net (Dan White) Date: Tue, 6 Oct 2009 08:36:13 -0500 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> Message-ID: <20091006133613.GA5059@dan.olp.net> On 05/10/09?22:28?-0400, Ricky Beam wrote: > On Mon, 05 Oct 2009 17:13:37 -0400, Dan White wrote: >> I don't understand. You're saying you have overlapping class boundaries >> in your network? > > No. What I'm saying is IPv6 is supposed to be the new, ground-breaking, > unimaginably huge *classless* network. Yet, 2 hours into day one, a > classful boundary has already been woven into it's DNA. Saying it's I would disagree. IPv6 is designed around class boundaries which, in my understanding, are: A layer two network gets assigned a /64 A customer gets assigned a /48 An ISP gets assigned a /32 (unless they need more) > classless because routing logic doesn't care is pure bull. In order for > the most basic, fundamental, part (the magic -- holy grail -- address > autoconfig) to function, the network has to be a minimum of /64. Even > when the reason for that limit -- using one's MAC to form a (supposedly) > unique address without having to consult with anything or fire off a > single packet -- has long bit the dust; privacy extensions generate > addresses at random and have to take steps to avoid address collisions, > so continuing to cling to "it has to be 64bits" is infuriating. IPv6 provides you the opportunity to design your network around your layer two needs, not limited by restrictive layer 3 subnetting needs. If your complaint is that all devices in a /64 are going to see IPv6 broadcast/multicast packets from the rest of the devices in that subnet, then don't assign 2^64 devices to that subnet. I still don't understand why its infuriating to you, but I can certainly tell that it is. -- Dan White BTC Broadband From dwhite at olp.net Tue Oct 6 08:42:18 2009 From: dwhite at olp.net (Dan White) Date: Tue, 6 Oct 2009 08:42:18 -0500 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <174173.1254782109@turing-police.cc.vt.edu> <20091005225534.GU5403@dan.olp.net> Message-ID: <20091006134218.GA7127@dan.olp.net> On 05/10/09?22:53?-0400, Ricky Beam wrote: > On Mon, 05 Oct 2009 18:55:35 -0400, Dan White wrote: >> All of the items in the above list are true of DHCP. ... > > In an IPv4 world (which is where DHCP lives), it's much MUCH harder to > track assignments -- I don't share my DHCP logs with anyone, nor does > anyone send theirs to me. From the perspective of remote systems (ie. > not on the same network), there is about a 100% chance NAT is involved > making it near impossible to individually identify a specific machine, > even if it gets the same address every Tuesday when you're at Starbucks > for coffee. IPv6 does away with NAT (or it's supposed to); in doing so, > the veil is removed and everything that had been hidden from site is now > openly displayed. If the "host" part of your address never changes, then > you are instantly identifiable everywhere you go, with zero effort, > forever. Use random addresses, and change as often as you like. Why depend on someone else's DHCP server to provide you the addressing uniqueness you desire? -- Dan White BTC Broadband From trejrco at gmail.com Tue Oct 6 08:45:45 2009 From: trejrco at gmail.com (TJ) Date: Tue, 6 Oct 2009 09:45:45 -0400 Subject: ISP customer assignments In-Reply-To: <20091006133613.GA5059@dan.olp.net> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <20091006133613.GA5059@dan.olp.net> Message-ID: <71bfd60c0910060645o16c17563x91e65ced700a2d2d@mail.gmail.com> Actually, I would argue IPv6 is a bit of both classfull and classless. (Moreso the latter ...) The protocol itself, /64 "mandate" aside, certainly allows you to place arbitrary-bit-long prefix lengths - and to aggregate/summarize at any point. And /64s do not so much apply in some cases, whether 'permitted' by spec (/128) or not(/126). Thus classless. OTOH, we have policies that define how we will allocate this address space that do look eerily similar to the Classfull methods we started off with in IPv4. I too am always ... hmm, surprised isn't the right word ... when this angers|scares|confuses people. Anyway, I enjoy the conversation and hope this helps ... /TJ On Tue, Oct 6, 2009 at 9:36 AM, Dan White wrote: > On 05/10/09 22:28 -0400, Ricky Beam wrote: > >> On Mon, 05 Oct 2009 17:13:37 -0400, Dan White wrote: >> >>> I don't understand. You're saying you have overlapping class boundaries >>> in your network? >>> >> >> No. What I'm saying is IPv6 is supposed to be the new, ground-breaking, >> unimaginably huge *classless* network. Yet, 2 hours into day one, a >> classful boundary has already been woven into it's DNA. Saying it's >> > > I would disagree. IPv6 is designed around class boundaries which, in my > understanding, are: > > A layer two network gets assigned a /64 > A customer gets assigned a /48 > An ISP gets assigned a /32 (unless they need more) > > classless because routing logic doesn't care is pure bull. In order for >> the most basic, fundamental, part (the magic -- holy grail -- address >> autoconfig) to function, the network has to be a minimum of /64. Even >> when the reason for that limit -- using one's MAC to form a (supposedly) >> unique address without having to consult with anything or fire off a >> single packet -- has long bit the dust; privacy extensions generate >> addresses at random and have to take steps to avoid address collisions, so >> continuing to cling to "it has to be 64bits" is infuriating. >> > > IPv6 provides you the opportunity to design your network around your layer > two needs, not limited by restrictive layer 3 subnetting needs. > > If your complaint is that all devices in a /64 are going to see IPv6 > broadcast/multicast packets from the rest of the devices in that subnet, > then don't assign 2^64 devices to that subnet. > > I still don't understand why its infuriating to you, but I can certainly > tell that it is. > > -- > Dan White > BTC Broadband > > -- /TJ From lee at asgard.org Tue Oct 6 08:51:54 2009 From: lee at asgard.org (lee at asgard.org) Date: Tue, 6 Oct 2009 09:51:54 -0400 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <4ACAFDB8.908@imacandi.net> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> Message-ID: <001301ca468c$2fd192f0$8f74b8d0$@org> > -----Original Message----- > From: Eugeniu Patrascu [mailto:eugen at imacandi.net] > Sent: Tuesday, October 06, 2009 4:20 AM > To: Gadi Evron > Cc: NANOG > Subject: Re: Dutch ISPs to collaborate and take responsibility for bottedclients . > > > I think the need for someone being able to call 911 from their VoIP > outweighs your right to claim that they should be disconnected from the > Internet. I believe the FCC requires even deactivated phones to be able to reach 911. Can't confirm, fcc.gov is down. Don't know about CRTC. And I don't know how this could apply to an over-the-top VoIP service--how would an ISP know you're trying to call 911 on Skype? > Besides, if that provider wants to help out, he might setup a captive > portal or something with information regarding tools to clean their > computer. Many providers already do that. Lee From lee at asgard.org Tue Oct 6 09:21:08 2009 From: lee at asgard.org (Lee Howard) Date: Tue, 6 Oct 2009 10:21:08 -0400 Subject: ISP customer assignments In-Reply-To: <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> Message-ID: <002001ca4690$41071aa0$c3154fe0$@org> > -----Original Message----- > From: William Herrin [mailto:herrin-nanog at dirtside.com] > Sent: Monday, October 05, 2009 12:58 PM > To: Brian Johnson > Cc: nanog at nanog.org > Subject: Re: ISP customer assignments > > /60 - the smallest amount you should allocate to a downstream customer > with more than one computer. Anything smaller will cost you extra > management overhead from not matching the nibble boundary for RDNS > delegation, I have a lack of imagination, I guess. I can't imagine anyone larger than a small residential user being assigned a /60 or less. Therefore, nybble boundary for rDNS delegation only matters if you delegate rDNS for that block. > handling multiple routes when the customer grows, not Any customer getting a /60 or less will be dynamically numbered (RA, DHCPv6, whatever), and if more space is needed, should be easily renumbered into a larger prefix. > matching the standard /64 subnet size and a myriad other obscure > issues. I don't know about "myriad" but I agree that /64 is the standard subnet size. I am *not* advocating assignments of /60 or less, just pointing out that if you do it, it doesn't have to break. Lee From dwhite at olp.net Tue Oct 6 09:25:44 2009 From: dwhite at olp.net (Dan White) Date: Tue, 6 Oct 2009 09:25:44 -0500 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> Message-ID: <20091006142543.GC7127@dan.olp.net> On 05/10/09?23:23?-0400, Ricky Beam wrote: > You underestimate the power of the marketing department and the bean > counters. I assure you, residential ISPs are looking for schemes to give > out as little address space as possible. That has not been my (limited) experience. If you are aware of any ISPs which are not handing out a reasonable address space to customers, please call them out. >> The current revision of IPv6 introduces a way to nail down the boundary >> between network and host. This is fantastic, from an implementation >> point of view. It simplifies the design of silicon for forwarding >> engines, etc. > > And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The > instant some idiot wires /64 into silicon, we're right back to not being > able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot > make any assumptions about what people may or may not be doing with those > bits. If I don't use SLAAC, then I'm not bound by it's lame rules. > >> You don't do that. Or at least, you shouldn't do that. :-) We have a >> fairly reliable DNS system these days... The assumption that IPv6 addresses are harder has not been my experience. A server address of 2610:b8:5::1 is just as easy for me to remember as 67.217.144.1. Granted, auto configured addresses are much harder to remember. > And where did DNS get the name/number assignments? In my case, it's > either been typed in by ME or automatically updated by DHCP. Anything I put in DNS is a server/router, and gets a static address, just like with IPv4. -- Dan White BTC Broadband From lee at asgard.org Tue Oct 6 09:29:50 2009 From: lee at asgard.org (Lee Howard) Date: Tue, 6 Oct 2009 10:29:50 -0400 Subject: ISP customer assignments In-Reply-To: References: Message-ID: <002101ca4691$77a5d780$66f18680$@org> > -----Original Message----- > From: Robert.E.VanOrmer at frb.gov [mailto:Robert.E.VanOrmer at frb.gov] > Sent: Monday, October 05, 2009 7:41 PM > To: nanog at nanog.org > Subject: Re: ISP customer assignments > > Organizations will be provided /48s or smaller, but given the current > issues with routing /48's globally, I think you will find more > organizations fighting for /32s or smaller... Most organizations will still be assigned a /48 (or whatever) from their ISP. Provider-aggregable addressing has no routing scalability problems. > I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 > bit address... I have to agree, here. Moving between letters and numbers, and having to hit "shift" to use the colon wastes valuable keystrokes compared to the keypad. However, compare IPv6 vs IPv4-like numbering: 2001:db8:f1::1 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 Did I type the right number of zeroes? Lee From alh-ietf at tndh.net Tue Oct 6 09:32:18 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 6 Oct 2009 07:32:18 -0700 Subject: Practical numbers for IPv6 allocations In-Reply-To: <4ACABBF5.8030005@dougbarton.us> References: <4ACABBF5.8030005@dougbarton.us> Message-ID: <25fd01ca4691$cf0a6e50$6d1f4af0$@net> Doug Barton wrote: > [ I normally don't say this, but please reply to the list only, thanks. > ] > > I've been a member of the "let's not assume the IPv6 space is > infinite" school from day 1, even though I feel like I have a pretty > solid grasp of the math. Others have alluded to some of the reasons > why I have concerns about this, but they mostly revolve around the > concepts that the address space is not actually flat (i.e., it's going > to be carved up and handed out to RIRs, LIRs, companies, individuals, > etc.) and that both the people making the requests and the people > doing the allocations have a WIDE (pardon the pun) variety of > motivations, not all of which are centered around the greater good. > > I'm also concerned that the two main pillars of what I semi-jokingly > refer to as the "profligate" school of IPv6 allocation actually > conflict with one another (even if they both had valid major premises, > which I don't think they do). On the one hand people say, "The address > space is so huge, we should allocate and assign with a 50-100 year > time horizon" and on the other they say, "The address space is so > huge, even if we screw up 2000::/3 we have 7 more bites at the apple." > I DO believe that the space is large enough to make allocation > policies with a long time horizon, but relying on "trying again" if we > screw up the first time has a lot of costs that are currently > undefined, and should not be assumed to be trivial. I agree with the point about undefined costs, but the biggest one that is easy to see is that 100-300 years from now when someone thinks about moving on to the second /3, this entire discussion will have been lost and there will be an embedded-for-generations expectation that the model is cast in stone for all of the /3's. > It also ignores > the fact that if we reduce the pool of /3s because we do something > stupid with the first one we allocate from it reduces our > opportunities to do "cool things" with the other 7 that we haven't > even thought of yet. www.tndh.net/~tony/ietf/draft-hain-ipv6-geo-addr-00.txt shows a different way to allocate space, using only 1/16 the total space to achieve a /48 globally on a 6m grid. Other ideas will emerge, so you are correct that we can't assume we have 8 shots at this, but if the first pass is really bad the second will be so draconian in restrictions that you will never get to the third. > > In regards to the first of the "profligate" arguments, the idea that > we can do anything now that will actually have even a 25 year horizon > is naively optimistic at best. It ignores the day-to-day realities of > corporate mergers and acquisitions, residential customers changing > residences and/or ISPs, the need for PI space, etc. IPv6 is not a "set > it and forget it" tool any more than IPv4 is because a lot of the same > realities apply to it. Well mostly. It is not set & forget, but a lot of the day-to-day in IPv4 is wrapped up in managing subnet sizes to 'avoid waste'. In an IPv6 environment the only concern is the total number of subnets needed to meet routing/access policy, avoiding the nonsense of continually shifting the subnet size to align with the number of endpoints over time. > > You also have to keep in mind that even if we could come up with a > theoretically "perfect" address allocation scheme at minimum the > existing space is going to be carved up 5 ways for each of the RIRs to > implement. (When I was at IANA I actually proposed dividing it along > the 8 /6 boundaries, which is sort of what has happened subsequently > if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to > LACNIC and 2c00::/12 to AfriNIC.) > > Since it's not germane to NANOG I will avoid rehashing the "why RA and > 64-bit host IDs were bad ideas from the start" argument. :) People need to get over it... the original design was 64 bits for both hosts and routing exceeding the design goal by >10^3, then routing wanted more so it was given the whole 64 bits. The fact that 64 more bits was added is not routing's concern, but the IPv4-conservation mindset can't seem to let it go despite having >10^6 more space to work with than the target. It could have been 32 bits (resulting in a 96 bit address), but given that 64 bit processors were expected to be widespread, it makes no sense to use less than that. > > In the following I'm assuming that you're familiar with the fact that > staying on the 4-byte boundaries makes sense because it makes reverse > DNS delegation easier. It also makes the math easier. I assume you meant 4-bit. ;) ^^^ > > As a practical matter we're "stuck" with /64 as the smallest possible > network we can reliably assign. A /60 contains 16 /64s, which > personally I think is more than enough for a residential customer, > even taking a "long view" into consideration. Stop looking backward. To achieve the home network of the last millennium a small number of subnets was appropriate. Constraining the world to that through allocation is a self-fulfilling way to force people that need more than that to develop/deploy hacks to work around the braindead practice. > The last time I looked > into this there were several ISPs in Japan who were assigning /60s to > their residential users with good success. OTOH, a /56 contains 256 > /64s, which is way WAY more than enough for a residential user. The > idea that a residential user needs a full /48 (65,536 /64s) is absurd. A consumer is not a professional network operator and can't do 'well managed' subnet structures the way that this community would. To allow a plug-n-play consumer network, a fair amount of 'waste' is required. > OTOH, assigning a /48 to even a fairly large commercial customer is > perfectly reasonable. This would give them 256 /56 networks (which > would in turn have 256 /64 networks) which should be plenty to handle > the problems of multiple campuses with multiple subnets, etc. > > So let's assume that we'll take /56 as the standard unit of assignment > to residential customers, and /48 as the standard unit of assignment > to commercial customers. A /32 has 65,536 /48s in it. If your business > was focused mainly on commercial customers that's not a very big pool. A /32 is a starter-kit for a new ISP with no customers, so this argument is a continuation of the bogus 'denial' mindset used to avoid deployments. A real ISP should be documenting the number of customers they have * /48, then add in normal hierarchy loss and get a 'REAL BLOCK'. > OTOH if your business was focused primarily on residential customers > you'd have 16,777,216 /56s to work with. That's enough for even a very > large regional ISP. One could also easily imagine a model where out of > a /32 you carve out one /34 for /56 assignments (4,194,304) and use > the other 3/4ths of the space for /48s (49,152). > > A really large ("national" or even "global") ISP would obviously need > more space if they were going to intelligently divide up addresses on > a regional basis. A /28 would have 16 /32s which should be enough for > even a "very large" ISP, but let's really make sure that we cover the > bases and go /24 (256 /32s). Even if you assume splitting that address > space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s, > and 8,388,608 /48s. > > There are roughly 2,097,152 /24s in 2000::/3 (I say "roughly" because > I'm ignoring space that's already been carved out, like 6to4, etc.), > or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that > yes, we really do have "a lot" of space to work with. I also think it > means that even with "a lot" of space there is no point in wasting it > with foolish allocation policies that give out way more space than is > realistically necessary just "because we can." I agree we should not be foolish, but that includes not partitioning the space into a bunch of discontiguous blocks just 'because that is how we did IPv4'. From a big picture perspective we have already avoided 'waste' by agreeing to limitations on how much a new ISP gets and using a justification process for those that need more. The fact that end customers are not required to do the same level of justification (until they get really large), is avoiding waste in terms of process. The lack of tight control at the edge allows for innovation, which in turn drives the whole system forward. > > I've ignored PI space up till now but I think it's reasonable for > there to be a midpoint for PI somewhere between /48 and /32. > Personally I think that a /40 has a nice sound to it. That's 256 /48 > networks. I don't see any reason why the RIRs couldn't also agree to a > /36, which would be 4,096 /48s. Even I don't see any reason why they > should mess around with numbers like /41 or /43. I personally agree, but we have a structure in place, and it has to have something to do to justify its continued existence. > > To get back to the question that started the original thread, if I > were the one who was requesting an IPv6 allocation I would use the > following formula: > > 1 /56 per # of residential customers expected in 10 years > + > 1 /48 per # of business customers expected in 10 years I would make that /48 & /44 > > Then assuming your current numbers are roughly 1/16th of what you hope > they'll be in 10 years; when actually handing out addresses I'd give > out the first /60 from each /56 to the residential customers. That way > if you need to you can go back and chop up those /56s. BS ... go back and get the larger block that supports the current customer base. The argument you present here says that an ISP gets one & only one shot at an allocation. The only way the approach of growing the request to match the customer base will ever be a problem is if every person on the planet individually subscribed to every service provider, but even that nonsense would work up to 32k providers globally. > I'd also start > off handing out the first /48 out of every /44 to my commercial > customers. That way they will have room to expand painlessly. This is > sort of a bastardized version of the "sparse allocation" model that > the RIRs have promoted. (Obviously the 1/16th number was chosen for > convenience, but hopefully you get the idea of what I'm going for > here.) > > I realize that this is quite long, so if you've gotten this far, > congratulations! I hope it was useful. As people emerge from denial they need this type of lengthy and well reasoned line of thought, even though I disagree with some of the details. Tony From bjohnson at drtel.com Tue Oct 6 10:09:45 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 6 Oct 2009 10:09:45 -0500 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> Message-ID: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> Rick et al, I work at an ISP, and I know staff at several other ISPs, we are all trying to do this right. If a /56 makes sense and is supported by the IPv6 technology and we won't have issues supplying these to customers (technically speaking), then we will most likely do this or something similar. The issue is more of a nuanced issue. There seems to be a variance between "It's OK to just give out a /64" to "You better be thinking about giving out a /48". I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound? This wasn't suppose to digress to this level of vitriol. - Brian > -----Original Message----- > From: Ricky Beam [mailto:jfbeam at gmail.com] > Sent: Monday, October 05, 2009 10:23 PM > To: Joe Greco; Robert.E.VanOrmer at frb.gov > Cc: nanog at nanog.org > Subject: Re: ISP customer assignments > > On Mon, 05 Oct 2009 20:14:01 -0400, Joe Greco > wrote: > > Generally speaking, we shouldn't *want* end users to be provided with > a > > single /64. The number of addresses is not the point. The idea of > > getting rid of the horribleness that is CIDR is the point. > > You underestimate the power of the marketing department and the bean > counters. I assure you, residential ISPs are looking for schemes to > give > out as little address space as possible. > > > The current revision of IPv6 introduces a way to nail down the > boundary > > between network and host. This is fantastic, from an implementation > > point of view. It simplifies the design of silicon for forwarding > > engines, etc. > > And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The > instant some idiot wires /64 into silicon, we're right back to not > being > able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot > make any assumptions about what people may or may not be doing with > those > bits. If I don't use SLAAC, then I'm not bound by it's lame rules. > > > You don't do that. Or at least, you shouldn't do that. :-) We have > a > > fairly reliable DNS system these days... > > And where did DNS get the name/number assignments? In my case, it's > either been typed in by ME or automatically updated by DHCP. > > --Ricky From owen at delong.com Tue Oct 6 10:56:48 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Oct 2009 08:56:48 -0700 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <4ACAFDB8.908@imacandi.net> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> Message-ID: <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> On Oct 6, 2009, at 1:20 AM, Eugeniu Patrascu wrote: > Gadi Evron wrote: >> Barton F Bruce wrote: >>> Stopping the abuse is fine, but cutting service to the point that >>> a family >>> using VOIP only for their phone service can't call 911 and several >>> children >>> burn to death could bring all sorts of undesirable regulation let >>> alone the >>> bad press and legal expenses. >> >> While a legitimate concern it's also a red herring, as it's a >> technical problem looking for a technical solution. >> >> Gadi. >> > I think the need for someone being able to call 911 from their VoIP > outweighs your right to claim that they should be disconnected from > the Internet. > > > Besides, if that provider wants to help out, he might setup a > captive portal or something with information regarding tools to > clean their computer. I disagree... Distributed Denials of Service have gotten to the point where they can actually endanger lives. Think about this... In order to be able to make your 911 VOIP call, the VOIP provider has to be able to process your call. The system that is getting disconnected because it is an active source of abuse may be one of many participating in a DOS against someone elses 911 VOIP provider. Removing them from the internet could be saving more lives than it risks. Someone else pointed out that if the system in question has been botted/owned/pwn3d/whatever you want to call it, then, you can't guarantee it would make the 911 call correctly anyway. Owen From mark at edgewire.sg Tue Oct 6 11:08:17 2009 From: mark at edgewire.sg (mark [at] edgewire) Date: Wed, 7 Oct 2009 00:08:17 +0800 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> Message-ID: <7E534842-E607-4B49-AB2B-D6778925A6C9@edgewire.sg> The end problem is still users and really, these users will click on anything that has a bright and shiny button which says, Ok. Really, does setting up a portal help? Perhaps a "sandboxed" area which has some information on securing their machine and keeping it clean may be the way to go but how much more of a resource will it chew up? Best regards, Mark On 06-Oct-2009, at 11:56 PM, Owen DeLong wrote: > > On Oct 6, 2009, at 1:20 AM, Eugeniu Patrascu wrote: > >> Gadi Evron wrote: >>> Barton F Bruce wrote: >>>> Stopping the abuse is fine, but cutting service to the point that >>>> a family >>>> using VOIP only for their phone service can't call 911 and >>>> several children >>>> burn to death could bring all sorts of undesirable regulation let >>>> alone the >>>> bad press and legal expenses. >>> >>> While a legitimate concern it's also a red herring, as it's a >>> technical problem looking for a technical solution. >>> >>> Gadi. >>> >> I think the need for someone being able to call 911 from their VoIP >> outweighs your right to claim that they should be disconnected from >> the Internet. >> >> >> Besides, if that provider wants to help out, he might setup a >> captive portal or something with information regarding tools to >> clean their computer. > > I disagree... Distributed Denials of Service have gotten to the > point where they can actually endanger > lives. Think about this... In order to be able to make your 911 > VOIP call, the VOIP provider has to > be able to process your call. The system that is getting > disconnected because it is an active source > of abuse may be one of many participating in a DOS against someone > elses 911 VOIP provider. > Removing them from the internet could be saving more lives than it > risks. > > Someone else pointed out that if the system in question has been > botted/owned/pwn3d/whatever > you want to call it, then, you can't guarantee it would make the 911 > call correctly anyway. > > Owen > > From kloch at kl.net Tue Oct 6 11:12:05 2009 From: kloch at kl.net (Kevin Loch) Date: Tue, 06 Oct 2009 12:12:05 -0400 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <4ACA12E3.5020600@rollernet.us> <29A54911243620478FF59F00EBB12F4701A60AD3@ex01.drtel.lan> <87k4z91z80.fsf@laphroiag.quux.de> <20091005183451.GA53850@typo.org> Message-ID: <4ACB6C55.6080909@kl.net> Owen DeLong wrote: > Part of the reason that 128 bits was chosen (64 bits is FAR more than > enough) was that it allowed for 64 bits of stateless auto-configuration > (IEEE was already pushing EUI-64) within each network and still > provided more than enough network numbers. I'm sure the Really Smart People over at the IETF could have figured out a way to do auto configuration with "just" 16 bits of /112 (or a /48 of 64 bit space). It will be interesting to see if things evolve to using /112's anyway just to escape auto configuration. I use them for router links and server subnets because it's a convenient boundary for notation. - Kevin From owen at delong.com Tue Oct 6 11:34:28 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Oct 2009 09:34:28 -0700 Subject: ISP customer assignments In-Reply-To: <002101ca4691$77a5d780$66f18680$@org> References: <002101ca4691$77a5d780$66f18680$@org> Message-ID: On Oct 6, 2009, at 7:29 AM, Lee Howard wrote: >> -----Original Message----- >> From: Robert.E.VanOrmer at frb.gov [mailto:Robert.E.VanOrmer at frb.gov] >> Sent: Monday, October 05, 2009 7:41 PM >> To: nanog at nanog.org >> Subject: Re: ISP customer assignments >> >> Organizations will be provided /48s or smaller, but given the current >> issues with routing /48's globally, I think you will find more >> organizations fighting for /32s or smaller... > > Most organizations will still be assigned a /48 (or whatever) from > their > ISP. Provider-aggregable addressing has no routing scalability > problems. > > >> I can see between IPv4 and IPv6 is how much of a pain it is to type >> a 128 >> bit address... > > I have to agree, here. Moving between letters and numbers, and having > to hit "shift" to use the colon wastes valuable keystrokes compared to > the keypad. However, compare IPv6 vs IPv4-like numbering: > > 2001:db8:f1::1 > 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 > > Did I type the right number of zeroes? > I don't know, but, it's not 81.93.35.12... It's: 32.1.13.184.241.0.0.0.0.0.0.0.0.0.0.1 And that is the correct number of zeroes for 2001:db8:f1::1. Also, there's no reason the syntax couldn't be made 32.1.13.184.241..1 although that isn't the case today. However, I believe that 90.1 is supposed to be parsed equivalent to 90.0.0.1 and 90.5.1 is supposed to be treated as 90.5.0.1, so, 32.1.13.184.241.1 should also work for the above if you expanded todays IPv4 notation to accept IPv6 length addresses. Owen > > Lee > From fw at deneb.enyo.de Tue Oct 6 12:03:52 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 06 Oct 2009 17:03:52 +0000 Subject: IPv6 peering between Internet2 and Hurricane Electric In-Reply-To: <87eiph6bm9.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Mon, 05 Oct 2009 16:37:02 +0000") References: <87eiph6bm9.fsf@mid.deneb.enyo.de> Message-ID: <871vlgihdz.fsf@mid.deneb.enyo.de> * Florian Weimer: > It seems to be down, based on > and trying to get a > traceroute to he.net/2001:470:0:76::2 from the SEAT location. BGP > seems to be up, though. I've been told that the looking glass needs some knowledge about Internet2's routing architecture to use properly, and that I had misinterpreted its output. Sorry about that. > Shouldn't this cause quite a few problems for Internet2 downstreams? > (We received a report from an academic site in Brazil that some > security.debian.org IPv6 instances are inaccessible, that's why I > looked.) That site hasn't got global IPv6 transit, and it's likely that this is causing the reachability issue (d'oh). From bzs at world.std.com Tue Oct 6 12:04:17 2009 From: bzs at world.std.com (Barry Shein) Date: Tue, 6 Oct 2009 13:04:17 -0400 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> Message-ID: <19147.30865.579881.16413@world.std.com> Re: VOIP, 911, bots Shape their bandwidth down to the minimum required to make a 911 call, around 64Kbps, and capture their web accesses. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From dougb at dougbarton.us Tue Oct 6 12:10:47 2009 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 06 Oct 2009 10:10:47 -0700 Subject: Practical numbers for IPv6 allocations In-Reply-To: <25fd01ca4691$cf0a6e50$6d1f4af0$@net> References: <4ACABBF5.8030005@dougbarton.us> <25fd01ca4691$cf0a6e50$6d1f4af0$@net> Message-ID: <4ACB7A17.7020209@dougbarton.us> Tony Hain wrote: > Doug Barton wrote: >> In the following I'm assuming that you're familiar with the fact that >> staying on the 4-byte boundaries makes sense because it makes reverse >> DNS delegation easier. It also makes the math easier. > > I assume you meant 4-bit. ;) Grrr, I hate when I do that. I spent quite a bit of time on this post, and the one time I remembered that I needed to go back and double-check what I wrote there I wasn't at the keyboard. Thanks for keeping me honest. There was one other thing you wrote that I wanted to clarify, you indicated that I was arguing for ISPs to only get one shot at an IPv6 allocation. Since my post was already really long I chose to leave out the bit about how (TMK, which could be outdated) the RIRs are reserving a bit or two for their allocations to ISPs so going back and expanding should be an easy thing to do. On a personal note, I hope that we DO need to expand IPv6 allocations to ISPs as this thing finally gets deployed. I'm not responding to the rest of your post because you and I have already had those discussions in person on more than one occasion and I know I'm not going to change your mind. I do think it's extremely gracious of you to say that my post was "well reasoned" though. :) Thanks to the others who had nice things to say as well. Regards, Doug From Valdis.Kletnieks at vt.edu Tue Oct 6 12:27:10 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Oct 2009 13:27:10 -0400 Subject: ISP customer assignments In-Reply-To: Your message of "Tue, 06 Oct 2009 09:34:28 PDT." References: <002101ca4691$77a5d780$66f18680$@org> Message-ID: <11902.1254850030@turing-police.cc.vt.edu> On Tue, 06 Oct 2009 09:34:28 PDT, Owen DeLong said: > although that isn't the case today. However, I believe > that 90.1 is supposed to be parsed equivalent to 90.0.0.1 > and 90.5.1 is supposed to be treated as 90.5.0.1, so, > 32.1.13.184.241.1 should also work for the above if > you expanded todays IPv4 notation to accept IPv6 length > addresses. So if you expand the notation like that, is 32.1.13.7 a 32 bit IPv4 address, or a 128 bit IPv6 address with lots of zeros between 13 and 7? They chose the ":" instead of overloading '.' for a *reason*... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeroen at unfix.org Tue Oct 6 13:09:20 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 06 Oct 2009 20:09:20 +0200 Subject: Up Next: Quarantine Phishing (Was: Dutch ISPs to collaborate and take responsibility for bottedclients) In-Reply-To: <7E534842-E607-4B49-AB2B-D6778925A6C9@edgewire.sg> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> <7E534842-E607-4B49-AB2B-D6778925A6C9@edgewire.sg> Message-ID: <4ACB87D0.5060703@spaghetti.zurich.ibm.com> mark [at] edgewire wrote: > The end problem is still users and really, these users will click on > anything that has a bright and shiny button which says, Ok. Really, does > setting up a portal help? Perhaps a "sandboxed" area which has some > information on securing their machine and keeping it clean may be the > way to go but how much more of a resource will it chew up? And then the nice phisher people come in and they replicate the quarantine website of various providers (just check IP address, you know the ISP and present the appropriate page) after having lured them to some site they control. Then they simply have a nice big "Install this cool tool to update your computer" link et voila. The problem with all of that boils down to what people have to believe... and how to properly inform them of that... Yes, I think the sandbox/quarantine style things is the way to go for the time being, but there are other more important things that need fixing. (afaik) Most people will get infected by clicking on something at one point in time on some weird website, even after having googled it etc. The problem is that it is really hard to show to the user that a site is 'trustworty' or not, especially as everyone can just get an SSL certificate for faceb0ok.com and m1crosoft.com and soon also for all the nice variants in the IDN space, thus SSL doesn't state anything, it just makes the connection secure (aka unsniffable unless there is a 3 letter acronym doing so, or they have access to either end). And that would not help much either as even Facebook and other such sites have been used to distribute worms, thus it becomes really hard to do it on a domain basis, as what is on a domain at point X in time, will be different at point Y, thus distributing lists becomes problematic too. The company that can come up with a proper universal solution to that problem (and patent it so they can actually get the moneyz) will probly end up doing quite well. Most likely though it means restricting user freedom, which is the counter problem as that is something one doesn't want, and when there is an option to disable it, then people will just disable it. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From bonomi at mail.r-bonomi.com Tue Oct 6 13:50:07 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 6 Oct 2009 13:50:07 -0500 (CDT) Subject: Dutch ISPs to collaborate and take responsibility for bottedclients Message-ID: <200910061850.n96Io796007082@mail.r-bonomi.com> > > > -----Original Message----- > > From: Eugeniu Patrascu [mailto:eugen at imacandi.net] > > Sent: Tuesday, October 06, 2009 4:20 AM > > To: Gadi Evron > > Cc: NANOG > > Subject: Re: Dutch ISPs to collaborate and take responsibility for > bottedclients > . > > > > > I think the need for someone being able to call 911 from their VoIP > > outweighs your right to claim that they should be disconnected from the > > Internet. > > I believe the FCC requires even deactivated phones to be able to reach 911. > Can't confirm, fcc.gov is down. Authoritatively *NOT* true for hard-wire landlines in the U.S. Cellular may, and I believe _is_, be a different story. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Oct 6 16:40:40 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 7 Oct 2009 08:10:40 +1030 Subject: ISP customer assignments In-Reply-To: <20091006142543.GC7127@dan.olp.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <20091006142543.GC7127@dan.olp.net> Message-ID: <20091007081040.40af2ae3@opy.nosense.org> On Tue, 6 Oct 2009 09:25:44 -0500 Dan White wrote: > On 05/10/09?23:23?-0400, Ricky Beam wrote: > > You underestimate the power of the marketing department and the bean > > counters. I assure you, residential ISPs are looking for schemes to give > > out as little address space as possible. > > That has not been my (limited) experience. If you are aware of any ISPs > which are not handing out a reasonable address space to customers, please > call them out. > Once one of them actually realises how much address space they've been given, and that giving more perceived value to a customer will win them the business, I think they will e.g. same price, same quota/bandwidth, one ISP giving you 64K more address space. I think customers will say, "I fully understand what it's for, and I don't really know what I'll use it for .. but I'll have it if I ever need it." > >> The current revision of IPv6 introduces a way to nail down the boundary > >> between network and host. This is fantastic, from an implementation > >> point of view. It simplifies the design of silicon for forwarding > >> engines, etc. > > > > And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The > > instant some idiot wires /64 into silicon, we're right back to not being > > able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot > > make any assumptions about what people may or may not be doing with those > > bits. If I don't use SLAAC, then I'm not bound by it's lame rules. > > I think it is both "classless" and "classfull" (although it's different enough that we probably should stop using loaded IPv4 terms ...) Forwarding is purely "classless" - the best route is the one with the longest matching prefix length, regardless of where that prefix length lands within the 128 bits. For 1/8th of the address space, it's "classful". It's been shown that humans work best with simplicity, so introducing fixed operational (but not forwarding) boundaries between node, subnet and global prefixes makes IPv6 much more operationally simple than dealing with IPv4 classes, subnets or classless addressing. I think anybody who has dealt operationally with IPX, Appletalk, XNS, DECnet or even Ethernet with it's single OUI/Node ID boundary would agree. If the plan for the "classful" 1/8th ends up being wrong, the "classless" forwarding means that we don't have to deploy new routing code or hardware to change to a different addressing model, be it "classless" or something else. > >> You don't do that. Or at least, you shouldn't do that. :-) We have a > >> fairly reliable DNS system these days... > > The assumption that IPv6 addresses are harder has not been my > experience. A server address of 2610:b8:5::1 is just as easy > for me to remember as 67.217.144.1. Granted, auto configured > addresses are much harder to remember. > > > And where did DNS get the name/number assignments? In my case, it's > > either been typed in by ME or automatically updated by DHCP. > > Anything I put in DNS is a server/router, and gets a static address, just > like with IPv4. > > -- > Dan White > BTC Broadband > From jgreco at ns.sol.net Tue Oct 6 18:27:55 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 6 Oct 2009 18:27:55 -0500 (CDT) Subject: Dutch ISPs to collaborate and take responsibility In-Reply-To: <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> from "Owen DeLong" at Oct 06, 2009 08:56:48 AM Message-ID: <200910062327.n96NRt5E093517@aurora.sol.net> > Someone else pointed out that if the system in question has been > botted/owned/pwn3d/whatever > you want to call it, then, you can't guarantee it would make the 911 > call correctly anyway. I realize that many NANOG'ers don't actually use the technologies that we talk about, so I'm just going to correct this: You seem to be under the mistaken assumption that most people using VoIP do so using their computer. While it kind of started out that way years ago, it simply isn't so anymore. Most VoIP services can be configured to work with an analog telephony adapter, providing a POTS jack. Most VoIP services even provide one as part of the subscription, sometimes for a fee. There's also a growing number of phones that support Skype or generic VoIP, sometimes alongside a regular POTS line, sometimes not. It is perfectly possible to have an infected PC sitting right next to a nice VoIP-capable DECT cordless phone system, both hooked to the same NAT router. This is, of course, problematic, and would be a useful problem to contemplate how to cause one to break while keeping the other operational. Assuming that the existence of an infected PC in the mix translates to some sort of inability to make a 911 call correctly is, however, simply irresponsible, and at some point, is probably asking for trouble. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mysidia at gmail.com Tue Oct 6 19:02:34 2009 From: mysidia at gmail.com (James Hess) Date: Tue, 6 Oct 2009 19:02:34 -0500 Subject: ISP customer assignments In-Reply-To: <20091006133613.GA5059@dan.olp.net> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <20091006133613.GA5059@dan.olp.net> Message-ID: <6eb799ab0910061702q7cd602e8x1d6470103bd5bbc9@mail.gmail.com> >> ?unimaginably huge *classless* network. ?Yet, 2 hours into day one, a >> ?classful boundary has already been woven into it's DNA. ?Saying it's No bit patterns in a V6 address indicate total size of a network. v6 doesn't bring classful addressing back or get rid of CIDR.. v6 dispenses with something much older: common use of VLSM on the local LAN and sizing subnets based on the number of hosts. Instead a form of FLSM is recommended, a fixed standard subnet size of /64 that essentially all IPv6 networks use for the subnets that have hosts on them. This restores consistency to LAN addressing. In V4 there is a valid reason for choosing VLSM and sizing every subnet: IP addresses are scarce. V6 removes that scarcity problem. No more unanticipated growth necessitating an addressing re-design, or at least error-prone adjustment of netmasks on all hosts. No more hodgepodge of different netmask settings for different sized LANs. No more LAN address ranges starting or ending with a different trailing string of digits than other LANs. /64 is the standard. V6 leaves the operator able to pick something different, but in most cases it would be a very poor design practice, and ISPs should think long and hard before ignoring the standard and trying to issue a customer subnet a /128, instead of /48 or /56. However... none of the network protocol documents were ever able to prevent determined people from coming up with bad designs, or ignoring recommendations due to politics or preconceived notion(s); don't hold your breath on that one... -- -J From jfbeam at gmail.com Tue Oct 6 20:09:12 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 06 Oct 2009 21:09:12 -0400 Subject: ISP customer assignments In-Reply-To: <20091007081040.40af2ae3@opy.nosense.org> References: <200910060014.n960E1AP095142@aurora.sol.net> <20091006142543.GC7127@dan.olp.net> <20091007081040.40af2ae3@opy.nosense.org> Message-ID: On Tue, 06 Oct 2009 17:40:40 -0400, Mark Smith wrote: > I think it is both "classless" and "classfull" (although it's different > enough that we probably should stop using loaded IPv4 terms ...) It's _classless_. There's none of this Class A, B, C, D, or E nonsense. The word everyone is dancing around is, "hierarchical". How the bits get divided up depends on what you want to do with it. SLAAC, in it's current form, requires a 64-bit prefix, but there are other ways to assign addresses that do not have that requirement. --Ricky From nanog at daork.net Tue Oct 6 20:13:06 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 7 Oct 2009 14:13:06 +1300 Subject: Practical numbers for IPv6 allocations In-Reply-To: <4ACB7A17.7020209@dougbarton.us> References: <4ACABBF5.8030005@dougbarton.us> <25fd01ca4691$cf0a6e50$6d1f4af0$@net> <4ACB7A17.7020209@dougbarton.us> Message-ID: <02F303E3-1F6F-40B0-B055-18DA36D9EC3E@daork.net> On 7/10/2009, at 6:10 AM, Doug Barton wrote: > Tony Hain wrote: >> Doug Barton wrote: >>> In the following I'm assuming that you're familiar with the fact >>> that >>> staying on the 4-byte boundaries makes sense because it makes >>> reverse >>> DNS delegation easier. It also makes the math easier. >> >> I assume you meant 4-bit. ;) > > Grrr, I hate when I do that. I spent quite a bit of time on this post, > and the one time I remembered that I needed to go back and > double-check what I wrote there I wasn't at the keyboard. Thanks for > keeping me honest. > > There was one other thing you wrote that I wanted to clarify, you > indicated that I was arguing for ISPs to only get one shot at an IPv6 > allocation. Since my post was already really long I chose to leave out > the bit about how (TMK, which could be outdated) the RIRs are > reserving a bit or two for their allocations to ISPs so going back and > expanding should be an easy thing to do. On a personal note, I hope > that we DO need to expand IPv6 allocations to ISPs as this thing > finally gets deployed. My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. -- Nathan Ward From drc at virtualized.org Tue Oct 6 20:17:23 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 6 Oct 2009 18:17:23 -0700 Subject: Practical numbers for IPv6 allocations In-Reply-To: <02F303E3-1F6F-40B0-B055-18DA36D9EC3E@daork.net> References: <4ACABBF5.8030005@dougbarton.us> <25fd01ca4691$cf0a6e50$6d1f4af0$@net> <4ACB7A17.7020209@dougbarton.us> <02F303E3-1F6F-40B0-B055-18DA36D9EC3E@daork.net> Message-ID: <480A7B9A-F4B5-4CFF-A9EE-4C8874A10993@virtualized.org> On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: > My understanding is that the RIRs are doing sparse allocation, as > opposed to reserving a few bits. I could be wrong. Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed. Regards, -drc From drc at virtualized.org Tue Oct 6 20:27:09 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 6 Oct 2009 18:27:09 -0700 Subject: Practical numbers for IPv6 allocations In-Reply-To: <480A7B9A-F4B5-4CFF-A9EE-4C8874A10993@virtualized.org> References: <4ACABBF5.8030005@dougbarton.us> <25fd01ca4691$cf0a6e50$6d1f4af0$@net> <4ACB7A17.7020209@dougbarton.us> <02F303E3-1F6F-40B0-B055-18DA36D9EC3E@daork.net> <480A7B9A-F4B5-4CFF-A9EE-4C8874A10993@virtualized.org> Message-ID: <17F120FE-8077-4CEE-9C6B-4C26435C5701@virtualized.org> On Oct 6, 2009, at 6:17 PM, David Conrad wrote: > On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: >> My understanding is that the RIRs are doing sparse allocation, as >> opposed to reserving a few bits. I could be wrong. > > Last I heard, with the exception of APNIC and contrary to what they > indicated they'd do prior to IANA allocating the /12s, you are > indeed wrong. I'd be happy to hear things have changed. Sigh. Seem to have troubles posting coherent English to the Nanog list recently. The "they" in the above sentence references the RIRs except for APNIC (last I heard). Regards, -drc From hank at efes.iucc.ac.il Wed Oct 7 00:44:57 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 7 Oct 2009 07:44:57 +0200 (IST) Subject: Does Internet Speed Vary by Season? Message-ID: http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion -Hank From justin at justinshore.com Wed Oct 7 03:10:36 2009 From: justin at justinshore.com (Justin Shore) Date: Wed, 07 Oct 2009 03:10:36 -0500 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: Message-ID: <4ACC4CFC.9030608@justinshore.com> Hank Nussbacher wrote: > http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion It's an interesting theory, that temperature affects overall throughput. Their assumptions on other conditions that affect bandwidth consumption are off IMHO. Our own data directly refutes what Wired reported in this article. Summertime is our most heavily utilized months on our network on average. For SPs heavily laden with residential subs I think this is probably the norm. Then school starts and you have a pronounced drop in traffic (that includes a major dip when college begins and again when primary school begins). The rates slowly increase back to their summer time highs until the holiday season begins where they either remain steady or taper off slightly. The theory here is that the high-bandwidth users are too busy with holiday affairs to play games, download music/porn, etc. That is until after X-mas when consumption suddenly spikes in a very pronounced way (new computers for X-mas). This also corresponds to our biggest month for new service turnups and speed increases in our bundles. Late winter varies from fairly constant to slight growth. Our single biggest days are the ones proceeding a major winter storm, or if the storm doesn't cut power to large swaths of our service area then the days in the middle of the winter storms come out on top. Spring growth depends on the weather. Good weather means less consumption for us. Bad weather means more consumption. Our least busy month is May when the kids are the most busy. June and July again show a major turn around. Bandwidth consumption is directly tied to your user demographics. If your SP is primarily business circuit then your traffic patterns will vary wildly from that of a SP with primarily residential circuits. Every SP is a little bit different. That's why some SPs set personal records for bandwidth consumption when Michael Jackson's memorial service was broadcast (including SPs less than an hour away from me) and other SPs (mine for example) didn't have a single user stream the broadcast and otherwise had a normal bandwidth day. Other than Wired making an assumption that all SPs have nearly identical traffic patterns, the article is otherwise ok. Justin From a.harrowell at gmail.com Wed Oct 7 03:43:26 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 7 Oct 2009 09:43:26 +0100 Subject: Dutch ISPs to collaborate and take responsibility In-Reply-To: <200910062327.n96NRt5E093517@aurora.sol.net> References: <200910062327.n96NRt5E093517@aurora.sol.net> Message-ID: <200910070943.26457.a.harrowell@gmail.com> On Wednesday 07 October 2009 00:27:55 Joe Greco wrote: > Assuming that the existence of an infected PC in the mix translates to > some sort of inability to make a 911 call correctly is, however, simply > irresponsible, and at some point, is probably asking for trouble. > > ... JG Also, someone mentioned that the FCC doesn't in fact mandate that PSTN terminals should be able to make emergency calls even if formally disconnected and asked about cellular. The opposite is true about GSM and its descendants; whether or not you're a valid roamer for the network you're talking to, have a prepaid balance, have paid your bill, you must be able to make emergency calls. Similarly, even if no SIM card is present, the device should register with the network as "limited service" - i.e. emergency only. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From marcoh at marcoh.net Wed Oct 7 04:16:35 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 7 Oct 2009 10:16:35 +0100 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: Message-ID: <6BE87046-1142-4A11-926E-88DC708F725F@marcoh.net> On Oct 7, 2009, at 6:44 AM, Hank Nussbacher wrote: > http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion I'm not sure the effects are so big compared to the actual speed that they are noticable for the average user. We also don't have any proper data available but we do (operating in NL) notice from time to time that periods with loads of rain can have influence on the stabillity and speed of DSL lines especially in older areas of towns where they still have paper/lead covered cabling instead of more modern PVC isolation. This as more visible when everybody still used 56k dialup.This may as well be a very local effect, the western part of our country is largely at or even below sealevel and very wet already. However as these effects might get you a few kilobits extra from time to time that effect is not visible in overall usage statisctics, as soon as the sun comes out we see traffic levels drop to only rise again near september when everybody is back to school and the office. As far as traffic levels go, it's the rainy winter nights which make it into the recordbooks. Grtx, Marco From davet1 at gmail.com Wed Oct 7 06:17:57 2009 From: davet1 at gmail.com (Dave Temkin) Date: Wed, 07 Oct 2009 18:17:57 +0700 Subject: Dutch ISPs to collaborate and take responsibility In-Reply-To: <200910070943.26457.a.harrowell@gmail.com> References: <200910062327.n96NRt5E093517@aurora.sol.net> <200910070943.26457.a.harrowell@gmail.com> Message-ID: <4ACC78E5.2060303@gmail.com> Alexander Harrowell wrote: > On Wednesday 07 October 2009 00:27:55 Joe Greco wrote: > > >> Assuming that the existence of an infected PC in the mix translates to >> some sort of inability to make a 911 call correctly is, however, simply >> irresponsible, and at some point, is probably asking for trouble. >> >> ... JG >> > > Also, someone mentioned that the FCC doesn't in fact mandate that PSTN > terminals should be able to make emergency calls even if formally disconnected > and asked about cellular. > > The opposite is true about GSM and its descendants; whether or not you're a > valid roamer for the network you're talking to, have a prepaid balance, have > paid your bill, you must be able to make emergency calls. Similarly, even if > no SIM card is present, the device should register with the network as > "limited service" - i.e. emergency only. > > The FCC generally doesn't come into play when you're talking about ILEC telephone service except at a very high level. In California, by PUC regulation telephone companies are required to allow access to 911 so long as there is copper in the facility and it was, at any time, active with any sort of phone service. Ref: http://ucan.org/telenforcers/files/SBC%20complaint%20PUC%20version.pdf Ref2: http://law.onecle.com/california/utilities/2883.html I believe this is also the case in numerous other states. From p.caci at seabone.net Wed Oct 7 08:26:43 2009 From: p.caci at seabone.net (Pierfrancesco Caci) Date: Wed, 07 Oct 2009 15:26:43 +0200 Subject: Does Internet Speed Vary by Season? In-Reply-To: (Hank Nussbacher's message of "Wed, 7 Oct 2009 07:44:57 +0200 (IST)") References: Message-ID: <87y6nnbai4.fsf@clarabella.noc.seabone.net> :-> "Hank" == Hank Nussbacher writes: > http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion > -Hank There are TXCOs and OXCOs inside equipment for a reason. And rubidium lamps as well, sometimes. Seasonal variations in usage from the end customers are a fact of life, instead. If your net is large enough you can even spot the different habits about vacations, holidays and whatnot across the different regions. Pf -- ------------------------------------------------------------------------------- Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC p.caci at seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/ From owen at delong.com Wed Oct 7 08:25:53 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Oct 2009 06:25:53 -0700 Subject: Dutch ISPs to collaborate and take responsibility In-Reply-To: <200910062327.n96NRt5E093517@aurora.sol.net> References: <200910062327.n96NRt5E093517@aurora.sol.net> Message-ID: On Oct 6, 2009, at 4:27 PM, Joe Greco wrote: >> Someone else pointed out that if the system in question has been >> botted/owned/pwn3d/whatever >> you want to call it, then, you can't guarantee it would make the 911 >> call correctly anyway. > > I realize that many NANOG'ers don't actually use the technologies that > we talk about, so I'm just going to correct this: > > You seem to be under the mistaken assumption that most people using > VoIP > do so using their computer. While it kind of started out that way > years > ago, it simply isn't so anymore. Most VoIP services can be > configured to > work with an analog telephony adapter, providing a POTS jack. Most > VoIP > services even provide one as part of the subscription, sometimes for a > fee. > I do use VOIP, bot computer and non-computer based. None the less, the fact remains that should any of my systems become compromised, my ability to make a VOIP phone call is in doubt regardless of what the provider does. Additionally the problems of DDOS sourced from a collection of compromised hosts could be interfering with someone else's ability to make a successful VOIP call. Abuse sources should be blocked from impacting the rest of the network. This blocking should be as narrow as possible. Owen From patrick at ianai.net Wed Oct 7 09:16:17 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Oct 2009 10:16:17 -0400 Subject: Does Internet Speed Vary by Season? In-Reply-To: <87y6nnbai4.fsf@clarabella.noc.seabone.net> References: <87y6nnbai4.fsf@clarabella.noc.seabone.net> Message-ID: <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> On Oct 7, 2009, at 9:26 AM, Pierfrancesco Caci wrote: > :-> "Hank" == Hank Nussbacher writes: > >> http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion >> -Hank > > There are TXCOs and OXCOs inside equipment for a reason. And rubidium > lamps as well, sometimes. > > Seasonal variations in usage from the end customers are a fact of > life, instead. If your net is large enough you can even spot the > different habits about vacations, holidays and whatnot across the > different regions. I read the article and the follow up posts and I wonder if we are all using the same definition for "speed" here. The article seems to imply you don't get 6 Mbps on your DSL line in summer because the copper is hotter and it's harder to push electrons down the link. That is clearly BS, the clock is ticking six million times per second, period. Then it talks about traffic, which is very different than speed, at least in my book. If the intertubes are congested, you might get less throughput, but your "speed" is the same. And congestion cannot affect speed. That laser is blinking at 10 billion times per second whether the queue behind the port is full or not. (And don't tell me the laser is quiescent when the queue is empty, you know what I mean.) So what are are talking here? Speed, throughput, congestion, packet loss, latency ... ? Oh, and while I am certain it is true different networks see different peaks & valleys for different seasons & times of day, the "Internet" (whatever the hell that is) definitely has less traffic in summer than fall. -- TTFN, patrick From sean at donelan.com Wed Oct 7 09:20:47 2009 From: sean at donelan.com (Sean Donelan) Date: Wed, 7 Oct 2009 10:20:47 -0400 (EDT) Subject: Up Next: Quarantine Phishing (Was: Dutch ISPs to collaborate and take responsibility for bottedclients) In-Reply-To: <4ACB87D0.5060703@spaghetti.zurich.ibm.com> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> <7E534842-E607-4B49-AB2B-D6778925A6C9@edgewire.sg> <4ACB87D0.5060703@spaghetti.zurich.ibm.com> Message-ID: <200910071017020.6B95064B.2643@clifden.donelan.com> On Tue, 6 Oct 2009, Jeroen Massar wrote: > The problem with all of that boils down to what people have to > believe... and how to properly inform them of that... How many people remember this oldie, but goodie? 3.3.2.1.1 Trusted Path The TCB shall support a trusted communication path between itself and users for use when a positive TCB-touser connection is required (e.g., login, change subject security level). Communications via this trusted path shall be activated exclusively by a user of the TCB and shall be logically isolated and unmistakably distinguishable from other paths. Its simple to say, hard to do. From bclark at spectraaccess.com Wed Oct 7 09:27:38 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Wed, 07 Oct 2009 10:27:38 -0400 Subject: Does Internet Speed Vary by Season? In-Reply-To: <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> References: <87y6nnbai4.fsf@clarabella.noc.seabone.net> <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> Message-ID: <1254925658.8515.10.camel@acer-laptop> Yeah I have to agree...that article was poorly written and clearly the author has little understanding of physics. "Velocity" has absolutely nothing to do with Wiedemann-Franz law, we are talking resistance and that determines current through the wire; not how fast the electrons are flowing through the wire. Plus unless you are selling services on Mercury or Pluto, the temperature extremes between summer and winter are not enough to affect the resistance level of a copper in such a manner that it would affect the current on the circuit. We all have traffic utilization graphs, and, at least in my case, its pretty obviously that trends are affected by seasons only in terms of vacation, holidays, and eve if it's a Monday or a Friday. If we need to do major backbone upgrades, we try to schedule around a holiday weekend, because that's when we find Internet traffic to be the least (well from a business utilization point of view). Bret On Wed, 2009-10-07 at 10:16 -0400, Patrick W. Gilmore wrote: > On Oct 7, 2009, at 9:26 AM, Pierfrancesco Caci wrote: > > > :-> "Hank" == Hank Nussbacher writes: > > > >> http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion > >> -Hank > > > > There are TXCOs and OXCOs inside equipment for a reason. And rubidium > > lamps as well, sometimes. > > > > Seasonal variations in usage from the end customers are a fact of > > life, instead. If your net is large enough you can even spot the > > different habits about vacations, holidays and whatnot across the > > different regions. > > I read the article and the follow up posts and I wonder if we are all > using the same definition for "speed" here. The article seems to > imply you don't get 6 Mbps on your DSL line in summer because the > copper is hotter and it's harder to push electrons down the link. > That is clearly BS, the clock is ticking six million times per second, > period. > > Then it talks about traffic, which is very different than speed, at > least in my book. If the intertubes are congested, you might get less > throughput, but your "speed" is the same. And congestion cannot > affect speed. That laser is blinking at 10 billion times per second > whether the queue behind the port is full or not. (And don't tell me > the laser is quiescent when the queue is empty, you know what I mean.) > > So what are are talking here? Speed, throughput, congestion, packet > loss, latency ... ? > > Oh, and while I am certain it is true different networks see different > peaks & valleys for different seasons & times of day, the > "Internet" (whatever the hell that is) definitely has less traffic in > summer than fall. > From tim at pelican.org Wed Oct 7 09:29:51 2009 From: tim at pelican.org (Tim Franklin) Date: Wed, 7 Oct 2009 14:29:51 +0000 (GMT) Subject: Does Internet Speed Vary by Season? In-Reply-To: <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> Message-ID: <10386696.1271254925791480.JavaMail.root@jennyfur.pelican.org> > I read the article and the follow up posts and I wonder if we are all > using the same definition for "speed" here. The article seems to > imply you don't get 6 Mbps on your DSL line in summer because the > copper is hotter and it's harder to push electrons down the link. > That is clearly BS, the clock is ticking six million times per second, > period. Are you trying to say that the *actual* DSL speed, as synchronised between the modems at either end, is neither a) affected by the physical characteristics of the copper pair, nor b) variable? I agree the article is woolly between line-speed, throughput, goodput, congestion, etc, but to say that DSL line speed is in any way fixed in the same way that Ethernet or PDH / SDH lines are is contrary to every DSL platform I've worked with. (Also, 6Mb/s DSL doesn't equate to 6 million ticks per second in anything relating to pushing electrons onto the wire. Remember, it's modem technology, just faster - your baud rate is still much lower than your bps.) Regards, Tim. From jgreco at ns.sol.net Wed Oct 7 09:48:30 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Oct 2009 09:48:30 -0500 (CDT) Subject: Does Internet Speed Vary by Season? In-Reply-To: from "Hank Nussbacher" at Oct 07, 2009 07:44:57 AM Message-ID: <200910071448.n97EmU9t080849@aurora.sol.net> > http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion It used to be that we would notice this, except that it had everything to do with temperature *and* dampness. In the '90's, it was still quite common for a lot of older outside plant to be really only "voice grade" and it wasn't unusual for copper to run all the way back to the CO, through a variety of taps and splice points. Even though Ma Bell would typically do a careful job handling their copper, the sheer number of potential points of failure meant that it wasn't unusual for water to infiltrate and penetrate. If I recall correctly, the worst was usually a long, hard cold rain (hey we're in Wisconsin) after which people who had been getting solidly high speed modem connects would see a somewhat slower speed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From scott at doc.net.au Wed Oct 7 09:52:22 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 7 Oct 2009 07:52:22 -0700 Subject: Does Internet Speed Vary by Season? In-Reply-To: <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> References: <87y6nnbai4.fsf@clarabella.noc.seabone.net> <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> Message-ID: On Wed, Oct 7, 2009 at 7:16 AM, Patrick W. Gilmore wrote: > I read the article and the follow up posts and I wonder if we are all using > the same definition for "speed" here. The article seems to imply you don't > get 6 Mbps on your DSL line in summer because the copper is hotter and it's > harder to push electrons down the link. That is clearly BS, the clock is > ticking six million times per second, period. > So you're saying that if I put in an 8Mbps ADSL1 connection, then I'm going to get a guaranteed 8Mbps point-to-point back to the exchange, regardless of the quality of my phone line, or the distance from the exchange? That laser is blinking at 10 billion times per second whether the queue > behind the port is full or not. (And don't tell me the laser is quiescent > when the queue is empty, you know what I mean.) > Laser? Perhaps this is a different type of ADSL than most people here are used to? (I'm not saying that the article is right, but...) Scott From Jonathan.Brashear at hq.speakeasy.net Wed Oct 7 09:52:55 2009 From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear) Date: Wed, 7 Oct 2009 07:52:55 -0700 Subject: Does Internet Speed Vary by Season? In-Reply-To: <200910071448.n97EmU9t080849@aurora.sol.net> References: from "Hank Nussbacher" at Oct 07, 2009 07:44:57 AM <200910071448.n97EmU9t080849@aurora.sol.net> Message-ID: <725755F5E728EE4086DAAF1A54DACF4F1A2D8124E9@sea5exbe1.speakeasy.hq> Trying to pinpoint the failure point on one of those circuits is a PITA as well. Getting a telco tech out to test on a circuit that only goes down when it rains is an exercise that Sisyphus would probably decline. Network Engineer, JNCIS-M > 214-981-1954 (office) > 214-642-4075 (cell) > jbrashear at hq.speakeasy.net http://www.speakeasy.net -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Wednesday, October 07, 2009 9:49 AM To: Hank Nussbacher Cc: nanog at nanog.org Subject: Re: Does Internet Speed Vary by Season? > http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion It used to be that we would notice this, except that it had everything to do with temperature *and* dampness. In the '90's, it was still quite common for a lot of older outside plant to be really only "voice grade" and it wasn't unusual for copper to run all the way back to the CO, through a variety of taps and splice points. Even though Ma Bell would typically do a careful job handling their copper, the sheer number of potential points of failure meant that it wasn't unusual for water to infiltrate and penetrate. If I recall correctly, the worst was usually a long, hard cold rain (hey we're in Wisconsin) after which people who had been getting solidly high speed modem connects would see a somewhat slower speed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From patrick at ianai.net Wed Oct 7 10:03:59 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Oct 2009 11:03:59 -0400 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: <87y6nnbai4.fsf@clarabella.noc.seabone.net> <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> Message-ID: <2B975057-E3D8-4866-ADB3-11736D6656FB@ianai.net> On Oct 7, 2009, at 10:52 AM, Scott Howard wrote: > On Wed, Oct 7, 2009 at 7:16 AM, Patrick W. Gilmore > wrote: >> I read the article and the follow up posts and I wonder if we are >> all using the same definition for "speed" here. The article seems >> to imply you don't get 6 Mbps on your DSL line in summer because >> the copper is hotter and it's harder to push electrons down the >> link. That is clearly BS, the clock is ticking six million times >> per second, period. >> > So you're saying that if I put in an 8Mbps ADSL1 connection, then > I'm going to get a guaranteed 8Mbps point-to-point back to the > exchange, regardless of the quality of my phone line, or the > distance from the exchange? Yes, everyone, I was imprecise. Please tell me all about baud and variability and such. Because that was the point I was trying to make. >> That laser is blinking at 10 billion times per second whether the >> queue behind the port is full or not. (And don't tell me the laser >> is quiescent when the queue is empty, you know what I mean.) >> > Laser? Perhaps this is a different type of ADSL than most people > here are used to? > > (I'm not saying that the article is right, but...) I admit I totally spaced on the fact DSL != ethernet when I was typing the first paragraph. But when I wrote the above, I actually thought to myself: "I better mention I'm talking about a 10G backbone link... nah, everyone on NANOG is smart enough to figure out what I meant." End of day, the point stands that the article is worse than useless as it does not add data to the general knowledge pool, but actually makes everyone dumber for reading it. Apparently it even made me forget how DSL works.... -- TTFN, patrick From bbc at misn.com Wed Oct 7 10:04:14 2009 From: bbc at misn.com (Bryan Campbell) Date: Wed, 07 Oct 2009 10:04:14 -0500 Subject: Does Internet Speed Vary by Season? In-Reply-To: <200910071448.n97EmU9t080849@aurora.sol.net> References: <200910071448.n97EmU9t080849@aurora.sol.net> Message-ID: <4ACCADEE.4030808@misn.com> No, I did not read the article . . . But, . . . Yes, DSL speed varies by season . . . or rather, temperature. But, this is really only the case for _aerial_copper_plant. Buried plant is nearly the same temperature year round. Copper pair resistance changes with temperature. And, therefore, the link speed of DSL will change depending upon the time of the year (temperature) and geographic location. If there is a difference of but a few degrees of temperature year round, then no there will be no difference. But, if you live in the desert southwest or even the mid-west where the temperatures can be 70-120 degrees different between seasons or even 40-70 degrees different between night and day . . . you are going to have pronounced differences in link speed. Worst cast, your link speed might vary 10-20%. The longer the cable length from the central office, the more the variance will be. But, this is something that must be measured on a case by case basis. And, since much of the aerial plant has been replaced with buried plant, this really isn't much of a problem anymore. BBC Joe Greco wrote: >> http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion > > It used to be that we would notice this, except that it had everything to > do with temperature *and* dampness. In the '90's, it was still quite > common for a lot of older outside plant to be really only "voice grade" > and it wasn't unusual for copper to run all the way back to the CO, > through a variety of taps and splice points. Even though Ma Bell would > typically do a careful job handling their copper, the sheer number of > potential points of failure meant that it wasn't unusual for water to > infiltrate and penetrate. If I recall correctly, the worst was usually > a long, hard cold rain (hey we're in Wisconsin) after which people who > had been getting solidly high speed modem connects would see a somewhat > slower speed. > > ... JG From adrian at creative.net.au Wed Oct 7 10:12:44 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 7 Oct 2009 23:12:44 +0800 Subject: Does Internet Speed Vary by Season? In-Reply-To: <4ACCADEE.4030808@misn.com> References: <200910071448.n97EmU9t080849@aurora.sol.net> <4ACCADEE.4030808@misn.com> Message-ID: <20091007151244.GA23874@skywalker.creative.net.au> Please don't forget moisture content. DSL speeds may drop during wet winters because cable pits fill with water. :) Those with real statistics, please stand up. I know ISPs who run large DSL infrastructures have these stats. I've even seen them at conferences. :) Adrian On Wed, Oct 07, 2009, Bryan Campbell wrote: > No, I did not read the article . . . But, . . . > > Yes, DSL speed varies by season . . . or rather, temperature. > > But, this is really only the case for _aerial_copper_plant. Buried > plant is nearly the same temperature year round. > > Copper pair resistance changes with temperature. And, therefore, the > link speed of DSL will change depending upon the time of the year > (temperature) and geographic location. > > If there is a difference of but a few degrees of temperature year round, > then no there will be no difference. But, if you live in the desert > southwest or even the mid-west where the temperatures can be 70-120 > degrees different between seasons or even 40-70 degrees different > between night and day . . . you are going to have pronounced differences > in link speed. > > Worst cast, your link speed might vary 10-20%. The longer the cable > length from the central office, the more the variance will be. But, > this is something that must be measured on a case by case basis. And, > since much of the aerial plant has been replaced with buried plant, this > really isn't much of a problem anymore. > > BBC > > Joe Greco wrote: > >>http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion > > > >It used to be that we would notice this, except that it had everything to > >do with temperature *and* dampness. In the '90's, it was still quite > >common for a lot of older outside plant to be really only "voice grade" > >and it wasn't unusual for copper to run all the way back to the CO, > >through a variety of taps and splice points. Even though Ma Bell would > >typically do a careful job handling their copper, the sheer number of > >potential points of failure meant that it wasn't unusual for water to > >infiltrate and penetrate. If I recall correctly, the worst was usually > >a long, hard cold rain (hey we're in Wisconsin) after which people who > >had been getting solidly high speed modem connects would see a somewhat > >slower speed. > > > >... JG -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From jgreco at ns.sol.net Wed Oct 7 10:13:02 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Oct 2009 10:13:02 -0500 (CDT) Subject: Dutch ISPs to collaborate and take responsibility In-Reply-To: from "Owen DeLong" at Oct 07, 2009 06:25:53 AM Message-ID: <200910071513.n97FD2Fq082215@aurora.sol.net> > On Oct 6, 2009, at 4:27 PM, Joe Greco wrote: > >> Someone else pointed out that if the system in question has been > >> botted/owned/pwn3d/whatever > >> you want to call it, then, you can't guarantee it would make the 911 > >> call correctly anyway. > > > > I realize that many NANOG'ers don't actually use the technologies that > > we talk about, so I'm just going to correct this: > > > > You seem to be under the mistaken assumption that most people using > > VoIP > > do so using their computer. While it kind of started out that way > > years > > ago, it simply isn't so anymore. Most VoIP services can be > > configured to > > work with an analog telephony adapter, providing a POTS jack. Most > > VoIP > > services even provide one as part of the subscription, sometimes for a > > fee. > > I do use VOIP, bot computer and non-computer based. None the less, the > fact remains that should any of my systems become compromised, my > ability to make a VOIP phone call is in doubt regardless of what the > provider does. Well, /that's/ obviously not true. Cable providers are already using PacketCable NCS (read: "MGCP lightly modified") to provide completely reliable QoS for their own VoIP-to-the-cablemodem products; you are going to find it tough to impact the service level of such a device. For general VoIP, there's no particularly good reason that the VoIP traffic cannot be QoS'd / filtered to allow VoIP to continue to work while gardening the remaining traffic from the customer. That is completely under the provider's control. Since many of the CPE devices actually have a programmable hardware ethernet switch, it is even possible to do a lot of the work in hardware. > Additionally the problems of DDOS sourced from a collection of > compromised > hosts could be interfering with someone else's ability to make a > successful > VOIP call. I think the above addresses that. There are always risks, of course. The guy pruning tree branches down the street can knock down the cable line, for example. Of course, he probably takes out the phone lines as well... :-) > Abuse sources should be blocked from impacting the rest of the network. Sure. > This blocking should be as narrow as possible. Yes, that's my point. We should be able to narrowly block compromised hosts so that we don't screw up legitimate VoIP uses. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From joelja at bogus.com Wed Oct 7 10:15:19 2009 From: joelja at bogus.com (joel jaeggli) Date: Wed, 07 Oct 2009 08:15:19 -0700 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: <87y6nnbai4.fsf@clarabella.noc.seabone.net> <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> Message-ID: <4ACCB087.6090002@bogus.com> Scott Howard wrote: > So you're saying that if I put in an 8Mbps ADSL1 connection, then I'm going > to get a guaranteed 8Mbps point-to-point back to the exchange, regardless of > the quality of my phone line, or the distance from the exchange? > > (I'm not saying that the article is right, but...) ADSL systems will retrain to a lower rate as line conditions (SNR) change for the worse. The attentuation characteristics of a given pair will change of time due to a number of factor, including but not certainly limited to physical wear, moisture invasion, localized source of interference, sunspot activity etc. Are dsl plants subject to localized environmental conditions? Absolutely. > Scott > From jgreco at ns.sol.net Wed Oct 7 10:28:29 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Oct 2009 10:28:29 -0500 (CDT) Subject: Does Internet Speed Vary by Season? In-Reply-To: <4ACCADEE.4030808@misn.com> from "Bryan Campbell" at Oct 07, 2009 10:04:14 AM Message-ID: <200910071528.n97FSTOW083365@aurora.sol.net> > No, I did not read the article . . . But, . . . > > Yes, DSL speed varies by season . . . or rather, temperature. > > But, this is really only the case for _aerial_copper_plant. Buried > plant is nearly the same temperature year round. Yes, but it is more susceptible to long-term water infiltration, which leads to longer-term speed drops. This is actually more difficult to work with and test for. > Copper pair resistance changes with temperature. And, therefore, the > link speed of DSL will change depending upon the time of the year > (temperature) and geographic location. > > If there is a difference of but a few degrees of temperature year round, > then no there will be no difference. But, if you live in the desert > southwest or even the mid-west where the temperatures can be 70-120 > degrees different between seasons or even 40-70 degrees different > between night and day . . . you are going to have pronounced differences > in link speed. You might. Or you might not. Around here, it's not unusual to see a difference of a hundred degrees between summer and winter. Speaking from a few decades of experience working with telecom up here, I'd be tempted to say that either a circuit tends towards being problematic or towards being reliable, and that where I've been able to ascertain enough facts, there's a correlation with the age of the outdoor plant- but that's only a loose correlation. > Worst cast, your link speed might vary 10-20%. The longer the cable > length from the central office, the more the variance will be. But, > this is something that must be measured on a case by case basis. And, > since much of the aerial plant has been replaced with buried plant, this > really isn't much of a problem anymore. Buried plant mostly has more consistent (maybe less severe) problems, IMHO. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From kloch at kl.net Wed Oct 7 10:39:04 2009 From: kloch at kl.net (Kevin Loch) Date: Wed, 07 Oct 2009 11:39:04 -0400 Subject: Practical numbers for IPv6 allocations In-Reply-To: <480A7B9A-F4B5-4CFF-A9EE-4C8874A10993@virtualized.org> References: <4ACABBF5.8030005@dougbarton.us> <25fd01ca4691$cf0a6e50$6d1f4af0$@net> <4ACB7A17.7020209@dougbarton.us> <02F303E3-1F6F-40B0-B055-18DA36D9EC3E@daork.net> <480A7B9A-F4B5-4CFF-A9EE-4C8874A10993@virtualized.org> Message-ID: <4ACCB618.7070509@kl.net> David Conrad wrote: > On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: >> My understanding is that the RIRs are doing sparse allocation, as >> opposed to reserving a few bits. I could be wrong. > > Last I heard, with the exception of APNIC and contrary to what they > indicated they'd do prior to IANA allocating the /12s, you are indeed > wrong. I'd be happy to hear things have changed. Only APNIC is doing "bisection" style assignments today: 20091001|apnic|AU|ipv6|2402:c00::|32|allocated 20091001|apnic|SG|ipv6|2402:400::|32|allocated 20091005|apnic|JP|ipv6|2402:1400::|32|allocated 20091006|apnic|NZ|ipv6|2402:1c00::|32|allocated 20090930|arin|US|ipv6|2607:fd70::|32|allocated 20090930|arin|CA|ipv6|2607:fd78::|32|allocated 20091001|arin|US|ipv6|2607:fd80::|32|allocated 20091006|arin|US|ipv6|2607:fd88::|32|allocated 20091005|ripencc|RU|ipv6|2a00:1440::|32|allocated 20091005|ripencc|SI|ipv6|2a00:1448::|32|allocated 20091005|ripencc|IE|ipv6|2a00:1450::|32|allocated 20091005|ripencc|BE|ipv6|2a00:1458::|32|allocated 20090709|lacnic|PY|ipv6|2800:3a0::|32|allocated 20090714|lacnic|CL|ipv6|2800:3b0::|32|allocated 20090807|lacnic|GY|ipv6|2800:3c0::|32|allocated 20090903|lacnic|AR|ipv6|2800:3d0::|32|allocated 20090708|afrinic|GH|ipv6|2001:43c0::|32|allocated 20090729|afrinic|EG|ipv6|2001:43c8::|32|allocated 20090813|afrinic|KE|ipv6|2001:43d0::|32|allocated 20090909|afrinic|ZA|ipv6|2001:43d8::|32|allocated - Kevin From mruiz at telwestservices.com Wed Oct 7 11:56:13 2009 From: mruiz at telwestservices.com (Michael Ruiz) Date: Wed, 7 Oct 2009 11:56:13 -0500 Subject: Message-ID: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> Group, I am stuck like chuck. We are unable to activate a VPN in one of the virtual firewall context. Under the crypto commands, none of the IP-sec are available. Any help on this would be appreciated. Version we running is 8.0(4) Michael Ruiz mruiz at telwestservices.com From mike.lyon at gmail.com Wed Oct 7 12:00:38 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 7 Oct 2009 10:00:38 -0700 Subject: In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> References: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> Message-ID: <1b5c1c150910071000l1c9b6d26l4ed7ba46471fd257@mail.gmail.com> Call 1-800-553-2447, they should be able to help. On Wed, Oct 7, 2009 at 9:56 AM, Michael Ruiz wrote: > Group, > > > > I am stuck like chuck. We are unable to activate a VPN > in one of the virtual firewall context. Under the crypto commands, none > of the IP-sec are available. Any help on this would be appreciated. > Version we running is 8.0(4) > > > > > > Michael Ruiz mruiz at telwestservices.com > > > > > > > From steve.tillinger at SourceMedia.com Wed Oct 7 12:00:29 2009 From: steve.tillinger at SourceMedia.com (Tillinger, Steve) Date: Wed, 7 Oct 2009 13:00:29 -0400 Subject: Message-ID: IPsec isn't available when in multiple context mode. -----Original Message----- From: Michael Ruiz [mailto:mruiz at telwestservices.com] Sent: Wednesday, October 07, 2009 12:56 PM To: nanog at nanog.org Subject: Group, I am stuck like chuck. We are unable to activate a VPN in one of the virtual firewall context. Under the crypto commands, none of the IP-sec are available. Any help on this would be appreciated. Version we running is 8.0(4) Michael Ruiz mruiz at telwestservices.com "This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution" From fobdfc at gmail.com Wed Oct 7 12:02:43 2009 From: fobdfc at gmail.com (Mike) Date: Wed, 7 Oct 2009 12:02:43 -0500 Subject: In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> References: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> Message-ID: VPNs work only in single, routed mode. VPN functionality is unavailable in configurations that include either security contexts, also referred to as multi-mode firewall, or Active/Active stateful failover. The exception to this caveat is that you can configure and use one connection for administrative purposes to (not through) the security appliance in transparent mode. From http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/vpnsysop.html On Wed, Oct 7, 2009 at 11:56 AM, Michael Ruiz wrote: > Group, > > > > ? ? ? ? ? ? ? ?I am stuck like chuck. ?We are unable to activate a VPN > in one of the virtual firewall context. ?Under the crypto commands, none > of the IP-sec are available. ?Any help on this would be appreciated. > Version we running is 8.0(4) > > > > > > Michael Ruiz mruiz at telwestservices.com > > > > > > > From jason at i6ix.com Wed Oct 7 12:02:37 2009 From: jason at i6ix.com (Jason Bertoch) Date: Wed, 07 Oct 2009 13:02:37 -0400 Subject: In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> References: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> Message-ID: <4ACCC9AD.2020801@i6ix.com> Michael Ruiz wrote: > Group, > > > > I am stuck like chuck. We are unable to activate a VPN > in one of the virtual firewall context. Under the crypto commands, none > of the IP-sec are available. Any help on this would be appreciated. > Version we running is 8.0(4) > > Isn't VPN only available in single-context mode? From jhodges at simplexity.com Wed Oct 7 12:26:06 2009 From: jhodges at simplexity.com (John Hodges) Date: Wed, 7 Oct 2009 13:26:06 -0400 Subject: In-Reply-To: <4ACCC9AD.2020801@i6ix.com> References: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> <4ACCC9AD.2020801@i6ix.com> Message-ID: I was in ASA class just last week and asked about this exact issue. I was told that at this time you cannot do the IPSec VPN in Multiple context mode (due to the ASA not being able to keep track of the SA). This is a software issue that Cisco is working on and has in test at this time. No timeframe for release though. -John -----Original Message----- From: Jason Bertoch [mailto:jason at i6ix.com] Sent: Wednesday, October 07, 2009 1:03 PM To: nanog at nanog.org Subject: Re: Michael Ruiz wrote: > Group, > > > > I am stuck like chuck. We are unable to activate a VPN > in one of the virtual firewall context. Under the crypto commands, none > of the IP-sec are available. Any help on this would be appreciated. > Version we running is 8.0(4) > > Isn't VPN only available in single-context mode? From dane.newman at gmail.com Wed Oct 7 12:29:00 2009 From: dane.newman at gmail.com (Dane Newman) Date: Wed, 7 Oct 2009 13:29:00 -0400 Subject: In-Reply-To: References: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> <4ACCC9AD.2020801@i6ix.com> Message-ID: yup you lose alot in mutli context mode such as vpn, and routing protocols. It basically just becomes a true stateful firewall. On Wed, Oct 7, 2009 at 1:26 PM, John Hodges wrote: > I was in ASA class just last week and asked about this exact issue. > > I was told that at this time you cannot do the IPSec VPN in Multiple > context mode (due to the ASA not being able to keep track of the SA). This > is a software issue that Cisco is working on and has in test at this time. > No timeframe for release though. > > -John > > -----Original Message----- > From: Jason Bertoch [mailto:jason at i6ix.com] > Sent: Wednesday, October 07, 2009 1:03 PM > To: nanog at nanog.org > Subject: Re: > > Michael Ruiz wrote: > > Group, > > > > > > > > I am stuck like chuck. We are unable to activate a VPN > > in one of the virtual firewall context. Under the crypto commands, none > > of the IP-sec are available. Any help on this would be appreciated. > > Version we running is 8.0(4) > > > > > Isn't VPN only available in single-context mode? > > > From devangnp at gmail.com Wed Oct 7 12:33:14 2009 From: devangnp at gmail.com (Devangnp) Date: Wed, 7 Oct 2009 11:33:14 -0600 Subject: In-Reply-To: References: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> <4ACCC9AD.2020801@i6ix.com> Message-ID: <669D1B9A-2390-4BA8-8D91-3092F9AE9653@gmail.com> Does Juniper firewall has same issue? Devang Patel On Oct 7, 2009, at 11:29 AM, Dane Newman wrote: > yup you lose alot in mutli context mode such as vpn, and routing > protocols. > It basically just becomes a true stateful firewall. > > On Wed, Oct 7, 2009 at 1:26 PM, John Hodges > wrote: > >> I was in ASA class just last week and asked about this exact issue. >> >> I was told that at this time you cannot do the IPSec VPN in Multiple >> context mode (due to the ASA not being able to keep track of the >> SA). This >> is a software issue that Cisco is working on and has in test at >> this time. >> No timeframe for release though. >> >> -John >> >> -----Original Message----- >> From: Jason Bertoch [mailto:jason at i6ix.com] >> Sent: Wednesday, October 07, 2009 1:03 PM >> To: nanog at nanog.org >> Subject: Re: > 5520> >> >> Michael Ruiz wrote: >>> Group, >>> >>> >>> >>> I am stuck like chuck. We are unable to activate a >>> VPN >>> in one of the virtual firewall context. Under the crypto >>> commands, none >>> of the IP-sec are available. Any help on this would be appreciated. >>> Version we running is 8.0(4) >>> >>> >> Isn't VPN only available in single-context mode? >> >> >> From smeuse at mara.org Wed Oct 7 12:46:15 2009 From: smeuse at mara.org (Steve Meuse) Date: Wed, 7 Oct 2009 13:46:15 -0400 Subject: Does Internet Speed Vary by Season? In-Reply-To: <4ACCB087.6090002@bogus.com> References: <87y6nnbai4.fsf@clarabella.noc.seabone.net> <35C18BC1-B796-414A-956C-E4F4B9288ADB@ianai.net> <4ACCB087.6090002@bogus.com> Message-ID: <20091007174615.GA8062@mara.org> joel jaeggli expunged (joelja at bogus.com): > ADSL systems will retrain to a lower rate as line conditions (SNR) > change for the worse. The attentuation characteristics of a given pair > will change of time due to a number of factor, including but not > certainly limited to physical wear, moisture invasion, localized source > of interference, sunspot activity etc. > > Are dsl plants subject to localized environmental conditions? Absolutely. I could be convinced that extremem heat could change a cables velocity factor, but that should only result in slight changes in phase, which I guess would result in a higher BER. Oh, and you forogot about cosmic rays :) -Steve From bonomi at mail.r-bonomi.com Wed Oct 7 12:53:26 2009 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 7 Oct 2009 12:53:26 -0500 (CDT) Subject: Dutch ISPs to collaborate and take responsibility Message-ID: <200910071753.n97HrQcH019671@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Wed Oct 7 06:18:24 2009 > Date: Wed, 07 Oct 2009 18:17:57 +0700 > From: Dave Temkin > To: Alexander Harrowell > Subject: Re: Dutch ISPs to collaborate and take responsibility > Cc: nanog at nanog.org > > Alexander Harrowell wrote: > > On Wednesday 07 October 2009 00:27:55 Joe Greco wrote: > > > > > >> Assuming that the existence of an infected PC in the mix translates to > >> some sort of inability to make a 911 call correctly is, however, simply > >> irresponsible, and at some point, is probably asking for trouble. > >> > >> ... JG > >> > > > > Also, someone mentioned that the FCC doesn't in fact mandate that PSTN > > terminals should be able to make emergency calls even if formally disconnected > > and asked about cellular. > > > > The opposite is true about GSM and its descendants; whether or not you're a > > valid roamer for the network you're talking to, have a prepaid balance, have > > paid your bill, you must be able to make emergency calls. Similarly, even if > > no SIM card is present, the device should register with the network as > > "limited service" - i.e. emergency only. > > > > > The FCC generally doesn't come into play when you're talking about ILEC > telephone service except at a very high level. In California, by PUC > regulation telephone companies are required to allow access to 911 so > long as there is copper in the facility and it was, at any time, active > with any sort of phone service. "Not exactly". They are required to do it only 'to the extent permitted by existing facilities'. To wit, if they need that wire pair to provide service (say, an additional line) to a paying customer, they _can_ physically disconnct the 'inactive account' premises, and hook up the new paying account to that pair. On occasion, telcos are known to re-use the pair, by just hooking the new customer onto it, _without_ pulling the bridge clips at the 'multiple' where the old custmer was connected. This leads to all sorts of messes. the 'non- customer' discovers dial-tone on the pair and starts using it. Calls are being made which the _real_ customer didn't make, which leads to real arguments with the billing department. Then, the customer picks up their phone, and instead of getting dial tone, discovers a conversation _in_progress_ on the line -- when _nobody_else_ at their place is on the phone. Strangely, the parties to that conversation refuse to identify themselves, and one of them is _really_ anxious to terminate that call, so you can use "your" line. I, personally, have been through this more than once, in older, high-density housing neighborhoods. From swm at emanon.com Wed Oct 7 13:22:31 2009 From: swm at emanon.com (Scott Morris) Date: Wed, 07 Oct 2009 14:22:31 -0400 Subject: Does Internet Speed Vary by Season? In-Reply-To: <200910071448.n97EmU9t080849@aurora.sol.net> References: <200910071448.n97EmU9t080849@aurora.sol.net> Message-ID: <4ACCDC67.7080108@emanon.com> I may be having my wires a little crossed (I'm not an electrical engineer) but I was always under the impression that manipulation of the physical characteristics like that from heat/dampness didn't reduce the "speed" but the "quality" (like line noise/errors/etc) of the line. Whether old telco lines or newer data lines it's all about electrical signal and bit error rates. More errors = more retransmissions = slower perceived throughput. Just my thinking. Scott Joe Greco wrote: >> http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion >> > > It used to be that we would notice this, except that it had everything to > do with temperature *and* dampness. In the '90's, it was still quite > common for a lot of older outside plant to be really only "voice grade" > and it wasn't unusual for copper to run all the way back to the CO, > through a variety of taps and splice points. Even though Ma Bell would > typically do a careful job handling their copper, the sheer number of > potential points of failure meant that it wasn't unusual for water to > infiltrate and penetrate. If I recall correctly, the worst was usually > a long, hard cold rain (hey we're in Wisconsin) after which people who > had been getting solidly high speed modem connects would see a somewhat > slower speed. > > ... JG > From mruiz at telwestservices.com Wed Oct 7 14:47:31 2009 From: mruiz at telwestservices.com (Michael Ruiz) Date: Wed, 7 Oct 2009 14:47:31 -0500 Subject: In-Reply-To: References: Message-ID: <9F285BFE1D7757499D9FF095B4EE347D045ED444@tw-xchange01.TWC.local> Thank you for your help for this question. Have a good day. -----Original Message----- From: Tillinger, Steve [mailto:steve.tillinger at SourceMedia.com] Sent: Wednesday, October 07, 2009 12:00 PM To: Michael Ruiz; nanog at nanog.org Subject: RE: IPsec isn't available when in multiple context mode. -----Original Message----- From: Michael Ruiz [mailto:mruiz at telwestservices.com] Sent: Wednesday, October 07, 2009 12:56 PM To: nanog at nanog.org Subject: Group, I am stuck like chuck. We are unable to activate a VPN in one of the virtual firewall context. Under the crypto commands, none of the IP-sec are available. Any help on this would be appreciated. Version we running is 8.0(4) Michael Ruiz mruiz at telwestservices.com "This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution" From black at csulb.edu Wed Oct 7 15:13:58 2009 From: black at csulb.edu (Matthew Black) Date: Wed, 07 Oct 2009 13:13:58 -0700 Subject: Does Internet Speed Vary by Season? In-Reply-To: <20091007151244.GA23874@skywalker.creative.net.au> References: <200910071448.n97EmU9t080849@aurora.sol.net> <4ACCADEE.4030808@misn.com> <20091007151244.GA23874@skywalker.creative.net.au> Message-ID: On Wed, 7 Oct 2009 23:12:44 +0800 Adrian Chadd wrote: > Please don't forget moisture content. DSL speeds may drop during > wet winters because cable pits fill with water. :) > > Those with real statistics, please stand up. I know ISPs who run > large DSL infrastructures have these stats. I've even seen them > at conferences. :) > > > Adrian Me! During the rainy season of recent past years, the cable vault in front of my home would flood, thereby degrading or completely hosing DSL service. Haven't had heavy rains for a couple years so no trouble. I had to replace my DSL modem about 6 months ago because the previous Westell Wirespeed modem had died very slowly. My speed went from 1.5M to less than 200k and was flaky. The new modem gives me a clean 3M/768k connection. Not bad for DSL ($35/month). But that wasn't weather related. Verizon. matthew black california state university, long beach From nanog at freshdot.net Wed Oct 7 15:44:06 2009 From: nanog at freshdot.net (Sander Smeenk) Date: Wed, 7 Oct 2009 22:44:06 +0200 Subject: Does Internet Speed Vary by Season? In-Reply-To: <200910071448.n97EmU9t080849@aurora.sol.net> References: <200910071448.n97EmU9t080849@aurora.sol.net> Message-ID: <20091007204406.GC26959@dot.freshdot.net> Quoting Joe Greco (jgreco at ns.sol.net): > > http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion > If I recall correctly, the worst was usually a long, hard cold rain > (hey we're in Wisconsin) after which people who had been getting > solidly high speed modem connects would see a somewhat slower speed. Matches my story exactly. I once had an ADSL connection which, on dry periods, synced at the maximum of 8Mbps and when it had rained for a day this would drop to about 6Mbps. It always worked though, the SNR just went up. I regularly rebooted the modem to make it retrain. An engineer from the telephone company came to check the wiring but couldn't find anything that would constitute replacing the line or something less drastic... Regards, -Sndr. (NL) -- | /dev/hda1 has been checked 20 times without being mounted, mount forced | 4096R/6D40 - 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 From jason at lixfeld.ca Wed Oct 7 16:13:47 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 7 Oct 2009 17:13:47 -0400 Subject: Telus BGP/ACL contact Message-ID: <0B646351-F0AD-46B5-B2A0-F67859A746E3@lixfeld.ca> I'm looking for a Telus individual who might be able to adjust a prefix list for me. Our sales rep no longer works for Telus and it's after 5pm here, so no account managers are available to help me expedite this request. The NOC insists that there's nothing they can do unless I have something from my account person and unfortunately this is relatively time sensitive. Thanks in advance. From info at n-connect.net Wed Oct 7 16:19:04 2009 From: info at n-connect.net (Jerry Pasker) Date: Wed, 7 Oct 2009 16:19:04 -0500 Subject: Does Internet Speed Vary by Season? In-Reply-To: <200910071528.n97FSTOW083365@aurora.sol.net> References: <200910071528.n97FSTOW083365@aurora.sol.net> Message-ID: Ignoring the little distractions, and taking a 30,000 ft view on this topic, my thoughts were always that backbone capacity gets behind, and backbone takes time to provision. Then it catches up, or leap frogs demand just in time for a wane in traffic. Try as we may, you can only predict traffic to a certain extent, and sometimes backbone upgrades planned and it works out, and sometimes those upgrades are reactionary. Usually a mix, as I will now demonstrate with the following example: (Late Spring) "oh, it looks like I'll need more capacity in a few months...better start the upgrade..." (Summer) "We're still doing well because bandwidth growth has waned, but that upgrade will be welcome..good thing it's in progress" (Fall) "We're peaking at 80-90%... really hurting and still waiting on the upgrade! delays from (telco, fiber company, government giving rights of way, fiber provider not having enough capacity, etc)" (Late fall) "This new upgraded set of tubes is great!" (Winter) "oh, it looks like I'll need more capacity in a few months...better start the upgrade process" (Spring) "We're feeling the crunch and out of bandwidth...can't get bandwidth fast enough" (Summer) "This new upgrade came just in time for the bandwidth constraints to ease..." We've all been through this cycle. Multiply it by the whole internet going through this cycle all the time and of course things will feel faster/slower at certain times of the year. If we al had OC-Ubber-bit pipes on demand, there wouldn't be slow times. But the fact of the matter is that upgrades take time. Usually longer than quoted. Add seasonal variations in use to a 30-90-180 day lag time (depending on the size of the tube that's being upgraded) and you get people noticing the perceived speed changes. -Jerry From source_route at yahoo.com Wed Oct 7 16:33:33 2009 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 7 Oct 2009 14:33:33 -0700 (PDT) Subject: Data Centers in England Message-ID: <828517.67207.qm@web30805.mail.mud.yahoo.com> Anyone know a good DC on England that caters to financial industry clients? From scott at dwc-computer.com Wed Oct 7 16:46:50 2009 From: scott at dwc-computer.com (Scott Spencer) Date: Wed, 7 Oct 2009 15:46:50 -0600 Subject: Data Centers in England In-Reply-To: <828517.67207.qm@web30805.mail.mud.yahoo.com> References: <828517.67207.qm@web30805.mail.mud.yahoo.com> Message-ID: <54B0ACE3FCEB434089EEA8157BFD71A5@HPWORKSTATION> http://www.datacentermap.com/united-kingdom/london/ As a good resource as well - Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Wednesday, October 07, 2009 3:34 PM To: nanog Subject: Data Centers in England Anyone know a good DC on England that caters to financial industry clients? From jgreco at ns.sol.net Wed Oct 7 16:49:07 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 7 Oct 2009 16:49:07 -0500 (CDT) Subject: Does Internet Speed Vary by Season? In-Reply-To: <4ACCDC67.7080108@emanon.com> from "Scott Morris" at Oct 07, 2009 02:22:31 PM Message-ID: <200910072149.n97Ln7oM099746@aurora.sol.net> > I may be having my wires a little crossed (I'm not an electrical > engineer) but I was always under the impression that manipulation of the > physical characteristics like that from heat/dampness didn't reduce the > "speed" but the "quality" (like line noise/errors/etc) of the line. > > Whether old telco lines or newer data lines it's all about electrical > signal and bit error rates. More errors = more retransmissions = slower > perceived throughput. > > Just my thinking. Reduced quality results in reduced speed. In the best case, you have a technology like DSL that detects the reduced quality, and dynamically adjusts transmission characteristics to adapt. In other cases, you have a technology like Ethernet where misdetection of bits results in the loss of a packet, and ultimately requires retransmission. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From simon at slimey.org Wed Oct 7 16:59:52 2009 From: simon at slimey.org (Simon Lockhart) Date: Wed, 7 Oct 2009 22:59:52 +0100 Subject: Data Centers in England In-Reply-To: <828517.67207.qm@web30805.mail.mud.yahoo.com> References: <828517.67207.qm@web30805.mail.mud.yahoo.com> Message-ID: <20091007215952.GM20581@virtual.bogons.net> On Wed Oct 07, 2009 at 02:33:33PM -0700, Philip Lavine wrote: > Anyone know a good DC on England that caters to financial industry clients? Telehouse London started as a Banking DR centre, so would probably meet your needs. Otherwise, there's Interxion, which claims to have all sorts of security certifications. The other usual suspects are also available in London - Level3, Equinix, C&W, etc... Simon From sronan at fattoc.com Wed Oct 7 17:09:02 2009 From: sronan at fattoc.com (Shane Ronan) Date: Wed, 7 Oct 2009 18:09:02 -0400 Subject: Data Centers in England In-Reply-To: <20091007215952.GM20581@virtual.bogons.net> References: <828517.67207.qm@web30805.mail.mud.yahoo.com> <20091007215952.GM20581@virtual.bogons.net> Message-ID: <442EBF4F-A0C9-4A9E-9FA1-9E7F759C3591@fattoc.com> As the CTO of a financial company with multiple data centers in London, I would recommend Equinix Slough (or London 4) site. They have a website setup just for Financial firms. http://financial.equinix.com/ I've got space in both Telehouse and Equinix and would recommend Equinix for someone looking for full service collocation and Telehouse to someone who is looking for network interconnection. Shane On Oct 7, 2009, at 5:59 PM, Simon Lockhart wrote: > On Wed Oct 07, 2009 at 02:33:33PM -0700, Philip Lavine wrote: >> Anyone know a good DC on England that caters to financial industry >> clients? > > Telehouse London started as a Banking DR centre, so would probably > meet your > needs. Otherwise, there's Interxion, which claims to have all sorts > of security > certifications. The other usual suspects are also available in > London - Level3, > Equinix, C&W, etc... > > Simon > From mehmet at akcin.net Wed Oct 7 18:39:33 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 8 Oct 2009 00:39:33 +0100 Subject: Turkish Networks related questions.. Message-ID: <2909d6d90910071639w1e22bddcu533b770fc7e651c6@mail.gmail.com> I have got few questions regarding Turkish ISPs, networks, could someone from Turkey possibly contact me offlist please? thank you. -- Mehmet Akcin Blog: http://www.mehmetakcin.com E-mail: mehmet at akcin.net From leigh.porter at ukbroadband.com Thu Oct 8 02:38:22 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 08 Oct 2009 08:38:22 +0100 Subject: Data Centers in England In-Reply-To: <20091007215952.GM20581@virtual.bogons.net> References: <828517.67207.qm@web30805.mail.mud.yahoo.com> <20091007215952.GM20581@virtual.bogons.net> Message-ID: <4ACD96EE.8090909@ukbroadband.com> Simon Lockhart wrote: > On Wed Oct 07, 2009 at 02:33:33PM -0700, Philip Lavine wrote: > >> Anyone know a good DC on England that caters to financial industry clients? >> > > Telehouse London started as a Banking DR centre, so would probably meet your > needs. Otherwise, there's Interxion, which claims to have all sorts of security > certifications. The other usual suspects are also available in London - Level3, > Equinix, C&W, etc... > > Simon > > The C&W space is certainly secure and is good if you only ever want to use C&W but try and get anything else there and you'll have a hard time. -- Leigh From wavetossed at googlemail.com Thu Oct 8 05:37:20 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Oct 2009 11:37:20 +0100 Subject: ISP customer assignments In-Reply-To: <20091006133613.GA5059@dan.olp.net> References: <29A54911243620478FF59F00EBB12F4701A60AC7@ex01.drtel.lan> <3c3e3fca0910050958q205eebf5r8fd761335afc1d70@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A60AE9@ex01.drtel.lan> <3c3e3fca0910051137j27f38210ua16749eaa4291d68@mail.gmail.com> <20091005211337.GP5403@dan.olp.net> <20091006133613.GA5059@dan.olp.net> Message-ID: <877585b00910080337s54f82c9ame2e289855932058a@mail.gmail.com> > I would disagree. IPv6 is designed around class boundaries which, in my > understanding, are: > > A layer two network gets assigned a /64 > A customer gets assigned a /48 A "site" gets assigned a /48. It could be a customer site, or one of your many sites or one of a customer's many sites. I interpret "site" to roughly be within a single building, although a campus type arrangement could be considered a single site if the network architects want to do it that way. > An ISP gets assigned a /32 (unless they need more) > If your complaint is that all devices in a /64 are going to see IPv6 > broadcast/multicast packets from the rest of the devices in that subnet, > then don't assign 2^64 devices to that subnet. Indeed! > I still don't understand why its infuriating to you, but I can certainly > tell that it is. It's purely a case of stage 2 which is a good thing IMHO, since it shows some movement forwards past denial. Confronting the Reality of Emotional Denial and Grief BTW, that PDF really *is* about IPv6 deployment. --Michael Dillon From wavetossed at googlemail.com Thu Oct 8 05:46:47 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Oct 2009 11:46:47 +0100 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> Message-ID: <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> > There seems to be a variance between "It's OK to just give out a /64" to > "You better be thinking about giving out a /48". I can live in those > boundaries and am most likely fine with either. I'm leaning toward a /56 > for regular subscribers and a /48 only for business or large scale > customers, and undecided on dial-up. How does this sound? The starting point is to give everybody a /48 per site. If a business customer has 3 sites, then give them enough space for a /48 for each site. Could be 3 /48s or could be a /46. But, if you have a lot of residential customers, it is quite reasonable to give them a /56 per site instead. Be prepared for some customers to ask for two /56s because they have a granny-flat or in-law apartment in the house. Also be prepared for some to ask for a /48 because they are running a business at home, or they are technical types who have a their own home network lab. Your plan for /56 to residential subscribers and /48 to business subscribers sounds perfectly fine as long as your systems have some way to accomodate that grey area, either by recording a /48 against a residential subscriber or counting them as a class of business customer that pays a residential rate. Charging a customer extra for more IPv6 addresses just will not fly in a competitive market. --Michael Dillon From cmaurand at xyonet.com Thu Oct 8 09:24:30 2009 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 08 Oct 2009 10:24:30 -0400 Subject: ISP customer assignments In-Reply-To: <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> Message-ID: <4ACDF61E.9030900@xyonet.com> Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? Curtis Michael Dillon wrote: >> There seems to be a variance between "It's OK to just give out a /64" to >> "You better be thinking about giving out a /48". I can live in those >> boundaries and am most likely fine with either. I'm leaning toward a /56 >> for regular subscribers and a /48 only for business or large scale >> customers, and undecided on dial-up. How does this sound? >> > > The starting point is to give everybody a /48 per site. If a business customer > has 3 sites, then give them enough space for a /48 for each site. Could be > 3 /48s or could be a /46. > > But, if you have a lot of residential customers, it is quite > reasonable to give them > a /56 per site instead. Be prepared for some customers to ask for two > /56s because > they have a granny-flat or in-law apartment in the house. Also be > prepared for some > to ask for a /48 because they are running a business at home, or they > are technical > types who have a their own home network lab. > > Your plan for /56 to residential subscribers and /48 to business > subscribers sounds > perfectly fine as long as your systems have some way to accomodate > that grey area, > either by recording a /48 against a residential subscriber or counting > them as a class > of business customer that pays a residential rate. > > Charging a customer extra for more IPv6 addresses just will not fly in > a competitive > market. > > --Michael Dillon > > From tjc at ecs.soton.ac.uk Thu Oct 8 09:28:42 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 8 Oct 2009 15:28:42 +0100 Subject: ISP customer assignments In-Reply-To: <4ACDF61E.9030900@xyonet.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <4ACDF61E.9030900@xyonet.com> <20091008142842.GO4872@login.ecs.soton.ac.uk> Message-ID: On Thu, Oct 08, 2009 at 10:24:30AM -0400, Curtis Maurand wrote: > > Sorry to be a curmudgeon and let me play devil's advocate for a minute. > I realize that the address space is enormous; gigantic, even, but if we > treat it as cavalierly as you all are proposing, it will get used up. > If its treated like an infinite resource that will never, ever be used > up as we have done with every other resource on the planet, won't we > find ourselves in a heap of trouble? At this stage we're only 'being cavalier' with 1/8th of the space. We can be more restrictive with the the other 7/8ths if those predicting rapid consumption turn out to be correct. Right now that would be a nice problem to have. Tim From trejrco at gmail.com Thu Oct 8 09:30:13 2009 From: trejrco at gmail.com (TJ) Date: Thu, 8 Oct 2009 10:30:13 -0400 Subject: ISP customer assignments In-Reply-To: <4ACDF61E.9030900@xyonet.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <4ACDF61E.9030900@xyonet.com> Message-ID: <71bfd60c0910080730v6b4c0fc1oa6f644cc5ee7941f@mail.gmail.com> And I will play devil's advocate to the devil's advocate ... wait, does that make me God's advocate? Nice! On Thu, Oct 8, 2009 at 10:24 AM, Curtis Maurand wrote: > > Sorry to be a curmudgeon and let me play devil's advocate for a minute. I > realize that the address space is enormous; gigantic, even, but if we treat > it as cavalierly as you all are proposing, it will get used up. If its > treated like an infinite resource that will never, ever be used up as we > have done with every other resource on the planet, won't we find ourselves > in a heap of trouble? > Curtis But the thing is - no-one is proposing we treat it as infinite - just that we treat it the way it was designed to be used. The IETF community "did the math" and decided a /48 per customer was both scalable and sufficient. The community, by and in large, decided that /56s were more appropriate for "small customers" and that is fine, even if some still view it as additional, unneeded complexity. My opinion, based on having done the math as well and operational experience to date, seems to jive that /48s (or even moreso /56s) will work. So let's get to it! /TJ From wavetossed at googlemail.com Thu Oct 8 10:29:39 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 8 Oct 2009 16:29:39 +0100 Subject: ISP customer assignments In-Reply-To: <4ACDF61E.9030900@xyonet.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <4ACDF61E.9030900@xyonet.com> Message-ID: <877585b00910080829v71067c7eucfc5b522161bbb39@mail.gmail.com> > Sorry to be a curmudgeon and let me play devil's advocate for a minute.? I > realize that the address space is enormous; gigantic, even, but if we treat > it as cavalierly as you all are proposing, it will get used up.? If its > treated like an infinite resource? that will never, ever be used up as we > have done with every other resource on the planet, won't we find ourselves > in a heap of trouble? Of course, you are right. That's why, when some people took a close look at the numbers based on a /48 per site, and published their findings, the RIRs made an adjustment to address allocation policy so that it was acceptable to allocate a /56 for a consumer customer, i.e. private residence of some sort. By doing that, they calculated that they could mitigate the small risk that we would run very low on IPv6 addresses around 100 years from now. Having made the change, we are now confident that there are plenty of IPv6 addresses to last more than a century, which basically means that you and your children and your grand children will all be dead when IPv6 gets close to exhaustion. Geoff Huston wrote this: to explain the small risk, and his proposals to adjust the HD ratio and go to a /56 for private residential assignments was basically accepted. If only a few of the biggest cable ISPs use the /56 model, then we are OK. I have great confidence that our descendants will avoid the Idiocracy and be capable of designing and deploying a replacement for IPv6 if that is ever needed. Last time I checked, my taps were still delivering fresh clean "toilet water", not Brawndo energy drink. --Michael Dillon From bensons at queuefull.net Thu Oct 8 10:50:04 2009 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 8 Oct 2009 10:50:04 -0500 Subject: Data Centers in England In-Reply-To: <442EBF4F-A0C9-4A9E-9FA1-9E7F759C3591@fattoc.com> References: <828517.67207.qm@web30805.mail.mud.yahoo.com> <20091007215952.GM20581@virtual.bogons.net> <442EBF4F-A0C9-4A9E-9FA1-9E7F759C3591@fattoc.com> Message-ID: <30FA79F9-5631-43AA-B1ED-8F599BF9F898@queuefull.net> Philip- I'm only really familiar with my employer's facilities: Savvis has data centers in London, Slough, and Reading with good exchange connectivity*. There is a financial-firm oriented microsite at http://financial.savvis.net/ , but beware the annoying* embedded video. You can look at http://www.savvis.net/en-US/Industries/Financial/Pages/Home.aspx for more info, too. Cheers, -Benson * - Obligatory Legal Statement for which I Personally Apologize: I'm employed by Savvis, but my opinions, postings, and all other materials are my own and do not necessarily represent those of my employer (Savvis, Inc.) or of any other entity. On 7 Oct 09, at 5:09 PM, Shane Ronan wrote: > As the CTO of a financial company with multiple data centers in > London, I would recommend Equinix Slough (or London 4) site. They > have a website setup just for Financial firms. http://financial.equinix.com/ > > I've got space in both Telehouse and Equinix and would recommend > Equinix for someone looking for full service collocation and > Telehouse to someone who is looking for network interconnection. > > Shane > > > On Oct 7, 2009, at 5:59 PM, Simon Lockhart wrote: > >> On Wed Oct 07, 2009 at 02:33:33PM -0700, Philip Lavine wrote: >>> Anyone know a good DC on England that caters to financial industry >>> clients? >> >> Telehouse London started as a Banking DR centre, so would probably >> meet your >> needs. Otherwise, there's Interxion, which claims to have all sorts >> of security >> certifications. The other usual suspects are also available in >> London - Level3, >> Equinix, C&W, etc... >> >> Simon >> > > From dwhite at olp.net Thu Oct 8 11:48:19 2009 From: dwhite at olp.net (Dan White) Date: Thu, 8 Oct 2009 11:48:19 -0500 Subject: ISP customer assignments In-Reply-To: <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> Message-ID: <20091008164818.GB4984@dan.olp.net> On 08/10/09?11:46?+0100, Michael Dillon wrote: >> There seems to be a variance between "It's OK to just give out a /64" to >> "You better be thinking about giving out a /48". I can live in those >> boundaries and am most likely fine with either. I'm leaning toward a /56 >> for regular subscribers and a /48 only for business or large scale >> customers, and undecided on dial-up. How does this sound? > >The starting point is to give everybody a /48 per site. If a business customer >has 3 sites, then give them enough space for a /48 for each site. Could be >3 /48s or could be a /46. How are other providers approaching dial-up? I would presume we are in the same boat as a lot of other folks - we have aging dial-up equipment that does not support IPv6 (3com Total Control). Our customer base has dropped quite a bit, and we have even kicked around the idea dropping that service and forcing customers to purchase broadband service or go elsewhere. I expect we won't invest any more into dial-up equipment, and when a dial-up customer happens to ask about IPv6 (if ever), we'll strongly encourage them to move to broadband, and as a last resort manually configure a /64 tunnel to them. What are other providers doing, or considering doing? -- Dan White BTC Broadband From marmata at gmail.com Thu Oct 8 12:14:25 2009 From: marmata at gmail.com (Marco Matarazzo) Date: Thu, 8 Oct 2009 19:14:25 +0200 Subject: Data Centers in England In-Reply-To: <828517.67207.qm@web30805.mail.mud.yahoo.com> References: <828517.67207.qm@web30805.mail.mud.yahoo.com> Message-ID: On Wed, Oct 7, 2009 at 11:33 PM, Philip Lavine wrote: > Anyone know a good DC on England that caters to financial industry clients? Have a look at Telecity* too, DCs in London, Manchester and Dublin, others spread out over Europe. Not just colo but a bunch of services too if you need them. They already serve some financial customers as well! * I work for them in Italy, standard disclaimer apply Cheers, ]\/[arco -- I'm Winston Wolf, I solve problems. From eugen at imacandi.net Thu Oct 8 13:13:26 2009 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 08 Oct 2009 21:13:26 +0300 Subject: In-Reply-To: <669D1B9A-2390-4BA8-8D91-3092F9AE9653@gmail.com> References: <9F285BFE1D7757499D9FF095B4EE347D045ED32B@tw-xchange01.TWC.local> <4ACCC9AD.2020801@i6ix.com> <669D1B9A-2390-4BA8-8D91-3092F9AE9653@gmail.com> Message-ID: <4ACE2BC6.8040309@imacandi.net> Devangnp wrote: > Does Juniper firewall has same issue? Nope. Just that you need to get an ISG 1000 or ISG 2000 to be able to virtualize nowadays, as the old lower model NetScreen boxes are no longer up for sale. From eric at nixwizard.net Thu Oct 8 13:46:13 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Thu, 8 Oct 2009 11:46:13 -0700 Subject: Anyone seeing BGP weirdness? Message-ID: <5792267e0910081146i7c7e9f17u1ac1ff97dd04b1ac@mail.gmail.com> I know this post sounds like a noobish thing to ask, but I've got sites in three different cities - Tucson, Arizona; Devnver, Colorado and Salt Lake City, Utah, and all three of them can't reach certain IPs of our clients whom we have IPsec tunnels to. In one case I can traceroute to 4.2.2.2 fine, but the traceroute to the public IP of one of my clients dies at the second hop, right after my ASA. Is anyone else seeing general routing weirdness on the Internets, or at least can someone point me at a good "BGP dashboard" site that monitors the state of routing tables at various places? Thanks, Eric From andree+nanog at toonk.nl Thu Oct 8 14:14:09 2009 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 8 Oct 2009 21:14:09 +0200 Subject: Anyone seeing BGP weirdness? In-Reply-To: <5792267e0910081146i7c7e9f17u1ac1ff97dd04b1ac@mail.gmail.com> References: <5792267e0910081146i7c7e9f17u1ac1ff97dd04b1ac@mail.gmail.com> Message-ID: <20091008191409.GA4685@toonk.nl> Hi Eric, .-- My secret spy satellite informs me that at Thu, 08 Oct 2009, Eric Gearhart wrote: > Is anyone else seeing general routing weirdness on the Internets, or at > least can someone point me at a good "BGP dashboard" site that monitors the > state of routing tables at various places? I have not seen 'weirdness'. You can check: http://www.ripe.net/ris/index.html or telnet to route-views.routeviews.org and verify if there's anything strange going on with your prefixes. Also, http://BGPmon.net might be useful for you in this case. It will monitor your prefixes from several detectors all over the world. Alarm / Notification messages will be sent to you in case of suspicious announcements or instability. Hope that helps. Cheers Andree From beckman at angryox.com Thu Oct 8 16:27:22 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 8 Oct 2009 17:27:22 -0400 Subject: Dutch ISPs to collaborate and take responsibility for bottedclients In-Reply-To: <19147.30865.579881.16413@world.std.com> References: <4AC7A8FA.80007@linuxbox.org> <20091004123458.GA25333@gsp.org> <20AFD779C33D40A489AC7AEC37752F44@bvsupport> <4AC93ED9.5080909@linuxbox.org> <4ACAFDB8.908@imacandi.net> <86DFAA44-272B-4490-BA14-DD1A470D8A87@delong.com> <19147.30865.579881.16413@world.std.com> Message-ID: Looks like ISP-to-customer notification of possible infection is starting on Comcast in the US now. http://news.cnet.com/8301-27080_3-10370996-245.html --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From tvhawaii at shaka.com Thu Oct 8 16:31:08 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 8 Oct 2009 11:31:08 -1000 Subject: Dutch ISPs to collaborate and take responsibility for botted clients References: <4AC7A8FA.80007@linuxbox.org> Message-ID: Gadi Evron wrote: [snip] > This will be an interesting phenomenon to watch. If it is successful > perhaps it could work here too." Comcast is launching a trial on Thursday of a new automated service that will warn broadband customers of possible virus infections, if the computers are behaving as if they have been compromised by malware. "ISPs have a helpful role to play in helping subscribers mitigate these kinds of security threats," she said. "The challenge is...when users get these notices, do they understand them? Do they trust that they are real? Do they follow through to the point where they clean up their computers?" http://news.cnet.com/8301-27080_3-10370996-245.html From if at xip.at Thu Oct 8 18:54:20 2009 From: if at xip.at (Ingo Flaschberger) Date: Fri, 9 Oct 2009 01:54:20 +0200 (CEST) Subject: hotmail send bare LF Message-ID: Hi, it seems, that hotmail send a bare LF in the added signature (and violates RFC). qmail drops the connection afterwards: 451 See http://pobox.com/~djb/docs/smtplf.html no helpfull response from hotmail: https://windowslivehelp.com/community/t/121824.aspx Kind regards, Ingo Flaschberger From mike at mtcc.com Thu Oct 8 18:57:38 2009 From: mike at mtcc.com (Michael Thomas) Date: Thu, 08 Oct 2009 16:57:38 -0700 Subject: hotmail send bare LF In-Reply-To: References: Message-ID: <4ACE7C72.6010402@mtcc.com> On 10/08/2009 04:54 PM, Ingo Flaschberger wrote: > Hi, > > it seems, that hotmail send a bare LF in the added signature > (and violates RFC). > > qmail drops the connection afterwards: > 451 See http://pobox.com/~djb/docs/smtplf.html > > no helpfull response from hotmail: > https://windowslivehelp.com/community/t/121824.aspx > > > Kind regards, > Ingo Flaschberger > Which added signature? Mike From mailinglists at expresswebsystems.com Thu Oct 8 19:12:55 2009 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Thu, 8 Oct 2009 19:12:55 -0500 Subject: hotmail send bare LF In-Reply-To: References: Message-ID: <01b201ca4875$40306f50$c0914df0$@com> Obviously not as good a solution as having Hotmail fix their issue, but the fixcrio application (http://cr.yp.to/ucspi-tcp/fixcrio.html) is designed to correct this particular issue. I have always thought it funny that DJB has a stance of "strict compliance sending, loose acceptance receive" in his MTA except for this one particular issue. Anyways, good luck. Tom Walsh > -----Original Message----- > From: Ingo Flaschberger [mailto:if at xip.at] > Sent: Thursday, October 08, 2009 6:54 PM > To: nanog at nanog.org > Subject: hotmail send bare LF > > Hi, > > it seems, that hotmail send a bare LF in the added signature > (and violates RFC). > > qmail drops the connection afterwards: > 451 See http://pobox.com/~djb/docs/smtplf.html > > no helpfull response from hotmail: > https://windowslivehelp.com/community/t/121824.aspx > > > Kind regards, > Ingo Flaschberger From if at xip.at Thu Oct 8 19:37:50 2009 From: if at xip.at (Ingo Flaschberger) Date: Fri, 9 Oct 2009 02:37:50 +0200 (CEST) Subject: hotmail send bare LF In-Reply-To: <4ACE7C72.6010402@mtcc.com> References: <4ACE7C72.6010402@mtcc.com> Message-ID: Hi, >> it seems, that hotmail send a bare LF in the added signature >> (and violates RFC). >> >> qmail drops the connection afterwards: >> 451 See http://pobox.com/~djb/docs/smtplf.html >> >> no helpfull response from hotmail: >> https://windowslivehelp.com/community/t/121824.aspx >> >> >> Kind regards, >> Ingo Flaschberger > > Which added signature? hotmail added: 0000006A 52 65 63 65 69 76 65 64 3a 20 66 72 6f 6d 20 53 Received : from S 0000007A 4e 54 31 32 34 2d 57 32 38 20 28 5b 36 35 2e 35 NT124-W2 8 ([65.5 0000008A 35 2e 39 30 2e 37 5d 29 20 62 5.90.7]) b 00000094 b5 c4 d3 ca bc fe 2d 2d 0d 0a 46 72 6f 6d 3a 20 ......-- ..From: (removed) (removed) 000000BE b0 cf e4 a1 a3 b1 be b3 b5 bc db b8 f1 ca c7 34 ........ .......4 000000CE 33 30 d4 aa a3 ac d5 e2 bf c9 ca c7 c5 e4 cc d7 30...... ........ 000000DE c6 eb c8 ab b5 c4 bc db b8 f1 ........ .. 000000E8 0d 0a 0d 0a d2 f8 c9 ab b5 c4 0d 0a 0d 0a 0d 0a ........ ........ 000000F8 b4 cb d6 f7 cc e2 cf e0 b9 d8 cd bc c6 ac c8 e7 ........ ........ 00000108 cf c2 a3 ba 0d 0a 0d 0a 0d 0a ........ .. 00000112 a2 bf cc cf c2 d4 d8 a3 a1 0d 0a 0d 0a 0d 0a 0d ........ ........ 00000122 0a ca b9 d3 c3 d0 c2 d2 bb b4 fa 20 57 69 6e 64 ........ ... Wind 00000132 6f 77 73 20 4c 69 76 65 20 4d ows Live M 0000013C b5 bd d5 e2 bf c9 b0 ae b5 c4 b3 b5 b3 b5 ba f3 ........ ........ 0000014C be cd c4 dc bf aa d0 c4 b5 c4 c6 ef d7 c5 cb fc ........ ........ 0000015C a3 ac cb f9 d2 d4 ce d2 be a1 ........ .. 00000166 0a 0d 0a cd fe cd fb a3 ba 30 0d 0a 0d 0a ce c4 ........ .0...... ^^ here 00000176 d5 c2 a3 ba 32 38 36 0d 0a 0d 0a b9 b1 cf d7 a3 ....286. ........ 00000186 ba 31 39 37 34 0d 0a 0d 0a d7 .1974... .. Kind regards, Ingo Flaschberger From iljitsch at muada.com Fri Oct 9 03:31:52 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 9 Oct 2009 10:31:52 +0200 Subject: 32-bit AS numbers Message-ID: Hi all, As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving out 32-bit AS numbers. I'm writing an article for Ars Technica about this, and I was wondering about the perspective of network operators who may be faced with customers with a 32-bit AS number in the near future, and how the vendor support for 32-bit AS numbers is working out. If you send me info in private mail, let me know your title/ affiliation and whether I can quote you or not. Iljitsch From rsk at gsp.org Fri Oct 9 05:05:39 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 9 Oct 2009 06:05:39 -0400 Subject: Dutch ISPs to collaborate and take responsibility In-Reply-To: References: <200910062327.n96NRt5E093517@aurora.sol.net> Message-ID: <20091009100539.GA31884@gsp.org> On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: > Additionally the problems of DDOS sourced from a collection of > compromised hosts could be interfering with someone else's ability > to make a successful VOIP call. Much more than that: they could be interfering with the underlying infrastructure, or they could be attacking the VOIP destination, or they could be making fake VOIP calls (see below), or they could be doing ANYTHING. A compromised system is enemy territory, which is why: > This blocking should be as narrow as possible. Blocking should be total. A compromised system is as much enemy-controlled as if it were physically located at the RBN. Trying to figure out which of externally-visible behaviors A, B, C, etc. it exhibits might be malicious and which might not be is a loss, doubly so given that many of the attacks launched by such systems are of a distributed nature and thus are very difficult to infer solely by observation of one system. Moreover, there is no way to know, given a current observation of behavior A, whether or not behavior B will begin, when it will begin, or what it will be. For example, there's no way to know that a supposed VOIP call to 911 from that system is actually being made by a human being. It's certainly well within the capabilities of malware to place such a call -- and abuses of 911 in efforts to misdirect authorities are well-known. (See "swatting". And note that nothing stops a botnet equipped with appropriate s/w from launching a number of such calls in sequence, with what I think are predictable consequences.) The bottom line is that once a system is compromised, all bets are off. Nothing it does can be trusted by anyone: not its *former* owners, not the network operator, not anyone in receipt of its traffic. So the only logical course of action is to cut it off completely, as quickly as possible, and keep it that way until it's properly fixed. (Which of course involves booting from known-clean media, restoring apps from known-clean sources, scanning all user data, etc. Booting from known-infected media is an obvious and immediate fail.) ---Rsk From matthew at walster.org Fri Oct 9 06:22:01 2009 From: matthew at walster.org (Matthew Walster) Date: Fri, 9 Oct 2009 12:22:01 +0100 Subject: 109/8 - not a BOGON Message-ID: Hi there, A customer of mine is reporting that there are a large number of addresses he can not reach with his addresses in the 109/8 range. This was declassified as a BOGON and assigned by IANA to RIPE in January 2009. If you have a manually updated BOGON list, can I please ask that you review it and update it as soon as possible please? His addresses in 89/8 and 83/8 work just fine, hence this presumption of BOGON filtering. Matthew Walster From shane at short.id.au Fri Oct 9 06:35:55 2009 From: shane at short.id.au (Shane Short) Date: Fri, 9 Oct 2009 19:35:55 +0800 Subject: 109/8 - not a BOGON In-Reply-To: References: Message-ID: <512828EA-9CC9-49EC-B8E9-C544E1BCD793@short.id.au> Hi Matthew, I had the same problem with our new range assigned to us by APNIC, out of 110/8 You're in for a long, hard and frustrating road. If you manage to get in contact with anyone, or anyone responds to you, mind letting me know? I'd suspect they'd probably have us blocked still too, we've just not come across it yet. Regards, Shane Short On 09/10/2009, at 7:22 PM, Matthew Walster wrote: > Hi there, > > A customer of mine is reporting that there are a large number of > addresses > he can not reach with his addresses in the 109/8 range. This was > declassified as a BOGON and assigned by IANA to RIPE in January 2009. > > If you have a manually updated BOGON list, can I please ask that you > review > it and update it as soon as possible please? His addresses in 89/8 > and 83/8 > work just fine, hence this presumption of BOGON filtering. > > Matthew Walster From jstuppi at cisco.com Fri Oct 9 06:42:56 2009 From: jstuppi at cisco.com (John Stuppi (jstuppi)) Date: Fri, 9 Oct 2009 07:42:56 -0400 Subject: 109/8 - not a BOGON In-Reply-To: References: Message-ID: <15B718938C4EB84BAF41312951253BAB097D54BB@xmb-rtp-20e.amer.cisco.com> The 109/8 range was removed from our ISP Ingress Prefix Filters in version 22 (dated 6-Feb-2009): ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Template s/T-ip-prefix-filter-ingress-loose-check-v22.txt Thanks, John -----Original Message----- From: Matthew Walster [mailto:matthew at walster.org] Sent: Friday, October 09, 2009 7:22 AM To: nanog at nanog.org Subject: 109/8 - not a BOGON Hi there, A customer of mine is reporting that there are a large number of addresses he can not reach with his addresses in the 109/8 range. This was declassified as a BOGON and assigned by IANA to RIPE in January 2009. If you have a manually updated BOGON list, can I please ask that you review it and update it as soon as possible please? His addresses in 89/8 and 83/8 work just fine, hence this presumption of BOGON filtering. Matthew Walster From leo.vegoda at icann.org Fri Oct 9 07:08:35 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 9 Oct 2009 05:08:35 -0700 Subject: 109/8 - not a BOGON In-Reply-To: Message-ID: On 09/10/2009 4:22, "Matthew Walster" wrote: > A customer of mine is reporting that there are a large number of addresses > he can not reach with his addresses in the 109/8 range. This was > declassified as a BOGON and assigned by IANA to RIPE in January 2009. > > If you have a manually updated BOGON list, can I please ask that you review > it and update it as soon as possible please? His addresses in 89/8 and 83/8 > work just fine, hence this presumption of BOGON filtering. This might be a good moment to list all the /8s allocated so far this year. 046/8 RIPE NCC 2009-09 whois.ripe.net ALLOCATED 002/8 RIPE NCC 2009-09 whois.ripe.net ALLOCATED 182/8 APNIC 2009-08 whois.apnic.net ALLOCATED 175/8 APNIC 2009-08 whois.apnic.net ALLOCATED 183/8 APNIC 2009-04 whois.apnic.net ALLOCATED 180/8 APNIC 2009-04 whois.apnic.net ALLOCATED 178/8 RIPE NCC 2009-01 whois.ripe.net ALLOCATED 109/8 RIPE NCC 2009-01 whois.ripe.net ALLOCATED Also, I'd like to mention that if you ever want to check your filters against the registry, we have made the columns sortable. It's now nice and easy to identify newly allocated /8s. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml Regards, Leo Vegoda From mhuff at ox.com Fri Oct 9 07:28:20 2009 From: mhuff at ox.com (Matthew Huff) Date: Fri, 9 Oct 2009 08:28:20 -0400 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Message-ID: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com? | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 From wp at null0.nl Fri Oct 9 07:34:45 2009 From: wp at null0.nl (Wouter Prins) Date: Fri, 9 Oct 2009 14:34:45 +0200 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> Message-ID: Hi Matthew, You are not the only one having this issue. They are announcing some other prefixes as well! 2009/10/9 Matthew Huff > About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from > AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 > (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass > sites. Hopefully this was just a typo that was quickly corrected. I would > appreciate if people have time and can double check let me know if any > announcements are active except from our AS6128/AS6395 upstreams. > > If this were to persist, what would be the best course of action to resolve > it, especially given that the AS was within RIPE. > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > > -- Wouter Prins wp at null0.nl 0x301FA912 From akennedy at cyberlinktech.com Fri Oct 9 08:20:14 2009 From: akennedy at cyberlinktech.com (Adam Kennedy) Date: Fri, 09 Oct 2009 09:20:14 -0400 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: Message-ID: Agreed. Our prefixes at AS40060 were announced as well. I received a notification around 7:00am EDT that our prefixes were detected announced from AS9035 with the same upstream AS1267. On 10/9/09 8:34 AM, "Wouter Prins" wrote: > Hi Matthew, > You are not the only one having this issue. They are announcing some other > prefixes as well! > > 2009/10/9 Matthew Huff > >> About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from >> AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 >> (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass >> sites. Hopefully this was just a typo that was quickly corrected. I would >> appreciate if people have time and can double check let me know if any >> announcements are active except from our AS6128/AS6395 upstreams. >> >> If this were to persist, what would be the best course of action to resolve >> it, especially given that the AS was within RIPE. >> >> >> ---- >> Matthew Huff | One Manhattanville Rd >> OTA Management LLC | Purchase, NY 10577 >> http://www.ox.com | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-460-4139 >> >> >> >> > -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 x4352 Fax: 574-855-5761 From marla.azinger at frontiercorp.com Fri Oct 9 09:04:54 2009 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 9 Oct 2009 10:04:54 -0400 Subject: 32-bit AS numbers In-Reply-To: References: Message-ID: <2E2FECEBAE57CC4BAACDE67638305F104851507129@ROCH-EXCH1.corp.pvt> Hi Iljitsch- This statement isnt entirely correct. Im not sure if this is just a word smithing error in your email or if the management of this issue in the ARIN region isnt well known. I can only address the ARIN region but in that region if there is a 16 bit ASN in the free pool it will be given out before a 32 bit one. They are going to manage the ASN free pool by lower bit number out first. Granted if zero 16 bit ASN's are in the pool then the only thing going out at the time would be a 32 bit ASN. However, I just wanted to clarify for the ARIN region that 16 bit ASN assignments will not be halted. If they exist in the free pool they will be used. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] Sent: Friday, October 09, 2009 1:32 AM To: NANOG list Subject: 32-bit AS numbers Hi all, As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving out 32-bit AS numbers. I'm writing an article for Ars Technica about this, and I was wondering about the perspective of network operators who may be faced with customers with a 32-bit AS number in the near future, and how the vendor support for 32-bit AS numbers is working out. If you send me info in private mail, let me know your title/ affiliation and whether I can quote you or not. Iljitsch From dylan.ebner at crlmed.com Fri Oct 9 09:07:42 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 9 Oct 2009 14:07:42 +0000 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> Message-ID: <017265BF3B9640499754DD48777C3D20664ECB074E@MBX9.EXCHPROD.USA.NET> We also received a notification that our IP block 67.135.55.0/24 (AS19629) is being annouced by AS9035. Hopefully someone is receiving my emails. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Friday, October 09, 2009 7:28 AM To: nanog at nanog.org Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com? | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 From cowie at renesys.com Fri Oct 9 09:11:09 2009 From: cowie at renesys.com (Jim Cowie) Date: Fri, 9 Oct 2009 10:11:09 -0400 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: References: Message-ID: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> Lots of people were affected, but none significantly. They originated 86,747 networks very briefly (less than a minute at 7:23 UTC), and I don't think anyone outside Telecom Italia's customer cone even saw them. So the impact was really, really limited. The correct origins were being reasserted even before the last of the announcements came over the wire. It always irks me when I see "routing alerts" that arrive hours after the event is over, without any of the context that would allow you to know whether it had any real impact. Your instinct to check looking glasses is the right one, but you have to move quickly and know where to look. Of course, I'm biased. --jim On Fri, Oct 9, 2009 at 9:20 AM, Adam Kennedy wrote: > Agreed. Our prefixes at AS40060 were announced as well. I received a > notification around 7:00am EDT that our prefixes were detected announced > from AS9035 with the same upstream AS1267. > > > On 10/9/09 8:34 AM, "Wouter Prins" wrote: > > > Hi Matthew, > > You are not the only one having this issue. They are announcing some > other > > prefixes as well! > > > > 2009/10/9 Matthew Huff > > > >> About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 > from > >> AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 > >> (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking > glass > >> sites. Hopefully this was just a typo that was quickly corrected. I > would > >> appreciate if people have time and can double check let me know if any > >> announcements are active except from our AS6128/AS6395 upstreams. > >> > >> If this were to persist, what would be the best course of action to > resolve > >> it, especially given that the AS was within RIPE. > >> > >> > >> ---- > >> Matthew Huff | One Manhattanville Rd > >> OTA Management LLC | Purchase, NY 10577 > >> http://www.ox.com | Phone: 914-460-4039 > >> aim: matthewbhuff | Fax: 914-460-4139 > >> > >> > >> > >> > > > > -- > Adam Kennedy > Senior Network Administrator > Cyberlink Technologies, Inc. > Phone: 888-293-3693 x4352 > Fax: 574-855-5761 > > > From sjk at sleepycatz.com Fri Oct 9 09:19:37 2009 From: sjk at sleepycatz.com (sjk) Date: Fri, 09 Oct 2009 09:19:37 -0500 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <017265BF3B9640499754DD48777C3D20664ECB074E@MBX9.EXCHPROD.USA.NET> References: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> <017265BF3B9640499754DD48777C3D20664ECB074E@MBX9.EXCHPROD.USA.NET> Message-ID: <4ACF4679.6040309@sleepycatz.com> We are seeing the same ting with 66.146.192.0/19 & 66.251.224.0/19. According to cyclopes this is still continuing. . . Dylan Ebner wrote: > We also received a notification that our IP block 67.135.55.0/24 (AS19629) is being annouced by AS9035. Hopefully someone is receiving my emails. > > Thanks > > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > > > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Friday, October 09, 2009 7:28 AM > To: nanog at nanog.org > Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 > > About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. > > If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. > > > > ---- > Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > > > From dylan.ebner at crlmed.com Fri Oct 9 09:23:25 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 9 Oct 2009 14:23:25 +0000 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> References: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> Message-ID: <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner -----Original Message----- From: Jim Cowie [mailto:cowie at renesys.com] Sent: Friday, October 09, 2009 9:11 AM To: Adam Kennedy Cc: NANOG Subject: Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Lots of people were affected, but none significantly. They originated 86,747 networks very briefly (less than a minute at 7:23 UTC), and I don't think anyone outside Telecom Italia's customer cone even saw them. So the impact was really, really limited. The correct origins were being reasserted even before the last of the announcements came over the wire. It always irks me when I see "routing alerts" that arrive hours after the event is over, without any of the context that would allow you to know whether it had any real impact. Your instinct to check looking glasses is the right one, but you have to move quickly and know where to look. Of course, I'm biased. --jim On Fri, Oct 9, 2009 at 9:20 AM, Adam Kennedy wrote: > Agreed. Our prefixes at AS40060 were announced as well. I received a > notification around 7:00am EDT that our prefixes were detected > announced from AS9035 with the same upstream AS1267. > > > On 10/9/09 8:34 AM, "Wouter Prins" wrote: > > > Hi Matthew, > > You are not the only one having this issue. They are announcing some > other > > prefixes as well! > > > > 2009/10/9 Matthew Huff > > > >> About 4 hours ago BGPmon picked up a rogue announcement of > >> 129.77.0.0 > from > >> AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of > >> AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on > >> any looking > glass > >> sites. Hopefully this was just a typo that was quickly corrected. I > would > >> appreciate if people have time and can double check let me know if > >> any announcements are active except from our AS6128/AS6395 upstreams. > >> > >> If this were to persist, what would be the best course of action to > resolve > >> it, especially given that the AS was within RIPE. > >> > >> > >> ---- > >> Matthew Huff | One Manhattanville Rd > >> OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: > >> 914-460-4039 > >> aim: matthewbhuff | Fax: 914-460-4139 > >> > >> > >> > >> > > > > -- > Adam Kennedy > Senior Network Administrator > Cyberlink Technologies, Inc. > Phone: 888-293-3693 x4352 > Fax: 574-855-5761 > > > From dylan.ebner at crlmed.com Fri Oct 9 09:26:44 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 9 Oct 2009 14:26:44 +0000 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <4ACF4679.6040309@sleepycatz.com> References: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> <017265BF3B9640499754DD48777C3D20664ECB074E@MBX9.EXCHPROD.USA.NET> <4ACF4679.6040309@sleepycatz.com> Message-ID: <017265BF3B9640499754DD48777C3D20664ECB077D@MBX9.EXCHPROD.USA.NET> I just received confirmation from AS9035 that they are not annoucing my IP block. Dylan Ebner, Network Engineer -----Original Message----- From: sjk [mailto:sjk at sleepycatz.com] Sent: Friday, October 09, 2009 9:20 AM Cc: nanog at nanog.org Subject: Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16 We are seeing the same ting with 66.146.192.0/19 & 66.251.224.0/19. According to cyclopes this is still continuing. . . Dylan Ebner wrote: > We also received a notification that our IP block 67.135.55.0/24 (AS19629) is being annouced by AS9035. Hopefully someone is receiving my emails. > > Thanks > > > Dylan Ebner, Network Engineer > Consulting Radiologists, Ltd. > 1221 Nicollet Mall, Minneapolis, MN 55403 > ph. 612.573.2236 fax. 612.573.2250 > dylan.ebner at crlmed.com > www.consultingradiologists.com > > > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Friday, October 09, 2009 7:28 AM > To: nanog at nanog.org > Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 > > About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. > > If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. > > > > ---- > Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > > > From Andrew.Nusbaum at mindspark.com Fri Oct 9 09:27:08 2009 From: Andrew.Nusbaum at mindspark.com (Andrew Nusbaum) Date: Fri, 9 Oct 2009 10:27:08 -0400 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> References: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> Message-ID: <7CC9F803BE7E0644A6219521B951AE38047A8DB549@s003mb01.staff.iaccap.com> Usually I get alerts from BGPMon within about 20 minutes of an event being detected. Not so much with the event this morning. I'm guessing that the orgination of 86,747 prefixes from the wrong AS probably got their MTA pretty busy... -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Friday, October 09, 2009 10:23 AM To: Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner From mmaberry at gmail.com Fri Oct 9 09:30:19 2009 From: mmaberry at gmail.com (Mike Maberry) Date: Fri, 9 Oct 2009 07:30:19 -0700 Subject: Time Warner/Road Runner issues in the Mid West Message-ID: Is anyone else seeing connectivity issues to the internet using Time Warner/Road Runner in the Mid West? Kansas City and Wisconsin seem to be unable to access sites on the west coast... From dylan.ebner at crlmed.com Fri Oct 9 09:30:36 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 9 Oct 2009 14:30:36 +0000 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <7CC9F803BE7E0644A6219521B951AE38047A8DB549@s003mb01.staff.iaccap.com> References: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> <7CC9F803BE7E0644A6219521B951AE38047A8DB549@s003mb01.staff.iaccap.com> Message-ID: <017265BF3B9640499754DD48777C3D20664ECB0786@MBX9.EXCHPROD.USA.NET> I thought that may be the case as well. Do people know of other services like BGPMon that may be able to keep up with the load better? Does anyone know how cyclops faired this morning with the additional load? Dylan Ebner -----Original Message----- From: Andrew Nusbaum [mailto:Andrew.Nusbaum at mindspark.com] Sent: Friday, October 09, 2009 9:27 AM To: Dylan Ebner; Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Usually I get alerts from BGPMon within about 20 minutes of an event being detected. Not so much with the event this morning. I'm guessing that the orgination of 86,747 prefixes from the wrong AS probably got their MTA pretty busy... -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Friday, October 09, 2009 10:23 AM To: Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner From christian at automatick.net Fri Oct 9 09:35:34 2009 From: christian at automatick.net (christian) Date: Fri, 9 Oct 2009 07:35:34 -0700 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> References: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> Message-ID: there are multiple systems available, sign up for a few i've noticed cyclops alerts are sent faster than bgpon PHAS was fast, but the project is over and something new is going to be released there is ripe MyASN there is watchmynet and IAR On Fri, Oct 9, 2009 at 7:23 AM, Dylan Ebner wrote: > Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. > > Thanks > > > Dylan Ebner > > -----Original Message----- > From: Jim Cowie [mailto:cowie at renesys.com] > Sent: Friday, October 09, 2009 9:11 AM > To: Adam Kennedy > Cc: NANOG > Subject: Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16 > > Lots of people were affected, but none significantly. ? They originated > 86,747 networks very briefly (less than a minute at 7:23 UTC), and I don't > think anyone outside Telecom Italia's customer cone even saw them. ? So the > impact was really, really limited. ?The correct origins were being reasserted even before the last of the announcements came over the wire. > > It always irks me when I see "routing alerts" that arrive hours after the event is over, without any of the context that would allow you to know > whether it had any real impact. ? Your instinct to check looking glasses is > the right one, but you have to move quickly and know where to look. > > Of course, I'm biased. ? ?--jim > > > > On Fri, Oct 9, 2009 at 9:20 AM, Adam Kennedy wrote: > >> Agreed. Our prefixes at AS40060 were announced as well. I received a >> notification around 7:00am EDT that our prefixes were detected >> announced from AS9035 with the same upstream AS1267. >> >> >> On 10/9/09 8:34 AM, "Wouter Prins" wrote: >> >> > Hi Matthew, >> > You are not the only one having this issue. They are announcing some >> other >> > prefixes as well! >> > >> > 2009/10/9 Matthew Huff >> > >> >> About 4 hours ago BGPmon picked up a rogue announcement of >> >> 129.77.0.0 >> from >> >> AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of >> >> AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on >> >> any looking >> glass >> >> sites. Hopefully this was just a typo that was quickly corrected. I >> would >> >> appreciate if people have time and can double check let me know if >> >> any announcements are active except from our AS6128/AS6395 upstreams. >> >> >> >> If this were to persist, what would be the best course of action to >> resolve >> >> it, especially given that the AS was within RIPE. >> >> >> >> >> >> ---- >> >> Matthew Huff ? ? ? | One Manhattanville Rd >> >> OTA Management LLC | Purchase, NY 10577 http://www.ox.com ?| Phone: >> >> 914-460-4039 >> >> aim: matthewbhuff ?| Fax: ? 914-460-4139 >> >> >> >> >> >> >> >> >> > >> >> -- >> Adam Kennedy >> Senior Network Administrator >> Cyberlink Technologies, Inc. >> Phone: 888-293-3693 x4352 >> Fax: 574-855-5761 >> >> >> > > > From Andrew.Nusbaum at mindspark.com Fri Oct 9 09:41:04 2009 From: Andrew.Nusbaum at mindspark.com (Andrew Nusbaum) Date: Fri, 9 Oct 2009 10:41:04 -0400 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <017265BF3B9640499754DD48777C3D20664ECB0786@MBX9.EXCHPROD.USA.NET> References: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> <7CC9F803BE7E0644A6219521B951AE38047A8DB549@s003mb01.staff.iaccap.com> <017265BF3B9640499754DD48777C3D20664ECB0786@MBX9.EXCHPROD.USA.NET> Message-ID: <7CC9F803BE7E0644A6219521B951AE38047A8DB581@s003mb01.staff.iaccap.com> I actually got origin change alerts from Cyclops about 2 minutes after the announcements started. -Andy -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Friday, October 09, 2009 10:31 AM To: Andrew Nusbaum; Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 I thought that may be the case as well. Do people know of other services like BGPMon that may be able to keep up with the load better? Does anyone know how cyclops faired this morning with the additional load? Dylan Ebner -----Original Message----- From: Andrew Nusbaum [mailto:Andrew.Nusbaum at mindspark.com] Sent: Friday, October 09, 2009 9:27 AM To: Dylan Ebner; Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Usually I get alerts from BGPMon within about 20 minutes of an event being detected. Not so much with the event this morning. I'm guessing that the orgination of 86,747 prefixes from the wrong AS probably got their MTA pretty busy... -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Friday, October 09, 2009 10:23 AM To: Jim Cowie; Adam Kennedy Cc: NANOG Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. Thanks Dylan Ebner From ghankins at mindspring.com Fri Oct 9 10:13:50 2009 From: ghankins at mindspring.com (Greg Hankins) Date: Fri, 9 Oct 2009 11:13:50 -0400 Subject: 32-bit AS numbers In-Reply-To: References: Message-ID: <20091009151350.GA28764@switchanddata.com> On Fri, Oct 09, 2009 at 10:31:52AM +0200, Iljitsch van Beijnum wrote: > As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving > out 32-bit AS numbers. I'm writing an article for Ars Technica about > this, and I was wondering about the perspective of network operators who > may be faced with customers with a 32-bit AS number in the near future, > and how the vendor support for 32-bit AS numbers is working out. > > If you send me info in private mail, let me know your title/affiliation > and whether I can quote you or not. Chris Malayter and I gave a presentation at NANOG45 earlier this year that touches on some of the operational issues. http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf We also started a Wiki with content based on the presentation that has more updated information, including a current list of vendor support. If you see a vendor missing, let us know and we can update the list. Or better yet, create an account and add some content yourself :-). http://as4.cluepon.net/index.php/Main_Page Greg -- Greg Hankins From jaitken at aitken.com Fri Oct 9 10:46:09 2009 From: jaitken at aitken.com (Jeff Aitken) Date: Fri, 9 Oct 2009 15:46:09 +0000 Subject: Time Warner/Road Runner issues in the Mid West In-Reply-To: References: Message-ID: <20091009154609.GA1408@eagle.aitken.com> On Fri, Oct 09, 2009 at 07:30:19AM -0700, Mike Maberry wrote: > Is anyone else seeing connectivity issues to the internet using Time > Warner/Road Runner in the Mid West? Kansas City and Wisconsin seem to be > unable to access sites on the west coast... Mike, There is an ongoing issue that our ops folks are currently troubleshooting. I don't have any details at this time, but if you've got a traceroute or other details on the specific issue that you're seeing, feel free to forward to me directly and I'll make sure it gets to the right parties here. Thanks, --Jeff From kloch at kl.net Fri Oct 9 11:05:57 2009 From: kloch at kl.net (Kevin Loch) Date: Fri, 09 Oct 2009 12:05:57 -0400 Subject: 32-bit AS numbers In-Reply-To: <20091009151350.GA28764@switchanddata.com> References: <20091009151350.GA28764@switchanddata.com> Message-ID: <4ACF5F65.70902@kl.net> Greg Hankins wrote: > We also started a Wiki with content based on the presentation that has > more updated information, including a current list of vendor support. > If you see a vendor missing, let us know and we can update the list. > Or better yet, create an account and add some content yourself :-). > > http://as4.cluepon.net/index.php/Main_Page While it's good to see support _finally_ in 2.2SX, I still don't see it in 12.2SR (for rsp720). It's almost like Cisco has no idea how many of these things are actually used on the Internet. - Kevin From jared at puck.nether.net Fri Oct 9 11:13:13 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 9 Oct 2009 12:13:13 -0400 Subject: 32-bit AS numbers In-Reply-To: <4ACF5F65.70902@kl.net> References: <20091009151350.GA28764@switchanddata.com> <4ACF5F65.70902@kl.net> Message-ID: On Oct 9, 2009, at 12:05 PM, Kevin Loch wrote: > Greg Hankins wrote: > >> We also started a Wiki with content based on the presentation that >> has >> more updated information, including a current list of vendor support. >> If you see a vendor missing, let us know and we can update the list. >> Or better yet, create an account and add some content yourself :-). >> http://as4.cluepon.net/index.php/Main_Page > > While it's good to see support _finally_ in 2.2SX, I still don't see > it > in 12.2SR (for rsp720). It's almost like Cisco has no idea how > many of these things are actually used on the Internet. One can use the 23456 method in the interim, but I'd rather see everyone deploy 4-byte code. There have already been cases already of people putting 23456 in an as4_path inappropriately. - Jared From repstein at chello.at Fri Oct 9 11:16:52 2009 From: repstein at chello.at (Randy Epstein) Date: Fri, 9 Oct 2009 12:16:52 -0400 Subject: 32-bit AS numbers In-Reply-To: <4ACF5F65.70902@kl.net> References: <20091009151350.GA28764@switchanddata.com> <4ACF5F65.70902@kl.net> Message-ID: <04e001ca48fb$eb71dee0$c2559ca0$@at> > While it's good to see support _finally_ in 2.2SX, I still don't see it > in 12.2SR (for rsp720). It's almost like Cisco has no idea how > many of these things are actually used on the Internet. This is actually our issue as well. Our backbone runs primarily RSP720's (with some Sup720's for good measure). Support in 12.2SRx would be much appreciated if anyone from Cisco product is listening. Regards, Randy From lmay at nframe.com Fri Oct 9 11:26:19 2009 From: lmay at nframe.com (Larry May) Date: Fri, 9 Oct 2009 12:26:19 -0400 Subject: 32-bit AS numbers In-Reply-To: <04e001ca48fb$eb71dee0$c2559ca0$@at> References: <20091009151350.GA28764@switchanddata.com><4ACF5F65.70902@kl.net> <04e001ca48fb$eb71dee0$c2559ca0$@at> Message-ID: <053E179161004E4C91C8613916AA37B9053012FE@nframemail01.nframe.local> We are running into the same issues regarding 12.0 train for 12008 GSR w/PRP-2's. Even though there are IOS's that have a "fixed" 4 Byte ASN code...it has other bugs in NSF-SSO that we use here extensively. So hence the reason we are waiting to upgrade. Larry May Network Services n|Frame 888-223-8633 -----Original Message----- From: Randy Epstein [mailto:repstein at chello.at] Sent: Friday, October 09, 2009 12:17 PM To: 'Kevin Loch'; nanog at nanog.org Subject: RE: 32-bit AS numbers > While it's good to see support _finally_ in 2.2SX, I still don't see it > in 12.2SR (for rsp720). It's almost like Cisco has no idea how > many of these things are actually used on the Internet. This is actually our issue as well. Our backbone runs primarily RSP720's (with some Sup720's for good measure). Support in 12.2SRx would be much appreciated if anyone from Cisco product is listening. Regards, Randy From chaim.rieger at gmail.com Fri Oct 9 11:30:34 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Fri, 09 Oct 2009 09:30:34 -0700 Subject: Time Warner/Road Runner issues in the Mid West In-Reply-To: References: Message-ID: <4ACF652A.6020404@gmail.com> Mike Maberry wrote: > Is anyone else seeing connectivity issues to the internet using Time > Warner/Road Runner in the Mid West? Kansas City and Wisconsin seem to be > unable to access sites on the west coast... Still ongoing in los angeles, From adrian at creative.net.au Fri Oct 9 13:26:06 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 10 Oct 2009 02:26:06 +0800 Subject: wanted: facebook technical contact Message-ID: <20091009182606.GA18335@skywalker.creative.net.au> howdy, I'm chasing a technical contact at Facebook. There's some broken HTTP being served which is confusing Squid in a way that isn't easily, cleanly worked around. Please feel free to contact me off-list. Thanks, Adrian From cscora at apnic.net Fri Oct 9 13:27:22 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Oct 2009 04:27:22 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200910091827.n99IRMBq025399@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 10 Oct, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 299909 Prefixes after maximum aggregation: 140664 Deaggregation factor: 2.13 Unique aggregates announced to Internet: 148721 Total ASes present in the Internet Routing Table: 32379 Prefixes per ASN: 9.26 Origin-only ASes present in the Internet Routing Table: 28138 Origin ASes announcing only one prefix: 13738 Transit ASes present in the Internet Routing Table: 4241 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 560 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs: 292 Prefixes from 32-bit ASNs in the Routing Table: 213 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 190 Number of addresses announced to Internet: 2112370016 Equivalent to 125 /8s, 232 /16s and 53 /24s Percentage of available address space announced: 57.0 Percentage of allocated address space announced: 64.6 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 79.3 Total number of prefixes smaller than registry allocations: 144194 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 71884 Total APNIC prefixes after maximum aggregation: 25318 APNIC Deaggregation factor: 2.84 Prefixes being announced from the APNIC address blocks: 68393 Unique aggregates announced from the APNIC address blocks: 30300 APNIC Region origin ASes present in the Internet Routing Table: 3816 APNIC Prefixes per ASN: 17.92 APNIC Region origin ASes announcing only one prefix: 1047 APNIC Region transit ASes present in the Internet Routing Table: 587 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 461684000 Equivalent to 27 /8s, 132 /16s and 189 /24s Percentage of available APNIC address space announced: 78.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 126884 Total ARIN prefixes after maximum aggregation: 66823 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 101398 Unique aggregates announced from the ARIN address blocks: 38471 ARIN Region origin ASes present in the Internet Routing Table: 13278 ARIN Prefixes per ASN: 7.64 ARIN Region origin ASes announcing only one prefix: 5135 ARIN Region transit ASes present in the Internet Routing Table: 1301 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 706797568 Equivalent to 42 /8s, 32 /16s and 224 /24s Percentage of available ARIN address space announced: 62.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 68963 Total RIPE prefixes after maximum aggregation: 40347 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 62540 Unique aggregates announced from the RIPE address blocks: 41940 RIPE Region origin ASes present in the Internet Routing Table: 13579 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7080 RIPE Region transit ASes present in the Internet Routing Table: 2043 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 401178048 Equivalent to 23 /8s, 233 /16s and 125 /24s Percentage of available RIPE address space announced: 74.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 25802 Total LACNIC prefixes after maximum aggregation: 6344 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24098 Unique aggregates announced from the LACNIC address blocks: 13510 LACNIC Region origin ASes present in the Internet Routing Table: 1190 LACNIC Prefixes per ASN: 20.25 LACNIC Region origin ASes announcing only one prefix: 380 LACNIC Region transit ASes present in the Internet Routing Table: 192 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 67013376 Equivalent to 3 /8s, 254 /16s and 139 /24s Percentage of available LACNIC address space announced: 66.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5925 Total AfriNIC prefixes after maximum aggregation: 1561 AfriNIC Deaggregation factor: 3.80 Prefixes being announced from the AfriNIC address blocks: 4303 Unique aggregates announced from the AfriNIC address blocks: 1546 AfriNIC Region origin ASes present in the Internet Routing Table: 325 AfriNIC Prefixes per ASN: 13.24 AfriNIC Region origin ASes announcing only one prefix: 96 AfriNIC Region transit ASes present in the Internet Routing Table: 67 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12557568 Equivalent to 0 /8s, 191 /16s and 157 /24s Percentage of available AfriNIC address space announced: 37.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1766 6996 458 Korea Telecom (KIX) 17488 1460 137 144 Hathway IP Over Cable Interne 4755 1261 292 145 TATA Communications formerly 9583 1101 87 530 Sify Limited 4134 1010 18168 391 CHINANET-BACKBONE 18101 979 204 33 Reliance Infocom Ltd Internet 7545 893 199 102 TPG Internet Pty Ltd 9829 816 629 21 BSNL National Internet Backbo 17974 790 248 93 PT TELEKOMUNIKASI INDONESIA 24560 775 285 164 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4161 3626 313 bellsouth.net, inc. 4323 3697 1037 385 Time Warner Telecom 1785 1762 714 138 PaeTec Communications, Inc. 7018 1543 5860 1057 AT&T WorldNet Services 20115 1484 1480 673 Charter Communications 6478 1405 280 340 AT&T Worldnet Services 2386 1308 641 947 AT&T Data Communications Serv 3356 1221 10963 433 Level 3 Communications, LLC 11492 1133 208 12 Cable One 22773 1111 2604 67 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 509 94 207 Evolva Telecom 3292 450 1908 394 TDC Tele Danmark 35805 445 40 5 United Telecom of Georgia 12479 427 578 6 Uni2 Autonomous System 702 422 1822 340 UUNET - Commercial IP service 9198 390 138 12 Kazakhtelecom Data Network Ad 8866 356 110 21 Bulgarian Telecommunication C 3320 352 7067 303 Deutsche Telekom AG 3301 351 1412 308 TeliaNet Sweden 3215 349 3144 111 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1482 2899 243 UniNet S.A. de C.V. 10620 1020 227 95 TVCABLE BOGOTA 28573 762 651 87 NET Servicos de Comunicao S.A 7303 656 346 97 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 475 310 61 Instituto Costarricense de El 11172 440 99 70 Servicios Alestra S.A de C.V 14117 436 29 11 Telefonica del Sur S.A. 7738 428 858 29 Telecomunicacoes da Bahia S.A 6471 421 96 31 ENTEL CHILE S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 984 188 7 TEDATA 24863 926 95 68 LINKdotNET AS number 3741 278 857 239 The Internet Solution 2018 192 187 118 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 140 14 6 Ci Telecom Autonomous system 33776 125 7 11 Starcomms Nigeria Limited 24835 123 46 9 RAYA Telecom - Egypt 5536 122 8 13 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4161 3626 313 bellsouth.net, inc. 4323 3697 1037 385 Time Warner Telecom 4766 1766 6996 458 Korea Telecom (KIX) 1785 1762 714 138 PaeTec Communications, Inc. 7018 1543 5860 1057 AT&T WorldNet Services 20115 1484 1480 673 Charter Communications 8151 1482 2899 243 UniNet S.A. de C.V. 17488 1460 137 144 Hathway IP Over Cable Interne 6478 1405 280 340 AT&T Worldnet Services 2386 1308 641 947 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3697 3312 Time Warner Telecom 1785 1762 1624 PaeTec Communications, Inc. 17488 1460 1316 Hathway IP Over Cable Interne 4766 1766 1308 Korea Telecom (KIX) 8151 1482 1239 UniNet S.A. de C.V. 11492 1133 1121 Cable One 4755 1261 1116 TATA Communications formerly 6478 1405 1065 AT&T Worldnet Services 18566 1062 1052 Covad Communications 22773 1111 1044 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:24 /11:63 /12:176 /13:354 /14:628 /15:1202 /16:10682 /17:4892 /18:8410 /19:17500 /20:21007 /21:21008 /22:27238 /23:26831 /24:157108 /25:932 /26:1091 /27:554 /28:154 /29:8 /30:9 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2694 4161 bellsouth.net, inc. 4323 2353 3697 Time Warner Telecom 4766 1438 1766 Korea Telecom (KIX) 1785 1228 1762 PaeTec Communications, Inc. 17488 1220 1460 Hathway IP Over Cable Interne 11492 1058 1133 Cable One 18566 1043 1062 Covad Communications 9583 953 1101 Sify Limited 10620 926 1020 TVCABLE BOGOTA 8452 912 984 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:226 12:2147 13:7 15:22 16:3 17:5 20:36 24:1168 32:52 34:2 38:601 40:97 41:1735 43:1 44:2 45:1 46:1 47:21 52:6 55:2 56:2 57:25 58:606 59:642 60:443 61:1078 62:1011 63:2012 64:3638 65:2382 66:4094 67:1795 68:985 69:2777 70:573 71:154 72:1668 73:2 74:1934 75:182 76:350 77:871 78:583 79:390 80:910 81:814 82:504 83:431 84:527 85:1003 86:381 87:688 88:386 89:1498 90:62 91:2590 92:412 93:1217 94:1258 95:1132 96:171 97:271 98:326 99:30 109:51 110:222 111:451 112:143 113:152 114:265 115:428 116:1097 117:552 118:350 119:778 120:135 121:784 122:1287 123:788 124:1044 125:1360 128:220 129:211 130:131 131:415 132:77 133:10 134:182 135:42 136:224 137:168 138:173 139:84 140:440 141:123 142:381 143:336 144:364 145:48 146:393 147:168 148:550 149:204 150:151 151:176 152:215 153:156 154:2 155:271 156:166 157:309 158:100 159:356 160:292 161:168 162:279 163:170 164:279 165:517 166:472 167:390 168:799 169:168 170:469 171:43 172:2 173:414 174:364 175:1 178:1 180:57 182:1 186:143 187:154 188:1134 189:603 190:3101 192:5756 193:4267 194:3295 195:2753 196:1159 198:3550 199:3346 200:5205 201:1351 202:7868 203:8227 204:3926 205:2190 206:2416 207:2976 208:3958 209:3491 210:2561 211:1127 212:1592 213:1620 214:189 215:40 216:4429 217:1336 218:411 219:457 220:1135 221:449 222:316 End of report From adrian at creative.net.au Fri Oct 9 13:48:57 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 10 Oct 2009 02:48:57 +0800 Subject: wanted: facebook technical contact In-Reply-To: <20091009182606.GA18335@skywalker.creative.net.au> References: <20091009182606.GA18335@skywalker.creative.net.au> Message-ID: <20091009184857.GD18335@skywalker.creative.net.au> A few people have asked what the specific problem is. http://www.squid-cache.org/mail-archive/squid-dev/200910/0089.html Adrian On Sat, Oct 10, 2009, Adrian Chadd wrote: > howdy, > > I'm chasing a technical contact at Facebook. There's some broken HTTP being > served which is confusing Squid in a way that isn't easily, cleanly > worked around. > > Please feel free to contact me off-list. From jared at puck.nether.net Fri Oct 9 14:10:15 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 9 Oct 2009 15:10:15 -0400 Subject: wanted: facebook technical contact In-Reply-To: <20091009184857.GD18335@skywalker.creative.net.au> References: <20091009182606.GA18335@skywalker.creative.net.au> <20091009184857.GD18335@skywalker.creative.net.au> Message-ID: I've been having the same issue when going through my Linux+Squid+WCCP setup, but if the browser is configured to go direct to the proxy it does not seem to have the same issue. (At least so far). - Jared On Oct 9, 2009, at 2:48 PM, Adrian Chadd wrote: > A few people have asked what the specific problem is. > > http://www.squid-cache.org/mail-archive/squid-dev/200910/0089.html > > > > > Adrian > > On Sat, Oct 10, 2009, Adrian Chadd wrote: >> howdy, >> >> I'm chasing a technical contact at Facebook. There's some broken >> HTTP being >> served which is confusing Squid in a way that isn't easily, cleanly >> worked around. >> >> Please feel free to contact me off-list. From adrian at creative.net.au Fri Oct 9 14:12:32 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 10 Oct 2009 03:12:32 +0800 Subject: wanted: facebook technical contact In-Reply-To: References: <20091009182606.GA18335@skywalker.creative.net.au> <20091009184857.GD18335@skywalker.creative.net.au> Message-ID: <20091009191232.GF18335@skywalker.creative.net.au> It is a HTTP/1.0 vs HTTP/1.1 thing (Chunked encoding for HTTP/1.1 doesn't require you to calculate and send a Content-Length.) Adrian On Fri, Oct 09, 2009, Jared Mauch wrote: > I've been having the same issue when going through my Linux+Squid+WCCP > setup, but if the browser is configured to go direct to the proxy it > does not seem to have the same issue. (At least so far). > > - Jared > > On Oct 9, 2009, at 2:48 PM, Adrian Chadd wrote: > > >A few people have asked what the specific problem is. > > > >http://www.squid-cache.org/mail-archive/squid-dev/200910/0089.html > > > > > > > > > >Adrian > > > >On Sat, Oct 10, 2009, Adrian Chadd wrote: > >>howdy, > >> > >>I'm chasing a technical contact at Facebook. There's some broken > >>HTTP being > >>served which is confusing Squid in a way that isn't easily, cleanly > >>worked around. > >> > >>Please feel free to contact me off-list. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From wavetossed at googlemail.com Fri Oct 9 15:05:40 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 9 Oct 2009 21:05:40 +0100 Subject: ISP customer assignments In-Reply-To: <20091008164818.GB4984@dan.olp.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> Message-ID: <877585b00910091305o36e02car8756f5c31adad133@mail.gmail.com> > How are other providers approaching dial-up? I would presume we are in the > same boat as a lot of other folks - we have aging dial-up equipment that > does not support IPv6 (3com Total Control). Our customer base has dropped > quite a bit, and we have even kicked around the idea dropping that service > and forcing customers to purchase broadband service or go elsewhere. Separate these technical issues from IPv6 allocation plans. If you intend to continue running an ISP in two years from now, either make a simple plan and allocate a /48 to every customer site, whether or not they are currently taking an IPv6 service from you. Or, take the slightly more complex plan and allocate a /56 per site where it is known for sure, 100% that the site is a private residence. If it is not, or there is doubt, then allocate a /48. > I expect we won't invest any more into dial-up equipment, and when a > dial-up customer happens to ask about IPv6 (if ever), we'll strongly > encourage them to move to broadband, and as a last resort manually > configure a /64 tunnel to them. You might use up a /64 for the two tunnel endpoints, but be sure to allocate the customer at least a /56. > What are other providers doing, or considering doing? In general, big providers are not going to attempt to cope with any older equipment that does not fully support IPv6. But small providers will be rather innovative and try things like your tunnel suggestion. After all, if Hurricane Electric can run an IPv6 tunnel broker, why can't you? --Michael Dillon From cidr-report at potaroo.net Fri Oct 9 17:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Oct 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200910092200.n99M01tP033443@wattle.apnic.net> BGP Update Report Interval: 01-Oct-09 -to- 08-Oct-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 49597 4.6% 163.7 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS9531 28365 2.6% 5673.0 -- GEDU-AS-KR Kwangju City Office Of Education 3 - AS1659 26099 2.4% 293.2 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 4 - AS8452 14240 1.3% 21.0 -- TEDATA TEDATA 5 - AS35805 11085 1.0% 25.0 -- UTG-AS United Telecom AS 6 - AS9829 10937 1.0% 25.0 -- BSNL-NIB National Internet Backbone 7 - AS4249 8936 0.8% 51.4 -- LILLY-AS - Eli Lilly and Company 8 - AS8866 7227 0.7% 20.2 -- BTC-AS Bulgarian Telecommunication Company Plc. 9 - AS7011 6663 0.6% 6.6 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 10 - AS5050 6127 0.6% 875.3 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - AS2697 5910 0.6% 107.5 -- ERX-ERNET-AS Education and Research Network 12 - AS14117 5909 0.6% 16.6 -- Telefonica del Sur S.A. 13 - AS17658 5787 0.5% 826.7 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 14 - AS4809 5767 0.5% 186.0 -- CHINATELECOM-CORE-WAN-CN2 China Telecom Next Generation Carrier Network 15 - AS5800 5732 0.5% 38.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 16 - AS33588 5713 0.5% 15.2 -- BRESNAN-AS - Bresnan Communications, LLC. 17 - AS30969 4927 0.5% 307.9 -- TAN-NET TransAfrica Networks 18 - AS7315 4861 0.5% 72.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 19 - AS17974 4801 0.5% 10.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS25524 4608 0.4% 18.0 -- OTON-AS SC Oton SRL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9531 28365 2.6% 5673.0 -- GEDU-AS-KR Kwangju City Office Of Education 2 - AS43880 3006 0.3% 3006.0 -- LITECH-AS Laboratory of Information Technologies LLC 3 - AS5691 2797 0.3% 2797.0 -- MITRE-AS-5 - The MITRE Corporation 4 - AS41060 1458 0.1% 1458.0 -- PRIMBANK-AS Joint-Stock Commercial Bank Primorye 5 - AS36239 1277 0.1% 1277.0 -- EXIGEN-CANADA - Exigen Canada 6 - AS43864 988 0.1% 988.0 -- INTEGRA-MEDIA-AS Integra-Media Ltd 7 - AS5050 6127 0.6% 875.3 -- PSC-EXT - Pittsburgh Supercomputing Center 8 - AS17658 5787 0.5% 826.7 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 9 - AS4628 1373 0.1% 686.5 -- ASN-PACIFIC-INTERNET-IX Pacific Internet Ltd 10 - AS23871 1358 0.1% 679.0 -- AINS-AS-AP Australia Internet Solutions 11 - AS24994 1136 0.1% 568.0 -- GENESYS-AS GENESYS Informatica AS for announcing own prefixes 12 - AS48728 460 0.0% 460.0 -- VODAFONEQATAR Vodafone Qatar Q.S.C. 13 - AS43008 446 0.0% 446.0 -- TREND-AS TREND IMPORT-EXPORT SRL 14 - AS5814 400 0.0% 400.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS39803 749 0.1% 374.5 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 16 - AS35301 747 0.1% 373.5 -- CCCMOS-AS CCCMOS GROUP AS Numbers 17 - AS6036 3801 0.3% 345.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS2642 1710 0.2% 342.0 -- LEG-CA-GOV - State of California 19 - AS30969 4927 0.5% 307.9 -- TAN-NET TransAfrica Networks 20 - AS17964 2436 0.2% 304.5 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 6106 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 113.11.156.0/24 5751 0.5% AS17658 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 3 - 211.253.68.0/22 5673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 4 - 211.253.72.0/21 5673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 5 - 210.218.64.0/19 5673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 6 - 210.217.224.0/19 5673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 7 - 210.218.0.0/18 5673 0.5% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 8 - 88.204.221.0/24 5334 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 89.218.218.0/23 5325 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 89.218.220.0/23 5322 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - 95.59.8.0/23 5316 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 12 - 95.59.4.0/22 5313 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 13 - 95.59.2.0/23 5311 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 14 - 95.59.3.0/24 5310 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 15 - 92.46.244.0/23 5307 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 16 - 95.59.1.0/24 5299 0.5% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 17 - 58.49.108.0/24 5227 0.5% AS4809 -- CHINATELECOM-CORE-WAN-CN2 China Telecom Next Generation Carrier Network 18 - 163.23.234.0/23 5120 0.4% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 19 - 163.23.236.0/22 5120 0.4% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 20 - 163.23.252.0/24 5118 0.4% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 9 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Oct 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200910092200.n99M00CJ033438@wattle.apnic.net> This report has been generated at Fri Oct 9 21:11:14 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 02-10-09 304773 185941 03-10-09 304871 185817 04-10-09 304733 186089 05-10-09 304982 186215 06-10-09 304949 186567 07-10-09 305120 186994 08-10-09 305290 187266 09-10-09 305384 187248 AS Summary 32540 Number of ASes in routing system 13844 Number of ASes announcing only one prefix 4311 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89611776 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 09Oct09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 305474 187286 118188 38.7% All ASes AS6389 4163 325 3838 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4311 1787 2524 58.5% TWTC - tw telecom holdings, inc. AS4766 1881 582 1299 69.1% KIXS-AS-KR Korea Telecom AS17488 1460 288 1172 80.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1062 10 1052 99.1% COVAD - Covad Communications Co. AS22773 1111 73 1038 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1762 841 921 52.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1483 577 906 61.1% Uninet S.A. de C.V. AS4755 1261 397 864 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18101 979 183 796 81.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1020 231 789 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1405 631 774 55.1% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1020 250 770 75.5% TV Cable S.A. AS8452 984 263 721 73.3% TEDATA TEDATA AS3356 1222 537 685 56.1% LEVEL3 Level 3 Communications AS4804 680 90 590 86.8% MPX-AS Microplex PTY LTD AS17908 638 59 579 90.8% TCISL Tata Communications AS4808 762 188 574 75.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 774 207 567 73.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 655 100 555 84.7% Telecom Argentina S.A. AS9498 650 112 538 82.8% BBIL-AP BHARTI Airtel Ltd. AS11492 1133 605 528 46.6% CABLEONE - CABLE ONE, INC. AS22047 545 18 527 96.7% VTR BANDA ANCHA S.A. AS7018 1543 1056 487 31.6% ATT-INTERNET4 - AT&T WorldNet Services AS17676 562 125 437 77.8% GIGAINFRA Softbank BB Corp. AS5668 801 365 436 54.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS4780 564 143 421 74.6% SEEDNET Digital United Inc. AS7011 1023 616 407 39.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS855 625 222 403 64.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS28573 763 362 401 52.6% NET Servicos de Comunicao S.A. Total 36842 11243 25599 69.5% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.72.112.0/20 AS19166 66.6.80.0/20 AS23350 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.248.72.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.73.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.74.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.75.0/24 AS11730 CIL-ASN - Circle Internet LTD 91.198.127.0/24 AS8972 PLUSSERVER-AS PlusServer AG, Germany 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 96.8.127.0/24 AS19166 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.229.192.0/18 AS44375 AISDP Asmanfaraz ISDP 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 193.34.199.0/24 AS20686 BISPING Bisping & Bisping GmbH & Co. KG 196.6.108.0/24 AS5713 SAIX-NET 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.162.0/24 AS4841 202.140.168.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK Wind International Services SA (previously known as M-LINK) 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.72.116.0/22 AS40907 CAPIT-159-AS01 - Tech Solutions 208.73.88.0/21 AS36835 208.75.0.0/22 AS40907 CAPIT-159-AS01 - Tech Solutions 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.24.192.0/20 AS10397 SINGLEPIPE - SinglePipe Communications, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From dr at kyx.net Fri Oct 9 19:38:19 2009 From: dr at kyx.net (Dragos Ruiu) Date: Fri, 9 Oct 2009 17:38:19 -0700 Subject: Does Internet Speed Vary by Season? In-Reply-To: <4ACCDC67.7080108@emanon.com> References: <200910071448.n97EmU9t080849@aurora.sol.net> <4ACCDC67.7080108@emanon.com> Message-ID: On 7-Oct-09, at 11:22 AM, Scott Morris wrote: > I may be having my wires a little crossed (I'm not an electrical > engineer) but I was always under the impression that manipulation of > the > physical characteristics like that from heat/dampness didn't reduce > the > "speed" but the "quality" (like line noise/errors/etc) of the line. Well, since it's been documented that internet speed / usage varies with the weather (it gets faster when it's sunny, slower when it rains) I'm sure some seasonal correlation could be found. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June 16/17 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From dave at stayonline.com Fri Oct 9 20:05:44 2009 From: dave at stayonline.com (Dave Larter) Date: Fri, 9 Oct 2009 21:05:44 -0400 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: <200910071448.n97EmU9t080849@aurora.sol.net><4ACCDC67.7080108@emanon.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB7346D6@MERCURY.socrdu.com> I may be missing a little bit here by jumping a bit in the thread so sorry. What is the difference between weather and seasonal? I define weather like, well its cloudy and raining here and get in the car and drive 20 minutes and it is clear and sunny. I would call this mostly localized, like ground zero. Nice here bad 15 miles/minutes away. Seasonal, well I think of Seattle, almost always rain/clouds..., more than a 15 minute/mile radius. Seasonal reminds me more of say, for months straight the ground/air is well, frozen. Like the northeast, where I used to live and will never go back. Just my .02, I'll shut up now. -----Original Message----- From: Dragos Ruiu [mailto:dr at kyx.net] Sent: Friday, October 09, 2009 8:38 PM To: swm at emanon.com Cc: nanog at nanog.org; Joe Greco Subject: Re: Does Internet Speed Vary by Season? On 7-Oct-09, at 11:22 AM, Scott Morris wrote: > I may be having my wires a little crossed (I'm not an electrical > engineer) but I was always under the impression that manipulation of > the > physical characteristics like that from heat/dampness didn't reduce > the > "speed" but the "quality" (like line noise/errors/etc) of the line. Well, since it's been documented that internet speed / usage varies with the weather (it gets faster when it's sunny, slower when it rains) I'm sure some seasonal correlation could be found. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June 16/17 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From ler762 at gmail.com Fri Oct 9 21:41:11 2009 From: ler762 at gmail.com (Lee) Date: Fri, 9 Oct 2009 22:41:11 -0400 Subject: Dutch ISPs to collaborate and take responsibility In-Reply-To: <20091009100539.GA31884@gsp.org> References: <200910062327.n96NRt5E093517@aurora.sol.net> <20091009100539.GA31884@gsp.org> Message-ID: On 10/9/09, Rich Kulawiec wrote: > On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: >> Additionally the problems of DDOS sourced from a collection of >> compromised hosts could be interfering with someone else's ability >> to make a successful VOIP call. > > Much more than that: they could be interfering with the underlying > infrastructure, or they could be attacking the VOIP destination, > or they could be making fake VOIP calls (see below), or they could > be doing ANYTHING. A compromised system is enemy territory, which is why: > >> This blocking should be as narrow as possible. > > Blocking should be total. A compromised system is as much > enemy-controlled as if it were physically located at the RBN. Trying > to figure out which of externally-visible behaviors A, B, C, etc. > it exhibits might be malicious and which might not be is a loss, If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised & should be blocked. Lee From Skywing at valhallalegends.com Fri Oct 9 22:21:59 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 9 Oct 2009 22:21:59 -0500 Subject: Dutch ISPs to collaborate and take responsibility Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6017379DBAA07@caralain.haven.nynaeve.net> ....or when I initiate offsite backups. I've seen ISPs that react to just traffic bursts. It's not the way to go without more intelligent decision making on the content (i.e. SMTP, all SYNs, etc). Of course, content inspection is a whole 'nother hornet's nest :) - S -----Original Message----- From: Lee Sent: Friday, October 09, 2009 19:41 To: nanog at nanog.org Subject: Re: Dutch ISPs to collaborate and take responsibility On 10/9/09, Rich Kulawiec wrote: > On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: >> Additionally the problems of DDOS sourced from a collection of >> compromised hosts could be interfering with someone else's ability >> to make a successful VOIP call. > > Much more than that: they could be interfering with the underlying > infrastructure, or they could be attacking the VOIP destination, > or they could be making fake VOIP calls (see below), or they could > be doing ANYTHING. A compromised system is enemy territory, which is why: > >> This blocking should be as narrow as possible. > > Blocking should be total. A compromised system is as much > enemy-controlled as if it were physically located at the RBN. Trying > to figure out which of externally-visible behaviors A, B, C, etc. > it exhibits might be malicious and which might not be is a loss, If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised & should be blocked. Lee From tvhawaii at shaka.com Fri Oct 9 22:26:30 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 9 Oct 2009 17:26:30 -1000 Subject: Dutch ISPs to collaborate and take responsibility References: <200910062327.n96NRt5E093517@aurora.sol.net><20091009100539.GA31884@gsp.org> Message-ID: <4E698A706BEE40C9A54DB9CD92CF1565@DELL16> Lee wrote: > If an ISP is involved with tracking down DDOS participants or > something, I can understand how they'd know a system was compromised. > But any kind of blocking because the ISP sees 'anomalous' traffic > seems .. premature at best. SANS newsbites has this bit: > On Thursday, October 8, Comcast began testing a service that alerts its > broadband subscribers with pop-ups if their computers appear to be > infected with malware. Among the indicative behaviors that trigger > alerts are spikes in overnight traffic, suggesting the machine has been > compromised and is being used to send spam. > > When my son comes home from college, there's a huge spike in overnight > traffic from my house. With all the people advocating immediate > blocking of pwned systems in this thread, I'm wondering what their > criteria is for deciding that the system is compromised & should be > blocked. > > Lee Some info. here (from http://networkmanagement.comcast.net/ ): 5. Detection of Bots http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03 http://tools.ietf.org/html/draft-livingood-web-notification-00 From bong.barnido at gmail.com Sat Oct 10 04:12:13 2009 From: bong.barnido at gmail.com (Bong Barnido) Date: Sat, 10 Oct 2009 17:12:13 +0800 Subject: NEED Some HELP Message-ID: <16a26ba20910100212i2158e929peef59520613150c8@mail.gmail.com> Hi Nanog Members, I've been troubleshooting this problem for a few days already but i'm still unable to fix it. I think it's now time to ask some help from Nanog members. I cannot ping the IP on my Cisco 6509 from the internet. Here are the setup: *Internet*---(copper)-->*GSR*----(fiber)--->* Cisco 6509* <<<<*GSR*----(copper)---> *Cisco 6509* <<<<< This setup is OK - I can ping(this is directly connected to the PRP2) NOTES: - I am using PRP2 on my GSR and the fiber is connected to the 4xGE module - I have a default route from Cisco 6509 to GSR - From the 6509 I can only ping the IP addresses on the GSR, addresses outside the GSR are not reachable - From the internet, I can only ping up to the GSR - I can ping from GSR to 6509 and vise versa - The IP on the 6509 is configured on the interface that is directly connected to the GSR. Thanks, -bong From rdobbins at arbor.net Sat Oct 10 04:24:35 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 10 Oct 2009 16:24:35 +0700 Subject: NEED Some HELP In-Reply-To: <16a26ba20910100212i2158e929peef59520613150c8@mail.gmail.com> References: <16a26ba20910100212i2158e929peef59520613150c8@mail.gmail.com> Message-ID: <0D85644F-A83F-461B-A9FB-EEBF54259DD6@arbor.net> On Oct 10, 2009, at 4:12 PM, Bong Barnido wrote: > I cannot ping the IP on my Cisco 6509 from the internet. Quite out of the context of the connectivity issue you're trying to troubleshoot, it's in fact extremely desirable to have your 6509 (and all your routers, for that matter) unpingable from the outside your own network. The BCP is to use iACLs, CoPP, et. al. to keep out all unsolicited traffic headed to, as opposed to through (like traceroute, pinging customer hosts, etc.), your network infrastructure. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From mpalmer at hezmatt.org Sat Oct 10 05:31:59 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 10 Oct 2009 21:31:59 +1100 Subject: 109/8 - not a BOGON In-Reply-To: References: Message-ID: <20091010103159.GY3191@hezmatt.org> On Fri, Oct 09, 2009 at 12:22:01PM +0100, Matthew Walster wrote: > A customer of mine is reporting that there are a large number of addresses > he can not reach with his addresses in the 109/8 range. This was > declassified as a BOGON and assigned by IANA to RIPE in January 2009. > > If you have a manually updated BOGON list, can I please ask that you review > it and update it as soon as possible please? His addresses in 89/8 and 83/8 > work just fine, hence this presumption of BOGON filtering. A pingable address in the problem range would help people to quickly evaluate whether they have a problem in their network or upstreams... - Matt From mpalmer at hezmatt.org Sat Oct 10 05:36:19 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 10 Oct 2009 21:36:19 +1100 Subject: 32-bit AS numbers In-Reply-To: <4ACF5F65.70902@kl.net> References: <20091009151350.GA28764@switchanddata.com> <4ACF5F65.70902@kl.net> Message-ID: <20091010103619.GZ3191@hezmatt.org> On Fri, Oct 09, 2009 at 12:05:57PM -0400, Kevin Loch wrote: > Greg Hankins wrote: > >> We also started a Wiki with content based on the presentation that has >> more updated information, including a current list of vendor support. >> If you see a vendor missing, let us know and we can update the list. >> Or better yet, create an account and add some content yourself :-). >> >> http://as4.cluepon.net/index.php/Main_Page > > While it's good to see support _finally_ in 2.2SX, I still don't see it > in 12.2SR (for rsp720). It's almost like Cisco has no idea how > many of these things are actually used on the Internet. Or, more plausibly, they know exactly how many there are out there, and how much they'd be able to make if everyone were forced to upgrade. - Matt From bong.barnido at gmail.com Sat Oct 10 08:24:41 2009 From: bong.barnido at gmail.com (Bong Barnido) Date: Sat, 10 Oct 2009 21:24:41 +0800 Subject: NEED Some HELP Message-ID: <16a26ba20910100624v65b66d24t7a57e5e42df2d0c4@mail.gmail.com> Hi Roland, My GSR and 6509 are newly installed and no ACLs in place. You can try to ping 180.178.73.1 and 180.178,73.2. 180.178.73.1 - GSR 180.178,73.2 - 6509 I can only reach 180.178.73.1 from outside. I cannot reach 180.178.73.2 which is the IP of my 6509. Not sure if this has something to do with the hardware. I am just wondering why I can't reach 180.178,73.2. Like I said earlier in my email, I have the default route from my 6509 to te GSR. My GE module is inserted to the GSR slot 1. Is the "hw-module" config requred on the GSR? Please help. Thanks, -bong ------------------------------ Message: 7 Date: Sat, 10 Oct 2009 16:24:35 +0700 From: Roland Dobbins Subject: Re: NEED Some HELP To: NANOG list Message-ID: <0D85644F-A83F-461B-A9FB-EEBF54259DD6 at arbor.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Oct 10, 2009, at 4:12 PM, Bong Barnido wrote: > I cannot ping the IP on my Cisco 6509 from the internet. Quite out of the context of the connectivity issue you're trying to troubleshoot, it's in fact extremely desirable to have your 6509 (and all your routers, for that matter) unpingable from the outside your own network. The BCP is to use iACLs, CoPP, et. al. to keep out all unsolicited traffic headed to, as opposed to through (like traceroute, pinging customer hosts, etc.), your network infrastructure. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ------------------------------ Message: 6 Date: Sat, 10 Oct 2009 17:12:13 +0800 From: Bong Barnido Subject: NEED Some HELP To: nanog at nanog.org Message-ID: <16a26ba20910100212i2158e929peef59520613150c8 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Nanog Members, I've been troubleshooting this problem for a few days already but i'm still unable to fix it. I think it's now time to ask some help from Nanog members. I cannot ping the IP on my Cisco 6509 from the internet. Here are the setup: *Internet*---(copper)-->*GSR*----(fiber)--->* Cisco 6509* <<<<*GSR*----(copper)---> *Cisco 6509* <<<<< This setup is OK - I can ping(this is directly connected to the PRP2) NOTES: - I am using PRP2 on my GSR and the fiber is connected to the 4xGE module - I have a default route from Cisco 6509 to GSR - From the 6509 I can only ping the IP addresses on the GSR, addresses outside the GSR are not reachable - From the internet, I can only ping up to the GSR - I can ping from GSR to 6509 and vise versa - The IP on the 6509 is configured on the interface that is directly connected to the GSR. Thanks, -bong From morrowc.lists at gmail.com Sat Oct 10 10:35:42 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 10 Oct 2009 11:35:42 -0400 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <7CC9F803BE7E0644A6219521B951AE38047A8DB581@s003mb01.staff.iaccap.com> References: <6762a99d0910090711i393129f4gfe7152bb284ab904@mail.gmail.com> <017265BF3B9640499754DD48777C3D20664ECB076B@MBX9.EXCHPROD.USA.NET> <7CC9F803BE7E0644A6219521B951AE38047A8DB549@s003mb01.staff.iaccap.com> <017265BF3B9640499754DD48777C3D20664ECB0786@MBX9.EXCHPROD.USA.NET> <7CC9F803BE7E0644A6219521B951AE38047A8DB581@s003mb01.staff.iaccap.com> Message-ID: <75cb24520910100835r1b022581q425cdae0784f6154@mail.gmail.com> On Fri, Oct 9, 2009 at 10:41 AM, Andrew Nusbaum wrote: > I actually got origin change alerts from Cyclops about 2 minutes after the announcements started. your email address starts with an A... So one of Jim's subtle hints here is that for folks willing to pay for alerting, they(renesys) can (not that I have any data to support this) alert 'in a timely fashion'. I suspect when your depending upon a machine under someone's desk that's not getting revenue support you get what you pay for. Note well, that I (personally) don't subscribe to any of these services... -Chris > -Andy > > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Friday, October 09, 2009 10:31 AM > To: Andrew Nusbaum; Jim Cowie; Adam Kennedy > Cc: NANOG > Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 > > I thought that may be the case as well. Do people know of other services like BGPMon that may be able to keep up with the load better? Does anyone know how cyclops faired this morning with the additional load? > > > > Dylan Ebner > > > -----Original Message----- > From: Andrew Nusbaum [mailto:Andrew.Nusbaum at mindspark.com] > Sent: Friday, October 09, 2009 9:27 AM > To: Dylan Ebner; Jim Cowie; Adam Kennedy > Cc: NANOG > Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 > > Usually I get alerts from BGPMon within about 20 minutes of an event being detected. ?Not so much with the event this morning. ?I'm guessing that the orgination of 86,747 prefixes from the wrong AS probably got their MTA pretty busy... > > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Friday, October 09, 2009 10:23 AM > To: Jim Cowie; Adam Kennedy > Cc: NANOG > Subject: RE: Invalid prefix announcement from AS9035 for 129.77.0.0/16 > > Does anyone know why it takes BGPMon so long to send out an email. It looks like it BGPMon detected the AS9035 announcements at the right time (around 7:00 UTC) but I didn't get a notification until around 13:00 UTC. It seems like many people rely on BGPMon to do this type of detection, so the long delay is frustrating. > > Thanks > > > Dylan Ebner > > > > From lukasz at bromirski.net Sat Oct 10 11:34:03 2009 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sat, 10 Oct 2009 18:34:03 +0200 Subject: 32-bit AS numbers In-Reply-To: <20091010103619.GZ3191@hezmatt.org> References: <20091009151350.GA28764@switchanddata.com> <4ACF5F65.70902@kl.net> <20091010103619.GZ3191@hezmatt.org> Message-ID: <4AD0B77B.60304@bromirski.net> On 2009-10-10 12:36, Matthew Palmer wrote: >>> http://as4.cluepon.net/index.php/Main_Page >> While it's good to see support _finally_ in 2.2SX, I still don't see it >> in 12.2SR (for rsp720). It's almost like Cisco has no idea how >> many of these things are actually used on the Internet. > Or, more plausibly, they know exactly how many there are out there, and how > much they'd be able to make if everyone were forced to upgrade. The 12.2SRE for RSP720 on 7600 is going to be available shortly and it will support 4B ASNs. It was communicated a number of times on cisco-nsp@ for those who subscribe it and did care. But I see that conspiracy theory looks nicer. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From pl+list at pmacct.net Sat Oct 10 14:23:22 2009 From: pl+list at pmacct.net (Paolo Lucente) Date: Sat, 10 Oct 2009 20:23:22 +0100 Subject: 32-bit AS numbers In-Reply-To: <4AD0B77B.60304@bromirski.net> References: <20091009151350.GA28764@switchanddata.com> <4ACF5F65.70902@kl.net> <20091010103619.GZ3191@hezmatt.org> <4AD0B77B.60304@bromirski.net> Message-ID: <20091010192321.GA3522@london.pmacct.net> On Sat, Oct 10, 2009 at 06:34:03PM +0200, ?ukasz Bromirski wrote: > The 12.2SRE for RSP720 on 7600 is going to be available shortly and > it will support 4B ASNs. It was communicated a number of times on > cisco-nsp@ for those who subscribe it and did care. > > But I see that conspiracy theory looks nicer. Even if i guess everybody is aware this is thankfully coming at some stage, and i personally find the "shortly" definition late 2009 a bit disappointing, i find the point being another: In late 2006 it was more or less monumentally announced that the paths of the "switch" and the "router" were to get separate: the 6500 and >= SXH releases on one side, the 7600 and >= SRA releases on the other. Then i see 32-bit ASNs being kindly implemented on the "switch" first, in SXI - with SRD for the "router" being released roughly in parallel; and one can amuse himself by reading issues people stumble upon with SXI. OK, a fuck-up on the way - it can happen: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml And finally, yes, 32-bit ASNs for the "router" will come: by the end of this year and on a new release: SRE. Which, re-phrased from an operator point of view, essentially means: a candidate release for a production deployment is not less than another 1 year away. And frankly pages like the one below, with no mention of plans for the 6500/7600 platforms whatsoever, are not encouraging at all: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html Cheers, Paolo From fred at cisco.com Sat Oct 10 16:27:07 2009 From: fred at cisco.com (Fred Baker) Date: Sat, 10 Oct 2009 14:27:07 -0700 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: <200910071448.n97EmU9t080849@aurora.sol.net> <4ACCDC67.7080108@emanon.com> Message-ID: On Oct 9, 2009, at 5:38 PM, Dragos Ruiu wrote: > Well, since it's been documented that internet speed / usage varies > with > the weather (it gets faster when it's sunny, slower when it rains) > I'm sure some > seasonal correlation could be found. Could you point to the documentation? I having trouble with language that sounds like one concept and I suspect is in fact another. Take as one example the basic digital signaling hierarchy. The specifications call for a certain rate plus or minus some number of parts per million. If they are within tolerance, the amount that they would speed up or slow down is measured in a pretty small number of bits per second. So I don't think the speed of the links is materially changing. If on the other hand we are discussing the volume of traffic using that available capacity, it is absolutely clear that there are diurnal, weekly, and seasonal variations as well as growth in time. Are we talking about bit rate, which one might expect to be modified by environmental characteristics and is in fact very tightly controlled to prevent that, or traffic volume? From ml at kenweb.org Sat Oct 10 18:24:54 2009 From: ml at kenweb.org (ML) Date: Sat, 10 Oct 2009 19:24:54 -0400 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> Message-ID: <4AD117C6.5010001@kenweb.org> Matthew Huff wrote: > About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. > > If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. > > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > Was there an explanation for the leak posted? Maybe this was a coincidence but the only prefixes I received alerts on were prefixes I only advertise to Level3. There was one exception. There was a leaked prefix that is the next /24 above on our Level3 only prefixes. -ML From frank at fttx.org Sat Oct 10 19:32:36 2009 From: frank at fttx.org (Frank A. Coluccio) Date: Sat, 10 Oct 2009 17:32:36 -0700 Subject: Does Internet Speed Vary by Season? Message-ID: <20091010173236.A6785258@resin09.mta.everyone.net> Hi Fred. I think you are referring, in the case of hierarchical synchronous architectures (SONET/SDH), to the absolute periodicity of the timing coming from clock sources. Frame slips and overwrites can occur when too many ppm lagging or leading are exceeded, as I believe was implied in your post. In contrast, I believe the notions that are being discussed in this thread have more to do with the effects of temperature coefficients of metallic conductors during shifts in outside temperature conditions, and the ensuing changes in the nominal velocity of propagation that accompany those changes, relative to the speed of light. In any case, I have been following this discussion from its beginning with a great amount of interest, finding it a great memory jogger from times misspent in my youth. I started a parallel discussion on my forum, where today I responded to another poster with the following observations, for anyone interested. [1]http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26010089 Frank --- fred at cisco.com wrote: From: Fred Baker To: Dragos Ruiu Cc: nanog at nanog.org, Joe Greco Subject: Re: Does Internet Speed Vary by Season? Date: Sat, 10 Oct 2009 14:27:07 -0700 On Oct 9, 2009, at 5:38 PM, Dragos Ruiu wrote: > Well, since it's been documented that internet speed / usage varies > with > the weather (it gets faster when it's sunny, slower when it rains) > I'm sure some > seasonal correlation could be found. Could you point to the documentation? I having trouble with language that sounds like one concept and I suspect is in fact another. Take as one example the basic digital signaling hierarchy. The specifications call for a certain rate plus or minus some number of parts per million. If they are within tolerance, the amount that they would speed up or slow down is measured in a pretty small number of bits per second. So I don't think the speed of the links is materially changing. If on the other hand we are discussing the volume of traffic using that available capacity, it is absolutely clear that there are diurnal, weekly, and seasonal variations as well as growth in time. Are we talking about bit rate, which one might expect to be modified by environmental characteristics and is in fact very tightly controlled to prevent that, or traffic volume? References 1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26010089 From deleskie at gmail.com Sat Oct 10 20:30:07 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Sun, 11 Oct 2009 01:30:07 +0000 Subject: Does Internet Speed Vary by Season? In-Reply-To: <20091010173236.A6785258@resin09.mta.everyone.net> References: <20091010173236.A6785258@resin09.mta.everyone.net> Message-ID: <2099903265-1255224607-cardhu_decombobulator_blackberry.rim.net-330945972-@bda023.bisx.prod.on.blackberry> Maybe I'm way off.. Maybe its view of KISS but as engineers we should all be looking for the simplest answer. To me they key in Dragos' post was usage. All physics aside, the warm weather (seasonal) people go out more, use the internet less. In cold months, we stay in, use the net more. As for document any of us that run networks have seen this well document going back many years in our mrgt graphs. But then maybe he was refering to the physics, and I just try to simplify things to much. Have. Good weekend all! -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: "Frank A. Coluccio" Date: Sat, 10 Oct 2009 17:32:36 To: Fred Baker Cc: ; Subject: Re: Does Internet Speed Vary by Season? Hi Fred. I think you are referring, in the case of hierarchical synchronous architectures (SONET/SDH), to the absolute periodicity of the timing coming from clock sources. Frame slips and overwrites can occur when too many ppm lagging or leading are exceeded, as I believe was implied in your post. In contrast, I believe the notions that are being discussed in this thread have more to do with the effects of temperature coefficients of metallic conductors during shifts in outside temperature conditions, and the ensuing changes in the nominal velocity of propagation that accompany those changes, relative to the speed of light. In any case, I have been following this discussion from its beginning with a great amount of interest, finding it a great memory jogger from times misspent in my youth. I started a parallel discussion on my forum, where today I responded to another poster with the following observations, for anyone interested. [1]http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26010089 Frank --- fred at cisco.com wrote: From: Fred Baker To: Dragos Ruiu Cc: nanog at nanog.org, Joe Greco Subject: Re: Does Internet Speed Vary by Season? Date: Sat, 10 Oct 2009 14:27:07 -0700 On Oct 9, 2009, at 5:38 PM, Dragos Ruiu wrote: > Well, since it's been documented that internet speed / usage varies > with > the weather (it gets faster when it's sunny, slower when it rains) > I'm sure some > seasonal correlation could be found. Could you point to the documentation? I having trouble with language that sounds like one concept and I suspect is in fact another. Take as one example the basic digital signaling hierarchy. The specifications call for a certain rate plus or minus some number of parts per million. If they are within tolerance, the amount that they would speed up or slow down is measured in a pretty small number of bits per second. So I don't think the speed of the links is materially changing. If on the other hand we are discussing the volume of traffic using that available capacity, it is absolutely clear that there are diurnal, weekly, and seasonal variations as well as growth in time. Are we talking about bit rate, which one might expect to be modified by environmental characteristics and is in fact very tightly controlled to prevent that, or traffic volume? References 1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26010089 From adrian at creative.net.au Sat Oct 10 21:41:36 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 11 Oct 2009 10:41:36 +0800 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: <200910071448.n97EmU9t080849@aurora.sol.net> <4ACCDC67.7080108@emanon.com> Message-ID: <20091011024135.GA8395@skywalker.creative.net.au> On Sat, Oct 10, 2009, Fred Baker wrote: > Are we talking about bit rate, which one might expect to be modified > by environmental characteristics and is in fact very tightly > controlled to prevent that, or traffic volume? Not true with modem type technologies, where the available transmission rate is a function of how many available frequency space slices are deemed to be "good" at any one time. This isn't really like SDH (from what I've read of SDH, anyway.) Adrian From christian at automatick.net Sat Oct 10 23:11:16 2009 From: christian at automatick.net (christian) Date: Sat, 10 Oct 2009 21:11:16 -0700 Subject: Invalid prefix announcement from AS9035 for 129.77.0.0/16 In-Reply-To: <4AD117C6.5010001@kenweb.org> References: <483E6B0272B0284BA86D7596C40D29F9D7742B14D3@PUR-EXCH07.ox.com> <4AD117C6.5010001@kenweb.org> Message-ID: On Sat, Oct 10, 2009 at 4:24 PM, ML wrote: > Matthew Huff wrote: >> >> About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from >> AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 >> (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass >> sites. Hopefully this was just a typo that was quickly corrected. I would >> appreciate if people have time and can double check let me know if any >> announcements are active except from our AS6128/AS6395 upstreams. >> >> If this were to persist, what would be the best course of action to >> resolve it, especially given that the AS was within RIPE. >> >> >> >> ---- >> Matthew Huff ? ? ? | One Manhattanville Rd >> OTA Management LLC | Purchase, NY 10577 >> http://www.ox.com ?| Phone: 914-460-4039 >> aim: matthewbhuff ?| Fax: ? 914-460-4139 >> >> >> > > Was there an explanation for the leak posted? > > > Maybe this was a coincidence but the only prefixes I received alerts on were > prefixes I only advertise to Level3. ?There was one exception. There was a > leaked prefix that is the next /24 above on our Level3 only prefixes. > > -ML > > > > on a side note, has anyone that's running any of these type of monitoring services performed any analysis or compiled any metrics on leaks? (renesys maybe?) personally, i'd be sort of interested in seeing some stats on leaks such as: origin (asn/network, country, common/exchange point) duration of leak size of leak # of upstream networks that accepted the leaked prefixes asn of networks that accepted the leak # of incidents per network/repeat offenders -ck From lorell at hathcock.org Sun Oct 11 00:23:26 2009 From: lorell at hathcock.org (Lorell Hathcock) Date: Sun, 11 Oct 2009 00:23:26 -0500 Subject: Does Internet Speed Vary by Season? In-Reply-To: References: <200910071448.n97EmU9t080849@aurora.sol.net> <4ACCDC67.7080108@emanon.com> Message-ID: <003301ca4a32$f5f959a0$e1ec0ce0$@org> Having worked in Operations at various ISPs in rain-riddled Houston for 1.5 decades, I can say that when it rains, water gets into the copper lines in the ground and caused increased copper-based local loop failures. That experience leaves me open to believe that where the internet backbone is copper based, when it rains, failures may ensue due to old or improperly installed outside plant and could cause failures which would slow down the internet. I would also conjecture that more people would be on line during bad weather, so that internet usage would increase and perhaps over-wrought links (copper or otherwise) could have some congestion. Finally, in those places where the internet is experienced through wireless links, some may see weather related slow downs. On Oct 9, 2009, at 5:38 PM, Dragos Ruiu wrote: > Well, since it's been documented that internet speed / usage varies > with > the weather (it gets faster when it's sunny, slower when it rains) > I'm sure some > seasonal correlation could be found. Could you point to the documentation? I having trouble with language that sounds like one concept and I suspect is in fact another. Take as one example the basic digital signaling hierarchy. The specifications call for a certain rate plus or minus some number of parts per million. If they are within tolerance, the amount that they would speed up or slow down is measured in a pretty small number of bits per second. So I don't think the speed of the links is materially changing. If on the other hand we are discussing the volume of traffic using that available capacity, it is absolutely clear that there are diurnal, weekly, and seasonal variations as well as growth in time. Are we talking about bit rate, which one might expect to be modified by environmental characteristics and is in fact very tightly controlled to prevent that, or traffic volume? From jgreco at ns.sol.net Sun Oct 11 18:22:03 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 11 Oct 2009 18:22:03 -0500 (CDT) Subject: Does Internet Speed Vary by Season? In-Reply-To: <2099903265-1255224607-cardhu_decombobulator_blackberry.rim.net-330945972-@bda023.bisx.prod.on.blackberry> from "deleskie@gmail.com" at Oct 11, 2009 01:30:07 AM Message-ID: <200910112322.n9BNM3a5093107@aurora.sol.net> > Maybe I'm way off.. Maybe its view of KISS but as engineers we should > all be looking for the simplest answer. To me they key in Dragos' > post was usage. All physics aside, the warm weather (seasonal) people > go out more, use the internet less. In cold months, we stay in, use > the net more. As for document any of us that run networks have seen > this well document going back many years in our mrgt graphs. But > then maybe he was refering to the physics, and I just try to simplify > things to much. Usage has an effect on overcommit, yes. However, when you notice that the average connect speed goes down for a day or two after a cold heavy rain, that's not usage. There are not more than one modems connecting(*) to a port. So you have established that something about the quality of the physical layer has been affected. ... JG (*) In the late 1990's, I heard the most astonishing claims made by a new entrant into the Milwaukee ISP market, about how some of the "other" ISP's "shared" lines between customers and this decreased your speeds. They had no clue who I was, so I engaged their technical person for a while who set out to convince me that other ISP's really _did_ do this mythical line- sharing - multiple modems to one port. Until I started talking about the technical aspects, that is. -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From dr at kyx.net Sun Oct 11 23:37:50 2009 From: dr at kyx.net (Dragos Ruiu) Date: Sun, 11 Oct 2009 21:37:50 -0700 Subject: Does Internet Speed Vary by Season? In-Reply-To: <003301ca4a32$f5f959a0$e1ec0ce0$@org> References: <200910071448.n97EmU9t080849@aurora.sol.net> <4ACCDC67.7080108@emanon.com> <003301ca4a32$f5f959a0$e1ec0ce0$@org> Message-ID: On 10-Oct-09, at 10:23 PM, Lorell Hathcock wrote: > > Could you point to the documentation? Well, a friend at one particular large internet exchange says he can predict semi-accurately the ambient temperature/ weather in the local city from the MRTG stats. :-) The stats he showed me backed him up - or at least clearly showed strong correlation between weather and traffic levels. The formal proof is left as an exercise for the reader. ;-P This has nothing to do with corrosion and all about usage and congestion. Cold weather leads to more people snuggling up with their laptops. In sunny warm weather everyone gets away from the kb and goes outside to have a real life. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June 16/17 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From vandry at TZoNE.ORG Mon Oct 12 02:08:52 2009 From: vandry at TZoNE.ORG (Phil Vandry) Date: Mon, 12 Oct 2009 03:08:52 -0400 Subject: Does Internet Speed Vary by Season? In-Reply-To: <200910112322.n9BNM3a5093107@aurora.sol.net> References: <200910112322.n9BNM3a5093107@aurora.sol.net> Message-ID: On 2009-10-11, at 19:22 , Joe Greco wrote: > (*) In the late 1990's, I heard the most astonishing claims made by > a new > entrant into the Milwaukee ISP market, about how some of the "other" > ISP's > "shared" lines between customers and this decreased your speeds. > They had > no clue who I was, so I engaged their technical person for a while > who set > out to convince me that other ISP's really _did_ do this mythical > line- > sharing - multiple modems to one port. Until I started talking > about the > technical aspects, that is. Not so mythical. Around the same time period, we found out about an ISP offering always-on ISDN BRI service for such a low price that it could not possibly make sense. We wondered how they could make ends meet at that rate until we found out how they did it. They daisy chained multiple customers' BRI lines together, using the second B channel from one customer to connect the next customer down the line. Once, one of their customers switched to our service and we reconfigured their router (a legitimate action: both router and BRI line belonged to the customer). Who knows how many downstream customers we broke by doing that. -Phil From igor at ergens.org Mon Oct 12 06:41:19 2009 From: igor at ergens.org (Igor Ybema) Date: Mon, 12 Oct 2009 13:41:19 +0200 Subject: IPv6 internet broken, cogent/telia/hurricane not peering Message-ID: Hi, I recently noticed that there seems a peering issue on the ipv6 internet. As we all know hurricane is currently the largest ipv6 carrier. Other large carriers are now implementing ipv6 on their networks, like Cogent and Telia. However, due to some politics it seems that they are not peering with each other resulting in a broken ipv6 internet currently. I noticed this by using the looking glasses from telia and hurricane. This is only a real problem if you use hurricane as the only transit. However, hurricane also announces 6to4 relays. When you happen to use the hurricane relay server (due to the shortest path), cogent and telia (and maybe more) are not reachable. I already asked hurricane about their point of view. They simply just ignore it because they 'are the biggest one'. I'm currious about you point of view. regards, Igor Ybema Senior network Administrator Oxilion From jgreco at ns.sol.net Mon Oct 12 09:04:05 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 12 Oct 2009 09:04:05 -0500 (CDT) Subject: Does Internet Speed Vary by Season? In-Reply-To: from "Phil Vandry" at Oct 12, 2009 03:08:52 AM Message-ID: <200910121404.n9CE45A6066413@aurora.sol.net> > On 2009-10-11, at 19:22 , Joe Greco wrote: > > (*) In the late 1990's, I heard the most astonishing claims made by > > a new > > entrant into the Milwaukee ISP market, about how some of the "other" > > ISP's > > "shared" lines between customers and this decreased your speeds. > > They had > > no clue who I was, so I engaged their technical person for a while > > who set > > out to convince me that other ISP's really _did_ do this mythical > > line- > > sharing - multiple modems to one port. Until I started talking > > about the > > technical aspects, that is. > > Not so mythical. Around the same time period, we found out about an > ISP offering always-on ISDN BRI service for such a low price that it > could not possibly make sense. We wondered how they could make ends > meet at that rate until we found out how they did it. They daisy > chained multiple customers' BRI lines together, using the second B > channel from one customer to connect the next customer down the line. > Once, one of their customers switched to our service and we > reconfigured their router (a legitimate action: both router and BRI > line belonged to the customer). Who knows how many downstream > customers we broke by doing that. A virtual ISDN party line! Cool! :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From patrick at ianai.net Mon Oct 12 11:09:58 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Oct 2009 12:09:58 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: Message-ID: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> On Oct 12, 2009, at 7:41 AM, Igor Ybema wrote: > I recently noticed that there seems a peering issue on the ipv6 > internet. > As we all know hurricane is currently the largest ipv6 carrier. > Other large > carriers are now implementing ipv6 on their networks, like Cogent > and Telia. > > However, due to some politics it seems that they are not peering > with each > other resulting in a broken ipv6 internet currently. I noticed this > by using > the looking glasses from telia and hurricane. > > This is only a real problem if you use hurricane as the only transit. > However, hurricane also announces 6to4 relays. When you happen to > use the > hurricane relay server (due to the shortest path), cogent and telia > (and > maybe more) are not reachable. > > I already asked hurricane about their point of view. They simply > just ignore > it because they 'are the biggest one'. It is sad to see that networks which used to care about connectivity, peering, latency, etc., when they are small change their mind when they are "big". The most recent example is Cogent, an open peer who decided to turn down peers when they reached transit free status. I never thought HE would be one of those networks. -- TTFN, patrick From marcoh at marcoh.net Mon Oct 12 11:15:34 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 12 Oct 2009 18:15:34 +0200 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> Message-ID: <3EE6EE2A-3958-4C61-B451-8763F60D11F2@marcoh.net> On Oct 12, 2009, at 6:09 PM, Patrick W. Gilmore wrote: > It is sad to see that networks which used to care about > connectivity, peering, latency, etc., when they are small change > their mind when they are "big". The most recent example is Cogent, > an open peer who decided to turn down peers when they reached > transit free status. > > I never thought HE would be one of those networks. Do we have any proof it's HE rejecting peering or is it that Cogent en Telia alike that are to proud to ask and think they can have a piece of the pie as they did with v4 ? MarcoH From sethm at rollernet.us Mon Oct 12 11:20:58 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 09:20:58 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: Message-ID: <4AD3576A.10203@rollernet.us> Igor Ybema wrote: > Hi, > I recently noticed that there seems a peering issue on the ipv6 internet. > As we all know hurricane is currently the largest ipv6 carrier. Other large > carriers are now implementing ipv6 on their networks, like Cogent and Telia. > > However, due to some politics it seems that they are not peering with each > other resulting in a broken ipv6 internet currently. I noticed this by using > the looking glasses from telia and hurricane. > > This is only a real problem if you use hurricane as the only transit. > However, hurricane also announces 6to4 relays. When you happen to use the > hurricane relay server (due to the shortest path), cogent and telia (and > maybe more) are not reachable. > > I already asked hurricane about their point of view. They simply just ignore > it because they 'are the biggest one'. > > I'm currious about you point of view. > Don't get me started on IPv6 crap... ;) If you are interested, I don't want to spam the list with my Verizon horror story, but you can read it here: http://www.rollernet.us/wordpress/category/ipv6/ ~Seth From deepak at ai.net Mon Oct 12 11:23:52 2009 From: deepak at ai.net (Deepak Jain) Date: Mon, 12 Oct 2009 12:23:52 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering Message-ID: Perhaps someone from HE can re-confirm their open peering policy for us? If they aren't (open) anymore, I'm impressed by the bravado... Deepak ----- Original Message ----- From: Marco Hogewoning To: Patrick W. Gilmore Cc: NANOG list Sent: Mon Oct 12 12:15:34 2009 Subject: Re: IPv6 internet broken, cogent/telia/hurricane not peering On Oct 12, 2009, at 6:09 PM, Patrick W. Gilmore wrote: > It is sad to see that networks which used to care about > connectivity, peering, latency, etc., when they are small change > their mind when they are "big". The most recent example is Cogent, > an open peer who decided to turn down peers when they reached > transit free status. > > I never thought HE would be one of those networks. Do we have any proof it's HE rejecting peering or is it that Cogent en Telia alike that are to proud to ask and think they can have a piece of the pie as they did with v4 ? MarcoH From patrick at ianai.net Mon Oct 12 11:49:02 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Oct 2009 12:49:02 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: Message-ID: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> On Oct 12, 2009, at 12:23 PM, Deepak Jain wrote: > Perhaps someone from HE can re-confirm their open peering policy for > us? > > If they aren't (open) anymore, I'm impressed by the bravado... To be clear, I was not trying to imply that HE has a closed policy. But I can see how people might think that given my Cogent example. My apologies to HE. And to be fair, I'm pounding on HE because they've always cared about their customers. I expect Telia to care more about their own ego than their customers' connectivity. So banging on them is nonproductive. In summary: HE has worked tirelessly and mostly thanklessly to promote v6. They have done more to bring v6 to the forefront than any other network. But at the end of day, despite HE's valiant effort on v6, v6 has all the problems of v4 on the backbone, PLUS growing pains. Which means it is difficult to rely on it, as v4 has enough dangers on its own. Anyway, I have confidence HE is trying to fix this. But I still think the fact that it happened - whatever the reason - is a black eye for the v6 "Internet", whatever the hell that is. -- TTFN, patrick > ----- Original Message ----- > From: Marco Hogewoning > To: Patrick W. Gilmore > Cc: NANOG list > Sent: Mon Oct 12 12:15:34 2009 > Subject: Re: IPv6 internet broken, cogent/telia/hurricane not peering > > > On Oct 12, 2009, at 6:09 PM, Patrick W. Gilmore wrote: > >> It is sad to see that networks which used to care about >> connectivity, peering, latency, etc., when they are small change >> their mind when they are "big". The most recent example is Cogent, >> an open peer who decided to turn down peers when they reached >> transit free status. >> >> I never thought HE would be one of those networks. > > > Do we have any proof it's HE rejecting peering or is it that Cogent en > Telia alike that are to proud to ask and think they can have a piece > of the pie as they did with v4 ? > > MarcoH > > From randy at psg.com Mon Oct 12 11:52:04 2009 From: randy at psg.com (Randy Bush) Date: Mon, 12 Oct 2009 09:52:04 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> Message-ID: sure would be nice if there was a diagnosis before the lynching From igor at ergens.org Mon Oct 12 12:06:37 2009 From: igor at ergens.org (Igor Ybema) Date: Mon, 12 Oct 2009 19:06:37 +0200 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: Message-ID: Just saw that telia <-> HE AND telia <-> Cogent got fixed. They are now connected through C&W. Maybe someone got woken up by these messages :) Cogent and HE is still broken but then again, ipv6 at cogent is still beta. regards, Igor From patrick at ianai.net Mon Oct 12 12:10:23 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Oct 2009 13:10:23 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> Message-ID: On Oct 12, 2009, at 12:52 PM, Randy Bush wrote: > sure would be nice if there was a diagnosis before the lynching If this happened in v4, would customers care 'why' it happened? Obviously not. Why should v6 be any different? It either is or is not production ready. I'm interested in HE's view on that. -- TTFN, patrick From michael at linuxmagic.com Mon Oct 12 12:25:07 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 12 Oct 2009 10:25:07 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> Message-ID: <200910121025.07137.michael@linuxmagic.com> On October 12, 2009, Patrick W. Gilmore wrote: > In summary: HE has worked tirelessly and mostly thanklessly to promote > v6. They have done more to bring v6 to the forefront than any other > network. But at the end of day, despite HE's valiant effort on v6, v6 > has all the problems of v4 on the backbone, PLUS growing pains. Which > means it is difficult to rely on it, as v4 has enough dangers on its > own. > And don't forget.. Once IPv6 gets to the mainstream.. IP Reputation lists are going to have a real fun time :) Spammers would love to see IPv6 in place I am sure. ;) Routing IPv6 is going to require one heck of a thinking re- adjustment. Would be nice to just leave IPv6 in the premises, and keep IPv4 for routing. -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From ras at e-gerbil.net Mon Oct 12 12:41:00 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 12 Oct 2009 12:41:00 -0500 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: Message-ID: <20091012174100.GD51443@gerbil.cluepon.net> On Mon, Oct 12, 2009 at 07:06:37PM +0200, Igor Ybema wrote: > Just saw that telia <-> HE AND telia <-> Cogent got fixed. They are now > connected through C&W. Maybe someone got woken up by these messages :) > > Cogent and HE is still broken but then again, ipv6 at cogent is still beta. Cogent has never carried a full IPv6 table, and probably never will (or at least, not for a REALLY long time). They aren't using any IPv6 transit, and will only turn up peering with a handful of large networks as measured by their IPv4 peering stats. This isn't even close to representative of the IPv6 routing table, so they're probably going to continue to miss huge chunks of IPv6 for many years to come. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sethm at rollernet.us Mon Oct 12 12:47:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 10:47:20 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> Message-ID: <4AD36BA8.3000907@rollernet.us> Patrick W. Gilmore wrote: > On Oct 12, 2009, at 12:52 PM, Randy Bush wrote: > >> sure would be nice if there was a diagnosis before the lynching > > If this happened in v4, would customers care 'why' it happened? > Obviously not. I suspect more NAT will become a better solution than migrating to IPv6 if/when runout becomes a problem because there's just not enough visibility or providers that take it seriously enough for IPv6 to be a viable solution. I try to do my part but it's a horrible pain. > Why should v6 be any different? It either is or is not production > ready. I'm interested in HE's view on that. > As far as HE goes, they're so pro-IPv6 I would be surprised if anything intentionally bad was going on. I wish more providers had their attitude towards IPv6. ~Seth From nenolod at systeminplace.net Mon Oct 12 13:04:22 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 12 Oct 2009 13:04:22 -0500 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <4AD36BA8.3000907@rollernet.us> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <4AD36BA8.3000907@rollernet.us> Message-ID: <1255370662.5279.31.camel@petrie> On Mon, 2009-10-12 at 10:47 -0700, Seth Mattinen wrote: > Patrick W. Gilmore wrote: > > On Oct 12, 2009, at 12:52 PM, Randy Bush wrote: > > > >> sure would be nice if there was a diagnosis before the lynching > > > > If this happened in v4, would customers care 'why' it happened? > > Obviously not. > > I suspect more NAT will become a better solution than migrating to IPv6 > if/when runout becomes a problem because there's just not enough > visibility or providers that take it seriously enough for IPv6 to be a > viable solution. I try to do my part but it's a horrible pain. > And then you have the hoards of DSLreports people screaming about how they do not have a routeable IP address anymore, which is bad for business, and then IPv6 comes about because the people *demand* it. (although they do not necessarily know they are demanding that -- what they are demanding is the ability to continue having publically routeable IP addresses for their broadband connection.) William From joelja at bogus.com Mon Oct 12 13:23:19 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 12 Oct 2009 11:23:19 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <200910121025.07137.michael@linuxmagic.com> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> Message-ID: <4AD37417.9040404@bogus.com> Michael Peddemors wrote: > On October 12, 2009, Patrick W. Gilmore wrote: >> In summary: HE has worked tirelessly and mostly thanklessly to promote >> v6. They have done more to bring v6 to the forefront than any other >> network. But at the end of day, despite HE's valiant effort on v6, v6 >> has all the problems of v4 on the backbone, PLUS growing pains. Which >> means it is difficult to rely on it, as v4 has enough dangers on its >> own. >> > > And don't forget.. Once IPv6 gets to the mainstream.. IP Reputation lists are > going to have a real fun time :) Spammers would love to see IPv6 in place I am > sure. You seem to have concluded that blacklisting a prefix is much harder in ipv6 than it is in v4... > ;) Routing IPv6 is going to require one heck of a thinking re- > adjustment. Would be nice to just leave IPv6 in the premises, and keep IPv4 > for routing. > From dwhite at olp.net Mon Oct 12 13:28:48 2009 From: dwhite at olp.net (Dan White) Date: Mon, 12 Oct 2009 13:28:48 -0500 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <200910121025.07137.michael@linuxmagic.com> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> Message-ID: <20091012182847.GI5163@dan.olp.net> On 12/10/09?10:25?-0700, Michael Peddemors wrote: >On October 12, 2009, Patrick W. Gilmore wrote: >> In summary: HE has worked tirelessly and mostly thanklessly to promote >> v6. They have done more to bring v6 to the forefront than any other >> network. But at the end of day, despite HE's valiant effort on v6, v6 >> has all the problems of v4 on the backbone, PLUS growing pains. Which >> means it is difficult to rely on it, as v4 has enough dangers on its >> own. >> > >And don't forget.. Once IPv6 gets to the mainstream.. IP Reputation lists are >going to have a real fun time :) Spammers would love to see IPv6 in place I am >sure. ;) Routing IPv6 is going to require one heck of a thinking re- >adjustment. Would be nice to just leave IPv6 in the premises, and keep IPv4 >for routing. Reputation lists will just be on the /64, /56 and /48 boundaries, rather than IPv4 /32. -- Dan White BTC Broadband From jbates at brightok.net Mon Oct 12 14:14:00 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 12 Oct 2009 14:14:00 -0500 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <20091012182847.GI5163@dan.olp.net> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> Message-ID: <4AD37FF8.2010303@brightok.net> Dan White wrote: > Reputation lists will just be on the /64, /56 and /48 boundaries, rather > than IPv4 /32. And then people will scream because someone setup a layout that hands out /128 addresses within a /64 pool. Jack From marcoh at marcoh.net Mon Oct 12 14:24:15 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 12 Oct 2009 21:24:15 +0200 Subject: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) In-Reply-To: <4AD37FF8.2010303@brightok.net> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> <4AD37FF8.2010303@brightok.net> Message-ID: <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> On Oct 12, 2009, at 9:14 PM, Jack Bates wrote: > Dan White wrote: >> Reputation lists will just be on the /64, /56 and /48 boundaries, >> rather >> than IPv4 /32. > > And then people will scream because someone setup a layout that > hands out /128 addresses within a /64 pool. There is that chance yes especially from access networks which use RA. As this thread has drifted off topic any way, would it for instance be a good idea to simply not accept mail from hosts that clearly use autoconfig ie reject all smtp from EUI-64 addresses. Of course not a wise idea for your own outbound relays which should handle mail from your customers but on the incoming side it might as well save a lot of headache and there is no need to keep track of which /64 are access networks. Just a few cents, MarcoH From jeffm at iglou.com Mon Oct 12 14:26:28 2009 From: jeffm at iglou.com (Jeff McAdams) Date: Mon, 12 Oct 2009 15:26:28 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD3576A.10203@rollernet.us> References: <4AD3576A.10203@rollernet.us> Message-ID: <4AD382E4.9010901@iglou.com> Seth Mattinen wrote: > If you are interested, I don't want to spam the list with my Verizon > horror story, but you can read it here: > http://www.rollernet.us/wordpress/category/ipv6/ At the risk of sounding like I'm piling on, I'm in the same basically the same boat that Seth is, except that I do know who my account rep is and have been in touch with him. Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon. I've been told that Verizon is discussing this policy and whether it should be updated, but until they update their policy to be in line with the IPv6 Internet allocation/assignment policies from at least September of 2006 (when ARIN assigned their first /48 from 2620:0::/23), if your announcements are only longer than /32, you should be aware that Verizon is completely unreachable for you - even if you are a Verizon customer directly. -- Jeff McAdams From jeroen at unfix.org Mon Oct 12 14:40:57 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 12 Oct 2009 21:40:57 +0200 Subject: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) In-Reply-To: <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> <4AD37FF8.2010303@brightok.net> <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> Message-ID: <4AD38649.2030009@spaghetti.zurich.ibm.com> Marco Hogewoning wrote: [..] > As this thread has drifted off topic any way, would it for instance be a > good idea to simply not accept mail from hosts that clearly use > autoconfig ie reject all smtp from EUI-64 addresses Can you please *NOT* suggest people *STUPID* ideas like filtering on arbitrary bits inside an address!? Thank you. I hope that you realize that stupid people will use these kind of practices and then "forget" to update them when they are actually realize that they are just that: stupid. Just a note: it is very useful to be able to just throw boxes in an ethernet, bootp them and assign them a function. This is how most large scale ISPs work, maybe no yours but there are lots that do. Assigning addresses using a stateless method like RA is suddenly a god-given. Of course if you do not want to receive mail from anybody, just don't use the Internet. > Of course not a > wise idea for your own outbound relays which should handle mail from > your customers but on the incoming side it might as well save a lot of > headache and there is no need to keep track of which /64 are access > networks. Just use a *DYNAMIC* RBL, aka one which updates, aka the same system as currently in use on IPv4. These will most likely start blocking per /64, and when reaching a certain amount of /64s /48, will block the /48 and when reaching a certain amount of /48s per /32 just block out the whole /32. Of course other current "IPv4" practices for fending of botted hosts include: - require a valid and correct SMTP conversation - require HELO/EHLO + that the given hostname properly forward + reverses and matches the host that is connecting (this simple check cuts out most botted hosts) - Score sending hosts and message based on RBL and message content (aka use spamassassin and keep your rules up to date) For IPv6 nothing changes, the only thing that might change is that RBLs will take above policy, aggregating their prefixes to avoid hosts that swap addresses inside a /64, /48 or even a complete /32 to spam the world. This is also a good thing, because ISPs who keep their network clean will not go into the RBL, just like in IPv4. or in postfix config something like: 8<---------------------------------------------------------------------- smtpd_data_restrictions = reject_unauth_pipelining smtpd_recipient_restrictions = reject_unauth_pipelining, reject_unknown_recipient_domain, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_recipient_maps smtpd_sender_restrictions = reject_unknown_sender_domain, reject_unauth_pipelining, permit_mynetworks smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_unknown_hostname, reject_invalid_hostname, reject_unauth_pipelining smtpd_helo_required = yes smtpd_client_restrictions = permit_mynetworks ---------------------------------------------------------------------->8 Problem solved. Happy internetting.... Greets, Jeroen (Who indeed is not calling Marco stupid, as he is one of those people who is not stupid, he sometimes just has a wrong idea, just like me ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From mleber at he.net Mon Oct 12 14:41:15 2009 From: mleber at he.net (Mike Leber) Date: Mon, 12 Oct 2009 12:41:15 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: Message-ID: <4AD3865B.8010908@he.net> Igor Ybema wrote: > I recently noticed that there seems a peering issue on the ipv6 internet. > As we all know hurricane is currently the largest ipv6 carrier. Other large > carriers are now implementing ipv6 on their networks, like Cogent and Telia. > > However, due to some politics it seems that they are not peering with each > other resulting in a broken ipv6 internet currently. I noticed this by using > the looking glasses from telia and hurricane. I'll spell it out for your entertainment. Hurricane aggressively tries to solve connectivity problems, IPv4 or IPv6. In the case of Cogent, they hilariously are trying to reduce peering with Hurricane over time. Hurricane has IPv4 peering with Cogent. Years ago this was at four locations in the world, then this was at three locations in the world, then two locations in the world. Why? Because over time when a BGP session would go down for longer than 30 seconds, Cogent permanently shut the session. Both Cogent and Hurricane have progressively lowered the local preference and otherwise filtered the routes we receive from each other to prevent the connections from saturating due to the size of our networks and the number of prefixes we each announce. These connections were a combination of OC12s in the US and public peering in Europe. Hurricane repeatedly over the years has pushed to replace the OC12s with atleast giges (if not 10GE), on the principle it would be cheaper, conform to more of the hardware each of us uses, allow us to remove legacy OC12 cards from the network, etc. Cogent hasn't. Why? Because even though they are content heavy and due to the routing tables one might infer they don't have settlement free peering with all networks, they don't want to help Hurricane in any way. Ok, fine. Not everybody choses to operate their network this way, usually most are more concerned about their customers, however hey who am I to say whatever they view as their core mission isn't being met. If you've been around long enough, you'd know that normally nobody talks about peering publicly like this. Most of the core network operators here could just infer what I told you above. Then why would I write this post? Because I want to set the record straight regarding Hurricane Electric's IPv6 peering goals, and nothing in Cogent's case seems to get through to them. Oh, BTW, let me describe the special case of irony. If Cogent wanted to ensure they weren't in a subservient role in IPv6 as they are for IPv4 (and I'm not talking about Hurricane, I'm talking about all the networks they've ever had to pay or fight in one way or another), then they would be working to have a complete IPv6 table by working with a player like Hurricane which reduces their dependency on networks that will be difficult with them, that is: be cooperative with them rather than give them a huge amount of crap and try to torture them at each turn (i.e. in order to get "peering" you need to buy these local loops, etc etc etc). BTW, regarding the comments about 6to4, with Hurricane Electric you will reach more of the IPv6 Internet, with lower latency than anybody else. > I already asked hurricane about their point of view. They simply just ignore > it because they 'are the biggest one'. We don't ignore comments about connectivity, in fact quite the opposite. We study each AS and which ASes are behind them. We work on getting peering with the specific AS, in the case that they are unresponsive, getting the ASes behind them. Among the things we do to discuss peering: send email to any relevant contacts, call them, contact them on IRC, send people to the relevant conferences to seek them out specifically, send people to their offices, etc. So far we stop short of baking cakes, but hey... Our goal is to provide as much connectivity to as many people as possible. That might be our goal, however, not everybody's goal on the Internet is to provide as much connectivity as possible for their customers. Mike. From michael at linuxmagic.com Mon Oct 12 14:43:42 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 12 Oct 2009 12:43:42 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <20091012182847.GI5163@dan.olp.net> References: <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> Message-ID: <200910121243.42796.michael@linuxmagic.com> On October 12, 2009, Dan White wrote: > Reputation lists will just be on the /64, /56 and /48 boundaries, rather > than IPv4 /32. > IF Network Operators started advertising and routing /64 addresses, and assuming there were email servers our there running MX records on IPv6, http://eng.genius.com/blog/2009/09/14/email-on-ipv6/ for the spammers to send too, they would quickly adopt the idea of large blocks of IPv6 Addresses. If you had to apply reputation to them individually, it would make a much larger dataset to maintain. If you look at for instance the number of IP's on RATS-DYNA and RATS-NOPTR, (examples of IP's typically representative of DUL's) they have 65 Million IP's in the database at /32 IPv4, just think what the numbers would be with IPv6. Spammers could in theory be using a much larger set of routable IP's to send from. Once NAT is out, it opens a huge can of worms to detect and maintain the size of databases that would be needed to reflect this new space. With 18,446,744,073,709,551,616 compared to 4,294,967,296 anyone who is trying to build an effecient way to gather and store reputation, has their work cut out for them. Currently, maintaining the reputation of the IPv4 space is feasible, however once we reach IPv6 numbers, it would almost require a model of registering IP's for certain uses. We have enough trouble getting current providers to even have whois delgation, of who is using what part of their IPv4 spaces, I don't expect it to get any easier with IPv6. Imagine the size of ACL lists? -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From marcoh at marcoh.net Mon Oct 12 14:48:53 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 12 Oct 2009 21:48:53 +0200 Subject: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) In-Reply-To: <4AD38649.2030009@spaghetti.zurich.ibm.com> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> <4AD37FF8.2010303@brightok.net> <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> <4AD38649.2030009@spaghetti.zurich.ibm.com> Message-ID: <7386844D-6D28-413A-9E66-FD7E322E54DA@marcoh.net> On Oct 12, 2009, at 9:40 PM, Jeroen Massar wrote: > Marco Hogewoning wrote: > [..] >> As this thread has drifted off topic any way, would it for instance >> be a >> good idea to simply not accept mail from hosts that clearly use >> autoconfig ie reject all smtp from EUI-64 addresses > > Can you please *NOT* suggest people *STUPID* ideas like filtering on > arbitrary bits inside an address!? Thank you. I was just testing out how others feel about this... > (Who indeed is not calling Marco stupid, as he is one of those people > who is not stupid, he sometimes just has a wrong idea, just like > me ;) Just testing the waters, the solution you suggested is more practical but you know as well as i do that there are those people out there who just filter out any inetnum object which matches *dsl* or *dhcp* which is about the same. MarcoH From jeroen at unfix.org Mon Oct 12 15:15:41 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 12 Oct 2009 22:15:41 +0200 Subject: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) In-Reply-To: <7386844D-6D28-413A-9E66-FD7E322E54DA@marcoh.net> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> <4AD37FF8.2010303@brightok.net> <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> <4AD38649.2030009@spaghetti.zurich.ibm.com> <7386844D-6D28-413A-9E66-FD7E322E54DA@marcoh.net> Message-ID: <4AD38E6D.8000600@spaghetti.zurich.ibm.com> Marco Hogewoning wrote: > > On Oct 12, 2009, at 9:40 PM, Jeroen Massar wrote: > >> Marco Hogewoning wrote: >> [..] >>> As this thread has drifted off topic any way, would it for instance be a >>> good idea to simply not accept mail from hosts that clearly use >>> autoconfig ie reject all smtp from EUI-64 addresses >> >> Can you please *NOT* suggest people *STUPID* ideas like filtering on >> arbitrary bits inside an address!? Thank you. > > I was just testing out how others feel about this... > >> (Who indeed is not calling Marco stupid, as he is one of those people >> who is not stupid, he sometimes just has a wrong idea, just like me ;) > > Just testing the waters, the solution you suggested is more practical > but you know as well as i do that there are those people out there who > just filter out any inetnum object which matches *dsl* or *dhcp* which > is about the same. Well, that is simply because some people are stupid ;) Greets, Jeroen (Who now hopes these couple of messages are properly archived so that if stupid people at least google they don't fall into the above pitfulls). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From ben at cuckoo.org Mon Oct 12 15:38:10 2009 From: ben at cuckoo.org (Ben White) Date: Mon, 12 Oct 2009 21:38:10 +0100 Subject: .se disappeared? Message-ID: Does anyone else also see trouble reaching .se domains at the moment? -- Ben From michael at staff.openaccess.org Mon Oct 12 15:41:20 2009 From: michael at staff.openaccess.org (Michael DeMan (OA)) Date: Mon, 12 Oct 2009 13:41:20 -0700 Subject: .se disappeared? In-Reply-To: References: Message-ID: <9381707E-1927-4827-9CE1-CB182CF80865@staff.openaccess.org> Yes. On Oct 12, 2009, at 1:38 PM, Ben White wrote: > Does anyone else also see trouble reaching .se domains at the moment? > > -- > Ben > > From bortzmeyer at nic.fr Mon Oct 12 15:42:19 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 12 Oct 2009 22:42:19 +0200 Subject: .se disappeared? In-Reply-To: References: Message-ID: <20091012204219.GA10393@nic.fr> On Mon, Oct 12, 2009 at 09:38:10PM +0100, Ben White wrote a message of 4 lines which said: > Does anyone else also see trouble reaching .se domains at the moment? It fails for me through an Unbound resolver but works with a BIND one. Certainly a DNSSEC glitch but I did not find which one yet. Or if the fault is on my side or not. From amar at telia.net Mon Oct 12 15:42:16 2009 From: amar at telia.net (Amar) Date: Mon, 12 Oct 2009 22:42:16 +0200 Subject: .se disappeared? In-Reply-To: References: Message-ID: <4AD394A8.2080200@telia.net> Ben White skrev: > Does anyone else also see trouble reaching .se domains at the moment? > Trailing dot misstake in dns as it looks like. People are working on it as we speak. -- amar From m.hallgren at free.fr Mon Oct 12 15:42:33 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 12 Oct 2009 22:42:33 +0200 Subject: .se disappeared? In-Reply-To: References: Message-ID: <1255380153.29169.16.camel@home> Le lundi 12 octobre 2009 ? 21:38 +0100, Ben White a ?crit : > Does anyone else also see trouble reaching .se domains at the moment? No, at least not all (from a French viewpoint). Which ones? mh > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nick at foobar.org Mon Oct 12 15:43:55 2009 From: nick at foobar.org (Nick Hilliard) Date: Mon, 12 Oct 2009 21:43:55 +0100 Subject: .se disappeared? In-Reply-To: References: Message-ID: <4AD3950B.3060100@foobar.org> On 12/10/2009 21:38, Ben White wrote: > Does anyone else also see trouble reaching .se domains at the moment? it would appear that someone may have left out the trailing dot on ".se.". Dig is returning: se. 172800 IN NS h.ns.se.se. se. 172800 IN NS i.ns.se.se. se. 172800 IN NS e.ns.se.se. se. 172800 IN NS a.ns.se.se. se. 172800 IN NS d.ns.se.se. se. 172800 IN NS j.ns.se.se. se. 172800 IN NS b.ns.se.se. se. 172800 IN NS c.ns.se.se. se. 172800 IN NS g.ns.se.se. se. 172800 IN NS f.ns.se.se. However, a dig at the root servers returns: se. 172800 IN NS F.NS.se. se. 172800 IN NS C.NS.se. se. 172800 IN NS J.NS.se. se. 172800 IN NS I.NS.se. se. 172800 IN NS H.NS.se. se. 172800 IN NS E.NS.se. se. 172800 IN NS G.NS.se. se. 172800 IN NS D.NS.se. se. 172800 IN NS A.NS.se. se. 172800 IN NS B.NS.se. Ouch. Nick From james at now.ie Mon Oct 12 15:48:35 2009 From: james at now.ie (James Raftery) Date: Mon, 12 Oct 2009 21:48:35 +0100 Subject: .se disappeared? In-Reply-To: <20091012204219.GA10393@nic.fr> References: <20091012204219.GA10393@nic.fr> Message-ID: On 12 Oct 2009, at 21:42, Stephane Bortzmeyer wrote: > > It fails for me through an Unbound resolver but works with a BIND > one. Certainly a DNSSEC glitch but I did not find which one yet. Or if > the fault is on my side or not. I don't think so: ; <<>> DiG 9.4.2-P2 <<>> @192.36.133.107 se ns +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18046 ;; flags: qr aa; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;se. IN NS ;; ANSWER SECTION: se. 172800 IN NS d.ns.se.se. se. 172800 IN NS e.ns.se.se. se. 172800 IN NS f.ns.se.se. se. 172800 IN NS g.ns.se.se. se. 172800 IN NS h.ns.se.se. se. 172800 IN NS i.ns.se.se. se. 172800 IN NS j.ns.se.se. se. 172800 IN NS a.ns.se.se. se. 172800 IN NS b.ns.se.se. se. 172800 IN NS c.ns.se.se. ;; Query time: 46 msec ;; SERVER: 192.36.133.107#53(192.36.133.107) ;; WHEN: Mon Oct 12 21:44:09 2009 ;; MSG SIZE rcvd: 186 -- Time flies like an arrow. Fruit flies like bananas. From swmike at swm.pp.se Mon Oct 12 15:56:18 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 12 Oct 2009 22:56:18 +0200 (CEST) Subject: .se disappeared? In-Reply-To: References: <20091012204219.GA10393@nic.fr> Message-ID: On Mon, 12 Oct 2009, James Raftery wrote: > > On 12 Oct 2009, at 21:42, Stephane Bortzmeyer wrote: >> >> It fails for me through an Unbound resolver but works with a BIND >> one. Certainly a DNSSEC glitch but I did not find which one yet. Or if >> the fault is on my side or not. > > I don't think so: All .se cctld-servers are now updated, so if you're still seeing problems, please reload your resolvers. -- Mikael Abrahamsson email: swmike at swm.pp.se From repstein at chello.at Mon Oct 12 15:56:36 2009 From: repstein at chello.at (Randy Epstein) Date: Mon, 12 Oct 2009 16:56:36 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <4AD3865B.8010908@he.net> References: <4AD3865B.8010908@he.net> Message-ID: <01d401ca4b7e$7f98c000$7eca4000$@at> No need for me to repeat what Mike has posted. I agree 100% with him on all fronts. Mike and his team have gone out of their way to promote and support IPv6 from the very beginning and I think everyone knows this. In the past, I had some differences with Mike over legacy policies that Hurricane adopted initially, but after spending time with him and explaining those issues, he did everything in his power to correct them. I'd even say he went above and beyond everyone's expectations. I hope this issue gets resolved quickly. I've seen first hand the political issues in v4 and I really hope we don't have a repeat of this in v6. There are a handful of providers that have turned to a restrictive IPv6 policy (or "must be existing peer in v4 to peer in v6 with us") and I find it outrageous at this point in time. Cogent, get with the program. Regards, Randy From davet1 at gmail.com Mon Oct 12 16:09:33 2009 From: davet1 at gmail.com (Dave Temkin) Date: Mon, 12 Oct 2009 14:09:33 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <01d401ca4b7e$7f98c000$7eca4000$@at> References: <4AD3865B.8010908@he.net> <01d401ca4b7e$7f98c000$7eca4000$@at> Message-ID: <4AD39B0D.6030106@gmail.com> Randy Epstein wrote: > No need for me to repeat what Mike has posted. I agree 100% with him on all > fronts. Mike and his team have gone out of their way to promote and support > IPv6 from the very beginning and I think everyone knows this. In the past, > I had some differences with Mike over legacy policies that Hurricane adopted > initially, but after spending time with him and explaining those issues, he > did everything in his power to correct them. I'd even say he went above and > beyond everyone's expectations. > > I hope this issue gets resolved quickly. I've seen first hand the political > issues in v4 and I really hope we don't have a repeat of this in v6. There > are a handful of providers that have turned to a restrictive IPv6 policy (or > "must be existing peer in v4 to peer in v6 with us") and I find it > outrageous at this point in time. > > Cogent, get with the program. > > Regards, > > Randy > > > Cogent: You are absolutely insane. You are doing nothing but alienating your customers and doing a disservice to IPv6 and the internet as a whole. You are publishing AAAA records for www.cogentco.com, which means that I CANNOT reach it to even look at your looking glass. I send my prefixes to 4436, 22822, and 6939 and you are not peering with any of them. Why not peer, for FREE, with 6939? What could you possibly gain from NOT doing this? HE is NOT going to buy transit from you (nor am I). Please fix your policy. -Dave From mpetach at netflight.com Mon Oct 12 16:13:54 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 12 Oct 2009 14:13:54 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <01d401ca4b7e$7f98c000$7eca4000$@at> References: <4AD3865B.8010908@he.net> <01d401ca4b7e$7f98c000$7eca4000$@at> Message-ID: <63ac96a50910121413h7cfb938fk2847254c183fc87e@mail.gmail.com> On Mon, Oct 12, 2009 at 1:56 PM, Randy Epstein wrote: > No need for me to repeat what Mike has posted. I agree 100% with him on > all > fronts. Mike and his team have gone out of their way to promote and > support > IPv6 from the very beginning and I think everyone knows this. In the past, > I had some differences with Mike over legacy policies that Hurricane > adopted > initially, but after spending time with him and explaining those issues, he > did everything in his power to correct them. I'd even say he went above > and > beyond everyone's expectations. > > I hope this issue gets resolved quickly. I've seen first hand the > political > issues in v4 and I really hope we don't have a repeat of this in v6. There > are a handful of providers that have turned to a restrictive IPv6 policy > (or > "must be existing peer in v4 to peer in v6 with us") and I find it > outrageous at this point in time. > > Cogent, get with the program. > *shrug* If Cogent wants to isolate itself from the rest of the Internet, it's kinda their problem, right? I mean, it's their network, if they don't want to play with the rest of us, they don't have to. They just won't have much to offer their customers if they decide not to play along. There's no mandate about universal connectivity; when you buy service from a provider, you select which provider to buy from based on the breadth and scope of services you desire. There may be a huge customer base for Cogent that fears the rest of the IPv6 Internet, and doesn't want to connect to it. If there's enough of a revenue stream from them to keep Cogent afloat, more power to them, I applaud them for discovering an alternative business model. I, for one, don't particularly believe in the utility of such a service, and wouldn't pay for it, but that doesn't mean there aren't a lot of frightened, paranoid people who really do want to play in a sheltered walled garden, kept apart from everyone else--and if Cogent can make a business out of servicing them, more power to them. I just wouldn't put my salary on the line banking on that business model panning out.* > Regards, > > Randy > Matt *note, however, that I also opted to stay in college in 1991, rather than join Cisco because I felt they did not have a workable business model; in 1995, I rejected Mosaic Communications, because the idea of trying to compete with a freely downloadable browser seemed like business suicide; and I rejected Google's offer letter in early 2000, because it was clear that trying to compete with altavista by trying to support a company off revenues from search advertising was completely ludicrous. Given that track record, some may take my scathing indictment of Cogent's walled garden approach to IPv6 as a clear indicator of future earnings potential. :/ From marcoh at marcoh.net Mon Oct 12 16:15:02 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 12 Oct 2009 23:15:02 +0200 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <4AD39B0D.6030106@gmail.com> References: <4AD3865B.8010908@he.net> <01d401ca4b7e$7f98c000$7eca4000$@at> <4AD39B0D.6030106@gmail.com> Message-ID: <6BFDC9C5-2AC5-4E0B-832E-E8149FD65CE7@marcoh.net> > Cogent: You are absolutely insane. You are doing nothing but > alienating your customers and doing a disservice to IPv6 and the > internet as a whole. > > You are publishing AAAA records for www.cogentco.com, which means > that I CANNOT reach it to even look at your looking glass. I send > my prefixes to 4436, 22822, and 6939 and you are not peering with > any of them. Why not peer, for FREE, with 6939? What could you > possibly gain from NOT doing this? HE is NOT going to buy transit > from you (nor am I). Please fix your policy. May I suggest to vote with your feet and take your business somewhere else. They obviously are not interested in you, your traffic or your money. MarcoH From davet1 at gmail.com Mon Oct 12 16:16:46 2009 From: davet1 at gmail.com (Dave Temkin) Date: Mon, 12 Oct 2009 14:16:46 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <6BFDC9C5-2AC5-4E0B-832E-E8149FD65CE7@marcoh.net> References: <4AD3865B.8010908@he.net> <01d401ca4b7e$7f98c000$7eca4000$@at> <4AD39B0D.6030106@gmail.com> <6BFDC9C5-2AC5-4E0B-832E-E8149FD65CE7@marcoh.net> Message-ID: <4AD39CBE.8090709@gmail.com> Marco Hogewoning wrote: >> Cogent: You are absolutely insane. You are doing nothing but >> alienating your customers and doing a disservice to IPv6 and the >> internet as a whole. >> >> You are publishing AAAA records for www.cogentco.com, which means >> that I CANNOT reach it to even look at your looking glass. I send my >> prefixes to 4436, 22822, and 6939 and you are not peering with any of >> them. Why not peer, for FREE, with 6939? What could you possibly >> gain from NOT doing this? HE is NOT going to buy transit from you >> (nor am I). Please fix your policy. > > > May I suggest to vote with your feet and take your business somewhere > else. They obviously are not interested in you, your traffic or your > money. > > MarcoH > Already done. All they are doing is continuing to provide fodder for engineers to tell their bosses why to NOT consider 174 transit when it's brought up. -Dave From charles at thewybles.com Mon Oct 12 16:18:23 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 12 Oct 2009 14:18:23 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <63ac96a50910121413h7cfb938fk2847254c183fc87e@mail.gmail.com> References: <4AD3865B.8010908@he.net> <01d401ca4b7e$7f98c000$7eca4000$@at> <63ac96a50910121413h7cfb938fk2847254c183fc87e@mail.gmail.com> Message-ID: <4AD39D1F.3000905@thewybles.com> > Matt > > *note, however, that I also opted to stay in college in 1991, rather than > join Cisco because I felt they did not have a workable business model; > in 1995, I rejected Mosaic Communications, because the idea of trying > to compete with a freely downloadable browser seemed like business > suicide; and I rejected Google's offer letter in early 2000, because it > was clear that trying to compete with altavista by trying to support a > company off revenues from search advertising was completely ludicrous. > Given that track record, some may take my scathing indictment of > Cogent's walled garden approach to IPv6 as a clear indicator of future > earnings potential. :/ *rofl* *cries* That was good! From randy at psg.com Mon Oct 12 16:23:46 2009 From: randy at psg.com (Randy Bush) Date: Mon, 12 Oct 2009 14:23:46 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> Message-ID: >> sure would be nice if there was a diagnosis before the lynching > If this happened in v4, would customers care 'why' it happened? > Obviously not. > Why should v6 be any different? It either is or is not production > ready. I'm interested in HE's view on that. many of us are interested in diagnosis. few in your lynch rope. randy From brandon.galbraith at gmail.com Mon Oct 12 16:27:49 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 12 Oct 2009 14:27:49 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <4AD39CBE.8090709@gmail.com> References: <4AD3865B.8010908@he.net> <01d401ca4b7e$7f98c000$7eca4000$@at> <4AD39B0D.6030106@gmail.com> <6BFDC9C5-2AC5-4E0B-832E-E8149FD65CE7@marcoh.net> <4AD39CBE.8090709@gmail.com> Message-ID: <366100670910121427j6b47bc43td21ec8dfeecc19a6@mail.gmail.com> Funny enough, we've been looking at moving from 174 to HE for a large amount of traffic, and this discussion is making the decision *a lot* easier. On 10/12/09, Dave Temkin wrote: > Marco Hogewoning wrote: >>> Cogent: You are absolutely insane. You are doing nothing but >>> alienating your customers and doing a disservice to IPv6 and the >>> internet as a whole. >>> >>> You are publishing AAAA records for www.cogentco.com, which means >>> that I CANNOT reach it to even look at your looking glass. I send my >>> prefixes to 4436, 22822, and 6939 and you are not peering with any of >>> them. Why not peer, for FREE, with 6939? What could you possibly >>> gain from NOT doing this? HE is NOT going to buy transit from you >>> (nor am I). Please fix your policy. >> >> >> May I suggest to vote with your feet and take your business somewhere >> else. They obviously are not interested in you, your traffic or your >> money. >> >> MarcoH >> > Already done. All they are doing is continuing to provide fodder for > engineers to tell their bosses why to NOT consider 174 transit when it's > brought up. > > -Dave > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From steve at ibctech.ca Mon Oct 12 16:33:21 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 12 Oct 2009 17:33:21 -0400 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> Message-ID: <4AD3A0A1.9080005@ibctech.ca> Randy Bush wrote: >>> sure would be nice if there was a diagnosis before the lynching >> If this happened in v4, would customers care 'why' it happened? >> Obviously not. >> Why should v6 be any different? It either is or is not production >> ready. I'm interested in HE's view on that. > > many of us are interested in diagnosis. few in your lynch rope. What Randy has been *hinting* at is largely relevant... I'm a /32 holder, with clients that have /48. I would appreciate some of the diagnostic paperwork that has been written... Steve ps. I'm not choosing sides in any way, nor do I want to start a flame, but HE has been exceptionally helpful v6-wise since I got into the game. From sethm at rollernet.us Mon Oct 12 16:44:58 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 14:44:58 -0700 Subject: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) In-Reply-To: <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> <4AD37FF8.2010303@brightok.net> <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> Message-ID: <4AD3A35A.9070307@rollernet.us> Marco Hogewoning wrote: > > As this thread has drifted off topic any way, would it for instance be a > good idea to simply not accept mail from hosts that clearly use > autoconfig ie reject all smtp from EUI-64 addresses. Of course not a > wise idea for your own outbound relays which should handle mail from > your customers but on the incoming side it might as well save a lot of > headache and there is no need to keep track of which /64 are access > networks. > That would be really, really bad. My 3750's won't accept arbitrary /128's in an ACL unless it's EUI-64 or I make up something similar that it will like. I'm sure I'm not the only person who owns a 3750. As such, my mail servers are using EUI-64 addresses. ~Seth From list+nanog at hauke-lampe.de Mon Oct 12 17:23:46 2009 From: list+nanog at hauke-lampe.de (Hauke Lampe) Date: Tue, 13 Oct 2009 00:23:46 +0200 Subject: .se disappeared? In-Reply-To: References: <20091012204219.GA10393@nic.fr> Message-ID: <4AD3AC72.1080807@hauke-lampe.de> Mikael Abrahamsson wrote: > All .se cctld-servers are now updated, so if you're still seeing > problems, please reload your resolvers. Even after a cache reload, the SOA record appears still bogus: | se has SOA record catcher-in-the-rye.nic.se. registry-default.nic.se. 2009101211 1800 1800 2419200 7200 (BOGUS (security failure)) even though other records are unaffected: | se has NS record a.ns.se. (secure) BIND logs a failure but returns an answer without AD flag: | named[2843]: validating @0xb50c0030: se SOA: no valid signature found ~$ dig +dnssec -t mx se ; <<>> DiG 9.7.0a3 <<>> +dnssec -t mx se ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55359 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 [...] Unbound returns SERVFAIL instead. I don't quite understand why BIND doesn't so, too. Hauke. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From marka at isc.org Mon Oct 12 17:40:47 2009 From: marka at isc.org (Mark Andrews) Date: Tue, 13 Oct 2009 09:40:47 +1100 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: Your message of "Mon, 12 Oct 2009 15:26:28 EDT." <4AD382E4.9010901@iglou.com> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> Message-ID: <200910122240.n9CMel2I000196@drugs.dv.isc.org> In message <4AD382E4.9010901 at iglou.com>, Jeff McAdams writes: > Seth Mattinen wrote: > > > If you are interested, I don't want to spam the list with my Verizon > > horror story, but you can read it here: > > http://www.rollernet.us/wordpress/category/ipv6/ > > At the risk of sounding like I'm piling on, I'm in the same basically > the same boat that Seth is, except that I do know who my account rep is > and have been in touch with him. > > Verizon's policy has been related to me that they will not accept or > propogate any IPv6 route advertisements with prefix lengths longer than > /32. Full stop. So that even includes those of us that have /48 PI > space from ARIN that are direct customers of Verizon. Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet. > I've been told that Verizon is discussing this policy and whether it > should be updated, but until they update their policy to be in line with > the IPv6 Internet allocation/assignment policies from at least September > of 2006 (when ARIN assigned their first /48 from 2620:0::/23), if your > announcements are only longer than /32, you should be aware that Verizon > is completely unreachable for you - even if you are a Verizon customer > directly. > > -- > Jeff McAdams > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jonny at jonnynet.net Mon Oct 12 17:54:38 2009 From: jonny at jonnynet.net (Jonny Martin) Date: Mon, 12 Oct 2009 15:54:38 -0700 Subject: APRICOT 2010 Call for Papers Message-ID: <5C571650-1E7E-4ADA-8BE5-DA096501E743@jonnynet.net> [Apologies for duplicates] Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 23 February - 5 March 2010, Kuala Lumpur, Malaysia http://www.apricot2010.net CALL FOR PAPERS =============== The APRICOT 2010 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2010. 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 proposals on-line at http://submission.apricot.net/paper/user/login.php?event=22 CONFERENCE MILESTONES --------------------- Call for Papers Opens: 12 October 2009 First Deadline for Submissions: 30 November 2009 First Draft Programme Published: 7 December 2009 Final Deadline for Submissions: 14 February 2010 Final Programme Published: 15 February 2010 Final Slides Received: 19 February 2010 PROGRAM MATERIAL ---------------- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) CFP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at http://submission.apricot.net/paper/user/login.php?event=22 Any questions or concerns should be addressed to the Programme Committee by e-mail. We look forward to receiving your presentation proposals. Jonny Martin & Philip Smith Co-Chairs, APRICOT Programme Committee program at apricot.net From bclark at spectraaccess.com Mon Oct 12 18:09:02 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 12 Oct 2009 19:09:02 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <200910122240.n9CMel2I000196@drugs.dv.isc.org> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> Message-ID: <1255388942.12984.1.camel@acer-laptop> On Tue, 2009-10-13 at 09:40 +1100, Mark Andrews wrote: > > Verizon's policy has been related to me that they will not accept > or > > propogate any IPv6 route advertisements with prefix lengths longer > than > > /32. Full stop. So that even includes those of us that have /48 > PI > > space from ARIN that are direct customers of Verizon. > > Looks like Verizon doesn't want any IPv6 customers. If a company > has idiotic policies like this vote with your wallet. Unfortunately, not everyone always has that choice. From marka at isc.org Mon Oct 12 18:24:35 2009 From: marka at isc.org (Mark Andrews) Date: Tue, 13 Oct 2009 10:24:35 +1100 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: Your message of "Mon, 12 Oct 2009 19:09:02 EDT." <1255388942.12984.1.camel@acer-laptop> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <1255388942.12984.1.camel@acer-laptop> Message-ID: <200910122324.n9CNOZp9001344@drugs.dv.isc.org> In message <1255388942.12984.1.camel at acer-laptop>, Bret Clark writes: > On Tue, 2009-10-13 at 09:40 +1100, Mark Andrews wrote: > > > > Verizon's policy has been related to me that they will not accept > > or > > > propogate any IPv6 route advertisements with prefix lengths longer > > than > > > /32. Full stop. So that even includes those of us that have /48 > > PI > > > space from ARIN that are direct customers of Verizon. > > > > Looks like Verizon doesn't want any IPv6 customers. If a company > > has idiotic policies like this vote with your wallet. > > Unfortunately, not everyone always has that choice. If there isn't as choice then regulation is required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sethm at rollernet.us Mon Oct 12 18:32:42 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 16:32:42 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <200910122240.n9CMel2I000196@drugs.dv.isc.org> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> Message-ID: <4AD3BC9A.8050802@rollernet.us> Mark Andrews wrote: > In message <4AD382E4.9010901 at iglou.com>, Jeff McAdams writes: >> Seth Mattinen wrote: >> >>> If you are interested, I don't want to spam the list with my Verizon >>> horror story, but you can read it here: >>> http://www.rollernet.us/wordpress/category/ipv6/ >> At the risk of sounding like I'm piling on, I'm in the same basically >> the same boat that Seth is, except that I do know who my account rep is >> and have been in touch with him. >> >> Verizon's policy has been related to me that they will not accept or >> propogate any IPv6 route advertisements with prefix lengths longer than >> /32. Full stop. So that even includes those of us that have /48 PI >> space from ARIN that are direct customers of Verizon. > > Looks like Verizon doesn't want any IPv6 customers. If a company > has idiotic policies like this vote with your wallet. > I am, sort of; I'm a new customer so they installed, but I haven't accepted it yet. Unfortunately I won't be able to get back to dealing with it until late next week at the earliest as I'm in the middle of moving to a new facility. ~Seth From drc at virtualized.org Mon Oct 12 18:37:44 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 12 Oct 2009 16:37:44 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <200910122240.n9CMel2I000196@drugs.dv.isc.org> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> Message-ID: Mark, On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote: >> Verizon's policy has been related to me that they will not accept or >> propogate any IPv6 route advertisements with prefix lengths longer than >> /32. Full stop. So that even includes those of us that have /48 PI >> space from ARIN that are direct customers of Verizon. > > Looks like Verizon doesn't want any IPv6 customers. If a company > has idiotic policies like this vote with your wallet. Not knowing all the details, it is difficult for me to judge, however it is worth observing that provider independent addresses, regardless of where they come from or whether they are IPv4 or IPv6 simply do not scale. In the face of everybody and their mother now being able to obtain PI prefixes from all the RIRs, any ISP that handles full routing is going to have to hope their router vendor of choice can keep buying more/bigger CAMs (passing the expense on to the ISP who will pass it on to their customers) and/or they'll start implementing the same sort of prefix length limitations that we saw back in the mid-90s. And, of course, we have IPv4 runout in the near future with the inevitable market which will almost certainly promote the use of longer prefixes. In other words, get used to it. Regards, -drc From nanog at daork.net Mon Oct 12 18:39:18 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 13 Oct 2009 12:39:18 +1300 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD382E4.9010901@iglou.com> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> Message-ID: On 13/10/2009, at 8:26, Jeff McAdams wrote: > Verizon's policy has been related to me that they will not accept or > propogate any IPv6 route advertisements with prefix lengths longer > than /32. Full stop. So that even includes those of us that have / > 48 PI space from ARIN that are direct customers of Verizon. What about the small matter of all of the current AAAAs for the the IPv6 enabled root DNS servers? -- Nathan Ward From owen at delong.com Mon Oct 12 19:09:41 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Oct 2009 17:09:41 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> Message-ID: <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> On Oct 12, 2009, at 4:37 PM, David Conrad wrote: > Mark, > > On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote: >>> Verizon's policy has been related to me that they will not accept or >>> propogate any IPv6 route advertisements with prefix lengths longer >>> than >>> /32. Full stop. So that even includes those of us that have /48 PI >>> space from ARIN that are direct customers of Verizon. >> >> Looks like Verizon doesn't want any IPv6 customers. If a company >> has idiotic policies like this vote with your wallet. > > Not knowing all the details, it is difficult for me to judge, > however it is worth observing that provider independent addresses, > regardless of where they come from or whether they are IPv4 or IPv6 > simply do not scale. In the face of everybody and their mother now > being able to obtain PI prefixes from all the RIRs, any ISP that > handles full routing is going to have to hope their router vendor of > choice can keep buying more/bigger CAMs (passing the expense on to > the ISP who will pass it on to their customers) and/or they'll start > implementing the same sort of prefix length limitations that we saw > back in the mid-90s. > I disagree. With IPv4 the bigger issue is that everyone and their mom has 9 different announcements behind their single ASN. With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much closer. Even if the average drops to 1/2, you're talking about a 70,000 route table today, and, likely growth in the 250-300,000 route range over the next 5-10 years. CAM will probably scale faster than that. The problematic time scale is that time where we have to support dual stack for a majority of the network. That's what will really stress the CAM as the IPv6 table becomes meaningfully large (but not huge) and the IPv4 table cannot yet be retired. > And, of course, we have IPv4 runout in the near future with the > inevitable market which will almost certainly promote the use of > longer prefixes. > There is that problem, too. Personally, I think the market was a horrible idea, but, it had way too much momentum for me to be able to stop it. > In other words, get used to it. > Pretty much. I think eventually, we're going to have to look at moving to an ID/Locator split method in the IDR realm. Owen From owen at delong.com Mon Oct 12 19:16:48 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Oct 2009 17:16:48 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> Message-ID: From where I sit, it looks like: a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 BGP routing table entry for 2001:503:ba3e::/48 f.root-servers.net has IPv6 address 2001:500:2f::f BGP routing table entry for 2001:500:2f::/48 h.root-servers.net has IPv6 address 2001:500:1::803f:235 BGP routing table entry for 2001:500:1::/48 j.root-servers.net has IPv6 address 2001:503:c27::2:30 BGP routing table entry for 2001:503:c27::/48 k.root-servers.net has IPv6 address 2001:7fd::1 BGP routing table entry for 2001:7fd::/32 l.root-servers.net has IPv6 address 2001:500:3::42 BGP routing table entry for 2001:500:3::/48 m.root-servers.net has IPv6 address 2001:dc3::35 BGP routing table entry for 2001:dc3::/32 b.root-servers.net has no AAAA record c.root-servers.net has no AAAA record d.root-servers.net has no AAAA record e.root-servers.net has no AAAA record g.root-servers.net has no AAAA record i.root-servers.net has no AAAA record So... Likely, Verizon customers can reach k and m root servers via IPv6 and not the others. The fact that b, c, d, e, g, and i do not have AAAA records actually concerns me more than the fact that Verizon customers can only reach two. Owen On Oct 12, 2009, at 4:39 PM, Nathan Ward wrote: > On 13/10/2009, at 8:26, Jeff McAdams wrote: > >> Verizon's policy has been related to me that they will not accept >> or propogate any IPv6 route advertisements with prefix lengths >> longer than /32. Full stop. So that even includes those of us >> that have /48 PI space from ARIN that are direct customers of >> Verizon. > > What about the small matter of all of the current AAAAs for the the > IPv6 enabled root DNS servers? > > -- > Nathan Ward From drc at virtualized.org Mon Oct 12 19:40:36 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 12 Oct 2009 17:40:36 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> Message-ID: <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> Owen, On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote: > With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much closer. I wasn't aware people would be doing traffic engineering differently in IPv6 than in IPv4. > Even if the average drops to 1/2, you're talking about a 70,000 route table today, How big are IPv6 objects in CAMs again? > and, likely growth in the 250-300,000 route range over the next 5-10 years. > CAM will probably scale faster than that. I've heard differing opinions on this (e.g., router ASICs being both some of the most complicated ASICs ever made and being non-commodity parts hence not necessarily following Moore's Law, pin density in those ASICs reaching a point where you start running into crosstalk problems, cats and dogs living together, mass hysteria, etc). I'm not a hardware guy so I'll just stare blankly. > The problematic time scale is that time where we have to support dual stack for a majority of the network. That's what will > really stress the CAM as the IPv6 table becomes meaningfully large (but not huge) and the IPv4 table cannot yet be > retired. Right. And when are we planning on retiring IPv4 again? Interestingly, if you're an ISP and you don't want to redeploy your insanely expensive high end routers with the huge CAMs, you might look to see which prefixes you could drop that would cause the least impact to the majority of your customers. In this light, filtering the crap out of IPv6 would appear to make business sense. > I think eventually, we're going to have to look at moving to an ID/Locator split method in the IDR realm. The big challenge with this is backwards compatibility... Regards, -drc From morrowc.lists at gmail.com Mon Oct 12 20:11:51 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Oct 2009 21:11:51 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> Message-ID: <75cb24520910121811r195d5913r3045f8d8a4a80206@mail.gmail.com> On Mon, Oct 12, 2009 at 8:16 PM, Owen DeLong wrote: > From where I sit, it looks like: ..snip.. > So... Likely, Verizon customers can reach k and m root servers via IPv6 > and not the others. or.. vzb (is now dead, it's all vz) has holes in filters to permit prefixes of certain lengths or certain prefixes exactly. I believe since I can reach k-root from my uu-connected + uu-v6'd device that'd be the case. -chris From morrowc.lists at gmail.com Mon Oct 12 20:15:00 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Oct 2009 21:15:00 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> Message-ID: <75cb24520910121815h41cf430aw492556400b872524@mail.gmail.com> On Mon, Oct 12, 2009 at 8:40 PM, David Conrad wrote: > On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote: >> and, likely growth in the 250-300,000 route range over the next 5-10 years. >> CAM will probably scale faster than that. > > I've heard differing opinions on this (e.g., router ASICs being both some of the most complicated > ASICs ever made and being non-commodity parts hence not necessarily following Moore's Law, > pin density in those ASICs reaching a point where you start running into crosstalk problems, > cats and dogs living together, mass hysteria, etc). ?I'm not a hardware guy so I'll just stare > blankly. I thought Tony's preso from RAWS was available or part of the report, no? (which seemed pretty clear to me about cam sizes and asic capabilities not going to meet the needs within the next 5-7 years) -chris From sethm at rollernet.us Mon Oct 12 20:22:10 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 18:22:10 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> Message-ID: <4AD3D642.10903@rollernet.us> Owen DeLong wrote: > From where I sit, it looks like: > > a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 > BGP routing table entry for 2001:503:ba3e::/48 > > f.root-servers.net has IPv6 address 2001:500:2f::f > BGP routing table entry for 2001:500:2f::/48 > > h.root-servers.net has IPv6 address 2001:500:1::803f:235 > BGP routing table entry for 2001:500:1::/48 > > j.root-servers.net has IPv6 address 2001:503:c27::2:30 > BGP routing table entry for 2001:503:c27::/48 > > k.root-servers.net has IPv6 address 2001:7fd::1 > BGP routing table entry for 2001:7fd::/32 > > l.root-servers.net has IPv6 address 2001:500:3::42 > BGP routing table entry for 2001:500:3::/48 > > m.root-servers.net has IPv6 address 2001:dc3::35 > BGP routing table entry for 2001:dc3::/32 > > > b.root-servers.net has no AAAA record > c.root-servers.net has no AAAA record > d.root-servers.net has no AAAA record > e.root-servers.net has no AAAA record > g.root-servers.net has no AAAA record > i.root-servers.net has no AAAA record > > > So... Likely, Verizon customers can reach k and m root servers via IPv6 > and not the others. > I can see the /48's out of 2001 in Verizon's table. ~Seth From jeffm at iglou.com Mon Oct 12 20:24:17 2009 From: jeffm at iglou.com (Jeff McAdams) Date: Mon, 12 Oct 2009 21:24:17 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> Message-ID: <4AD3D6C1.3000003@iglou.com> Owen DeLong wrote: > From where I sit, it looks like: > > a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 > BGP routing table entry for 2001:503:ba3e::/48 > > f.root-servers.net has IPv6 address 2001:500:2f::f > BGP routing table entry for 2001:500:2f::/48 > > h.root-servers.net has IPv6 address 2001:500:1::803f:235 > BGP routing table entry for 2001:500:1::/48 > > j.root-servers.net has IPv6 address 2001:503:c27::2:30 > BGP routing table entry for 2001:503:c27::/48 > > k.root-servers.net has IPv6 address 2001:7fd::1 > BGP routing table entry for 2001:7fd::/32 > > l.root-servers.net has IPv6 address 2001:500:3::42 > BGP routing table entry for 2001:500:3::/48 > > m.root-servers.net has IPv6 address 2001:dc3::35 > BGP routing table entry for 2001:dc3::/32 > So... Likely, Verizon customers can reach k and m root servers via IPv6 > and not the others. I can see all of those through Verizon, so I'm not sure of how their policy applies, or if they're making an exception for these, but they are visible through Verizon. -- Jeff McAdams jeffm at iglou.com From jeffm at iglou.com Mon Oct 12 20:48:49 2009 From: jeffm at iglou.com (Jeff McAdams) Date: Mon, 12 Oct 2009 21:48:49 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> Message-ID: <4AD3DC81.30701@iglou.com> David Conrad wrote: > On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote: >>> Verizon's policy has been related to me that they will not accept >>> or propogate any IPv6 route advertisements with prefix lengths >>> longer than /32. Full stop. So that even includes those of us >>> that have /48 PI space from ARIN that are direct customers of >>> Verizon. >> Looks like Verizon doesn't want any IPv6 customers. If a company >> has idiotic policies like this vote with your wallet. > Not knowing all the details, it is difficult for me to judge, however > it is worth observing that provider independent addresses, regardless > of where they come from or whether they are IPv4 or IPv6 simply do > not scale. In the face of everybody and their mother now being able > to obtain PI prefixes from all the RIRs, any ISP that handles full > routing is going to have to hope their router vendor of choice can > keep buying more/bigger CAMs (passing the expense on to the ISP who > will pass it on to their customers) and/or they'll start implementing > the same sort of prefix length limitations that we saw back in the > mid-90s. > And, of course, we have IPv4 runout in the near future with the > inevitable market which will almost certainly promote the use of > longer prefixes. And I look at the other side of it. For us "mere" end-user organization (ie, not big backbone ISPs who have dominated the discussion for so long), IPv6 without PI is an utter and complete non-starter. Despite how huge of a proponent of IPv6 deployment that I am, until PI space was available, I didn't start the work, because without PI space, its utter foolishness for a company that depends on their Internet access to move forward. I don't think its a coincidence that we've seen a big uptick in deployment of IPv6 since PI space became available. Telling end-user organizations to get a block from each upstream and multihome by putting an address from each upstream on every system is now and always has been a bad joke. > In other words, get used to it. In other words, figure it out. Either we'll have PI space in IPv6, or IPv4 is going to get *crazy* fragmented as continually smaller blocks are bought and sold. If you want to keep your cam tables from blowing up, I truly think the way forward is to get people to IPv6 as quickly as possible, where they can get blocks big enough to put all of their address space in 1 or 2 blocks, rather than the 4, 7 or more, blocks that they're currently using for IPv4. And, no, not everyone deaggregates for TE purposes. No network that I've ever been in charge of has ever advertised anything but the most aggregated blocks that we could given the allocations/assignments we had. We'll have savings from that, and if you want to filter to limit deaggregating for TE purposes, I'm quite OK with that. But if you cut out PI space, you're dead in the water, we just can't have that. -- Jeff McAdams From bicknell at ufp.org Mon Oct 12 20:58:50 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 12 Oct 2009 18:58:50 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> Message-ID: <20091013015850.GA79898@ussenterprise.ufp.org> In a message written on Mon, Oct 12, 2009 at 05:09:41PM -0700, Owen DeLong wrote: > With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come > much closer. Even if the average drops to 1/2, you're > talking about a 70,000 route table today, and, likely growth in the > 250-300,000 route range over the next 5-10 years. > CAM will probably scale faster than that. Here's a presentation from 2007. http://www.vaf.net/~vaf/apricot-plenary.pdf On page 13, you'll find a table. It starts with numbers in November of 2006, and makes projections. The 5 year projections (Nov 2011) have already been exceeded, in both IPv4 Internet Routes and Active ASN's. The problem isn't that we have 300,000 "global routes" on the Internet (http://www.cidr-report.org/as2.0/#General_Status), but that there are other things that compete for TCAM space. It's that TCAM must hold not only the global routes, but also: - Internal routes. Your IGP routes, no-exported customer deagregations, blackhole routes, etc. - MPLS Labels, including: - MPLS Traffic Engineering - MPLS VPN Identifiers - Virtual Routing Instances for Layer 3 VPN's. - ARP Entries - Multicast Routes Unfortunately details are hard to come by as most of the folks who see this in any significant way (e.g. global "tier 1" full service ISP's) tend not to release too many specific numbers for competitive reasons. That said, even using some basic assumptions (some of which are in the preso) those 300,000 global routes might have added to them: 300,000 global routes 150,000 internal routes 20,000 MPLS labels 200,000 VPN/VRF Routes 5,000 ARP Entries 20,000 Multicast Routes -------- 695,000 TCAM Entries Consumed That's today, right now, in major ISP's routers. All the sudden those "1 million route" core routers don't seem so large. Keep in mind we've passed the 2006 projection in this report in 3 years, not 5. So we're growing faster than we expected. Add in your 70,000 route IPv6 table, plus growth, and the 1 million route routers are probably failing sometime in 2011. Someone will likely pipe up, but Cisco has a 3 million route processor now! (I believe that is the spec of the just announced PRP3, but can't find a reference on Cisco's web site). Yes, that's a route processor that can do the job, but in these high end boxes the TCAM is distributed on the linecards. So upgrading from the 1 million route TCAM core routers to the 3 Million route TCAM means upgrading every linecard in each router you upgrade. Ouch. The picture I painted above is actually the rosy part of the picture. Many of these backbones have older equipment in the core which can't even do 1M routes. They use careful design and other techniques to limit the number of entries particular boxes have to see. > The problematic time scale is that time where we have to support dual > stack for a majority of the network. That's what will > really stress the CAM as the IPv6 table becomes meaningfully large > (but not huge) and the IPv4 table cannot yet be > retired. While I think Verizon's move is somewhat premature, I can see why they might be afraid of routing table growth. I think there is an extremely high probability that given the growth of the table due to primarily to IPv6 and the growth of MPLS VPN offerings, combined with the current economic climate which has reduced the capital available for upgrades that we will see several providers "hit the wall" of various popular bits of equipment. I think some of the engineering staff at various major providers has already realized this as well. We don't seem to have a technological solution. LISP has scaling issues of its own, and would require swapping out a huge amount of equipment. TCAM scaling is at best cost prohibitive, at worst not possible due to the physical ram speed, and both are being improved at a modest rate (the preso suggests 10% per year). Worse, the problem is being made worse at an alarming rate. MPLS VPN's are quicky replacing frame relay, ATM, and leased line circuits adding MPLS lables and VPN/VRF routes to edge routers. Various RIR's are pushing "PI for all" in IPv6 based on addressing availbility. Some networks are actually finally using multicast for IPTV services, generating much larger number of entries than the global multicast table would otherwise indicate. The next 5 years may bring internet instability problems and route filtering on a scale we haven't seen since the early 90's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From sethm at rollernet.us Mon Oct 12 21:00:46 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 19:00:46 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> Message-ID: <4AD3DF4E.8000102@rollernet.us> I get asked often enough about what's in 701's IPv6 routes so I just dumped it to a plain text file for anyone interested: http://www.rollernet.us/wordpress/as701-ipv6/ ~Seth From sethm at rollernet.us Mon Oct 12 21:13:04 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 19:13:04 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <20091013015850.GA79898@ussenterprise.ufp.org> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20091013015850.GA79898@ussenterprise.ufp.org> Message-ID: <4AD3E230.4070404@rollernet.us> Leo Bicknell wrote: > > Worse, the problem is being made worse at an alarming rate. MPLS > VPN's are quicky replacing frame relay, ATM, and leased line circuits > adding MPLS lables and VPN/VRF routes to edge routers. Various > RIR's are pushing "PI for all" in IPv6 based on addressing availbility. > Some networks are actually finally using multicast for IPTV services, > generating much larger number of entries than the global multicast table > would otherwise indicate. > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable site multihoming. The only goal seems to have been to limit /32's to an "ISP" but screw you if you aren't one. There was no alternative and it's been how long now? PI, multihoming, multicast, etc. is reality because the internet is now Very Serious Business for many, many people. Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a debate about them, so I'll just say that if there had been a viable alternative to multihoming as we know it I think it would have been given a go before policy got pushed to the RIR's to allow IPv6 PI. ~Seth From adrian at creative.net.au Mon Oct 12 21:20:40 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 13 Oct 2009 10:20:40 +0800 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD3E230.4070404@rollernet.us> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20091013015850.GA79898@ussenterprise.ufp.org> <4AD3E230.4070404@rollernet.us> Message-ID: <20091013022040.GF8395@skywalker.creative.net.au> On Mon, Oct 12, 2009, Seth Mattinen wrote: > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. The only goal seems to have been to limit /32's to an > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. IPv6 -policy- wasn't initially designed for any workable site multihoming. The addressing and BGP stuff works fine for it. Its just not "different" to the issues faced with IPv4. adrian From morrowc.lists at gmail.com Mon Oct 12 21:22:46 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Oct 2009 22:22:46 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD3E230.4070404@rollernet.us> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20091013015850.GA79898@ussenterprise.ufp.org> <4AD3E230.4070404@rollernet.us> Message-ID: <75cb24520910121922t4f602668j1bc7f821c173805a@mail.gmail.com> On Mon, Oct 12, 2009 at 10:13 PM, Seth Mattinen wrote: > Leo Bicknell wrote: >> >> Worse, the problem is being made worse at an alarming rate. ?MPLS >> VPN's are quicky replacing frame relay, ATM, and leased line circuits >> adding MPLS lables and VPN/VRF routes to edge routers. ?Various >> RIR's are pushing "PI for all" in IPv6 based on addressing availbility. >> Some networks are actually finally using multicast for IPTV services, >> generating much larger number of entries than the global multicast table >> would otherwise indicate. >> > > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. The only goal seems to have been to limit /32's to an here's where a pointer to this dicussion of ~4yrs ago should be (on this list no less)... that said: "Hey, this is afu, if you as operators want this to work properly, please, please, please get your butts on v6ops at ietf and make some noise." I believe that'd have been from me, but marla azinger also sent out some similar emails and presented 2-3 times at past nanog meetings about multihoming options wrt ipv6. This ain't gonna get fixed by nanog-kvetching. > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. v6 was designed in an era quite different than today's network. there were a large number of assumptions made, practically none of which hold water today. this can't get fixed here, please see v6man/v6ops at ietf. Alternately please see rrg at ietf or lisp at ietf, rrg's looking to make a decision on their research 'soon', lisp is looking for active folks to provide comment/direction... > Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a there are no (save lisp) network based 'hacks' for this... shim6/hip/mip all basically do host-level multihoming, which is cool, and may be useful to some folks, but they are not useful for folks trying to do TE in the network. (which also was hashed out quite a bit on this list) > debate about them, so I'll just say that if there had been a viable > alternative to multihoming as we know it I think it would have been > given a go before policy got pushed to the RIR's to allow IPv6 PI. 100% agreement... wanna join in the discussion and offer some options/fixes/commentary? -chris From justin at justinshore.com Mon Oct 12 21:34:14 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 12 Oct 2009 21:34:14 -0500 Subject: ISP customer assignments In-Reply-To: <20091008164818.GB4984@dan.olp.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> Message-ID: <4AD3E726.80400@justinshore.com> Dan White wrote: > How are other providers approaching dial-up? I would presume we are in the > same boat as a lot of other folks - we have aging dial-up equipment that > does not support IPv6 (3com Total Control). Our customer base has dropped > quite a bit, and we have even kicked around the idea dropping that service > and forcing customers to purchase broadband service or go elsewhere. > > What are other providers doing, or considering doing? I'd like to beat this dead horse some more if you gents don't mind. I think there's still some life left in the beast before we haul it off to the glue factory. I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class. What are providers doing for residential customers and how does it different from business customers? At what point are you assigning bigger blocks? To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? Thanks Justin From bicknell at ufp.org Mon Oct 12 21:51:04 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 12 Oct 2009 19:51:04 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD3E230.4070404@rollernet.us> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20091013015850.GA79898@ussenterprise.ufp.org> <4AD3E230.4070404@rollernet.us> Message-ID: <20091013025104.GA82466@ussenterprise.ufp.org> In a message written on Mon, Oct 12, 2009 at 07:13:04PM -0700, Seth Mattinen wrote: > Leo Bicknell wrote: > > Worse, the problem is being made worse at an alarming rate. MPLS > > VPN's are quicky replacing frame relay, ATM, and leased line circuits > > adding MPLS lables and VPN/VRF routes to edge routers. Various > > RIR's are pushing "PI for all" in IPv6 based on addressing availbility. > > Some networks are actually finally using multicast for IPTV services, > > generating much larger number of entries than the global multicast table > > would otherwise indicate. > > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. The only goal seems to have been to limit /32's to an > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. I may have editorialized in a way that was not completely clear. I agree that due to lack of an alternative "PI IPv6" is necessary and effectively the only option we have right now. Were IPv6 policy to only allow those who could get IPv4 PI to get IPv6 PI I would say the problem was "the same". However, the reason I say it is being made worse is that there is a subset of the RIR community who sees the lack of scarcity of addres space as a reason to provide IPv6 PI to people who cannot qualify for IPv4 PI. My impression of the current RIR policy trends are resulting in a situation that more folks will be able to get IPv6 PI than can currently get IPv4 PI. Hence why I put that in the list of things making it worse. > Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a > debate about them, so I'll just say that if there had been a viable > alternative to multihoming as we know it I think it would have been > given a go before policy got pushed to the RIR's to allow IPv6 PI. The only idea I have seen that holds any promise is LISP. There is working code, and the idea is sound. However, like squeezing a balloon while it makes some issues better it then puts pressure in other directions. It trades off TCAM lookups for LOC/ID lookups and caching. It's not clear to me on an Internet scale system this is better; but I do hope the folks doing that work continue on the chance that it is... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dougb at dougbarton.us Mon Oct 12 21:54:38 2009 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 12 Oct 2009 19:54:38 -0700 Subject: ISP customer assignments In-Reply-To: <4AD3E726.80400@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> Message-ID: On Oct 12, 2009, at 7:34 PM, Justin Shore wrote: > I'm actually taking an IPv6 class right now and the topic of > customer assignments came up today (day 1). The instructor was > suggesting dynamically allocating /127s to residential customers. I > relayed the gist of this thread to him (/48, /56 and /64). I expect > to dive deeper into this in the following days in the class. Out of curiosity who is conducting this class and what was their rationale for using /127s? Doug From joelja at bogus.com Mon Oct 12 22:06:25 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 12 Oct 2009 20:06:25 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD3E230.4070404@rollernet.us> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20091013015850.GA79898@ussenterprise.ufp.org> <4AD3E230.4070404@rollernet.us> Message-ID: <4AD3EEB1.3080403@bogus.com> Seth Mattinen wrote: > Leo Bicknell wrote: >> Worse, the problem is being made worse at an alarming rate. MPLS >> VPN's are quicky replacing frame relay, ATM, and leased line circuits >> adding MPLS lables and VPN/VRF routes to edge routers. Various >> RIR's are pushing "PI for all" in IPv6 based on addressing availbility. >> Some networks are actually finally using multicast for IPTV services, >> generating much larger number of entries than the global multicast table >> would otherwise indicate. >> > > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. Lest anyone forget it has the same non-workable site-multihoming that has allowed the internet to grow to the size it is today. by non-working we mean not-better than ipv4. We actually know how to run that network pain and all. > The only goal seems to have been to limit /32's to an > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. > > Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a > debate about them, so I'll just say that if there had been a viable > alternative to multihoming as we know it I think it would have been > given a go before policy got pushed to the RIR's to allow IPv6 PI. > > ~Seth > From ggm at apnic.net Mon Oct 12 22:17:33 2009 From: ggm at apnic.net (George Michaelson) Date: Tue, 13 Oct 2009 13:17:33 +1000 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> Message-ID: <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> On 13/10/2009, at 12:54 PM, Doug Barton wrote: > On Oct 12, 2009, at 7:34 PM, Justin Shore > wrote: >> I'm actually taking an IPv6 class right now and the topic of >> customer assignments came up today (day 1). The instructor was >> suggesting dynamically allocating /127s to residential customers. >> I relayed the gist of this thread to him (/48, /56 and /64). I >> expect to dive deeper into this in the following days in the class. > > Out of curiosity who is conducting this class and what was their > rationale for using /127s? > > Doug As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR. I have from time to time, asked people in ACM and IEEE about how one informs the tertiary teaching community about this kind of change. The answers were not inspiring: compared to civil engineering, where compliance issues and re-training by professionals is almost regulated (sorry for the R- word) as a function of professional indemnity insurance and status, its much more common for the syllabus to be under continual review. -George From swm at emanon.com Mon Oct 12 22:32:23 2009 From: swm at emanon.com (Scott Morris) Date: Mon, 12 Oct 2009 23:32:23 -0400 Subject: ISP customer assignments In-Reply-To: <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> Message-ID: <4AD3F4C7.70103@emanon.com> I'm going to have to pull the "mixed-hat" on this one. If you are comparing this to a true "academia" environment, I'd agree with you. Too much theory, not enough reality in things. However, I've yet to see the part about where the person is being trained from. I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment. But that's a personal point of view trying to keep reality involved and be worthwhile. I'm not trying to open any sort of debate or can of worms here, but just because one is receiving training does not mean the instructor has no functional knowledge of something. I'm interested in hearing the playout on this one as well. How many addresses do you like on point-to-point circuits? Scott George Michaelson wrote: > > On 13/10/2009, at 12:54 PM, Doug Barton wrote: > >> On Oct 12, 2009, at 7:34 PM, Justin Shore >> wrote: >>> I'm actually taking an IPv6 class right now and the topic of >>> customer assignments came up today (day 1). The instructor was >>> suggesting dynamically allocating /127s to residential customers. I >>> relayed the gist of this thread to him (/48, /56 and /64). I expect >>> to dive deeper into this in the following days in the class. >> >> Out of curiosity who is conducting this class and what was their >> rationale for using /127s? >> >> Doug > > As a point of view on this, a member of staff from APNIC was doing a > Masters of IT in the last 3-4 years, and had classfull A/B/C > addressing taught to her in the networks unit. She found it quite a > struggle to convince the lecturer that reality had moved on and they > had no idea about CIDR. > > I have from time to time, asked people in ACM and IEEE about how one > informs the tertiary teaching community about this kind of change. The > answers were not inspiring: compared to civil engineering, where > compliance issues and re-training by professionals is almost regulated > (sorry for the R- word) as a function of professional indemnity > insurance and status, its much more common for the syllabus to be > under continual review. > > -George > > From newton at internode.com.au Mon Oct 12 22:52:15 2009 From: newton at internode.com.au (Mark Newton) Date: Tue, 13 Oct 2009 14:22:15 +1030 Subject: ISP customer assignments In-Reply-To: <4AD3F4C7.70103@emanon.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> Message-ID: <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> On 13/10/2009, at 2:02 PM, Scott Morris wrote: > I happen to train people at CCIE level. I also happen to do > consulting, > implementation, and design work. In my training environment, there > are > all sorts of re-thinking of what/how things are being taught even > within > the confines of comparison to a lab environment. Does the CCNA exam still ask questions about RIP and classful addressing? Just askin' :-) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From Valdis.Kletnieks at vt.edu Mon Oct 12 23:12:06 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Oct 2009 00:12:06 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: Your message of "Mon, 12 Oct 2009 17:40:36 PDT." <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> Message-ID: <14776.1255407126@turing-police.cc.vt.edu> On Mon, 12 Oct 2009 17:40:36 PDT, David Conrad said: > On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote: > > With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come > much closer. > > I wasn't aware people would be doing traffic engineering differently in > IPv6 than in IPv4. You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48. And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From adrian at creative.net.au Mon Oct 12 23:21:30 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 13 Oct 2009 12:21:30 +0800 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <14776.1255407126@turing-police.cc.vt.edu> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> <14776.1255407126@turing-police.cc.vt.edu> Message-ID: <20091013042130.GL8395@skywalker.creative.net.au> On Tue, Oct 13, 2009, Valdis.Kletnieks at vt.edu wrote: > You get some substantial wins for the non-TE case by being able to fix > the legacy cruft. For instance, AS1312 advertises 4 prefixes: > 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 > but on the IPv6 side we've just got 2001:468:c80::/48. > > And we're currently advertising *more* address space in one /48 than we > are in the 4 IPv4 prefixes - we have a large chunk of wireless network that > is currently NAT'ed into the 172.31 space because we simply ran out of room > in our 2 /16s - but we give those users globally routed IPv6 addresses. I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE. 2c, Adrian From kloch at kl.net Mon Oct 12 23:46:00 2009 From: kloch at kl.net (Kevin Loch) Date: Tue, 13 Oct 2009 00:46:00 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <20091013042130.GL8395@skywalker.creative.net.au> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> <14776.1255407126@turing-police.cc.vt.edu> <20091013042130.GL8395@skywalker.creative.net.au> Message-ID: <4AD40608.1020004@kl.net> Adrian Chadd wrote: > On Tue, Oct 13, 2009, Valdis.Kletnieks at vt.edu wrote: > >> You get some substantial wins for the non-TE case by being able to fix >> the legacy cruft. For instance, AS1312 advertises 4 prefixes: >> 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 >> but on the IPv6 side we've just got 2001:468:c80::/48. >> >> And we're currently advertising *more* address space in one /48 than we >> are in the 4 IPv4 prefixes - we have a large chunk of wireless network that >> is currently NAT'ed into the 172.31 space because we simply ran out of room >> in our 2 /16s - but we give those users globally routed IPv6 addresses. > > > I suggest you're not yet doing enough IPv6 traffic to have to care > about IPv6 TE. I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes. Speaking of TE, it's going to be interesting to see how we deal with that. We can't expect everyone to accept any /48 that gets announced. I'm still waiting for the first time someone blows up the Internet by announcing all 65536 /48's in their /32. I'm amazed it hasn't happened yet. Stricter use of the IRR might help if there wasn't rampant auto proxy registering going on. RPKI may be the answer since that can't be proxy-registered. That would at least mitigate router bugs and carelessness. The issue of what intentional TE routes are seen as "acceptable" is another issue. - Kevin From sethm at rollernet.us Mon Oct 12 23:50:07 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Oct 2009 21:50:07 -0700 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD40608.1020004@kl.net> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> <14776.1255407126@turing-police.cc.vt.edu> <20091013042130.GL8395@skywalker.creative.net.au> <4AD40608.1020004@kl.net> Message-ID: <4AD406FF.9090705@rollernet.us> Kevin Loch wrote: > Adrian Chadd wrote: >> On Tue, Oct 13, 2009, Valdis.Kletnieks at vt.edu wrote: >> >>> You get some substantial wins for the non-TE case by being able to fix >>> the legacy cruft. For instance, AS1312 advertises 4 prefixes: >>> 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 >>> but on the IPv6 side we've just got 2001:468:c80::/48. >>> >>> And we're currently advertising *more* address space in one /48 than we >>> are in the 4 IPv4 prefixes - we have a large chunk of wireless >>> network that >>> is currently NAT'ed into the 172.31 space because we simply ran out >>> of room >>> in our 2 /16s - but we give those users globally routed IPv6 addresses. >> >> >> I suggest you're not yet doing enough IPv6 traffic to have to care >> about IPv6 TE. > > I think he was pointing out that extra routes due to "slow start" > policies should not be a factor in v6. My guess is that is about > half of the "extra" routes announced today, the other half being > TE routes. > > Speaking of TE, it's going to be interesting to see how we deal with > that. We can't expect everyone to accept any /48 that gets announced. > I'm still waiting for the first time someone blows up the Internet > by announcing all 65536 /48's in their /32. I'm amazed it hasn't > happened yet. > > Stricter use of the IRR might help if there wasn't rampant auto > proxy registering going on. RPKI may be the answer since that > can't be proxy-registered. That would at least mitigate router > bugs and carelessness. The issue of what intentional TE routes > are seen as "acceptable" is another issue. > I would love to see TE die a painful death. Maybe someone announcing 65536 routes will bring it to a swift end. ~Seth From Valdis.Kletnieks at vt.edu Tue Oct 13 00:22:15 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Oct 2009 01:22:15 -0400 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: Your message of "Tue, 13 Oct 2009 00:46:00 EDT." <4AD40608.1020004@kl.net> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> <14776.1255407126@turing-police.cc.vt.edu> <20091013042130.GL8395@skywalker.creative.net.au> <4AD40608.1020004@kl.net> Message-ID: <17483.1255411335@turing-police.cc.vt.edu> On Tue, 13 Oct 2009 00:46:00 EDT, Kevin Loch said: > Adrian Chadd wrote: > > On Tue, Oct 13, 2009, Valdis.Kletnieks at vt.edu wrote: > > > >> You get some substantial wins for the non-TE case by being able to fix > >> the legacy cruft. For instance, AS1312 advertises 4 prefixes: > >> 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 > >> but on the IPv6 side we've just got 2001:468:c80::/48. > >> > >> And we're currently advertising *more* address space in one /48 than we > >> are in the 4 IPv4 prefixes - we have a large chunk of wireless network that > >> is currently NAT'ed into the 172.31 space because we simply ran out of room > >> in our 2 /16s - but we give those users globally routed IPv6 addresses. > > > > > > I suggest you're not yet doing enough IPv6 traffic to have to care > > about IPv6 TE. > > I think he was pointing out that extra routes due to "slow start" > policies should not be a factor in v6. My guess is that is about > half of the "extra" routes announced today, the other half being > TE routes. Exactly. We have 4 prefixes only because we got slow-started and similar hysterical raisins, we don't use those for TE at all. If we wanted to do any globally visible TE that actually made a difference, we'd have to announce a more-specific out of one of the /16s anyhow, since that's where all our traffic generators/sinks are (and probably a matching more-specific out of our v6 /48). So we're always going to have 4+N on the IPv4 and 1+N on the IPv6 side. (And if we'd gotten more address space for that wireless net, we'd be at 5+N rather than 4+N). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fergdawgster at gmail.com Tue Oct 13 01:41:13 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 12 Oct 2009 23:41:13 -0700 Subject: AS3.196 [91.213.29.0/24] IM-AS Info-Media Ltd Message-ID: <6cd462c00910122341k347e2e3br88db223e4cf33eed@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm a bit confused (nothing really new here) with this BGP announcement, but following up on some cyber crime activity I stumbled on this: [Querying v4.whois.cymru.com] [v4.whois.cymru.com] AS | IP | AS Name 23456 | 91.213.29.250 | -Reserved AS- Is this legitimate? route-views2.routeviews.org> sho ip bgp 91.213.29.250 BGP routing table entry for 91.213.29.0/24 Paths: (42 available, best #33, table Default-IP-Routing-Table) Not advertised to any peer 6939 9002 40965 196804 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external Last update: Mon Oct 12 17:18:08 2009 13030 9002 40965 196804 213.144.128.203 from 213.144.128.203 (213.144.128.203) Origin IGP, metric 1, localpref 100, valid, external Community: 13030:1 13030:1016 Last update: Mon Oct 12 13:10:14 2009 14608 4323 9002 40965 196804 209.161.175.4 from 209.161.175.4 (209.161.175.4) Origin IGP, localpref 100, valid, external Community: no-export Last update: Mon Oct 12 08:06:19 2009 286 9002 40965 196804 134.222.87.3 from 134.222.87.3 (134.222.85.108) Origin IGP, metric 0, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 286:4019 Last update: Sat Oct 10 22:44:50 2009 1299 3549 9002 40965 196804 213.248.83.252 from 213.248.83.252 (213.248.83.252) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:43:18 2009 3303 9002 40965 196804 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 1120:2 3303:1004 3303:1006 3303:3056 Last update: Thu Oct 8 15:06:42 2009 2905 702 9002 40965 196804 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external Last update: Thu Oct 8 15:42:42 2009 31500 3267 9002 40965 196804 95.140.80.254 from 95.140.80.254 (1.0.0.10) Origin IGP, metric 0, localpref 100, valid, external Last update: Tue Oct 13 00:33:35 2009 1221 4637 3549 9002 40965 196804 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:32 2009 5056 1239 3549 9002 40965 196804 167.142.3.6 from 167.142.3.6 (167.142.225.101) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:10:31 2009 7660 2516 3549 9002 40965 196804 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 Last update: Thu Oct 8 14:44:01 2009 6762 3549 9002 40965 196804 195.22.216.188 from 195.22.216.188 (195.22.216.188) Origin IGP, metric 100, localpref 100, valid, external Community: 6762:31 Last update: Thu Oct 8 14:43:28 2009 16150 9002 40965 196804 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65215 16150:65320 Last update: Thu Oct 8 14:43:26 2009 6453 3549 9002 40965 196804 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:25 2009 2152 11164 9002 40965 196804 137.164.16.12 from 137.164.16.12 (137.164.16.196) Origin IGP, localpref 100, valid, external Community: 2152:65299 2152:65506 11164:1130 11164:7880 Last update: Sat Oct 10 13:52:50 2009 6453 3549 9002 40965 196804 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:22 2009 3277 3267 9002 40965 196804 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65321 3277:65323 Last update: Thu Oct 8 14:43:51 2009 852 3561 9002 40965 196804 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 Last update: Thu Oct 8 14:43:21 2009 3356 9002 40965 40965 196804 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 65000:0 Last update: Tue Oct 13 06:09:59 2009 701 3549 9002 40965 196804 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:48 2009 8492 9002 40965 196804 85.114.0.217 from 85.114.0.217 (85.114.0.2) Origin IGP, localpref 100, valid, external Community: 8492:1101 9002:0 9002:64677 Last update: Thu Oct 8 14:43:16 2009 5413 9002 40965 196804 62.72.136.2 from 62.72.136.2 (62.72.136.2) Origin IGP, metric 47, localpref 100, valid, external Last update: Thu Oct 8 14:43:15 2009 1239 3549 9002 40965 196804 144.228.241.130 from 144.228.241.130 (144.228.241.130) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:45 2009 286 9002 40965 196804 134.222.87.1 from 134.222.87.1 (134.222.86.1) Origin IGP, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 286:4019 Last update: Sat Oct 10 22:44:29 2009 6539 9002 40965 196804 216.18.31.102 from 216.18.31.102 (216.18.31.102) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:12 2009 3130 2914 3549 9002 40965 196804 147.28.7.1 from 147.28.7.1 (147.28.7.1) Origin IGP, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 3130:380 Last update: Thu Oct 8 14:43:11 2009 11686 11164 9002 40965 196804 96.4.0.55 from 96.4.0.55 (96.4.0.55) Origin IGP, localpref 100, valid, external Last update: Sat Oct 10 13:53:11 2009 1668 3549 9002 40965 196804 66.185.128.1 from 66.185.128.1 (66.185.128.3) Origin IGP, metric 502, localpref 100, valid, external Last update: Thu Oct 8 14:43:36 2009 3549 9002 40965 196804 67.17.82.114 from 67.17.82.114 (67.17.82.114) Origin IGP, metric 14124, localpref 100, valid, external Last update: Fri Oct 9 06:56:29 2009 3130 1239 3549 9002 40965 196804 147.28.7.2 from 147.28.7.2 (147.28.7.2) Origin IGP, metric 0, localpref 100, valid, external Community: 3130:370 3130:380 Last update: Thu Oct 8 14:43:21 2009 2914 3549 9002 40965 196804 129.250.0.11 from 129.250.0.11 (129.250.0.51) Origin IGP, metric 10, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:3549 Last update: Thu Oct 8 14:43:21 2009 2914 3549 9002 40965 196804 129.250.0.171 from 129.250.0.171 (129.250.0.79) Origin IGP, metric 5, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:3549 Last update: Thu Oct 8 14:43:23 2009 2497 9002 40965 196804 202.232.0.3 from 202.232.0.3 (58.138.96.149) Origin IGP, localpref 100, valid, external, best Last update: Thu Oct 8 14:43:02 2009 852 3561 9002 40965 196804 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 Last update: Sun Oct 11 01:25:14 2009 3257 3549 9002 40965 196804 89.149.178.10 from 89.149.178.10 (213.200.87.91) Origin IGP, metric 10, localpref 100, valid, external Community: 3257:8012 3257:30070 3257:50001 3257:54900 3257:54901 Last update: Thu Oct 8 14:43:09 2009 7018 3549 9002 40965 196804 12.0.1.63 from 12.0.1.63 (12.0.1.63) Origin IGP, localpref 100, valid, external Community: 7018:5000 Last update: Thu Oct 8 15:14:46 2009 13237 9002 40965 196804 81.209.156.1 from 81.209.156.1 (81.209.156.1) Origin IGP, localpref 100, valid, external Community: 13237:40044 13237:46441 Last update: Thu Oct 8 14:42:58 2009 8001 9002 40965 196804 209.123.12.51 from 209.123.12.51 (209.123.12.51) Origin IGP, localpref 100, valid, external Community: 8001:2000 8001:2001 Last update: Thu Oct 8 14:42:58 2009 3549 9002 40965 196804 208.51.134.246 from 208.51.134.246 (67.17.80.153) Origin IGP, metric 2633, localpref 100, valid, external Community: 3549:350 3549:4721 3549:31276 Last update: Thu Oct 8 14:42:58 2009 3561 9002 40965 196804 206.24.210.102 from 206.24.210.102 (206.24.210.102) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:42:58 2009 293 9002 40965 196804 198.129.33.85 from 198.129.33.85 (134.55.200.25) Origin IGP, localpref 100, valid, external Community: 293:14 Last update: Sat Oct 10 19:41:35 2009 812 3549 9002 40965 196804 64.71.255.61 from 64.71.255.61 (64.71.255.61) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:56 2009 route-views2.routeviews.org> See also: http://www.cidr-report.org/cgi-bin/as-report?as=196804 There's been some major criminal activity in this prefix and I was just following up on some research... http://www.malwareurl.com/search.php?domain=&s=91.213.29&match=0&rp=200&url s=on&redirs=on&ip=on&reverse=on&as=on Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFK1CD9q1pz9mNUZTMRAlfUAJ9u05ha1WP1RBnpW9ZpI5l5BLNERgCg8htQ UTeIoSWYUG8rBOTFltiWn9M= =1hHh -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From rveloso at cs.ucla.edu Tue Oct 13 01:44:42 2009 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Mon, 12 Oct 2009 23:44:42 -0700 Subject: AS3.196 [91.213.29.0/24] IM-AS Info-Media Ltd In-Reply-To: <6cd462c00910122341k347e2e3br88db223e4cf33eed@mail.gmail.com> References: <6cd462c00910122341k347e2e3br88db223e4cf33eed@mail.gmail.com> Message-ID: <8D589487-38F8-4E44-A07B-88D5905C2D6C@cs.ucla.edu> It seems Team Cymru needs to update its whois db to use 4-byte ASNs and remove AS_TRANS (23456) --Ricardo On Oct 12, 2009, at 11:41 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm a bit confused (nothing really new here) with this BGP > announcement, > but following up on some cyber crime activity I stumbled on this: > > [Querying v4.whois.cymru.com] > [v4.whois.cymru.com] > AS | IP | AS Name > 23456 | 91.213.29.250 | -Reserved AS- > > Is this legitimate? > > route-views2.routeviews.org> sho ip bgp 91.213.29.250 > BGP routing table entry for 91.213.29.0/24 > Paths: (42 available, best #33, table Default-IP-Routing-Table) > Not advertised to any peer > 6939 9002 40965 196804 > 216.218.252.164 from 216.218.252.164 (216.218.252.164) > Origin IGP, localpref 100, valid, external > Last update: Mon Oct 12 17:18:08 2009 > > 13030 9002 40965 196804 > 213.144.128.203 from 213.144.128.203 (213.144.128.203) > Origin IGP, metric 1, localpref 100, valid, external > Community: 13030:1 13030:1016 > Last update: Mon Oct 12 13:10:14 2009 > > 14608 4323 9002 40965 196804 > 209.161.175.4 from 209.161.175.4 (209.161.175.4) > Origin IGP, localpref 100, valid, external > Community: no-export > Last update: Mon Oct 12 08:06:19 2009 > > 286 9002 40965 196804 > 134.222.87.3 from 134.222.87.3 (134.222.85.108) > Origin IGP, metric 0, localpref 100, valid, external > Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 > 286:4019 > Last update: Sat Oct 10 22:44:50 2009 > > 1299 3549 9002 40965 196804 > 213.248.83.252 from 213.248.83.252 (213.248.83.252) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 15:43:18 2009 > > 3303 9002 40965 196804 > 164.128.32.11 from 164.128.32.11 (164.128.32.11) > Origin IGP, localpref 100, valid, external > Community: 1120:2 3303:1004 3303:1006 3303:3056 > Last update: Thu Oct 8 15:06:42 2009 > > 2905 702 9002 40965 196804 > 196.7.106.245 from 196.7.106.245 (196.7.106.245) > Origin IGP, metric 0, localpref 100, valid, external > Last update: Thu Oct 8 15:42:42 2009 > > 31500 3267 9002 40965 196804 > 95.140.80.254 from 95.140.80.254 (1.0.0.10) > Origin IGP, metric 0, localpref 100, valid, external > Last update: Tue Oct 13 00:33:35 2009 > > 1221 4637 3549 9002 40965 196804 > 203.62.252.186 from 203.62.252.186 (203.62.252.186) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:43:32 2009 > > 5056 1239 3549 9002 40965 196804 > 167.142.3.6 from 167.142.3.6 (167.142.225.101) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 15:10:31 2009 > > 7660 2516 3549 9002 40965 196804 > 203.181.248.168 from 203.181.248.168 (203.181.248.168) > Origin IGP, localpref 100, valid, external > Community: 2516:1030 > Last update: Thu Oct 8 14:44:01 2009 > > 6762 3549 9002 40965 196804 > 195.22.216.188 from 195.22.216.188 (195.22.216.188) > Origin IGP, metric 100, localpref 100, valid, external > Community: 6762:31 > Last update: Thu Oct 8 14:43:28 2009 > > 16150 9002 40965 196804 > 217.75.96.60 from 217.75.96.60 (217.75.96.60) > Origin IGP, metric 0, localpref 100, valid, external > Community: 16150:63392 16150:65215 16150:65320 > Last update: Thu Oct 8 14:43:26 2009 > > 6453 3549 9002 40965 196804 > 207.45.223.244 from 207.45.223.244 (66.110.0.124) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:43:25 2009 > > 2152 11164 9002 40965 196804 > 137.164.16.12 from 137.164.16.12 (137.164.16.196) > Origin IGP, localpref 100, valid, external > Community: 2152:65299 2152:65506 11164:1130 11164:7880 > Last update: Sat Oct 10 13:52:50 2009 > > 6453 3549 9002 40965 196804 > 195.219.96.239 from 195.219.96.239 (195.219.96.239) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:43:22 2009 > > 3277 3267 9002 40965 196804 > 194.85.4.55 from 194.85.4.55 (194.85.4.16) > Origin IGP, localpref 100, valid, external > Community: 3277:3267 3277:65321 3277:65323 > Last update: Thu Oct 8 14:43:51 2009 > > 852 3561 9002 40965 196804 > 154.11.98.225 from 154.11.98.225 (154.11.98.225) > Origin IGP, metric 0, localpref 100, valid, external > Community: 852:180 > Last update: Thu Oct 8 14:43:21 2009 > > 3356 9002 40965 40965 196804 > 4.69.184.193 from 4.69.184.193 (4.68.3.50) > Origin IGP, metric 0, localpref 100, valid, external > Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 > 65000:0 > Last update: Tue Oct 13 06:09:59 2009 > > 701 3549 9002 40965 196804 > 157.130.10.233 from 157.130.10.233 (137.39.3.60) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:43:48 2009 > > 8492 9002 40965 196804 > 85.114.0.217 from 85.114.0.217 (85.114.0.2) > Origin IGP, localpref 100, valid, external > Community: 8492:1101 9002:0 9002:64677 > Last update: Thu Oct 8 14:43:16 2009 > > 5413 9002 40965 196804 > 62.72.136.2 from 62.72.136.2 (62.72.136.2) > Origin IGP, metric 47, localpref 100, valid, external > Last update: Thu Oct 8 14:43:15 2009 > > 1239 3549 9002 40965 196804 > 144.228.241.130 from 144.228.241.130 (144.228.241.130) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:43:45 2009 > > 286 9002 40965 196804 > 134.222.87.1 from 134.222.87.1 (134.222.86.1) > Origin IGP, localpref 100, valid, external > Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 > 286:4019 > Last update: Sat Oct 10 22:44:29 2009 > > 6539 9002 40965 196804 > 216.18.31.102 from 216.18.31.102 (216.18.31.102) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:43:12 2009 > > 3130 2914 3549 9002 40965 196804 > 147.28.7.1 from 147.28.7.1 (147.28.7.1) > Origin IGP, localpref 100, valid, external > Community: 2914:420 2914:2000 2914:3000 3130:380 > Last update: Thu Oct 8 14:43:11 2009 > > 11686 11164 9002 40965 196804 > 96.4.0.55 from 96.4.0.55 (96.4.0.55) > Origin IGP, localpref 100, valid, external > Last update: Sat Oct 10 13:53:11 2009 > > 1668 3549 9002 40965 196804 > 66.185.128.1 from 66.185.128.1 (66.185.128.3) > Origin IGP, metric 502, localpref 100, valid, external > Last update: Thu Oct 8 14:43:36 2009 > > 3549 9002 40965 196804 > 67.17.82.114 from 67.17.82.114 (67.17.82.114) > Origin IGP, metric 14124, localpref 100, valid, external > Last update: Fri Oct 9 06:56:29 2009 > > 3130 1239 3549 9002 40965 196804 > 147.28.7.2 from 147.28.7.2 (147.28.7.2) > Origin IGP, metric 0, localpref 100, valid, external > Community: 3130:370 3130:380 > Last update: Thu Oct 8 14:43:21 2009 > > 2914 3549 9002 40965 196804 > 129.250.0.11 from 129.250.0.11 (129.250.0.51) > Origin IGP, metric 10, localpref 100, valid, external > Community: 2914:420 2914:2000 2914:3000 65504:3549 > Last update: Thu Oct 8 14:43:21 2009 > > 2914 3549 9002 40965 196804 > 129.250.0.171 from 129.250.0.171 (129.250.0.79) > Origin IGP, metric 5, localpref 100, valid, external > Community: 2914:420 2914:2000 2914:3000 65504:3549 > Last update: Thu Oct 8 14:43:23 2009 > > 2497 9002 40965 196804 > 202.232.0.3 from 202.232.0.3 (58.138.96.149) > Origin IGP, localpref 100, valid, external, best > Last update: Thu Oct 8 14:43:02 2009 > > 852 3561 9002 40965 196804 > 154.11.11.113 from 154.11.11.113 (154.11.11.113) > Origin IGP, metric 0, localpref 100, valid, external > Community: 852:180 > Last update: Sun Oct 11 01:25:14 2009 > > 3257 3549 9002 40965 196804 > 89.149.178.10 from 89.149.178.10 (213.200.87.91) > Origin IGP, metric 10, localpref 100, valid, external > Community: 3257:8012 3257:30070 3257:50001 3257:54900 3257:54901 > Last update: Thu Oct 8 14:43:09 2009 > > 7018 3549 9002 40965 196804 > 12.0.1.63 from 12.0.1.63 (12.0.1.63) > Origin IGP, localpref 100, valid, external > Community: 7018:5000 > Last update: Thu Oct 8 15:14:46 2009 > > 13237 9002 40965 196804 > 81.209.156.1 from 81.209.156.1 (81.209.156.1) > Origin IGP, localpref 100, valid, external > Community: 13237:40044 13237:46441 > Last update: Thu Oct 8 14:42:58 2009 > > 8001 9002 40965 196804 > 209.123.12.51 from 209.123.12.51 (209.123.12.51) > Origin IGP, localpref 100, valid, external > Community: 8001:2000 8001:2001 > Last update: Thu Oct 8 14:42:58 2009 > > 3549 9002 40965 196804 > 208.51.134.246 from 208.51.134.246 (67.17.80.153) > Origin IGP, metric 2633, localpref 100, valid, external > Community: 3549:350 3549:4721 3549:31276 > Last update: Thu Oct 8 14:42:58 2009 > > 3561 9002 40965 196804 > 206.24.210.102 from 206.24.210.102 (206.24.210.102) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:42:58 2009 > > 293 9002 40965 196804 > 198.129.33.85 from 198.129.33.85 (134.55.200.25) > Origin IGP, localpref 100, valid, external > Community: 293:14 > Last update: Sat Oct 10 19:41:35 2009 > > 812 3549 9002 40965 196804 > 64.71.255.61 from 64.71.255.61 (64.71.255.61) > Origin IGP, localpref 100, valid, external > Last update: Thu Oct 8 14:43:56 2009 > > route-views2.routeviews.org> > > > See also: > > http://www.cidr-report.org/cgi-bin/as-report?as=196804 > > > There's been some major criminal activity in this prefix and I was > just > following up on some research... > > http://www.malwareurl.com/search.php?domain=&s=91.213.29&match=0&rp=200&url > s=on&redirs=on&ip=on&reverse=on&as=on > > Thanks, > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFK1CD9q1pz9mNUZTMRAlfUAJ9u05ha1WP1RBnpW9ZpI5l5BLNERgCg8htQ > UTeIoSWYUG8rBOTFltiWn9M= > =1hHh > -----END PGP SIGNATURE----- > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > From bortzmeyer at nic.fr Tue Oct 13 01:48:06 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 13 Oct 2009 08:48:06 +0200 Subject: .se disappeared? In-Reply-To: <4AD3AC72.1080807@hauke-lampe.de> References: <20091012204219.GA10393@nic.fr> <4AD3AC72.1080807@hauke-lampe.de> Message-ID: <20091013064806.GA10552@nic.fr> On Tue, Oct 13, 2009 at 12:23:46AM +0200, Hauke Lampe wrote a message of 53 lines which said: > Even after a cache reload, the SOA record appears still bogus: Yes, even after a cold reboot, the data did not validate. But, this time, the problem was purely DNSSEC and was noticed only by people brave enough to validate. Too much haste in repairing probably. > Unbound returns SERVFAIL instead. Fixed, now. From fergdawgster at gmail.com Tue Oct 13 01:48:12 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 12 Oct 2009 23:48:12 -0700 Subject: AS3.196 [91.213.29.0/24] IM-AS Info-Media Ltd In-Reply-To: <8D589487-38F8-4E44-A07B-88D5905C2D6C@cs.ucla.edu> References: <6cd462c00910122341k347e2e3br88db223e4cf33eed@mail.gmail.com> <8D589487-38F8-4E44-A07B-88D5905C2D6C@cs.ucla.edu> Message-ID: <6cd462c00910122348w2804223elaf8d6e8f181322c2@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, is this the first usage of 4-byte ASNs by cyber criminals? :-) It would appear so. - - ferg On Mon, Oct 12, 2009 at 11:44 PM, Ricardo Oliveira wrote: > It seems Team Cymru needs to update its whois db to use 4-byte ASNs and > remove AS_TRANS (23456) > > --Ricardo > > On Oct 12, 2009, at 11:41 PM, Paul Ferguson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I'm a bit confused (nothing really new here) with this BGP announcement, >> but following up on some cyber crime activity I stumbled on this: >> >> [Querying v4.whois.cymru.com] >> [v4.whois.cymru.com] >> AS | IP | AS Name >> 23456 | 91.213.29.250 | -Reserved AS- >> >> Is this legitimate? >> >> route-views2.routeviews.org> sho ip bgp 91.213.29.250 >> BGP routing table entry for 91.213.29.0/24 >> Paths: (42 available, best #33, table Default-IP-Routing-Table) >> Not advertised to any peer >> 6939 9002 40965 196804 >> 216.218.252.164 from 216.218.252.164 (216.218.252.164) >> Origin IGP, localpref 100, valid, external >> Last update: Mon Oct 12 17:18:08 2009 >> >> 13030 9002 40965 196804 >> 213.144.128.203 from 213.144.128.203 (213.144.128.203) >> Origin IGP, metric 1, localpref 100, valid, external >> Community: 13030:1 13030:1016 >> Last update: Mon Oct 12 13:10:14 2009 >> >> 14608 4323 9002 40965 196804 >> 209.161.175.4 from 209.161.175.4 (209.161.175.4) >> Origin IGP, localpref 100, valid, external >> Community: no-export >> Last update: Mon Oct 12 08:06:19 2009 >> >> 286 9002 40965 196804 >> 134.222.87.3 from 134.222.87.3 (134.222.85.108) >> Origin IGP, metric 0, localpref 100, valid, external >> Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 >> 286:4019 >> Last update: Sat Oct 10 22:44:50 2009 >> >> 1299 3549 9002 40965 196804 >> 213.248.83.252 from 213.248.83.252 (213.248.83.252) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 15:43:18 2009 >> >> 3303 9002 40965 196804 >> 164.128.32.11 from 164.128.32.11 (164.128.32.11) >> Origin IGP, localpref 100, valid, external >> Community: 1120:2 3303:1004 3303:1006 3303:3056 >> Last update: Thu Oct 8 15:06:42 2009 >> >> 2905 702 9002 40965 196804 >> 196.7.106.245 from 196.7.106.245 (196.7.106.245) >> Origin IGP, metric 0, localpref 100, valid, external >> Last update: Thu Oct 8 15:42:42 2009 >> >> 31500 3267 9002 40965 196804 >> 95.140.80.254 from 95.140.80.254 (1.0.0.10) >> Origin IGP, metric 0, localpref 100, valid, external >> Last update: Tue Oct 13 00:33:35 2009 >> >> 1221 4637 3549 9002 40965 196804 >> 203.62.252.186 from 203.62.252.186 (203.62.252.186) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:32 2009 >> >> 5056 1239 3549 9002 40965 196804 >> 167.142.3.6 from 167.142.3.6 (167.142.225.101) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 15:10:31 2009 >> >> 7660 2516 3549 9002 40965 196804 >> 203.181.248.168 from 203.181.248.168 (203.181.248.168) >> Origin IGP, localpref 100, valid, external >> Community: 2516:1030 >> Last update: Thu Oct 8 14:44:01 2009 >> >> 6762 3549 9002 40965 196804 >> 195.22.216.188 from 195.22.216.188 (195.22.216.188) >> Origin IGP, metric 100, localpref 100, valid, external >> Community: 6762:31 >> Last update: Thu Oct 8 14:43:28 2009 >> >> 16150 9002 40965 196804 >> 217.75.96.60 from 217.75.96.60 (217.75.96.60) >> Origin IGP, metric 0, localpref 100, valid, external >> Community: 16150:63392 16150:65215 16150:65320 >> Last update: Thu Oct 8 14:43:26 2009 >> >> 6453 3549 9002 40965 196804 >> 207.45.223.244 from 207.45.223.244 (66.110.0.124) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:25 2009 >> >> 2152 11164 9002 40965 196804 >> 137.164.16.12 from 137.164.16.12 (137.164.16.196) >> Origin IGP, localpref 100, valid, external >> Community: 2152:65299 2152:65506 11164:1130 11164:7880 >> Last update: Sat Oct 10 13:52:50 2009 >> >> 6453 3549 9002 40965 196804 >> 195.219.96.239 from 195.219.96.239 (195.219.96.239) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:22 2009 >> >> 3277 3267 9002 40965 196804 >> 194.85.4.55 from 194.85.4.55 (194.85.4.16) >> Origin IGP, localpref 100, valid, external >> Community: 3277:3267 3277:65321 3277:65323 >> Last update: Thu Oct 8 14:43:51 2009 >> >> 852 3561 9002 40965 196804 >> 154.11.98.225 from 154.11.98.225 (154.11.98.225) >> Origin IGP, metric 0, localpref 100, valid, external >> Community: 852:180 >> Last update: Thu Oct 8 14:43:21 2009 >> >> 3356 9002 40965 40965 196804 >> 4.69.184.193 from 4.69.184.193 (4.68.3.50) >> Origin IGP, metric 0, localpref 100, valid, external >> Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 >> 65000:0 >> Last update: Tue Oct 13 06:09:59 2009 >> >> 701 3549 9002 40965 196804 >> 157.130.10.233 from 157.130.10.233 (137.39.3.60) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:48 2009 >> >> 8492 9002 40965 196804 >> 85.114.0.217 from 85.114.0.217 (85.114.0.2) >> Origin IGP, localpref 100, valid, external >> Community: 8492:1101 9002:0 9002:64677 >> Last update: Thu Oct 8 14:43:16 2009 >> >> 5413 9002 40965 196804 >> 62.72.136.2 from 62.72.136.2 (62.72.136.2) >> Origin IGP, metric 47, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:15 2009 >> >> 1239 3549 9002 40965 196804 >> 144.228.241.130 from 144.228.241.130 (144.228.241.130) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:45 2009 >> >> 286 9002 40965 196804 >> 134.222.87.1 from 134.222.87.1 (134.222.86.1) >> Origin IGP, localpref 100, valid, external >> Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 >> 286:4019 >> Last update: Sat Oct 10 22:44:29 2009 >> >> 6539 9002 40965 196804 >> 216.18.31.102 from 216.18.31.102 (216.18.31.102) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:12 2009 >> >> 3130 2914 3549 9002 40965 196804 >> 147.28.7.1 from 147.28.7.1 (147.28.7.1) >> Origin IGP, localpref 100, valid, external >> Community: 2914:420 2914:2000 2914:3000 3130:380 >> Last update: Thu Oct 8 14:43:11 2009 >> >> 11686 11164 9002 40965 196804 >> 96.4.0.55 from 96.4.0.55 (96.4.0.55) >> Origin IGP, localpref 100, valid, external >> Last update: Sat Oct 10 13:53:11 2009 >> >> 1668 3549 9002 40965 196804 >> 66.185.128.1 from 66.185.128.1 (66.185.128.3) >> Origin IGP, metric 502, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:36 2009 >> >> 3549 9002 40965 196804 >> 67.17.82.114 from 67.17.82.114 (67.17.82.114) >> Origin IGP, metric 14124, localpref 100, valid, external >> Last update: Fri Oct 9 06:56:29 2009 >> >> 3130 1239 3549 9002 40965 196804 >> 147.28.7.2 from 147.28.7.2 (147.28.7.2) >> Origin IGP, metric 0, localpref 100, valid, external >> Community: 3130:370 3130:380 >> Last update: Thu Oct 8 14:43:21 2009 >> >> 2914 3549 9002 40965 196804 >> 129.250.0.11 from 129.250.0.11 (129.250.0.51) >> Origin IGP, metric 10, localpref 100, valid, external >> Community: 2914:420 2914:2000 2914:3000 65504:3549 >> Last update: Thu Oct 8 14:43:21 2009 >> >> 2914 3549 9002 40965 196804 >> 129.250.0.171 from 129.250.0.171 (129.250.0.79) >> Origin IGP, metric 5, localpref 100, valid, external >> Community: 2914:420 2914:2000 2914:3000 65504:3549 >> Last update: Thu Oct 8 14:43:23 2009 >> >> 2497 9002 40965 196804 >> 202.232.0.3 from 202.232.0.3 (58.138.96.149) >> Origin IGP, localpref 100, valid, external, best >> Last update: Thu Oct 8 14:43:02 2009 >> >> 852 3561 9002 40965 196804 >> 154.11.11.113 from 154.11.11.113 (154.11.11.113) >> Origin IGP, metric 0, localpref 100, valid, external >> Community: 852:180 >> Last update: Sun Oct 11 01:25:14 2009 >> >> 3257 3549 9002 40965 196804 >> 89.149.178.10 from 89.149.178.10 (213.200.87.91) >> Origin IGP, metric 10, localpref 100, valid, external >> Community: 3257:8012 3257:30070 3257:50001 3257:54900 3257:54901 >> Last update: Thu Oct 8 14:43:09 2009 >> >> 7018 3549 9002 40965 196804 >> 12.0.1.63 from 12.0.1.63 (12.0.1.63) >> Origin IGP, localpref 100, valid, external >> Community: 7018:5000 >> Last update: Thu Oct 8 15:14:46 2009 >> >> 13237 9002 40965 196804 >> 81.209.156.1 from 81.209.156.1 (81.209.156.1) >> Origin IGP, localpref 100, valid, external >> Community: 13237:40044 13237:46441 >> Last update: Thu Oct 8 14:42:58 2009 >> >> 8001 9002 40965 196804 >> 209.123.12.51 from 209.123.12.51 (209.123.12.51) >> Origin IGP, localpref 100, valid, external >> Community: 8001:2000 8001:2001 >> Last update: Thu Oct 8 14:42:58 2009 >> >> 3549 9002 40965 196804 >> 208.51.134.246 from 208.51.134.246 (67.17.80.153) >> Origin IGP, metric 2633, localpref 100, valid, external >> Community: 3549:350 3549:4721 3549:31276 >> Last update: Thu Oct 8 14:42:58 2009 >> >> 3561 9002 40965 196804 >> 206.24.210.102 from 206.24.210.102 (206.24.210.102) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:42:58 2009 >> >> 293 9002 40965 196804 >> 198.129.33.85 from 198.129.33.85 (134.55.200.25) >> Origin IGP, localpref 100, valid, external >> Community: 293:14 >> Last update: Sat Oct 10 19:41:35 2009 >> >> 812 3549 9002 40965 196804 >> 64.71.255.61 from 64.71.255.61 (64.71.255.61) >> Origin IGP, localpref 100, valid, external >> Last update: Thu Oct 8 14:43:56 2009 >> >> route-views2.routeviews.org> >> >> >> See also: >> >> http://www.cidr-report.org/cgi-bin/as-report?as=196804 >> >> >> There's been some major criminal activity in this prefix and I was just >> following up on some research... >> >> >> http://www.malwareurl.com/search.php?domain=&s=91.213.29&match=0&rp=200& >> url s=on&redirs=on&ip=on&reverse=on&as=on >> >> Thanks, >> >> - - ferg >> >> -----BEGIN PGP SIGNATURE----- >> Version: PGP Desktop 9.5.3 (Build 5003) >> >> wj8DBQFK1CD9q1pz9mNUZTMRAlfUAJ9u05ha1WP1RBnpW9ZpI5l5BLNERgCg8htQ >> UTeIoSWYUG8rBOTFltiWn9M= >> =1hHh >> -----END PGP SIGNATURE----- >> >> >> >> -- >> "Fergie", a.k.a. Paul Ferguson >> Engineering Architecture for the Internet >> fergdawgster(at)gmail.com >> ferg's tech blog: http://fergdawg.blogspot.com/ >> > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFK1CKmq1pz9mNUZTMRAtTsAJoCqx7OEbkLYdnqG/YwZe9KScxXUACg0M/W 1dK6EuqxhYx6TJMZfHq6cA4= =cpLX -----END PGP SIGNATURE----- From nanog at daork.net Tue Oct 13 02:44:17 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 13 Oct 2009 20:44:17 +1300 Subject: IPv6 internet broken, Verizon route prefix length policy In-Reply-To: <4AD40608.1020004@kl.net> References: <4AD3576A.10203@rollernet.us> <4AD382E4.9010901@iglou.com> <200910122240.n9CMel2I000196@drugs.dv.isc.org> <778C6449-5FCE-4838-8FD2-BB7CC67BB298@delong.com> <20372E71-9EC3-40CE-B876-DE53985DC939@virtualized.org> <14776.1255407126@turing-police.cc.vt.edu> <20091013042130.GL8395@skywalker.creative.net.au> <4AD40608.1020004@kl.net> Message-ID: <88C7B048-7488-46AB-852A-985FD4CF66C3@daork.net> On 13/10/2009, at 5:46 PM, Kevin Loch wrote: > I think he was pointing out that extra routes due to "slow start" > policies should not be a factor in v6. My guess is that is about > half of the "extra" routes announced today, the other half being > TE routes. You can pretty easily figure out how many advertised prefixes are intentional de-aggregates, and you can get a fairly good idea as to how many of them are for TE as well I expect, by looking for different AS paths. Someone mentioned some slides earlier in this thread by Vince Fuller at APRICOT early '07 that from memory have pretty good data on this. -- Nathan Ward From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Oct 13 05:12:22 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 13 Oct 2009 20:42:22 +1030 Subject: ISP customer assignments In-Reply-To: <4AD3F4C7.70103@emanon.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> Message-ID: <20091013204222.1e608c51@opy.nosense.org> On Mon, 12 Oct 2009 23:32:23 -0400 Scott Morris wrote: > I'm going to have to pull the "mixed-hat" on this one. If you are > comparing this to a true "academia" environment, I'd agree with you. > Too much theory, not enough reality in things. However, I've yet to see > the part about where the person is being trained from. > > I happen to train people at CCIE level. I also happen to do consulting, > implementation, and design work. In my training environment, there are > all sorts of re-thinking of what/how things are being taught even within > the confines of comparison to a lab environment. But that's a personal > point of view trying to keep reality involved and be worthwhile. > > I'm not trying to open any sort of debate or can of worms here, but just > because one is receiving training does not mean the instructor has no > functional knowledge of something. I'm interested in hearing the > playout on this one as well. > > How many addresses do you like on point-to-point circuits? > How ever many the protocol designers thought there should be. > Scott > > > > George Michaelson wrote: > > > > On 13/10/2009, at 12:54 PM, Doug Barton wrote: > > > >> On Oct 12, 2009, at 7:34 PM, Justin Shore > >> wrote: > >>> I'm actually taking an IPv6 class right now and the topic of > >>> customer assignments came up today (day 1). The instructor was > >>> suggesting dynamically allocating /127s to residential customers. I > >>> relayed the gist of this thread to him (/48, /56 and /64). I expect > >>> to dive deeper into this in the following days in the class. > >> > >> Out of curiosity who is conducting this class and what was their > >> rationale for using /127s? > >> > >> Doug > > > > As a point of view on this, a member of staff from APNIC was doing a > > Masters of IT in the last 3-4 years, and had classfull A/B/C > > addressing taught to her in the networks unit. She found it quite a > > struggle to convince the lecturer that reality had moved on and they > > had no idea about CIDR. > > > > I have from time to time, asked people in ACM and IEEE about how one > > informs the tertiary teaching community about this kind of change. The > > answers were not inspiring: compared to civil engineering, where > > compliance issues and re-training by professionals is almost regulated > > (sorry for the R- word) as a function of professional indemnity > > insurance and status, its much more common for the syllabus to be > > under continual review. > > > > -George > > > > > From trejrco at gmail.com Tue Oct 13 05:18:31 2009 From: trejrco at gmail.com (TJ) Date: Tue, 13 Oct 2009 06:18:31 -0400 Subject: ISP customer assignments In-Reply-To: <4AD3E726.80400@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> Message-ID: <00f701ca4bee$846f8080$8d4e8180$@com> -----Original Message----- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? > My first (potentially ignorant) response would be to get your acquisitions > people aligned with your business, and by that I mean they should be making > a concerted effort to only buy IPv6 capable gear, especially when IPv6 is > coming to you within that gears lifecycle. > I guess your customers will need to tunnel, as long as you give them a public > IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better. From adrian at creative.net.au Tue Oct 13 05:26:08 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 13 Oct 2009 18:26:08 +0800 Subject: ISP customer assignments In-Reply-To: <00f701ca4bee$846f8080$8d4e8180$@com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <00f701ca4bee$846f8080$8d4e8180$@com> Message-ID: <20091013102608.GA31089@skywalker.creative.net.au> Nathan Ward, please stand up. Adrian On Tue, Oct 13, 2009, TJ wrote: > > -----Original Message----- > From: Justin > To go along with Dan's query from above, what are the preferred methods > that other SPs are using to deploy IPv6 with non-IPv6-capable edge > hardware? We too have a very limited number of dialup customers and > will never sink another dollar in the product. Unfortunately I also > have brand-new ADSL2+ hardware that doesn't support IPv6 and according > to the vendors (Pannaway) never will. We also have CMTSs that don't > support IPv6, even though they too are brand-new. Those CMTSs top out > at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs > regardless of the underlying CM's IPv6 support or lack thereof (like > Cisco allowed for example). Are providers implementing tunneling > solutions? Pros/cons of the various solutions? > > > > My first (potentially ignorant) response would be to get your acquisitions > > > people aligned with your business, and by that I mean they should be > making > > a concerted effort to only buy IPv6 capable gear, especially when IPv6 is > > > coming to you within that gears lifecycle. > > I guess your customers will need to tunnel, as long as you give them a > public > > IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is > better. > > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From if at xip.at Tue Oct 13 06:18:58 2009 From: if at xip.at (Ingo Flaschberger) Date: Tue, 13 Oct 2009 13:18:58 +0200 (CEST) Subject: .se disappeared? In-Reply-To: <20091013064806.GA10552@nic.fr> References: <20091012204219.GA10393@nic.fr> <4AD3AC72.1080807@hauke-lampe.de> <20091013064806.GA10552@nic.fr> Message-ID: Hi, .se statement: http://www.iis.se/en/2009/10/13/felaktig-dns-information/ Kind regards, ingo flaschberger From swm at emanon.com Tue Oct 13 06:39:46 2009 From: swm at emanon.com (Scott Morris) Date: Tue, 13 Oct 2009 07:39:46 -0400 Subject: ISP customer assignments In-Reply-To: <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> Message-ID: <4AD46702.3040605@emanon.com> No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? Or did you learn calculus in grade school? Just askin' ;) Scott Mark Newton wrote: > > On 13/10/2009, at 2:02 PM, Scott Morris wrote: > >> I happen to train people at CCIE level. I also happen to do consulting, >> implementation, and design work. In my training environment, there are >> all sorts of re-thinking of what/how things are being taught even within >> the confines of comparison to a lab environment. > > Does the CCNA exam still ask questions about RIP and classful addressing? > > Just askin' :-) > > - mark > > > -- > Mark Newton Email: > newton at internode.com.au (W) > Network Engineer Email: > newton at atdot.dotat.org (H) > Internode Pty Ltd Desk: +61-8-82282999 > "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 > > > > > > From nick at foobar.org Tue Oct 13 06:49:43 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 13 Oct 2009 12:49:43 +0100 Subject: .se disappeared? In-Reply-To: References: <20091012204219.GA10393@nic.fr> <4AD3AC72.1080807@hauke-lampe.de> <20091013064806.GA10552@nic.fr> Message-ID: <4AD46957.3020200@foobar.org> On 13/10/2009 12:18, Ingo Flaschberger wrote: > .se statement: > http://www.iis.se/en/2009/10/13/felaktig-dns-information/ The internet's reply (sfw): http://pr0nbot.phetast.nu/src/iis_xzibit-1255422509.JPEG Nick From jabley at hopcount.ca Tue Oct 13 06:53:55 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Oct 2009 07:53:55 -0400 Subject: ISP customer assignments In-Reply-To: <4AD46702.3040605@emanon.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> Message-ID: On 2009-10-13, at 07:39, Scott Morris wrote: > No idea, I haven't looked at that stuff in a while. But I would > assume > so, as it's easier to build a foundation than jumping straight to > something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with "don't ever use this". But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. > Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe From swm at emanon.com Tue Oct 13 07:05:37 2009 From: swm at emanon.com (Scott Morris) Date: Tue, 13 Oct 2009 08:05:37 -0400 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> Message-ID: <4AD46D11.3000702@emanon.com> While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case. I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? If you did calculus, more power to you. However, you still needed a foundation before a pseudo-random collection of letters and numbers together would make any sense. ;) I learned long ago that not everyone can learn in the same fashion that I do. So there's a path to everything with foundations. Some people have a hard time subnetting IPv4 on varying boundaries. More people have a hard time subnetting IPv6 on varying boundaries. While I don't have a problem with either I have to find ways to "fix" those that do while teaching. And typically it's missing foundation skills. But anyway, I don't think that's the important part! My point was more about not assuming that just because someone is teaching that they don't have a realistic set of experiences to go with it as the poster from APNIC pointed out. Just my two cents, Scott Joe Abley wrote: > > On 2009-10-13, at 07:39, Scott Morris wrote: > >> No idea, I haven't looked at that stuff in a while. But I would assume >> so, as it's easier to build a foundation than jumping straight to >> something difficult? > > I've found RIP to be a reasonable way to teach the concept of a > routing protocol, since the protocol is very simple and you can always > close with "don't ever use this". > > But teaching classful routing and addressing is just moronic. It's a > foundation that nothing is built on any more, and makes no sense to > teach outside of a history class. > >> Or did you learn calculus in grade school? Just askin' ;) > > Yes, since you asked, but your presumption is faulty. > > > Joe > > From jabley at hopcount.ca Tue Oct 13 07:14:59 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Oct 2009 08:14:59 -0400 Subject: ISP customer assignments In-Reply-To: <4AD46D11.3000702@emanon.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> <4AD46D11.3000702@emanon.com> Message-ID: <76DC7E82-F237-4F3B-9F1F-51373CA42173@hopcount.ca> On 2009-10-13, at 08:05, Scott Morris wrote: > While I may agree that teaching classful routing is stupid, the > addressing part lets people start getting the concept of binary. That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start with mask lengths that are multiples of 8. > While > I'd love to think that people coming out of the school system have a > grasp of simple mathematical skills, more and more I'm finding that's > not the case. I wouldn't spend a LOT of time with it, and I > certainly > wouldn't LEAVE at classful addressing, but it's a foundational step. > > Why is the presumption faulty? You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong. Joe From swm at emanon.com Tue Oct 13 07:22:26 2009 From: swm at emanon.com (Scott Morris) Date: Tue, 13 Oct 2009 08:22:26 -0400 Subject: ISP customer assignments In-Reply-To: <76DC7E82-F237-4F3B-9F1F-51373CA42173@hopcount.ca> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> <4AD46D11.3000702@emanon.com> <76DC7E82-F237-4F3B-9F1F-51373CA42173@hopcount.ca> Message-ID: <4AD47102.1070505@emanon.com> Ok, fair enough. I was working on the presumption not so much that it was simpler but more than it provided a logical structure. Having some framework to start with provides a base. True that binary is binary is binary... But rather than just an amorphous collection of x-number of bits, there's some initial rhyme and reason. Explaining that, getting buy in, and understanding the limitations therein will make the next progression to VLSM simpler to grasp. At least in my opinion. :) Scott Joe Abley wrote: > > On 2009-10-13, at 08:05, Scott Morris wrote: > >> While I may agree that teaching classful routing is stupid, the >> addressing part lets people start getting the concept of binary. > > That's true of classless addressing, too. When students have problems > with non-octet bit boundaries, that just means you start with mask > lengths that are multiples of 8. > >> While >> I'd love to think that people coming out of the school system have a >> grasp of simple mathematical skills, more and more I'm finding that's >> not the case. I wouldn't spend a LOT of time with it, and I certainly >> wouldn't LEAVE at classful addressing, but it's a foundational step. >> >> Why is the presumption faulty? > > You were suggesting that classful addressing is reasonable to teach > because it's simpler. It's not simpler, and in a modern-day context > it's just wrong. > > > Joe > From trejrco at gmail.com Tue Oct 13 07:24:23 2009 From: trejrco at gmail.com (TJ) Date: Tue, 13 Oct 2009 08:24:23 -0400 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> Message-ID: <71bfd60c0910130524j26a52872g8c4a04d6e8a15a9b@mail.gmail.com> Heh - Every time I try to say something close to "don't ever use this" or "not really used anymore" WRT RIP I get a student or three that is using it, and in fact it is there only option due to certain vendors' choices of what routing protocols to support on certain classes of gear. /TJ ... really hoping those certain vendors choose OSPFv3 (or ISIS, I really don't care - anything instead of RIPng :P ) for IPv6. On Tue, Oct 13, 2009 at 7:53 AM, Joe Abley wrote: > > On 2009-10-13, at 07:39, Scott Morris wrote: > > No idea, I haven't looked at that stuff in a while. But I would assume >> so, as it's easier to build a foundation than jumping straight to >> something difficult? >> > > I've found RIP to be a reasonable way to teach the concept of a routing > protocol, since the protocol is very simple and you can always close with > "don't ever use this". > > But teaching classful routing and addressing is just moronic. It's a > foundation that nothing is built on any more, and makes no sense to teach > outside of a history class. > > Or did you learn calculus in grade school? Just askin' ;) >> > > Yes, since you asked, but your presumption is faulty. > > > Joe > > > -- /TJ From Valdis.Kletnieks at vt.edu Tue Oct 13 07:28:40 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Oct 2009 08:28:40 -0400 Subject: ISP customer assignments In-Reply-To: Your message of "Tue, 13 Oct 2009 07:39:46 EDT." <4AD46702.3040605@emanon.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> Message-ID: <36577.1255436920@turing-police.cc.vt.edu> On Tue, 13 Oct 2009 07:39:46 EDT, Scott Morris said: > No idea, I haven't looked at that stuff in a while. But I would assume > so, as it's easier to build a foundation than jumping straight to > something difficult? Unfortunately, classful addressing is a foundation for networking the same way Roman numerals were a foundation for arithmetic. Both are "the way we used to do it", neither is relevant anymore, and once learned, both are bad habits that actively inhibit learning the more useful methods... And yes, as a matter of fact, I *did* start learning calculus in grade school. Have to admit that partial derivatives stumped me until middle school, though. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From justin at justinshore.com Tue Oct 13 08:33:03 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 13 Oct 2009 08:33:03 -0500 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> Message-ID: <4AD4818F.1060701@justinshore.com> Doug Barton wrote: > Out of curiosity who is conducting this class and what was their > rationale for using /127s? It's a GK class. The instructor seems to be fairly knowledgeable and has a lengthy history consulting on and deploying IPv6. The class seems to be geared much more towards enterprise though instead of service providers. That's very unfortunate considering that every one of the 15 people in this class either works for or contracts to a SP. Still the instructor has some SP knowledge so he fills in the blanks when possible. We're all thinking like SPs though and we ask the SP-oriented questions which usually helps us steer the course the direction we want. I wish GK and other training companies would start offering classes geared towards SPs. They could easily take the existing courseware, add a couple days at the end and interject useful SP info into the earlier days. All that extra info could be specifically aimed at SPs. He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. Justin From chaz at chaz6.com Tue Oct 13 08:51:07 2009 From: chaz at chaz6.com (Chris Hills) Date: Tue, 13 Oct 2009 15:51:07 +0200 Subject: ISP customer assignments In-Reply-To: <4AD4818F.1060701@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <4AD4818F.1060701@justinshore.com> Message-ID: On 13/10/09 15:33, Justin Shore wrote: > He didn't really give much of a reason for the /127s yet. I think it's > coming up in a later session. I think it basically boiled down to > whether or not the customer would actually use anything bigger. I'll > write back when we get into that discussion. Anything other than /64 removes the possibility of using privacy (aka temporary) addresses, enabled on Vista and above by default (net.ipv6.conf.all.use_tempaddr on Linux). For a single prefix a host may have by default up to 8 global unicast addresses - 1 EUI-64 and 7 privacy. From dwhite at olp.net Tue Oct 13 09:15:23 2009 From: dwhite at olp.net (Dan White) Date: Tue, 13 Oct 2009 09:15:23 -0500 Subject: ISP customer assignments In-Reply-To: <4AD3E726.80400@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> Message-ID: <20091013141523.GA5028@dan.olp.net> On 12/10/09?21:34?-0500, Justin Shore wrote: > To go along with Dan's query from above, what are the preferred methods > that other SPs are using to deploy IPv6 with non-IPv6-capable edge > hardware? We too have a very limited number of dialup customers and > will never sink another dollar in the product. Unfortunately I also > have brand-new ADSL2+ hardware that doesn't support IPv6 and according > to the vendors (Pannaway) never will. I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. -- Dan White From jtk at cymru.com Tue Oct 13 09:21:46 2009 From: jtk at cymru.com (John Kristoff) Date: Tue, 13 Oct 2009 09:21:46 -0500 Subject: ISP customer assignments In-Reply-To: <76DC7E82-F237-4F3B-9F1F-51373CA42173@hopcount.ca> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> <4AD46D11.3000702@emanon.com> <76DC7E82-F237-4F3B-9F1F-51373CA42173@hopcount.ca> Message-ID: <20091013092146.28a98e24@t61p> On Tue, 13 Oct 2009 08:14:59 -0400 Joe Abley wrote: > > While I may agree that teaching classful routing is stupid, the > > addressing part lets people start getting the concept of binary. > > That's true of classless addressing, too. When students have > problems with non-octet bit boundaries, that just means you start [...] > You were suggesting that classful addressing is reasonable to teach > because it's simpler. It's not simpler, and in a modern-day context > it's just wrong. I occasionally teach college level courses in networking, typically undergrads or grad students at DePaul University. I think I can offer some perspective from both the academic and operator viewpoint. No matter the class or the student, I always have to spend at least a week on IP addressing, even to students who should be coming in with already having had it, sometimes in multiple previous classes. Some know it fairly well, but with holes mostly due to lack of practical experience. I don't think I've seen anyone who would be considered expert enough to withstand the scrutiny of this crowd (though that probably goes for just about anyone really :-). No question about it, but something more than basic classful addressing for students who don't typically have to do it on a regular basis is not easy. Those who aren't afraid of math, can grasp numbering systems and binary arithmetic usually fare better. Some instructors are most certainly doing some harm. From what I can tell, classful addressing is always taught and if classless is taught, its practical reality and importance is not always stressed. In my most recent class this semester I made it abundantly clear to my students that classful addressing, while interesting and useful to know from a historic perspective, is obsolete and deprecated. A student who has another networking related class with another instructor came back saying their other instructor disagrees. :/ John From sethm at rollernet.us Tue Oct 13 10:27:58 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 13 Oct 2009 08:27:58 -0700 Subject: IPv6 in the ARIN region Message-ID: <4AD49C7E.6030007@rollernet.us> New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 AT&T, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 Did I miss anyone? Qwest only carries one route (out of 4 total) though, don't know if that's an exception or they only have one ARIN PI customer. ~Seth From justin at justinshore.com Tue Oct 13 10:59:53 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 13 Oct 2009 10:59:53 -0500 Subject: ISP customer assignments In-Reply-To: <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> Message-ID: <4AD4A3F9.6010904@justinshore.com> George Michaelson wrote: > As a point of view on this, a member of staff from APNIC was doing a > Masters of IT in the last 3-4 years, and had classfull A/B/C addressing > taught to her in the networks unit. She found it quite a struggle to > convince the lecturer that reality had moved on and they had no idea > about CIDR. I'm ok with teaching it to beginners to explain where we came from but that should be it. It should be made excruciatingly clear in the training that it's no longer done that way because we found a MUCH better way of doing things. That said I still occasionally refer to networks in classful terms and I can think of several network engineers who have years of enterprise experience that still don't understand CIDR. Justin From davet1 at gmail.com Tue Oct 13 11:09:05 2009 From: davet1 at gmail.com (David Temkin) Date: Tue, 13 Oct 2009 09:09:05 -0700 Subject: IPv6 in the ARIN region In-Reply-To: <4AD49C7E.6030007@rollernet.us> References: <4AD49C7E.6030007@rollernet.us> Message-ID: <148641da0910130909p4538c67bm28a40e226d6990a4@mail.gmail.com> I contacted 209 yesterday (due to the ongoing Cogent/174 silliness) and it seems like they are willing to turn up customer-facing v6, but have made it a sales process (versus a technical request) and so that complicates things. -Dave On Tue, Oct 13, 2009 at 8:27 AM, Seth Mattinen wrote: > New thread: who will route the full IPv6 table? So far I'm seeing PI > /48's out of 2620:0:/23 from: > > NTT, 2914 > AT&T, 7018 > Sprint, 1239 and 6175 > Hurricane, 6939 > Level 3, 3356 > Global Crossing, 3549 > Qwest, 209 > > Did I miss anyone? Qwest only carries one route (out of 4 total) though, > don't know if that's an exception or they only have one ARIN PI customer. > > ~Seth > > From chris at uplogon.com Tue Oct 13 11:13:44 2009 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 13 Oct 2009 11:13:44 -0500 Subject: IPv6 in the ARIN region In-Reply-To: <148641da0910130909p4538c67bm28a40e226d6990a4@mail.gmail.com> References: <4AD49C7E.6030007@rollernet.us> <148641da0910130909p4538c67bm28a40e226d6990a4@mail.gmail.com> Message-ID: <4AD4A738.1030009@uplogon.com> We are running IPv6 over 209 currently. 2607:F8E8::/32 ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com David Temkin wrote: > I contacted 209 yesterday (due to the ongoing Cogent/174 silliness) and it > seems like they are willing to turn up customer-facing v6, but have made it > a sales process (versus a technical request) and so that complicates things. > > -Dave > > On Tue, Oct 13, 2009 at 8:27 AM, Seth Mattinen wrote: > >> New thread: who will route the full IPv6 table? So far I'm seeing PI >> /48's out of 2620:0:/23 from: >> >> NTT, 2914 >> AT&T, 7018 >> Sprint, 1239 and 6175 >> Hurricane, 6939 >> Level 3, 3356 >> Global Crossing, 3549 >> Qwest, 209 >> >> Did I miss anyone? Qwest only carries one route (out of 4 total) though, >> don't know if that's an exception or they only have one ARIN PI customer. >> >> ~Seth >> >> From mksmith at adhost.com Tue Oct 13 11:31:11 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 13 Oct 2009 09:31:11 -0700 Subject: IPv6 in the ARIN region In-Reply-To: <4AD49C7E.6030007@rollernet.us> References: <4AD49C7E.6030007@rollernet.us> Message-ID: <17838240D9A5544AAA5FF95F8D52031606D0212B@ad-exh01.adhost.lan> > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Tuesday, October 13, 2009 8:28 AM > To: nanog at nanog.org > Subject: IPv6 in the ARIN region > > New thread: who will route the full IPv6 table? So far I'm seeing PI > /48's out of 2620:0:/23 from: > > NTT, 2914 > AT&T, 7018 > Sprint, 1239 and 6175 > Hurricane, 6939 > Level 3, 3356 > Global Crossing, 3549 > Qwest, 209 > You can add Time Warner, AS 4323, to the list. Regards, Mike From RWerber at epiknetworks.com Tue Oct 13 12:08:04 2009 From: RWerber at epiknetworks.com (Ryan Werber) Date: Tue, 13 Oct 2009 10:08:04 -0700 Subject: IPv6 in the ARIN region References: <4AD49C7E.6030007@rollernet.us> Message-ID: <61DCB7099770A24094E1A2B5D6C639C609EEE3@exchange151.Epik.local> You can add TiNet AS3257 to the list. Ryan Werber Sr. Network Engineer Epik Networks -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Tuesday, October 13, 2009 11:28 AM To: nanog at nanog.org Subject: IPv6 in the ARIN region New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 AT&T, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 Did I miss anyone? Qwest only carries one route (out of 4 total) though, don't know if that's an exception or they only have one ARIN PI customer. ~Seth From cspears at eng.oar.net Tue Oct 13 12:56:54 2009 From: cspears at eng.oar.net (Chris Spears) Date: Tue, 13 Oct 2009 13:56:54 -0400 Subject: IPv6 in the ARIN region In-Reply-To: <148641da0910130909p4538c67bm28a40e226d6990a4@mail.gmail.com> References: <4AD49C7E.6030007@rollernet.us> <148641da0910130909p4538c67bm28a40e226d6990a4@mail.gmail.com> Message-ID: <4AD4BF66.6010303@eng.oar.net> David Temkin wrote: > I contacted 209 yesterday (due to the ongoing Cogent/174 silliness) and it > seems like they are willing to turn up customer-facing v6, but have made it > a sales process (versus a technical request) and so that complicates things. > > -Dave > > On Tue, Oct 13, 2009 at 8:27 AM, Seth Mattinen wrote: > >> New thread: who will route the full IPv6 table? So far I'm seeing PI >> /48's out of 2620:0:/23 from: >> >> NTT, 2914 >> AT&T, 7018 >> Sprint, 1239 and 6175 >> Hurricane, 6939 >> Level 3, 3356 >> Global Crossing, 3549 >> Qwest, 209 >> >> Did I miss anyone? Qwest only carries one route (out of 4 total) though, >> don't know if that's an exception or they only have one ARIN PI customer. >> >> ~Seth >> >> Qwest still considers this a beta service. They're routing our /32, but we're still preferring our other peerings. Not to point fingers, but Force10 is advertising a /64 that HE (and subsequently Qwest & others) are accepting. I'd suspect they'll accept most anything. 2620:0:380::/48 x:x:x::x 1537 209 6939 18508 I 2620:0:380:2::/64 x:x:x::x 1537 209 6939 18508 393222 I -- Chris From jack at crepinc.com Tue Oct 13 13:01:54 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 13 Oct 2009 14:01:54 -0400 Subject: IPv6 in the ARIN region In-Reply-To: <61DCB7099770A24094E1A2B5D6C639C609EEE3@exchange151.Epik.local> References: <4AD49C7E.6030007@rollernet.us> <61DCB7099770A24094E1A2B5D6C639C609EEE3@exchange151.Epik.local> Message-ID: <2ad0f9f60910131101l2bbc33f5i66298e7f9885cbb2@mail.gmail.com> OCCAID as well. -Jack Carrozzo On Tue, Oct 13, 2009 at 1:08 PM, Ryan Werber wrote: > You can add TiNet AS3257 to the list. > > > Ryan Werber > Sr. Network Engineer > Epik Networks > > > > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Tuesday, October 13, 2009 11:28 AM > To: nanog at nanog.org > Subject: IPv6 in the ARIN region > > New thread: who will route the full IPv6 table? So far I'm seeing PI > /48's out of 2620:0:/23 from: > > NTT, 2914 > AT&T, 7018 > Sprint, 1239 and 6175 > Hurricane, 6939 > Level 3, 3356 > Global Crossing, 3549 > Qwest, 209 > > Did I miss anyone? Qwest only carries one route (out of 4 total) though, > don't know if that's an exception or they only have one ARIN PI customer. > > ~Seth > > From mpetach at netflight.com Tue Oct 13 13:22:23 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 13 Oct 2009 11:22:23 -0700 Subject: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) In-Reply-To: <4AD3A35A.9070307@rollernet.us> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> <4AD37FF8.2010303@brightok.net> <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> <4AD3A35A.9070307@rollernet.us> Message-ID: <63ac96a50910131122s2db8a588h800c851fcf2f6ec6@mail.gmail.com> On Mon, Oct 12, 2009 at 2:44 PM, Seth Mattinen wrote: > Marco Hogewoning wrote: > > > > As this thread has drifted off topic any way, would it for instance be a > > good idea to simply not accept mail from hosts that clearly use > > autoconfig ie reject all smtp from EUI-64 addresses. Of course not a > > wise idea for your own outbound relays which should handle mail from > > your customers but on the incoming side it might as well save a lot of > > headache and there is no need to keep track of which /64 are access > > networks. > > > > That would be really, really bad. My 3750's won't accept arbitrary > /128's in an ACL unless it's EUI-64 or I make up something similar that > it will like. I'm sure I'm not the only person who owns a 3750. As such, > my mail servers are using EUI-64 addresses. > > ~Seth > > As I understand it, (and Cisco's documentation seems to support this, http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2ZY/command/reference/M1.html#wpxref54198 as an example), if you put a /128 in an ACL, you cannot specify any L4 port information for the address due to the limited width of the TCAM; in order to specify L4 information for the ACL, Cisco stuffs it into bits 24 through 39, losing what information was originally stored in those bits. It just so happens those are the fixed FFFE bits in an EUI-64 address, so if you're using EUI-64, no "real" information is lost. You can do your own non-EUI-64 addressing and still use ACLs with layer 4 port information as long as you don't put any addressing information into bits 24 through 39. Or, if you want to be *really* clever, you can address blocks of hosts with identical functions and identical security rules by assigning them addresses that differ *only* in bits 24 through 39; then, a single L4 /128 rule in you v6 ACL will actually apply to the entire equivalence class of servers, since from the router's perspective, it doesn't distinguish one server from the next as far as applying the ACL rule. However, if you opt to do this, make sure you document it *really* carefully, so the poor engineer who has to pick up after you will understand why the router is treating all of the servers identically, in spite of having what looks to be a single /128 listed in its ACL. ^_^; Matt From wavetossed at googlemail.com Tue Oct 13 13:40:01 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 13 Oct 2009 19:40:01 +0100 Subject: ISP customer assignments In-Reply-To: <4AD4818F.1060701@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <4AD4818F.1060701@justinshore.com> Message-ID: <877585b00910131140p22c7d06eq2529b9444cf2dd6f@mail.gmail.com> > He didn't really give much of a reason for the /127s yet. ?I think it's > coming up in a later session. ?I think it basically boiled down to whether > or not the customer would actually use anything bigger. ?I'll write back > when we get into that discussion. As a service provider, you do not have any control over the customer's environment. As a starter, that means sticking to the /64 per subnet boundary because you don't really know whether a customer might need some devices which assume EUI-64 interface addressing. But when you look at the source of your addresses, the RIRs, you will see that there policy allows for a /56 or a /48 to be assigned to residential customers, your choice. So, why would you want to use longer prefixes? Admittedly, in an enterprise environment where you have total control over the devices on the network, it may be reasonable to use /127s and other odd prefix lengths. But only if you actually have a reason. Not wasting addresses is not a reason, and any IPv6 architectural decisions driven by not wasting addresses, are not reasonable decisions. It is fundamental to IPv6 to use large address blocks that can never possibly be used up, in order to design a network where your design decisions are based on solid technical reasoning, and that design can remain unchanged even if you massively scale up the number of devices on your network. --Michael Dillon From mpetach at netflight.com Tue Oct 13 13:46:39 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 13 Oct 2009 11:46:39 -0700 Subject: ISP customer assignments In-Reply-To: <4AD3F4C7.70103@emanon.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> Message-ID: <63ac96a50910131146p78a2aa32o95069e30ee7e7f46@mail.gmail.com> On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris wrote: > How many addresses do you like on point-to-point circuits? > > Scott > > I allocate a /64, but currently I configure only a /127 subnet on the actual interface. That prevents the neighbor table explosion/NS/ND traffic flooding challenges that can occur otherwise if you configure the link as a /64, and some not-nice person decides to start ping sweeping or nmapping the subnet; your router has to send out NS messages for every address in the /64 being probed, update the neighbor table with the incomplete entry, then flush it out when no ND message is seen. On a point-to-point link between routers you're never going to run stateless autoconfiguration, so there's not much downside to configuring it as a /127. Still...just in case, I do allocate the whole /64 for the link, so that if in the future it turns out that for some reason it really, *really* does have to be a /64 configured on it, I can make the change just by adjusting masks on each end, rather than having to actually renumber the entire network. *shrug* As always, your mileage will vary, but this has worked out well for me so far. Matt From wavetossed at googlemail.com Tue Oct 13 13:47:42 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 13 Oct 2009 19:47:42 +0100 Subject: ISP customer assignments In-Reply-To: <4AD3F4C7.70103@emanon.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> Message-ID: <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> > How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like "a /127" or "a /64" will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 The right decision for one network, or for one point in the topology, might not be the right decision for some other place. Some people may learn this by rote as a rule to always use a /126 or a /112 for point-to-point links, but even then it is best to understand why. --Michael Dillon From sethm at rollernet.us Tue Oct 13 13:52:36 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 13 Oct 2009 11:52:36 -0700 Subject: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering) In-Reply-To: <63ac96a50910131122s2db8a588h800c851fcf2f6ec6@mail.gmail.com> References: <4217E699-7F73-48DA-86B3-D0CA3D8C90D5@ianai.net> <200910121025.07137.michael@linuxmagic.com> <20091012182847.GI5163@dan.olp.net> <4AD37FF8.2010303@brightok.net> <72A0BEAA-1C0C-417B-B9B3-6C19C6572487@marcoh.net> <4AD3A35A.9070307@rollernet.us> <63ac96a50910131122s2db8a588h800c851fcf2f6ec6@mail.gmail.com> Message-ID: <4AD4CC74.4060503@rollernet.us> Matthew Petach wrote: > > As I understand it, (and Cisco's documentation seems to support this, > http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2ZY/command/reference/M1.html#wpxref54198 > as an example), if you put a /128 in an ACL, you cannot specify any L4 port > information for the address due to the limited width of the TCAM; in > order to specify L4 information for the ACL, Cisco stuffs it into bits 24 > through 39, losing what information was originally stored in those bits. > It just so happens those are the fixed FFFE bits in an EUI-64 address, > so if you're using EUI-64, no "real" information is lost. You can do your > own non-EUI-64 addressing and still use ACLs with layer 4 port information > as long as you don't put any addressing information into bits 24 through 39. > Interesting; makes sense though. Thanks for the explanation. ~Seth From wavetossed at googlemail.com Tue Oct 13 13:54:36 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 13 Oct 2009 19:54:36 +0100 Subject: ISP customer assignments In-Reply-To: <4AD4A3F9.6010904@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> Message-ID: <877585b00910131154o195f41f6y42da5be13be120a0@mail.gmail.com> > I'm ok with teaching it to beginners to explain where we came from but that > should be it. But why does that have to be done first? Why can't they teach current best practice in addressing, and then point out that historically it was done different but that caused problems which led to today's system? > ?That said I still occasionally refer to networks in classful terms > and I can think of several network engineers who have years of enterprise > experience that still don't understand CIDR. I'm very careful about classful terminology because I work with a team of engineers who still occasionally must deal with a customer network (using very old gear) which requires class C addressing. For those who don't know what a Class C address is, it is an IP address in the range 192.0.0.0 to 223.255.255.255, i.e. it begins with binary 110, and the network prefix is fixed at /24. This means that 10.2.3/24 is not a class C address, and 192.2/16 is not a legal address block. --Michael Dillon From jabley at hopcount.ca Tue Oct 13 14:56:22 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Oct 2009 15:56:22 -0400 Subject: ISP customer assignments In-Reply-To: <63ac96a50910131146p78a2aa32o95069e30ee7e7f46@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <63ac96a50910131146p78a2aa32o95069e30ee7e7f46@mail.gmail.com> Message-ID: On 2009-10-13, at 14:46, Matthew Petach wrote: > I allocate a /64, but currently I configure only a /127 subnet on the > actual interface. For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet. In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.) A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config. It seemed to work. BRAS was a Juniper E-series (test box was an ERX310). Joe From marcoh at marcoh.net Tue Oct 13 15:01:14 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 13 Oct 2009 22:01:14 +0200 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <63ac96a50910131146p78a2aa32o95069e30ee7e7f46@mail.gmail.com> Message-ID: <0BA4F26E-A02F-4FC2-96FF-2E9761E28811@marcoh.net> On Oct 13, 2009, at 9:56 PM, Joe Abley wrote: > > On 2009-10-13, at 14:46, Matthew Petach wrote: > >> I allocate a /64, but currently I configure only a /127 subnet on the >> actual interface. > > For BRAS/PPPoE deployments you're dealing with a point-to-point > link, so in principle you can number the endpoints using whatever > you want. They're just host addresses and interface routes when it > comes down to it. There's no need to number both ends within a > single conventional subnet. > > In the test deployment I did earlier in the year I defined a pool of > link addresses per BRAS (one /64 prefix per BRAS) and handed out one > to each subscriber using ND/RA after IPv6CP had completed. To the > subscriber that looked like a /128 host route, with some other > arbitrary address on the far side. (We could have done it with > RADIUS too, but having a static link address didn't seem > particularly important.) > > A sub-side static /48 was then assigned via RADIUS and a route > installed on the BRAS side, with DHCPv6 PD available as an option > for clients who want auto-configuration rather than static config. > > It seemed to work. BRAS was a Juniper E-series (test box was an > ERX310). We run roughly the same, although we skip the whole globalscope address on the PPP, running localscope only works for the CPE we tested so far. MarcoH From andyring at inebraska.com Tue Oct 13 15:08:46 2009 From: andyring at inebraska.com (Andy Ringsmuth) Date: Tue, 13 Oct 2009 15:08:46 -0500 Subject: DreamHost admin contacts Message-ID: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> Any chance there's someone from DreamHost on NANOG? Or that someone might have a way to reach them other than by filing a trouble ticket with them? POP has seemingly been down all day, with Webmail sporadic at best. Just migrated my company's e-mail over to them last week, and with this, of course our company president has been putting a severe squeeze on me to fix it. Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. Much appreciated! -Andy From justin at justinshore.com Tue Oct 13 15:32:51 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 13 Oct 2009 15:32:51 -0500 Subject: ISP customer assignments In-Reply-To: <20091013141523.GA5028@dan.olp.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <20091013141523.GA5028@dan.olp.net> Message-ID: <4AD4E3F3.7070809@justinshore.com> Dan White wrote: > I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix > of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda > in the same boat, but we expect to be able to gracefully transition to dual > stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring > the modems into bridged mode and leaving the layer 3 up to the customer's > router. > > We're also in the process of budgeting for a new broadband aggregation > router next year that will handle IPv6. > Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet > QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or > Cisco. In Pannaway's case they want to pretend to be in the router business and we ended up buying their BARs. Their DSLAMs (BASs) are aggregated into their BARs and the BAR ring terminates on my Cisco core. I would love to eliminate the BARs from the equation but that's not an option. I've been by several (dozen) people that their Minnesota Pannaway office stopped selling the BARs and instead worked with Cisco for aggregation. I've also been told by Cisco folks that numerous sites are trying to get Cisco to take the Pannaway BARs in on trade-in. It would appear that no one like the BARs. Occam did it right. They didn't try to pretend to be in the router business. They stuck with L2. We're also in a bit of a pickle because we're using "smart" DSL modems/routers. I've argued for years for dumb DSL modems that had no routing/NAT capabilities at all. Unfortunately I didn't win that argument. Now we have what amount to CPEs that do not support IPv6. Whether they'll even pass IPv6 packets in a bridging mode is yet to be determined. Since some of the modems are Pannaway and given my experience with Pannaway and trying to bridge things over it without Pannaway messing with it in the middle (VLAN carrying IS-IS for example), I fully expect problems... It's no secret; I do not recommend Pannaway products based on my firsthand experience. Their SE actually told us 2 years ago that IPv6 was a fad and would never be adopted. Justin From brandon.galbraith at gmail.com Tue Oct 13 15:34:47 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 13 Oct 2009 13:34:47 -0700 Subject: DreamHost admin contacts In-Reply-To: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> Message-ID: <366100670910131334i57bea3d0o88daf8f2c63c12cd@mail.gmail.com> Have had great luck (no outages) with Rackspace Mail (formerly Mailtrust). Quite affordable as well. Disclaimer: no affiliation, just a satisfied customer On 10/13/09, Andy Ringsmuth wrote: > Any chance there's someone from DreamHost on NANOG? Or that someone > might have a way to reach them other than by filing a trouble ticket > with them? POP has seemingly been down all day, with Webmail sporadic > at best. > > Just migrated my company's e-mail over to them last week, and with > this, of course our company president has been putting a severe > squeeze on me to fix it. > > Barring that, what recommendations might the NANOG community have for > an extremely rock-solid e-mail hosting company? I realize that may > mean self-promotion, but hey, bring it on. > > > Much appreciated! > > > -Andy > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From jsaxe at briworks.com Tue Oct 13 15:48:25 2009 From: jsaxe at briworks.com (Jeff Saxe) Date: Tue, 13 Oct 2009 13:48:25 -0700 Subject: DreamHost admin contacts In-Reply-To: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> Message-ID: <1404447E820C6C4B8C32C28EEDF4362212EC42287E@EXVMBX020-11.exch020.serverdata.net> > Barring that, what recommendations might the NANOG community have for > an extremely rock-solid e-mail hosting company? I realize that may > mean self-promotion, but hey, bring it on. Some people, when they say "email hosting company", inherently mean "hosting specifically of Microsoft Exchange email, contacts, and calendar". If that's what you're after, then I would recommend my employer's chosen hosted Exchange partner, Intermedia . They maintain server farms of Exchange clusters, and they have a very good customer portal (both at the administrator-of-the-site level and the individual end user). They also have an FTP-up-a-PST-file-and-merge-it-into-a-mailbox function that makes the initial migration from some other Exchange repository faster and more parallelizable than without it. We are extremely pleased, and we have basically stopped hosting Exchange for our own customers on our own in-house hardware, just using Intermedia as a branded service. Depending on your requirements (audit copy of every single email and and out, mandatory retention periods, BlackBerry connectivity, etc.), they probably can do anything you're asking for. Their uptime has been stellar except for one morning of about 3 to 4 hours, when a major MAN cable was busted around Manhattan somewhere and disconnected their datacenter. Other than that, we have not had the long, painful, tension-filled, customer-angering outage periods that we used to have with another provider which shall not be named. (OK, it will: GroupSpark. Stay far away from them.) -- Jeff Saxe Network Engineer, Blue Ridge InternetWorks Charlottesville, VA www.briworks.com From charles at thewybles.com Tue Oct 13 15:53:54 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 13 Oct 2009 13:53:54 -0700 Subject: DreamHost admin contacts In-Reply-To: <1404447E820C6C4B8C32C28EEDF4362212EC42287E@EXVMBX020-11.exch020.serverdata.net> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> <1404447E820C6C4B8C32C28EEDF4362212EC42287E@EXVMBX020-11.exch020.serverdata.net> Message-ID: <4AD4E8E2.3010503@thewybles.com> +1 for intermeida. I'm digging it. Though I've yet to find a way to turn off copying the originator of the e-mail when hitting reply all. Anyone know how to fix that? On 10/13/09 1:48 PM, Jeff Saxe wrote: >> Barring that, what recommendations might the NANOG community have for >> an extremely rock-solid e-mail hosting company? I realize that may >> mean self-promotion, but hey, bring it on. > > Some people, when they say "email hosting company", inherently mean "hosting specifically of Microsoft Exchange email, contacts, and calendar". If that's what you're after, then I would recommend my employer's chosen hosted Exchange partner, Intermedia. They maintain server farms of Exchange clusters, and they have a very good customer portal (both at the administrator-of-the-site level and the individual end user). They also have an FTP-up-a-PST-file-and-merge-it-into-a-mailbox function that makes the initial migration from some other Exchange repository faster and more parallelizable than without it. We are extremely pleased, and we have basically stopped hosting Exchange for our own customers on our own in-house hardware, just using Intermedia as a branded service. > From dwhite at olp.net Tue Oct 13 15:56:15 2009 From: dwhite at olp.net (Dan White) Date: Tue, 13 Oct 2009 15:56:15 -0500 Subject: ISP customer assignments In-Reply-To: <4AD4E3F3.7070809@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <20091013141523.GA5028@dan.olp.net> <4AD4E3F3.7070809@justinshore.com> Message-ID: <20091013205615.GD10190@dan.olp.net> On 13/10/09?15:32?-0500, Justin Shore wrote: > one like the BARs. Occam did it right. They didn't try to pretend to be > in the router business. They stuck with L2. Occam did it partially right. They're half-bridging only - not true layer 2 to an aggregator (which is not necessary in their scenario). The problem with the access vendor doing half-bridging is that they have to be very layer-3 smart, and Occam was not quite there for IPv6 last time I worked with them (about 6 months ago). > It's no secret; I do not recommend Pannaway products based on my > firsthand experience. Their SE actually told us 2 years ago that IPv6 > was a fad and would never be adopted. I haven't really been happy with any DSL vendor's response to my questions about IPv6. We happened to choose Calix, which is not particularly IPv6 friendly, but were successful in getting commitments from them to support IPv6 pass through. I have little doubt that Pannaway could implement IPv6, they just need to get enough demand from customers to make it worth their while. -- Dan White From justin at justinshore.com Tue Oct 13 16:11:06 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 13 Oct 2009 16:11:06 -0500 Subject: ISP customer assignments In-Reply-To: <20091013205615.GD10190@dan.olp.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <20091013141523.GA5028@dan.olp.net> <4AD4E3F3.7070809@justinshore.com> <20091013205615.GD10190@dan.olp.net> Message-ID: <4AD4ECEA.2010601@justinshore.com> Dan White wrote: > Occam did it partially right. They're half-bridging only - not true layer 2 > to an aggregator (which is not necessary in their scenario). The problem > with the access vendor doing half-bridging is that they have to be very > layer-3 smart, and Occam was not quite there for IPv6 last time I worked > with them (about 6 months ago). When we did a RFP with them they didn't support v6 yet but they also wouldn't get in the way of passing v6 over them (minus the DHCP snooping/learning features of course). That was 2 years ago. I haven't looked at them since but they said that they'd work on it. > I haven't really been happy with any DSL vendor's response to my questions > about IPv6. We happened to choose Calix, which is not particularly IPv6 > friendly, but were successful in getting commitments from them to support > IPv6 pass through. None of the FTTH vendors we vetted supported v6 but at least a few said that they'd work on it. Pannaway's response though was priceless. > I have little doubt that Pannaway could implement IPv6, they just need to > get enough demand from customers to make it worth their while. Pannaway was bought a while back by Enablence. Hopefully they will drive a bit more clue into the products. Hopefully that SE isn't there anymore or if he is hopefully he's not driving product development. His other 2 answers about QoS not being needed because our links were sustaining saturation (microbursts anyone?) and that we didn't need an IGP because our network wasn't big enough and that static routing would do (for just shy of 100 routing devices in 3 POPs) was the icing on the cake. Unfortunately the decision was made to eat the cake anyway. Justin From justin at justinshore.com Tue Oct 13 16:19:21 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 13 Oct 2009 16:19:21 -0500 Subject: DreamHost admin contacts In-Reply-To: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> Message-ID: <4AD4EED9.1030102@justinshore.com> Andy Ringsmuth wrote: > Barring that, what recommendations might the NANOG community have for an > extremely rock-solid e-mail hosting company? I realize that may mean > self-promotion, but hey, bring it on. I would strongly recommend against GoDaddy's hosted email. See my earlier post on 9/8 about their idiotic use of ancient SORBS data. Justin From cabenth at gmail.com Tue Oct 13 16:24:18 2009 From: cabenth at gmail.com (eric clark) Date: Tue, 13 Oct 2009 14:24:18 -0700 Subject: ISP customer assignments In-Reply-To: <877585b00910131140p22c7d06eq2529b9444cf2dd6f@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <4AD4818F.1060701@justinshore.com> <877585b00910131140p22c7d06eq2529b9444cf2dd6f@mail.gmail.com> Message-ID: <5b602b520910131424k2d8d5e2eue645cb8edd4384ec@mail.gmail.com> So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. Eric Clark From charles at thewybles.com Tue Oct 13 16:24:35 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 13 Oct 2009 14:24:35 -0700 Subject: DreamHost admin contacts In-Reply-To: <4AD4EED9.1030102@justinshore.com> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> <4AD4EED9.1030102@justinshore.com> Message-ID: <4AD4F013.1080100@thewybles.com> On 10/13/09 2:19 PM, Justin Shore wrote: > Andy Ringsmuth wrote: >> Barring that, what recommendations might the NANOG community have for >> an extremely rock-solid e-mail hosting company? I realize that may >> mean self-promotion, but hey, bring it on. > > I would strongly recommend against GoDaddy's hosted email. See my > earlier post on 9/8 about their idiotic use of ancient SORBS data. I would strongly recommend against GoDaddy's hosted anything. See for their idiotic . There fixed that for you :) From john-nanog at johnpeach.com Tue Oct 13 16:33:56 2009 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 13 Oct 2009 17:33:56 -0400 Subject: DreamHost admin contacts In-Reply-To: <4AD4F013.1080100@thewybles.com> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> <4AD4EED9.1030102@justinshore.com> <4AD4F013.1080100@thewybles.com> Message-ID: <20091013173356.794b3587@milhouse.peachfamily.net> On Tue, 13 Oct 2009 14:24:35 -0700 Charles Wyble wrote: > > > On 10/13/09 2:19 PM, Justin Shore wrote: > > Andy Ringsmuth wrote: > >> Barring that, what recommendations might the NANOG community have for > >> an extremely rock-solid e-mail hosting company? I realize that may > >> mean self-promotion, but hey, bring it on. > > > > I would strongly recommend against GoDaddy's hosted email. See my > > earlier post on 9/8 about their idiotic use of ancient SORBS data. > > I would strongly recommend against GoDaddy's hosted anything. See > for their idiotic . s/hosted// > > There fixed that for you :) > > -- John From dmm at 1-4-5.net Tue Oct 13 17:50:17 2009 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 13 Oct 2009 15:50:17 -0700 Subject: [NANOG-announce] A few notes on recent events and items of interest for NANOG 47 Message-ID: <20091013225017.GA9381@1-4-5.net> Folks, A few notes on recent events and items of interest: (i). The NANOG Steering Committee approved the 2009 Election Ballot. It will be posted on Sunday, October 18 by noon when the polls open. (ii). Charter amendments http://nanog.org/governance/elections/2009elections/2009charteramend.php (iii). SC Candidates http://nanog.org/governance/elections/2009elections/2009sc_candidates.php (iv). Current PC Candidates http://nanog.org/governance/elections/2009elections/2009pc_candidates.php (v). Important dates - Voting for the 2009/2010 NANOG SC opens: 1200 EDT 10-18-09 - Voting for the 2009/2010 NANOG SC closes: 0915 EDT 10-21-09 - PC Candidate Information posted/nominations close: 10-19-09 The NANOG 47 agenda has been posted, so please check that out. We have a great line-up of topics and presenters. We hope to see many more in Dearborn. For those who are considering a NANOG Sponsorship, we encourage you to contact marketing at merit.edu. The community really appreciates the support and vendors do have a wonderful opportunity to showcase their products. Thanks, and see you all in Dearborn. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From lists at memetic.org Tue Oct 13 18:11:06 2009 From: lists at memetic.org (Adam Armstrong) Date: Wed, 14 Oct 2009 00:11:06 +0100 Subject: ISP customer assignments In-Reply-To: <5b602b520910131424k2d8d5e2eue645cb8edd4384ec@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <4AD4818F.1060701@justinshore.com> <877585b00910131140p22c7d06eq2529b9444cf2dd6f@mail.gmail.com> <5b602b520910131424k2d8d5e2eue645cb8edd4384ec@mail.gmail.com> Message-ID: <4AD5090A.50807@memetic.org> eric clark wrote: > So far, I have only dabbled with IPv6, but my reading of the RFCs is that > VLSM for lengths beyond /64 is not required. Subsequently, to use anything > longer is an enormous gamble in an enterprise environment. I envision > upgrading code one day and finding that your /127 isn't supported any more > and they forgot to mention it. I'll stick to /64, though it does seem a > horrible waste of space. > > Someone else might have read the RFC differently though. > I'm sure there's an RFC somewhere talking about Classful addressing pre-CIDR. Perhaps we should stop using CIDR in IPv4. It might stop working one day. ;) Operational reality helps to refine RFCs. Many people are already using longer prefixes for infrastructure and other purposes, so it's unlikely to go away. The only real issue is that some old hardware may not support prefixes longer than /64 in hardware and so may drop to software routing. I don't know of any examples of this though. adam. From cmadams at hiwaay.net Tue Oct 13 18:26:20 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 13 Oct 2009 18:26:20 -0500 Subject: ISP customer assignments In-Reply-To: <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> Message-ID: <20091013232620.GB612455@hiwaay.net> Once upon a time, Michael Dillon said: > > How many addresses do you like on point-to-point circuits? > > That will become one of those great interview questions, because anyone who says > something like "a /127" or "a /64" will be someone that you probably > don't want to hire. > > The right answer is to explain that there are some issues surrounding > the choice of > addressing on point-to-point circuits and there has even been an RFC > published discussing > these issues, RFC 3627 Still learning here, so please go easy... I read the above, and I see section 4 item 3 says: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and "16 bits for node identifiers" on a point-to-point link? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cordmacleod at gmail.com Tue Oct 13 18:34:27 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Tue, 13 Oct 2009 16:34:27 -0700 Subject: ISP customer assignments In-Reply-To: <20091013232620.GB612455@hiwaay.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> Message-ID: <576CA6A0-72F2-469B-991B-22A8511DBC68@gmail.com> On Oct 13, 2009, at 4:26 PM, Chris Adams wrote: > Once upon a time, Michael Dillon said: >>> How many addresses do you like on point-to-point circuits? >> >> That will become one of those great interview questions, because >> anyone who says >> something like "a /127" or "a /64" will be someone that you probably >> don't want to hire. >> >> The right answer is to explain that there are some issues surrounding >> the choice of >> addressing on point-to-point circuits and there has even been an RFC >> published discussing >> these issues, RFC 3627 > > Still learning here, so please go easy... > > I read the above, and I see section 4 item 3 says: > > The author feels that if /64 cannot be used, /112, reserving the > last > 16 bits for node identifiers, has probably the least amount of > drawbacks (also see section 3). > > I guess I'm missing something; what in section 3 is this referring to? > I can understand /64 or /126 (or maybe /124 if you were going to > delegate reverse DNS?), but why /112 and "16 bits for node > identifiers" > on a point-to-point link? I'm actually completely unclear why people would use anything but a / 126 in 90% or more of cases. For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with IPv4? What's the point of a /64 on a point to point link? I'm not clear why people would intentionally be so frivolous with their IP space simply for the sake of "because I can." From kloch at kl.net Tue Oct 13 19:27:55 2009 From: kloch at kl.net (Kevin Loch) Date: Tue, 13 Oct 2009 20:27:55 -0400 Subject: ISP customer assignments In-Reply-To: <20091013232620.GB612455@hiwaay.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> Message-ID: <4AD51B0B.9090300@kl.net> Chris Adams wrote: > I guess I'm missing something; what in section 3 is this referring to? > I can understand /64 or /126 (or maybe /124 if you were going to > delegate reverse DNS?), but why /112 and "16 bits for node identifiers" > on a point-to-point link? The only thing special about /112 is that it is on a ":" boundary so it makes for some nice numbering plans: Let's say you set aside 2001:xxxx:0:1::/64 for /112's link 1: 2001:xxxx:0:1::1:1 2001:xxxx:0:1::1:2 link 2: 2001:xxxx:0:1::2:1 2001:xxxx:0:1::2:2 This :1, :2 arrangement seems to be common but for internal links you could make the last hextet be a unique id for the specific router. That could use more than a few bits in a large network. - Kevin From swm at emanon.com Tue Oct 13 19:36:39 2009 From: swm at emanon.com (Scott Morris) Date: Tue, 13 Oct 2009 20:36:39 -0400 Subject: ISP customer assignments In-Reply-To: <63ac96a50910131146p78a2aa32o95069e30ee7e7f46@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <63ac96a50910131146p78a2aa32o95069e30ee7e7f46@mail.gmail.com> Message-ID: <4AD51D17.2010606@emanon.com> That was the point. :) Scott Matthew Petach wrote: > > > On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris > wrote: > > How many addresses do you like on point-to-point circuits? > > Scott > > > I allocate a /64, but currently I configure only a /127 subnet on the > actual interface. That prevents the neighbor table explosion/NS/ND > traffic flooding challenges that can occur otherwise if you configure > the link as a /64, and some not-nice person decides to start ping > sweeping or nmapping the subnet; your router has to send out NS > messages for every address in the /64 being probed, update the > neighbor table with the incomplete entry, then flush it out when > no ND message is seen. On a point-to-point link between > routers you're never going to run stateless autoconfiguration, > so there's not much downside to configuring it as a /127. > > Still...just in case, I do allocate the whole /64 for the link, so > that if in the future it turns out that for some reason it really, > *really* does have to be a /64 configured on it, I can make the > change just by adjusting masks on each end, rather than > having to actually renumber the entire network. > > *shrug* As always, your mileage will vary, but this has > worked out well for me so far. > > Matt > From swm at emanon.com Tue Oct 13 19:42:44 2009 From: swm at emanon.com (Scott Morris) Date: Tue, 13 Oct 2009 20:42:44 -0400 Subject: ISP customer assignments In-Reply-To: <5b602b520910131424k2d8d5e2eue645cb8edd4384ec@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <4AD4818F.1060701@justinshore.com> <877585b00910131140p22c7d06eq2529b9444cf2dd6f@mail.gmail.com> <5b602b520910131424k2d8d5e2eue645cb8edd4384ec@mail.gmail.com> Message-ID: <4AD51E84.7030808@emanon.com> While entirely possible, I actually view it going the other way. RFC 3627 points out some nice issues as far as DAD and anycast operation is concerned, but what I'd see (just my random opinion as I haven't bothered to write an RFC) is that it would make entirely much more sense to come up with a structure to STOP the anycast performance on a link that is point-to-point. While there are 340 undecillion addresses, that doesn't mean we need to waste a /64 on a link that will possibly only have two addresses anyway. My two cents. Scott eric clark wrote: > So far, I have only dabbled with IPv6, but my reading of the RFCs is that > VLSM for lengths beyond /64 is not required. Subsequently, to use anything > longer is an enormous gamble in an enterprise environment. I envision > upgrading code one day and finding that your /127 isn't supported any more > and they forgot to mention it. I'll stick to /64, though it does seem a > horrible waste of space. > > Someone else might have read the RFC differently though. > > > Eric Clark > > From bicknell at ufp.org Tue Oct 13 19:48:17 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 13 Oct 2009 17:48:17 -0700 Subject: ISP customer assignments In-Reply-To: <20091013232620.GB612455@hiwaay.net> References: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> Message-ID: <20091014004817.GA75629@ussenterprise.ufp.org> In a message written on Tue, Oct 13, 2009 at 06:26:20PM -0500, Chris Adams wrote: > The author feels that if /64 cannot be used, /112, reserving the last > 16 bits for node identifiers, has probably the least amount of > drawbacks (also see section 3). > > I guess I'm missing something; what in section 3 is this referring to? > I can understand /64 or /126 (or maybe /124 if you were going to > delegate reverse DNS?), but why /112 and "16 bits for node identifiers" > on a point-to-point link? We use /112's, and do so for two (and a half) reasons: 1) If you think of all possible "network to network" interconnects they include the simple case like a single router on both ends, but they also include cases like two routers on one or both ends, and optionally with VRRP/HSRP. Maximally it appears 6 IP's may be required (two routers both ends, plus vrrp on each, statics at the VRRP). So it makes sense to have a 8 or 16 block of IP's per link so you never have to renumber the link if you switch these configurations. 2) Colon's separate 16 bit chunks in IPv6. /112's allow XXXX::1, XXXX::2 to be your IP's. The half a reason, if you have a /64 dedicate to point to point links, and use /112's, you have 2^(112-64) possible links. That's 281 trillion point to point links. Given 1, and 2, and the numbers /127's, /126's, /125's don't make any sense when you can standardize on one size fits all, and never run out. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mysidia at gmail.com Tue Oct 13 20:12:32 2009 From: mysidia at gmail.com (James Hess) Date: Tue, 13 Oct 2009 20:12:32 -0500 Subject: ISP customer assignments In-Reply-To: <576CA6A0-72F2-469B-991B-22A8511DBC68@gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <576CA6A0-72F2-469B-991B-22A8511DBC68@gmail.com> Message-ID: <6eb799ab0910131812q4f54140cyaadd4a27426250d9@mail.gmail.com> On Tue, Oct 13, 2009 at 6:34 PM, Cord MacLeod wrote: > IPv4? What's the point of a /64 on a point to point link? I'm not clear IP Addressing uniformity and simplicity. Use of /127s for Point-to-Point links introduces addressing complexity that may be avoided in V6: the scarcity of IPs necessitated it in V4 . At least /112 lies on an even 16-bit boundary, and that makes it the longest prefix that is a very good choice, if you do need a non-standard mask. Unless you have only a /32 of V6 space and 1 billion P2Pt links you need (or similar scenario), there is no utility in practicing rampant prefix length expansion, for the purpose of conservation (there may be other reasons such as preventing autoconfig). > For all intensive purposes a /126 translates to a /30 > in IPv4. ?Do people assign /24's to their point to point links today with Not really; there's a massive difference of scale. Say there's a big vat that contains all gold in the universe, you get to bring home one bucket of gold flakes to allocate to your customers. In the V4 universe, well you got a /19.. You got a 60 kilogram bucket, and a /30 represents a 1 troy ounce scoop taken out of that bucket.. In the V6 universe, even if you got a measly /48: one /64 from that is a 1 troy ounce gold flake out of your 2000 kilogram bucket. Should you really be worried about cutting up that flake? In reality... if you're an ISP the worst you have is a /32, you can think of a /48 that way, you do have 65536 of those /48s, also known as a 133,588,416kg bucket, since your /32 has a maximum of 4 billion /64s. Normally when you have a P2P link, it will mean you connect an end site also: that end site gets a /48 (Per the justification that allows you as an ISP to get a /32, such a large allocation). After assigning 65536 /64s, or 256 /64s (if you give out /56s to end sites) which you already do for each _end site_ as standard address allocation practice in V6, what's another single /64, seriously? -- -J From cmadams at hiwaay.net Tue Oct 13 20:14:40 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 13 Oct 2009 20:14:40 -0500 Subject: ISP customer assignments In-Reply-To: <20091014004817.GA75629@ussenterprise.ufp.org> References: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> Message-ID: <20091014011440.GC612455@hiwaay.net> Once upon a time, Leo Bicknell said: > 2) Colon's separate 16 bit chunks in IPv6. /112's allow XXXX::1, > XXXX::2 to be your IP's. Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jfbeam at gmail.com Tue Oct 13 20:19:19 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 13 Oct 2009 21:19:19 -0400 Subject: ISP customer assignments In-Reply-To: <4AD4818F.1060701@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <4AD4818F.1060701@justinshore.com> Message-ID: On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore wrote: > He didn't really give much of a reason for the /127s yet. I think it's > coming up in a later session. I think it basically boiled down to > whether or not the customer would actually use anything bigger. I'll > write back when we get into that discussion. It's the IPv6 equiv of an IPv4 /30 link network. Then a /64 or whatever can be aimed to that link address. This is exactly what Bellsouth does for business DSL: the link has a dynamic address and your netblock is then routed to it. (this is confusing and unworkable for a lot of cheap hardware.) From bicknell at ufp.org Tue Oct 13 20:24:09 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 13 Oct 2009 18:24:09 -0700 Subject: ISP customer assignments In-Reply-To: <20091014011440.GC612455@hiwaay.net> References: <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> Message-ID: <20091014012409.GA78079@ussenterprise.ufp.org> In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams wrote: > I would expect you just assign static addresses to servers. Are there > pros/cons to using /64 or something else there? If I'm statically > assigning IP (and DNS, etc. servers) info, why would I not just > configure the gateway there as well (especially if you just make all > local router interfaces ::1)? All of our servers are in binary coded hex. :) That is, if your IPv4 address is 10.12.3.187, your IPv6 address is A:B:C:D::187. The router is ::1, just as in IPv4, and servers have static routes. We still use /64's everywhere. You may want to use temporary (privacy) addresses outbound. You many want to allow a server to use EUI-64 to get an address while doing an install, or similar. > What about anycast-type addresses (e.g. DNS servers)? I route a few > server IPv4 /32s around in my network; do you assign a /128, a /64 (with > only one address in use), a /112, or something else? /128's for loopbacks, anycast addreses, and similar here. Typically out of a loopback /64. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From trejrco at gmail.com Tue Oct 13 20:31:36 2009 From: trejrco at gmail.com (TJ) Date: Tue, 13 Oct 2009 21:31:36 -0400 Subject: ISP customer assignments In-Reply-To: <20091014011440.GC612455@hiwaay.net> References: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> Message-ID: <002301ca4c6e$12e8f150$38bad3f0$@com> " What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else?" Yes, on any sort of multi-access segment you really should use /64s. A little less stringent on an all router segment perhaps, but even then I shoot for /64s on anything that is not a PtP link ... /TJ -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Tuesday, October 13, 2009 9:15 PM To: nanog at nanog.org Subject: Re: ISP customer assignments Once upon a time, Leo Bicknell said: > 2) Colon's separate 16 bit chunks in IPv6. /112's allow XXXX::1, > XXXX::2 to be your IP's. Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? From marka at isc.org Tue Oct 13 20:38:40 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 14 Oct 2009 12:38:40 +1100 Subject: ISP customer assignments In-Reply-To: Your message of "Tue, 13 Oct 2009 21:19:19 EDT." References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <4AD4818F.1060701@justinshore.com> Message-ID: <200910140138.n9E1ceCI041678@drugs.dv.isc.org> In message , "Ricky Beam" writes: > On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore > wrote: > > He didn't really give much of a reason for the /127s yet. I think it's > > coming up in a later session. I think it basically boiled down to > > whether or not the customer would actually use anything bigger. I'll > > write back when we get into that discussion. > > It's the IPv6 equiv of an IPv4 /30 link network. Then a /64 or whatever > can be aimed to that link address. This is exactly what Bellsouth does > for business DSL: the link has a dynamic address and your netblock is then > routed to it. (this is confusing and unworkable for a lot of cheap > hardware.) Just use a /64 for the customer link. That allows them to have a CGA if they need one. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at daork.net Tue Oct 13 21:04:24 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 14 Oct 2009 15:04:24 +1300 Subject: ISP customer assignments In-Reply-To: <20091014011440.GC612455@hiwaay.net> References: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> Message-ID: <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> On 14/10/2009, at 2:14 PM, Chris Adams wrote: > What about web-hosting type servers? Right now, I've got a group of > servers in a common IPv4 subnet (maybe a /26), with a /24 or two > routed > to each server for hosted sites. What is the IPv6 equivalent? I can > see a /64 for the common subnet, but what to route for aliased IPs for > web hosts? It is kind of academic right now, since our hosting > control > panel software doesn't handle IPv6, but I certainly won't be putting > 2^64 sites on a single server. Use a /112 here again as well? Use a > /64 per server because I can? Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router? -- Nathan Ward From mpalmer at hezmatt.org Tue Oct 13 21:10:23 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 14 Oct 2009 13:10:23 +1100 Subject: DreamHost admin contacts In-Reply-To: <366100670910131334i57bea3d0o88daf8f2c63c12cd@mail.gmail.com> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> <366100670910131334i57bea3d0o88daf8f2c63c12cd@mail.gmail.com> Message-ID: <20091014021023.GP3191@hezmatt.org> On Tue, Oct 13, 2009 at 01:34:47PM -0700, Brandon Galbraith wrote: > Have had great luck (no outages) with Rackspace Mail (formerly > Mailtrust). Quite affordable as well. It's definitely luck that's kept you outage free -- my former employer outsourced all their customer e-mail services to Mailtrust, and had no end of problems with it. They're on my "avoid with extreme prejudice" list. - Matt From cmadams at hiwaay.net Tue Oct 13 21:49:57 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 13 Oct 2009 21:49:57 -0500 Subject: ISP customer assignments In-Reply-To: <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> References: <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> Message-ID: <20091014024957.GD612455@hiwaay.net> Once upon a time, Nathan Ward said: > On 14/10/2009, at 2:14 PM, Chris Adams wrote: > >What about web-hosting type servers? Right now, I've got a group of > >servers in a common IPv4 subnet (maybe a /26), with a /24 or two > >routed > >to each server for hosted sites. What is the IPv6 equivalent? I can > >see a /64 for the common subnet, but what to route for aliased IPs for > >web hosts? It is kind of academic right now, since our hosting > >control > >panel software doesn't handle IPv6, but I certainly won't be putting > >2^64 sites on a single server. Use a /112 here again as well? Use a > >/64 per server because I can? > > Why route them to the servers? I would just put up a /64 for the web > servers and bind addresses to your ethernet interface out of that /64 > as they are used by each site. > I guess you might want to route them to the servers to save ND entries > or something on your router? In the past, we saw issues with thousands of ARP entries (it has been a while and I don't remember what issues now though). Moving a block from one server to another didn't require clearing an ARP cache (and triggering a couple of thousand new ARP requests). Also, it is an extra layer of misconfiguration-protection: if the IPs are routed, accidentally assigning the wrong IP on the wrong server didn't actually break any existing sites (and yes, that is a lesson from experience). Of course, with IPv4, you never assigned a large enough block to begin with that would anticipate all growth, so routing additional blocks was a lot easier than changing blocks, cleaner than secondary IPs multiplying like crazy, etc., etc. None of that would be an issue with a single /64. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nanog at daork.net Tue Oct 13 21:55:46 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 14 Oct 2009 15:55:46 +1300 Subject: ISP customer assignments In-Reply-To: <20091014024957.GD612455@hiwaay.net> References: <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> Message-ID: <267D5E9A-19A6-4BE0-A553-37D1E5F17CA4@daork.net> On 14/10/2009, at 3:49 PM, Chris Adams wrote: > Once upon a time, Nathan Ward said: >> On 14/10/2009, at 2:14 PM, Chris Adams wrote: >>> What about web-hosting type servers? Right now, I've got a group of >>> servers in a common IPv4 subnet (maybe a /26), with a /24 or two >>> routed >>> to each server for hosted sites. What is the IPv6 equivalent? I >>> can >>> see a /64 for the common subnet, but what to route for aliased IPs >>> for >>> web hosts? It is kind of academic right now, since our hosting >>> control >>> panel software doesn't handle IPv6, but I certainly won't be putting >>> 2^64 sites on a single server. Use a /112 here again as well? >>> Use a >>> /64 per server because I can? >> >> Why route them to the servers? I would just put up a /64 for the web >> servers and bind addresses to your ethernet interface out of that /64 >> as they are used by each site. >> I guess you might want to route them to the servers to save ND >> entries >> or something on your router? > > In the past, we saw issues with thousands of ARP entries (it has > been a > while and I don't remember what issues now though). Moving a block > from > one server to another didn't require clearing an ARP cache (and > triggering a couple of thousand new ARP requests). Yeah I figured as much. > Also, it is an extra layer of misconfiguration-protection: if the IPs > are routed, accidentally assigning the wrong IP on the wrong server > didn't actually break any existing sites (and yes, that is a lesson > from > experience). I guess. The advantage of doing it with a single /64 for all of them is that you can move individual sites to other servers without much drama. That might not be useful for everyone of course. -- Nathan Ward From markjr at easydns.com Tue Oct 13 22:33:02 2009 From: markjr at easydns.com (Mark Jeftovic) Date: Tue, 13 Oct 2009 23:33:02 -0400 Subject: blackholes.us RBL is defunct and wildcarded Message-ID: <4AD5466E.1020306@easydns.com> This is somewhat of a stability issue as I'm seeing a lot of remote mailservers affected. The blackholes.us series of RBLs (geotargetted IP space by country) is no more, hasn't been for awhile. It has now been wildcarded and answers positive to all queries. http://www.circleid.com/posts/20091013_unwelcome_afterlife_for_a_long_dead_blacklist/ Sorry if this is known, I checked the archives and didn't see anything. -mark -- Mark Jeftovic / Jabber: markjr at easysip.com Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com Better Living Through Private World Domination: http://PrivateWorld.com From johnl at iecc.com Tue Oct 13 22:55:44 2009 From: johnl at iecc.com (John Levine) Date: 14 Oct 2009 03:55:44 -0000 Subject: blackholes.us RBL is defunct and wildcarded In-Reply-To: <4AD5466E.1020306@easydns.com> Message-ID: <20091014035544.58053.qmail@simone.iecc.com> >The blackholes.us series of RBLs (geotargetted IP space by country) >is no more, hasn't been for awhile. It has now been wildcarded and >answers positive to all queries. The problem is that the domain has been abandoned, the IP block where its nameservers live was returned to ARIN and reallocated, and the new owner would like to get rid of the traffic. We've told him that wildcarding will not make the traffic go away, and I expect that in the next few days the domain will be turned off or at least the name servers pointed at someplace harmless. R's, John From patrick at ianai.net Tue Oct 13 23:40:21 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 14 Oct 2009 00:40:21 -0400 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> Message-ID: <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> On Oct 12, 2009, at 5:23 PM, Randy Bush wrote: >>> sure would be nice if there was a diagnosis before the lynching >> If this happened in v4, would customers care 'why' it happened? >> Obviously not. >> Why should v6 be any different? It either is or is not production >> ready. I'm interested in HE's view on that. > > many of us are interested in diagnosis. few in your lynch rope. I think you are stretching things to make a pithy post. More importantly, you are missing the point. For the v6 'Net to be used, customers - you know the people who pay for those router things and that fiber stuff and all our salaries and such - need to feel some comfort around it actually working. This did not help that comfort level. And I believe it is valid to ask about it. Diagnosis is good. Fortunately, anyone who cares knows exactly what happened on a technical level - HE has no v6 transit and does not peer with Telia; Telia had C&W transit, then they didn't, now they do. Took less time to 'diagnose' than your one-liners took to write. Were you actually interested in diagnostics, you would have spent some time looking as opposed to trying to be pithy to 10K of your not-so-closest buddies. Unfortunately, and you damned well know this, we are not going to get a /real/ diagnosis out of a busted peering relationship. Especially when one party is an incumbent telco. HE typically - and properly - will not discuss such relationships (modulo Mike's Cogent post, which even he says is unusual). And Telia won't discuss squat, full stop. So why it happened is a mystery, and will be for, well, ever. Diagnosis ends. However, the question still stands about the stability, and therefor, utility of the v6 'Net. Is it still some bastard child, some beta test, some side project? Or is it ready to have _revenue_producing_ traffic put on it? When a network as solid and customer-oriented as HE can have a long outage to such a large network as Telia, I submit it is not. I know, everyone is shocked. But operationally speaking, this matters. We can either say "but it was just v6", or we can think about how to not have this happen again. The former leads no where. Perhaps we should choose the latter instead of making pithy posts? If that is a "lynch rope", I will not bother arguing with you. Pigs & mud & all that. But that doesn't make it wrong, or irrelevant. In summary, we have the standard Chicken & Egg problem. No one cares about v6, so no one puts anything important on v6, so no one cares about v6. HE was trying harder to break that vicious cycle than anyone else, yet even they do not come close to supporting v6 as much as they support v4. Sad times for the future of the Internet if we all need to use v6 Real Soon Now. I asked for HE's view on that. Would you mind explaining why you don't want to hear it? -- TTFN, patrick P.S. Being a curmudgeon is useful from time to time. But only if you are, well, being useful. From fyodor at insecure.org Tue Oct 13 23:41:48 2009 From: fyodor at insecure.org (Fyodor) Date: Tue, 13 Oct 2009 21:41:48 -0700 Subject: Seeking old NANOG list mbox archives Message-ID: <20091014044148.GB1321@syn.titan.net> Hi All. I run a web archive for network security mailing lists at http://seclists.org and have decided to add NANOG. I find that this list often delves into security issues, including botnets, malware, DoS attacks, ways to contain them, etc. So I've added a page with the monthly archives since 2003, excerpts of the latest posts, RSS feeds, searching, etc: http://seclists.org/nanog/ The problem is that I have only been a list member for 6 years, while the NANOG list has a rich history going back to 1994 ('92 if you count the NSFNET Regional-Techs list it was formed from). I'd love to make that whole history available. If anyone has archives going back further than mine, please let me know. Traditional Unix-style mbox files are preferred, but I'll take whatever I can get and massage them into mboxes. Thanks, Fyodor From joelja at bogus.com Wed Oct 14 00:36:02 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 13 Oct 2009 22:36:02 -0700 Subject: ISP customer assignments In-Reply-To: <20091013232620.GB612455@hiwaay.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> Message-ID: <4AD56342.2070908@bogus.com> Chris Adams wrote: > I guess I'm missing something; what in section 3 is this referring to? > I can understand /64 or /126 (or maybe /124 if you were going to > delegate reverse DNS?), but why /112 and "16 bits for node identifiers" > on a point-to-point link? It falls on a 16 bit boundry and is therefore easy to read. some numbering concessions within a vast space exist for the convenience of the poor humans not the machines. I can pick out the host side of the address in a /64 no problem but for some reason I have a trouble finding subnet boundaries on a series of /93s. From nanog at daork.net Wed Oct 14 00:59:19 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 14 Oct 2009 18:59:19 +1300 Subject: ISP customer assignments In-Reply-To: <20091013102608.GA31089@skywalker.creative.net.au> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <00f701ca4bee$846f8080$8d4e8180$@com> <20091013102608.GA31089@skywalker.creative.net.au> Message-ID: Ok, I've decided to do this a different way to my usual ranting. Instead of explaining the options over and over and hoping people can make sense of the complexities of it, become experts, and make good informed decisions, I've made a flow chart. Feel free to ask about details and I can get in to the ranting part, this is really a place to start. Right now it assumes people only provide DSL or other dynamic sort of services. It also assumes DS-Lite people are insane, so probably need better language there. Also the first question is not necessarily about who you are, but who is driving the IPv6 'build' - which is why native, 6rd and ds-lite are not appropriate for the customer-driven side. I hope that makes sense. No talk about ISATAP and stuff for inside the customer network either. And before you ask no ISATAP is not appropriate for ISPs, doesn't work through NAT. Anyway: - 6RD is used by free.fr. Not widely implemented by anyone yet. - DS-Lite is something some guys at Comcast and others are talking about. Not widely implemented by anyone yet. - The rest you can figure out from wikipedia and stuff. Please email me with any corrections, complaints, or threats if you're a DS-Lite fan. I'll always keep old versions in this directory, and the latest version will always have this filename, so please link to it instead of copying it, etc. etc.: http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-current.pdf On 13/10/2009, at 11:26 PM, Adrian Chadd wrote: > Nathan Ward, please stand up. > > > > Adrian > > On Tue, Oct 13, 2009, TJ wrote: >> >> -----Original Message----- >> From: Justin >> To go along with Dan's query from above, what are the preferred >> methods >> that other SPs are using to deploy IPv6 with non-IPv6-capable edge >> hardware? We too have a very limited number of dialup customers and >> will never sink another dollar in the product. Unfortunately I also >> have brand-new ADSL2+ hardware that doesn't support IPv6 and >> according >> to the vendors (Pannaway) never will. We also have CMTSs that don't >> support IPv6, even though they too are brand-new. Those CMTSs top >> out >> at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs >> regardless of the underlying CM's IPv6 support or lack thereof (like >> Cisco allowed for example). Are providers implementing tunneling >> solutions? Pros/cons of the various solutions? >> >> >>> My first (potentially ignorant) response would be to get your >>> acquisitions >> >>> people aligned with your business, and by that I mean they should be >> making >>> a concerted effort to only buy IPv6 capable gear, especially when >>> IPv6 is >> >>> coming to you within that gears lifecycle. >>> I guess your customers will need to tunnel, as long as you give >>> them a >> public >>> IP they have 6to4 (and possibly Teredo, tunnel broker) - but >>> native is >> better. >> >> > > -- > - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial > Squid Support - > - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available > in WA - > > > !DSPAM:22,4ad455ce140151847938845! > > From marka at isc.org Wed Oct 14 01:23:16 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 14 Oct 2009 17:23:16 +1100 Subject: ISP customer assignments In-Reply-To: Your message of "Wed, 14 Oct 2009 18:59:19 +1300." References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <00f701ca4bee$846f8080$8d4e8180$@com> <20091013102608.GA31089@skywalker.creative.net.au> Message-ID: <200910140623.n9E6NGO0052696@drugs.dv.isc.org> In message , Nathan Ward writes: > Ok, I've decided to do this a different way to my usual ranting. > Instead of explaining the options over and over and hoping people can > make sense of the complexities of it, become experts, and make good > informed decisions, I've made a flow chart. Feel free to ask about > details and I can get in to the ranting part, this is really a place > to start. > > Right now it assumes people only provide DSL or other dynamic sort of > services. > It also assumes DS-Lite people are insane, so probably need better > language there. DS-Lite is there for when the ISP runs out of IPv4 addresses to hand one to each customer. Many customers don't need a unique IPv4 address, these are the ones you switch to DS-Lite. Those that do require a unique IPv4 you leave on full dual stack for as long as you can. You forgot the tunnel brokers. > Also the first question is not necessarily about who you are, but who > is driving the IPv6 'build' - which is why native, 6rd and ds-lite are > not appropriate for the customer-driven side. I hope that makes sense. > No talk about ISATAP and stuff for inside the customer network either. > And before you ask no ISATAP is not appropriate for ISPs, doesn't work > through NAT. > > Anyway: > - 6RD is used by free.fr. Not widely implemented by anyone yet. > - DS-Lite is something some guys at Comcast and others are talking > about. Not widely implemented by anyone yet. > - The rest you can figure out from wikipedia and stuff. > > Please email me with any corrections, complaints, or threats if you're > a DS-Lite fan. I'll always keep old versions in this directory, and > the latest version will always have this filename, so please link to > it instead of copying it, etc. etc.: > > http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-current.pdf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wouter at widexs.nl Wed Oct 14 03:48:00 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Wed, 14 Oct 2009 10:48:00 +0200 Subject: ISP customer assignments In-Reply-To: <20091014011440.GC612455@hiwaay.net> References: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan><877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com><20091008164818.GB4984@dan.olp.net><4AD3E726.80400@justinshore.com><7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net><4AD3F4C7.70103@emanon.com><877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com><20091013232620.GB612455@hiwaay.net><20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> Message-ID: <87458E9581E41E4F8FFD6062007408560458108B@mail01.widexs.local> In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams wrote: <..> > What about web-hosting type servers? Right now, I've got a group of > servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed > to each server for hosted sites. What is the IPv6 equivalent? I can > see a /64 for the common subnet, but what to route for aliased IPs for > web hosts? It is kind of academic right now, since our hosting control > panel software doesn't handle IPv6, but I certainly won't be putting > 2^64 sites on a single server. Use a /112 here again as well? Use a > /64 per server because I can? I'd be interested in any suggestions on this part as well. We're a Hosting provider and basicly we have (for now) 3 different product-groups we want to launch IPv6 on : 1 - Shared Hosting These servers (Linux), are all in 1 vlan. Each server has 1 IPv4 address from the subnet that's configured on the vlan. Then we have an IPv4 /24 routed to each of the servers (each server has 1 /24 to host sites on). Here I'd assign a single /64 and use static addressing. 2 - Premium Managed & Unmanaged Hosting (Co-location). Each customer has one (or more) dedicated subnets and vlans. Here I'd assign a /64 per vlan. I'd do static addressing for Managed, but probably provide RA (EUI-64) for Unmanaged. 3 - Managed and Umanaged Hosting (Co-location). These servers are in 'shared' subnets, ranging from /23 to /26, and each customer get's assigned at least 1 IP from this subnet and more if they can justify. For customers needing 'large' subnets, we'd route a different subnet to their server of choice. Here, I'm not sure what to do... You should at least assign a /64 per customer, but how would one do that when they are in shared subnets/vlans... ? If for every server I'd need to assign a /64 secondary to our vlan interfaces, I'd trip the maximums (Nortel Passport 8600 used for these customers has quite some limitations on IPv6). It would be nice though, cause once IPv4 is no longer used (...) we could move customers to another/dedicated vlan. We've also fiddled with the idea of assigning one /48 to each of these vlans, and let each 'server' use a /64 out of it. This still seems a bit weird though... Also, since we do IP based billing here, we'd never know if one has 'hijacked' some IP space. Yes, we'd know for un-assigned addresses (not assigned but has traffic -> alert), but I don't expect a customer to use all addresses out of 'their' /64, so the not used addresses could be easily be abused. For IPv4, all addresses are usually really used and the customer who's IP's are hijacked, would almost definitely hang on the phone in no-time. Some advice would be very appreciated. Best regards, Wouter de Jong WideXS From mleber at he.net Wed Oct 14 04:21:52 2009 From: mleber at he.net (Mike Leber) Date: Wed, 14 Oct 2009 02:21:52 -0700 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> Message-ID: <4AD59830.7000907@he.net> Patrick W. Gilmore wrote: > For the v6 'Net to be used, customers - you know the people who pay for > those router things and that fiber stuff and all our salaries and such - > need to feel some comfort around it actually working. This did not help > that comfort level. And I believe it is valid to ask about it. That is entirely correct and I'm glad you asked that question! ;) Let me explain: (Lots of truisms here, bear with me!) IPv6 is newer than IPv4. As IPv6 is newer than IPv4, the equipment to support IPv6 natively is newer than legacy equipment already deployed that only supports IPv4. As the equipment that supports native IPv6 is newer, there are fewer core networks that run native IPv6. As these new IPv6 networks are deployed they are growing and developing. (Like neurons forming connections, the IPv6 network is.) Deployment of IPv6 in the core has been growing year to year, with that growth accelerating. In fact, I'd tell trend watchers of business econometrics the accelerating growth curve both represents something important happening right now and something that is likely to have real world implications for Internet infrastructure companies in the future: http://bgp.potaroo.net/cgi-bin/plot?file=%2fvar%2fdata%2fbgp%2fv6%2fas6447%2fbgp%2dactive%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step (Short url: http://tiny.cc/An6fl ) If you are in the connectivity business, you can add a caption to this graph of your choosing: "Ignore at your own peril." Or (I like this one): "I see opportunity." > However, the question still stands about the stability, and therefor, > utility of the v6 'Net. Is it still some bastard child, some beta test, > some side project? As you know, the IPv4 Internet of today is a product of the hard work of people of yore (ok well, more seriously, a large number of the people on this list and at networks around the world). The nature of things is that the coherent shared illusion of a single Internet routing table is the result of a rough consensus produced by years and years and years of accumulated business relationships and network engineer routing policy configurations. IPv6 is going through that phase right now, at accelerated pace. Perhaps geometric growth is not good enough for you as a business person. Perhaps where we are on the curve is not good enough for you yet. Perhaps you'd like to retire before working with another protocol. I hereby apologize to you on behalf of IPv6 that it has not had the same three decades of deployment and experimentation as IPv4. ;) IPv6 is not going to spring into existence as a fully complete global network to replace IPv4 on a specific flag day (December 21st 2012?). IPv6 will grow in deployment at the same time the Internet continues to work, at what appears to be on a geometric growth curve, due to some reasons a business economist can write a paper about. Network effect? Risk avoidance due to IPv4 run out? Risk avoidance due to technology shift? Yukon gold rush? The after the fact result of careful planning by thoughtful people started years earlier? Or perhaps, the projected functional economic value of IP addresses? > Or is it ready to have _revenue_producing_ traffic > put on it? IPv6 is production for some value of the word production. We see traffic around 1.5 Gbps, peaks at 2 Gbps and growing... Perhaps this says something about the amount of traffic that will be seen when it gets used widely. 1000 times as much? (Our guess) What's your guess? Warning! If you pick a low number you are saying that IPv6 is in widespread production use right now. :-P > In summary, we have the standard Chicken & Egg problem. No one cares > about v6, speak for yourself (introduce into evidence exhibit 1: the graph linked to above, exhibit 2: we note how part of the original poster's problem got fixed that day). > so no one puts anything important on v6, speak for yourself (reference real traffic above). Once upon a time, something called IPv4 was invented, and some people created hardware for it, wrote software for it, tried it out, wrote some papers, wrote some RFCs (after writing working code, the way it should be done LOL), and then experimented some more. There were lots of problems that got solved, things that worked in real life in spite of theoretical problems, and bugs that got fixed. Some companies got created... blah blah blah. > Sad times for the future of the Internet if we all need to use v6 > Real Soon Now. Or, expect real freaking huge opportunity and dislocation ahead. Of course, this dislocation may only affect some specific players and companies and industries. For the regular user it could just happen transparently that by the time they get their next computer with Microsoft Windows 9 or Ubuntu Quick Quagga... it just works. Imagine, what would it be like if all the core network operators had to figure out who get Internet connectivity from again. Imagine, if they had to setup all their peering and transit sessions again because of their existing telecommunications vendors only some of them decided to try out this new Internet thing. (Deja vu yet?) Well you don't have to imagine! That is what is happening right now! We are talking about a major sea change here. How long might the central wave of this sea change take to pass? 5 years? To come up with a wildy guestimated date, you might average the time to: * Replace 60 percent of home computers (count existing Windows Vista and Macintosh OS X computers towards this total, since they already just magically work with IPv6 if you have IPv6 on your LAN). * Replace 60 percent of residential CPE. (Base it on customer churn, CPE failure, and technology upgrades.) * Replace 60 percent of core routers. Why use 60 percent as a milestone? Because it represents more than half. Why does more than half matter? Because we could use it to make a nice graph to project cross over for the prevalence of IPv6 connectivity vs IPv4. In most companies I've been at, this sort of graph is used to predict when to stop spending additional money on the item that will not be relevant to the company's future sources of revenue. In otherwords, 60 percent is the point of no return because at that point capital allocation budgets are co-opted. BTW, if you plan on getting started after that ship has sailed, well... > I asked for HE's view on that. My pleasure! :) Mike. From nanog at daork.net Wed Oct 14 04:54:02 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 14 Oct 2009 22:54:02 +1300 Subject: ISP customer assignments In-Reply-To: <200910140623.n9E6NGO0052696@drugs.dv.isc.org> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <00f701ca4bee$846f8080$8d4e8180$@com> <20091013102608.GA31089@skywalker.creative.net.au> <200910140623.n9E6NGO0052696@drugs.dv.isc.org> Message-ID: On 14/10/2009, at 7:23 PM, Mark Andrews wrote: > DS-Lite is there for when the ISP runs out of IPv4 addresses to > hand one to each customer. Many customers don't need a unique IPv4 > address, these are the ones you switch to DS-Lite. Those that do > require a unique IPv4 you leave on full dual stack for as long as > you can. The authors of DS-lite say it's because running a dual stack network is hard. You clearly don't share that view , so in your view what's wrong with dual stack with IPv4for everyone then, whether they need a unique address or not? DS-lite requires CGN, so does dual stack without enough IPv4 addresses. This is probably the wrong forum for a DS-lite debate. I'm sure people have a use for it, they actually might have gear that can only do IPv4 OR IPv6 but not both or something. My problem with it is that it's being seen as a solution for a whole lot of people, when in reality it's a solution for a small number of people. Thanks for the point about the tunnel brokers though, I missed that, I'll update this tomorrow with any suggestions I get before then. -- Nathan Ward From randy at psg.com Wed Oct 14 08:32:59 2009 From: randy at psg.com (Randy Bush) Date: Wed, 14 Oct 2009 09:32:59 -0400 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> Message-ID: > I think you are stretching things to make a pithy post. More > importantly, you are missing the point. and hundreds of words do not cover that you accused HE of something for which you had no basis in fact. type less, analyse and think more. randy From marka at isc.org Wed Oct 14 09:06:32 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 15 Oct 2009 01:06:32 +1100 Subject: ISP customer assignments In-Reply-To: Your message of "Wed, 14 Oct 2009 22:54:02 +1300." References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <00f701ca4bee$846f8080$8d4e8180$@com> <20091013102608.GA31089@skywalker.creative.net.au> <200910140623.n9E6NGO0052696@drugs.dv.isc.org> Message-ID: <200910141406.n9EE6WEU061013@drugs.dv.isc.org> In message , Nathan Ward writes : > > On 14/10/2009, at 7:23 PM, Mark Andrews wrote: > > > DS-Lite is there for when the ISP runs out of IPv4 addresses to > > hand one to each customer. Many customers don't need a unique IPv4 > > address, these are the ones you switch to DS-Lite. Those that do > > require a unique IPv4 you leave on full dual stack for as long as > > you can. > > The authors of DS-lite say it's because running a dual stack network > is hard. It is harder. > You clearly don't share that view, so in your view what's wrong with > dual stack with IPv4 for everyone then, whether they need a unique > address or not? Dual stack for everyone was feasible 5 years ago. It isn't anymore, that transition plan has sailed and almost no one got on board. Because there aren't enough addresses to go around and there hasn't been for years. PNAT is a kludge to work around that fact. When you can't give every customer their own IPv4 address yet you still need to provide IPv4 connectivity you need to work out how to share those addresses you have efficiently. Given double PNAT or DS-Lite I know which one I prefer. DS-Lite allows lots of the tricks used with PNAT to continue to work. Those tricks will just stop working with double PNAT. > DS-lite requires CGN, so does dual stack without enough IPv4 addresses. > > This is probably the wrong forum for a DS-lite debate. I'm sure people > have a use for it, they actually might have gear that can only do IPv4 > OR IPv6 but not both or something. > My problem with it is that it's being seen as a solution for a whole > lot of people, when in reality it's a solution for a small number of > people. It's not the only solution. There are others and customers and ISP's will need to work out what is best for their collective requirements. It is a reasonable fit for residentual ISP's as the CPE PNAT is really very inefficient at conserving addresses and by splitting the PNAT across 2 co-operating boxes you can get the address utilisation efficency we now need in IPv4 to cover all the short sightedness that has got us to the place where we need things other than dual stack. > Thanks for the point about the tunnel brokers though, I missed that, > I'll update this tomorrow with any suggestions I get before then. > > -- > Nathan Ward -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at ianai.net Wed Oct 14 10:11:51 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 14 Oct 2009 11:11:51 -0400 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> Message-ID: <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> On Oct 14, 2009, at 9:32 AM, Randy Bush wrote: >> I think you are stretching things to make a pithy post. More >> importantly, you are missing the point. > > and hundreds of words do not cover that you accused HE of something > for > which you had no basis in fact. type less, analyse and think more. I expanded to try and get you to see the point. I obviously failed. I shall not bother to try again as I'm worried the failure was at least partially because you would rather be pithy than see the point not matter how fully explained. As for facts, there is lots of basis. HE has run a network for decades and has never let a v4 bifurcation happen so long. Ever. They've run v6 for a few years yet it happened. Asking the network in question's view on this perfectly reasonable - in fact the opposite would be unreasonable. As for accusations, I challenge you to show where I accused them of anything. Typing less does not mean you are actually thinking. You should try the latter before your next pithy post. Or at least read the post to which you are replying. -- TTFN, patrick From source_route at yahoo.com Wed Oct 14 10:19:51 2009 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 14 Oct 2009 08:19:51 -0700 (PDT) Subject: multicast nightmare #42 Message-ID: <561404.91694.qm@web30802.mail.mud.yahoo.com> Please explain how this would be possible: 1 sender 1 mcast group 1 receiver ---------------- = no data loss 1 sender 1 mcast group 2+ receivers on same VLAN and physical segment -------------------- = data loss From aforestal at wolve.com Wed Oct 14 10:21:53 2009 From: aforestal at wolve.com (Forestal, Andre Jr.) Date: Wed, 14 Oct 2009 10:21:53 -0500 Subject: multicast nightmare #42 In-Reply-To: <561404.91694.qm@web30802.mail.mud.yahoo.com> References: <561404.91694.qm@web30802.mail.mud.yahoo.com> Message-ID: <6BCBFA220A7F4F49BD5A8EEA0A0F7709281741EF@WOLVE-MAILBOX.wolve.com> which mode? -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Wednesday, October 14, 2009 11:20 AM To: nanog Subject: multicast nightmare #42 Please explain how this would be possible: 1 sender 1 mcast group 1 receiver ---------------- = no data loss 1 sender 1 mcast group 2+ receivers on same VLAN and physical segment -------------------- = data loss This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. From adrian.minta at gmail.com Wed Oct 14 10:44:22 2009 From: adrian.minta at gmail.com (Adrian Minta) Date: Wed, 14 Oct 2009 18:44:22 +0300 Subject: multicast nightmare #42 In-Reply-To: <561404.91694.qm@web30802.mail.mud.yahoo.com> References: <561404.91694.qm@web30802.mail.mud.yahoo.com> Message-ID: <4AD5F1D6.5090207@gmail.com> Philip Lavine wrote: > Please explain how this would be possible: > > 1 sender > 1 mcast group > 1 receiver > ---------------- > = no data loss > > 1 sender > 1 mcast group > 2+ receivers on same VLAN and physical segment > -------------------- > = data loss > > > Probably a crappy switch. -- Best regards, Adrian Minta From randy at psg.com Wed Oct 14 10:47:07 2009 From: randy at psg.com (Randy Bush) Date: Wed, 14 Oct 2009 11:47:07 -0400 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> Message-ID: > As for accusations, I challenge you to show where I accused them of > anything. > From: patrick at ianai.net (Patrick W. Gilmore) > Date: Mon, 12 Oct 2009 12:09:58 -0400 > Subject: IPv6 internet broken, cogent/telia/hurricane not peering > In-Reply-To: > References: > Message-ID: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39 at ianai.net> > > ... > > It is sad to see that networks which used to care about connectivity, > peering, latency, etc., when they are small change their mind when > they are "big". The most recent example is Cogent, an open peer who > decided to turn down peers when they reached transit free status. > I never thought HE would be one of those networks. From patrick at ianai.net Wed Oct 14 10:49:51 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 14 Oct 2009 11:49:51 -0400 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> Message-ID: <2EA674F0-9B39-4D4C-8323-D1B0C2839CAA@ianai.net> You really can't read, can you? And I spoke to Martin about it personally. If he's OK with it, perhaps you should clam down? -- TTFN, patrick On Oct 14, 2009, at 11:47 AM, Randy Bush wrote: >> As for accusations, I challenge you to show where I accused them of >> anything. > >> From: patrick at ianai.net (Patrick W. Gilmore) >> Date: Mon, 12 Oct 2009 12:09:58 -0400 >> Subject: IPv6 internet broken, cogent/telia/hurricane not peering >> In-Reply-To: > > >> References: > > >> Message-ID: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39 at ianai.net> >> >> ... >> >> It is sad to see that networks which used to care about connectivity, >> peering, latency, etc., when they are small change their mind when >> they are "big". The most recent example is Cogent, an open peer who >> decided to turn down peers when they reached transit free status. > >> I never thought HE would be one of those networks. > From: "Patrick W. Gilmore" > Date: October 12, 2009 12:49:02 PM EDT > To: NANOG list > Cc: "Patrick W. Gilmore" > Subject: Re: IPv6 internet broken, cogent/telia/hurricane not peering > To be clear, I was not trying to imply that HE has a closed policy. > But I can see how people might think that given my Cogent example. > My apologies to HE. > > And to be fair, I'm pounding on HE because they've always cared > about their customers. I expect Telia to care more about their own > ego than their customers' connectivity. So banging on them is > nonproductive. > > > In summary: HE has worked tirelessly and mostly thanklessly to > promote v6. They have done more to bring v6 to the forefront than > any other network. But at the end of day, despite HE's valiant > effort on v6, v6 has all the problems of v4 on the backbone, PLUS > growing pains. Which means it is difficult to rely on it, as v4 has > enough dangers on its own. > > Anyway, I have confidence HE is trying to fix this. But I still > think the fact that it happened - whatever the reason - is a black > eye for the v6 "Internet", whatever the hell that is. From adrian at creative.net.au Wed Oct 14 10:52:57 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 14 Oct 2009 23:52:57 +0800 Subject: multicast nightmare #42 In-Reply-To: <4AD5F1D6.5090207@gmail.com> References: <561404.91694.qm@web30802.mail.mud.yahoo.com> <4AD5F1D6.5090207@gmail.com> Message-ID: <20091014155257.GC11300@skywalker.creative.net.au> On Wed, Oct 14, 2009, Adrian Minta wrote: > >1 sender > >1 mcast group > >2+ receivers on same VLAN and physical segment > >-------------------- > >= data loss > Probably a crappy switch. specifically, is your switch doing frame replication on ingress or egress? :) adrian From mleber at he.net Wed Oct 14 10:53:37 2009 From: mleber at he.net (Mike Leber) Date: Wed, 14 Oct 2009 08:53:37 -0700 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> Message-ID: <4AD5F401.7090407@he.net> Patrick W. Gilmore wrote: > As for facts, there is lots of basis. HE has run a network for decades > and has never let a v4 bifurcation happen so long. Ever. They've run > v6 for a few years yet it happened. News flash, IPv6 is new. News flash, every single IPv6 network that gets configured that previously did not exist is new. News flash, when an IPv6 newbie configures IPv6 for the first time they have zero IPv6 BGP peers and transits until they configure them. News flash, some of these IPv6 newbies will even commit the error of not bothering to establish much IPv6 peering or decent IPv6 transit, before adding a AAAA record for their main website, ensuring that it is broken for the majority of the existing IPv6 Internet. News flash, newbies make mistakes, insist up is down, blue is green etc. This is called learning if they fix it, and stupidity otherwise. News flash, Hurricane will do everything possible to reach these newbie networks where ever they are in the world, some of them rather large, and try to help them (sometimes in spite of themselves), however some of them will insist on breaking themselves anyway! It's just going to happen and there is nothing you can do to stop them. Customers will vote with dollars (or whatever currency), problem solved. Mike. From regnauld at catpipe.net Wed Oct 14 10:58:08 2009 From: regnauld at catpipe.net (Phil Regnauld) Date: Wed, 14 Oct 2009 17:58:08 +0200 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: <2EA674F0-9B39-4D4C-8323-D1B0C2839CAA@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> <2EA674F0-9B39-4D4C-8323-D1B0C2839CAA@ianai.net> Message-ID: <20091014155807.GT16309@bluepipe.dk> Patrick W. Gilmore (patrick) writes: > You really can't read, can you? > > And I spoke to Martin about it personally. If he's OK with it, > perhaps you should clam down? I know Randy to be a bit taciturn and hard to get through to sometimes, but never of being a shellfish. P. From randy at psg.com Wed Oct 14 11:10:26 2009 From: randy at psg.com (Randy Bush) Date: Wed, 14 Oct 2009 12:10:26 -0400 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: <20091014155807.GT16309@bluepipe.dk> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> <2EA674F0-9B39-4D4C-8323-D1B0C2839CAA@ianai.net> <20091014155807.GT16309@bluepipe.dk> Message-ID: >> You really can't read, can you? >> And I spoke to Martin about it personally. If he's OK with it, >> perhaps you should clam down? > I know Randy to be a bit taciturn and hard to get through to sometimes, > but never of being a shellfish. i am from the pacific northwest. so shellfish is good. it's endless aggressive/defensive bs that is harder to let go by without calling it. randy From davet1 at gmail.com Wed Oct 14 11:19:12 2009 From: davet1 at gmail.com (Dave Temkin) Date: Wed, 14 Oct 2009 09:19:12 -0700 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> Message-ID: <4AD5FA00.3030102@gmail.com> Randy Bush wrote: >> As for accusations, I challenge you to show where I accused them of >> anything. >> > > >> From: patrick at ianai.net (Patrick W. Gilmore) >> Date: Mon, 12 Oct 2009 12:09:58 -0400 >> Subject: IPv6 internet broken, cogent/telia/hurricane not peering >> In-Reply-To: >> References: >> Message-ID: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39 at ianai.net> >> >> ... >> >> It is sad to see that networks which used to care about connectivity, >> peering, latency, etc., when they are small change their mind when >> they are "big". The most recent example is Cogent, an open peer who >> decided to turn down peers when they reached transit free status. >> > > >> I never thought HE would be one of those networks. >> > > The only thing Patrick is guilty of is not providing enough context. The party at fault here is Cogent. If you re-read the entire thread and speak with Mike Leber, you'll find that HE offered peering and/or transit, for free, to Cogent - like they do to everyone else, and Cogent didn't take it, providing for the segmentation we saw. -Dave From source_route at yahoo.com Wed Oct 14 11:52:08 2009 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 14 Oct 2009 09:52:08 -0700 (PDT) Subject: multicast nightmare #42 - REDUX In-Reply-To: <561404.91694.qm@web30802.mail.mud.yahoo.com> References: <561404.91694.qm@web30802.mail.mud.yahoo.com> Message-ID: <826743.64603.qm@web30804.mail.mud.yahoo.com> More info if this helps: Switch Platform: 4500 SUPII+ with gig line cards Data rate is <100Mbps Server OS: Windows 2003 R2 (please withhold snickering). ----- Original Message ---- From: Philip Lavine To: nanog Sent: Wed, October 14, 2009 8:19:51 AM Subject: multicast nightmare #42 Please explain how this would be possible: 1 sender 1 mcast group 1 receiver ---------------- = no data loss 1 sender 1 mcast group 2+ receivers on same VLAN and physical segment -------------------- = data loss From adrian.minta at gmail.com Wed Oct 14 12:36:28 2009 From: adrian.minta at gmail.com (Adrian Minta) Date: Wed, 14 Oct 2009 20:36:28 +0300 Subject: multicast nightmare #42 - REDUX In-Reply-To: <826743.64603.qm@web30804.mail.mud.yahoo.com> References: <561404.91694.qm@web30802.mail.mud.yahoo.com> <826743.64603.qm@web30804.mail.mud.yahoo.com> Message-ID: <4AD60C1C.8040507@gmail.com> Philip Lavine wrote: > More info if this helps: > > Switch Platform: > 4500 SUPII+ > with gig line cards > > Data rate is <100Mbps > > Server OS: Windows 2003 R2 (please withhold snickering). > > Multicast traffic is routed ? -- Best regards, Adrian Minta From xxnog at ledeuns.net Wed Oct 14 14:14:52 2009 From: xxnog at ledeuns.net (Denis F.) Date: Wed, 14 Oct 2009 21:14:52 +0200 Subject: Contact for netsolmail.net / networksolutionsemail.com Message-ID: <4AD6232C.30208@ledeuns.net> Hello and sorry to bother you with my OT query. I'm looking for a technical contact at netsolmail.net or networksolutionsemail.com to troubleshoot an issue. It seems their SMTP servers can't join mine and I can't see what's wrong on my side. Thank you very much in advance, Denis From charles at thewybles.com Wed Oct 14 14:50:01 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 14 Oct 2009 12:50:01 -0700 Subject: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering] In-Reply-To: <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> References: <0A37FD5D-D9D1-4D89-AC8A-105612BB8E39@ianai.net> <3506312B-F043-478D-85A3-9AD4121E010E@ianai.net> <6B62AB1E-1620-4911-81CD-25CCF4287520@ianai.net> Message-ID: <4AD62B69.6060704@thewybles.com> On 10/14/09 8:11 AM, Patrick W. Gilmore wrote: > Typing less does not mean you are actually thinking. You should try the > latter before your next pithy post. Or at least read the post to which > you are replying. > Now now boys and girls. Settle down and be civil. :) From bensons at queuefull.net Wed Oct 14 15:14:35 2009 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 14 Oct 2009 15:14:35 -0500 Subject: multicast nightmare #42 - REDUX In-Reply-To: <4AD60C1C.8040507@gmail.com> References: <561404.91694.qm@web30802.mail.mud.yahoo.com> <826743.64603.qm@web30804.mail.mud.yahoo.com> <4AD60C1C.8040507@gmail.com> Message-ID: Is the packet loss uniform for each receiver? Or is there a pattern to the loss, e.g. each receiver hears a different / non-overlapping 50% of the packets? Off the cuff, I'd suspect a problem with IGMP snooping. Cheers, -Benson On 14 Oct 09, at 12:36 PM, Adrian Minta wrote: > Philip Lavine wrote: >> More info if this helps: >> >> Switch Platform: >> 4500 SUPII+ >> with gig line cards >> >> Data rate is <100Mbps >> >> Server OS: Windows 2003 R2 (please withhold snickering). >> >> > Multicast traffic is routed ? > > -- > Best regards, > Adrian Minta > > From frnkblk at iname.com Wed Oct 14 22:16:16 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 14 Oct 2009 22:16:16 -0500 Subject: ISP customer assignments In-Reply-To: <20091013141523.GA5028@dan.olp.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <20091013141523.GA5028@dan.olp.net> Message-ID: So you're saying moving away from PPPoA/E and just going bridged? Frank -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Tuesday, October 13, 2009 9:15 AM To: Justin Shore Cc: nanog at nanog.org Subject: Re: ISP customer assignments On 12/10/09?21:34?-0500, Justin Shore wrote: > To go along with Dan's query from above, what are the preferred methods > that other SPs are using to deploy IPv6 with non-IPv6-capable edge > hardware? We too have a very limited number of dialup customers and > will never sink another dollar in the product. Unfortunately I also > have brand-new ADSL2+ hardware that doesn't support IPv6 and according > to the vendors (Pannaway) never will. I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. -- Dan White From dwhite at olp.net Thu Oct 15 08:15:54 2009 From: dwhite at olp.net (Dan White) Date: Thu, 15 Oct 2009 08:15:54 -0500 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <20091013141523.GA5028@dan.olp.net> Message-ID: <20091015131553.GC5209@dan.olp.net> I can't offer any knowledgeable advice about PPPoA/E. We have never used it ourselves. On 14/10/09?22:16?-0500, Frank Bulk wrote: >So you're saying moving away from PPPoA/E and just going bridged? > >Frank > >-----Original Message----- >From: Dan White [mailto:dwhite at olp.net] > >Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet >QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or >Cisco. -- Dan White From source_route at yahoo.com Thu Oct 15 15:06:43 2009 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 15 Oct 2009 13:06:43 -0700 (PDT) Subject: multicast nightmare #42 In-Reply-To: <4AD6019F.4020505@mmi.net> References: <561404.91694.qm@web30802.mail.mud.yahoo.com> <4AD5ED4B.6020308@mmi.net> <436249.15061.qm@web30805.mail.mud.yahoo.com> <4AD6019F.4020505@mmi.net> Message-ID: <262055.10519.qm@web30807.mail.mud.yahoo.com> Thank you Eric you are a genius, that has solved and issue that has plagued me for 3 years. the problem was exactly as you said over subscription of the 8 ports tied to 1 ASIC ________________________________ From: Eric Ortega To: Philip Lavine Sent: Wed, October 14, 2009 9:51:43 AM Subject: Re: multicast nightmare #42 Depending on the model of blade there is an 8-to-1 over subscription on the 4500s. I have had all kinds of headaches with this myself. The 48 port SFP "gig" blade can only have 1 gig per each set of 8 ports. The aggregate ports are known as "gigaports". The layout is gigaport 1 = 1,3,5,7,9,11,13,15 gigaport 2 = 2,4,6,8,10,12,14,16 and so on. I bet that if add up the total bandwidth in each gigaport you might be over the "limit" Philip Lavine wrote: > >I wish that was the case but the switch is a 4500 and the data >rates are less than 100 mbps on a 1 gig blade/sup > > > > ________________________________ From: >Eric Ortega >To: Philip Lavine > >Sent: Wed, October 14, >2009 8:24:59 AM >Subject: Re: multicast >nightmare #42 > >Are you over subscribing >either the link or the backplane of the switching device? > >>Philip Lavine wrote: > >Please explain how this would be possible: >> >>1 sender >>1 mcast group >>1 receiver >>---------------- >> = no data loss >> >>1 sender >>1 mcast group >>2+ receivers on same VLAN and physical segment >>-------------------- >>= data loss >> >> >> >> >> > >-- > > >Eric R. Ortega >Network Engineer >Midcontinent Communications >605.357.5720 >eric_ortega at gmail.com > -- Eric R. Ortega Network Engineer Midcontinent Communications 605.357.5720 eric_ortega at gmail.com From mksmith at adhost.com Thu Oct 15 15:54:04 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 15 Oct 2009 13:54:04 -0700 Subject: multicast nightmare #42 In-Reply-To: <262055.10519.qm@web30807.mail.mud.yahoo.com> References: <561404.91694.qm@web30802.mail.mud.yahoo.com><4AD5ED4B.6020308@mmi.net><436249.15061.qm@web30805.mail.mud.yahoo.com><4AD6019F.4020505@mmi.net> <262055.10519.qm@web30807.mail.mud.yahoo.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031606EA58FB@ad-exh01.adhost.lan> As an aside, the 6-port GigE card is not oversubscribed. Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Thursday, October 15, 2009 1:07 PM > To: Eric Ortega; nanog > Subject: Re: multicast nightmare #42 > > Thank you Eric you are a genius, that has solved and issue that has > plagued me for 3 years. > > the problem was exactly as you said over subscription of the 8 ports > tied to 1 ASIC > > > > > ________________________________ > From: Eric Ortega > To: Philip Lavine > Sent: Wed, October 14, 2009 9:51:43 AM > Subject: Re: multicast nightmare #42 > > Depending on the model of > blade there is an 8-to-1 over subscription on the 4500s. I have had all > kinds of headaches with this myself. The 48 port SFP "gig" blade can > only have 1 gig per each set of 8 ports. The aggregate ports are known > as "gigaports". The layout is gigaport 1 = 1,3,5,7,9,11,13,15 gigaport > 2 = 2,4,6,8,10,12,14,16 and so on. I bet that if add up the total > bandwidth in each gigaport you might be over the "limit" > > Philip Lavine wrote: > > > >I wish that was the case but the switch is a 4500 and the data > >rates are less than 100 mbps on a 1 gig blade/sup > > > > > > > > > ________________________________ > From: >Eric Ortega > >To: Philip Lavine > > > >Sent: Wed, October 14, > >2009 8:24:59 AM > >Subject: Re: multicast > >nightmare #42 > > > >Are you over subscribing > >either the link or the backplane of the switching device? > > > >>Philip Lavine wrote: > > > >Please explain how this would be possible: > >> > >>1 sender > >>1 mcast group > >>1 receiver > >>---------------- > >> = no data loss > >> > >>1 sender > >>1 mcast group > >>2+ receivers on same VLAN and physical segment > >>-------------------- > >>= data loss > >> > >> > >> > >> > >> > > > >-- > > > > > >Eric R. Ortega > >Network Engineer > >Midcontinent Communications > >605.357.5720 > >eric_ortega at gmail.com > > > > -- > > > Eric R. Ortega > Network Engineer > Midcontinent Communications > 605.357.5720 > eric_ortega at gmail.com > > > From wavetossed at googlemail.com Thu Oct 15 18:51:21 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 16 Oct 2009 00:51:21 +0100 Subject: ISP customer assignments In-Reply-To: <20091014024957.GD612455@hiwaay.net> References: <20091008164818.GB4984@dan.olp.net> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> Message-ID: <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> > Of course, with IPv4, you never assigned a large enough block to begin > with that would anticipate all growth, so routing additional blocks was > a lot easier than changing blocks, cleaner than secondary IPs > multiplying like crazy, etc., etc. ?None of that would be an issue with > a single /64. You've hit on the key difference of IPv6. With IPv6 you should design your network so that it can grow for a long time without increasing the address block sizes anywhere. A /64 will work for even the biggest subnets. A /48 will do for for very, very big sites. And only the largest ISPs will outgrow a /32 allocation. If you assign a /48 to a data center site, then when you subnet it, try to maintain that growth ability if you can. Don't skimp on address block sizes unless you are backed into a corner for technical or business reasons. --Michael Dillon From cmadams at hiwaay.net Thu Oct 15 19:17:54 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 15 Oct 2009 19:17:54 -0500 Subject: ISP customer assignments In-Reply-To: <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> References: <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> Message-ID: <20091016001754.GB793724@hiwaay.net> Once upon a time, Michael Dillon said: > And only the largest ISPs will outgrow a /32 allocation. This brings up something else I'm trying to figure out. We're not a huge ISP; I've got our /32 but I don't see us using more. We have two main POPs, each with Internet links, plus a link between the two. Our IPv4 allocations are larger than the minimum, so I split our IPv4 space between the two POPs and avertise a smaller block out of the smaller of the two POPs. This has worked okay and handles the POP-to-POP link going down; when that happens, our POP-to-POP traffic (not a large precentage of our traffic) goes across our Internet connections, but Internet traffic for each POP goes to directly to the POP. With IPv6, we've got our single /32. From what I understand, if I try to advertise a /33 from the smaller POP, many (most?) will drop it (if my upstreams even take it). If I advertise the /32 from both routers, when that link goes down, my IPv6 traffic will be pretty much hosed. Is there any good solution to this? I don't expect us to fill the /32 to justify expanding it (although I do see ARIN appears to have left space for up to a /29; I guess that's their sparse allocation policy?). I guess this is traffic engineering, although I'm not deaggregating to try to control how much goes where, just to ensure connectivity in the face of failures. This link has been pretty reliable lately (since the telco re-engineered it), but it was flakey as hell a while back (when it went through 7 companies to go between cities 90 miles apart). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nanog at daork.net Thu Oct 15 20:02:13 2009 From: nanog at daork.net (Nathan Ward) Date: Fri, 16 Oct 2009 14:02:13 +1300 Subject: ISP customer assignments In-Reply-To: <20091016001754.GB793724@hiwaay.net> References: <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> <20091016001754.GB793724@hiwaay.net> Message-ID: <7B843A6F-DAAC-4387-B197-67DBC4DD4DE0@daork.net> On 16/10/2009, at 1:17 PM, Chris Adams wrote: > Is there any good solution to this? I don't expect us to fill the /32 > to justify expanding it (although I do see ARIN appears to have left > space for up to a /29; I guess that's their sparse allocation > policy?). Your justification is that you have two sites without a guaranteed link between them. This is a bit annoying though, yeah. But, I'm not sure I can think of a good solution that doesn't involve us changing the routing system so that we can handle a huge amount of intentional de-aggregates or something. -- Nathan Ward From herrin-nanog at dirtside.com Thu Oct 15 20:06:57 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 15 Oct 2009 21:06:57 -0400 Subject: ISP customer assignments In-Reply-To: <20091016001754.GB793724@hiwaay.net> References: <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> <20091016001754.GB793724@hiwaay.net> Message-ID: <3c3e3fca0910151806r2ded57dg1ef0836a8c75466b@mail.gmail.com> On Thu, Oct 15, 2009 at 8:17 PM, Chris Adams wrote: > With IPv6, we've got our single /32. From what I understand, > if I try to advertise a /33 from the smaller POP, many (most?) > will drop it (if my upstreams even take it). If I advertise the /32 > from both routers, when that link goes down, my IPv6 traffic > will be pretty much hosed. > Is there any good solution to this? Chris, Here's what I do with my IPv4 /24: I advertise it at higher priority at the larger POP and a slightly lower priority at the smaller POP. Then I got a small block of addresses from each upstream at each POP (from their still-aggregated blocks) to anchor a set of VPNs between the two. Something has to go disastrously wrong for me to suffer any worse effects than the occasional inefficient routing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sronan at fattoc.com Thu Oct 15 22:07:06 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 15 Oct 2009 23:07:06 -0400 Subject: DreamHost admin contacts In-Reply-To: <1404447E820C6C4B8C32C28EEDF4362212EC42287E@EXVMBX020-11.exch020.serverdata.net> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> <1404447E820C6C4B8C32C28EEDF4362212EC42287E@EXVMBX020-11.exch020.serverdata.net> Message-ID: <42879F8A-457F-4240-97A7-5CFF43D8CC45@fattoc.com> Agreed -1 for GroupSpark (AKA 123together) On Oct 13, 2009, at 4:48 PM, Jeff Saxe wrote: >> Barring that, what recommendations might the NANOG community have for >> an extremely rock-solid e-mail hosting company? I realize that may >> mean self-promotion, but hey, bring it on. > > Some people, when they say "email hosting company", inherently mean > "hosting specifically of Microsoft Exchange email, contacts, and > calendar". If that's what you're after, then I would recommend my > employer's chosen hosted Exchange partner, Intermedia >. They maintain server farms of Exchange clusters, and they have a > very good customer portal (both at the administrator-of-the-site > level and the individual end user). They also have an FTP-up-a-PST- > file-and-merge-it-into-a-mailbox function that makes the initial > migration from some other Exchange repository faster and more > parallelizable than without it. We are extremely pleased, and we > have basically stopped hosting Exchange for our own customers on our > own in-house hardware, just using Intermedia as a branded service. > > Depending on your requirements (audit copy of every single email and > and out, mandatory retention periods, BlackBerry connectivity, > etc.), they probably can do anything you're asking for. Their uptime > has been stellar except for one morning of about 3 to 4 hours, when > a major MAN cable was busted around Manhattan somewhere and > disconnected their datacenter. Other than that, we have not had the > long, painful, tension-filled, customer-angering outage periods that > we used to have with another provider which shall not be named. (OK, > it will: GroupSpark. Stay far away from them.) > > -- Jeff Saxe > Network Engineer, Blue Ridge InternetWorks > Charlottesville, VA > www.briworks.com > From rodrick.brown at gmail.com Thu Oct 15 22:42:25 2009 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Thu, 15 Oct 2009 23:42:25 -0400 Subject: DreamHost admin contacts In-Reply-To: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> References: <574FBCA4-5EAC-4BDD-A449-FEEFFB2D3120@inebraska.com> Message-ID: At my former firm we had much success with Mailstreet.com and their exchange hosting email services -- very simple to use admin panel and great customer service. On Tue, Oct 13, 2009 at 4:08 PM, Andy Ringsmuth wrote: > Any chance there's someone from DreamHost on NANOG? ?Or that someone might > have a way to reach them other than by filing a trouble ticket with them? > ?POP has seemingly been down all day, with Webmail sporadic at best. > > Just migrated my company's e-mail over to them last week, and with this, of > course our company president has been putting a severe squeeze on me to fix > it. > > Barring that, what recommendations might the NANOG community have for an > extremely rock-solid e-mail hosting company? ?I realize that may mean > self-promotion, but hey, bring it on. > > > Much appreciated! > > > -Andy > > -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown From davet1 at gmail.com Fri Oct 16 00:51:24 2009 From: davet1 at gmail.com (Dave Temkin) Date: Thu, 15 Oct 2009 22:51:24 -0700 Subject: ISP customer assignments In-Reply-To: <7B843A6F-DAAC-4387-B197-67DBC4DD4DE0@daork.net> References: <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> <20091016001754.GB793724@hiwaay.net> <7B843A6F-DAAC-4387-B197-67DBC4DD4DE0@daork.net> Message-ID: <4AD809DC.5040107@gmail.com> Nathan Ward wrote: > On 16/10/2009, at 1:17 PM, Chris Adams wrote: > >> Is there any good solution to this? I don't expect us to fill the /32 >> to justify expanding it (although I do see ARIN appears to have left >> space for up to a /29; I guess that's their sparse allocation policy?). > > Your justification is that you have two sites without a guaranteed > link between them. > > This is a bit annoying though, yeah. But, I'm not sure I can think of > a good solution that doesn't involve us changing the routing system so > that we can handle a huge amount of intentional de-aggregates or > something. > > -- > Nathan Ward > Actually, as of right now that's not justification. The Multiple Discrete Networks policy that's up for a vote in Dearborn will allow for this, but right now there's no IPv6 equivalent of that policy. -Dave From internetplumber at gmail.com Fri Oct 16 05:46:58 2009 From: internetplumber at gmail.com (Rob Evans) Date: Fri, 16 Oct 2009 11:46:58 +0100 Subject: ISP customer assignments In-Reply-To: <7B843A6F-DAAC-4387-B197-67DBC4DD4DE0@daork.net> References: <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> <20091016001754.GB793724@hiwaay.net> <7B843A6F-DAAC-4387-B197-67DBC4DD4DE0@daork.net> Message-ID: <9a8fa98b0910160346p5c7861c5i63cd0019abaf6f73@mail.gmail.com> > This is a bit annoying though, yeah. But, I'm not sure I can think of a good > solution that doesn't involve us changing the routing system so that we can > handle a huge amount of intentional de-aggregates or something. Within the RIPE region we're currently discussing a document on IPv6 route aggregation that acknowledges there are cases where it may be necessary to break up a /32 into a limited number of smaller blocks. Following discussion at the meeting last week I need to revise it, but the previous draft is here: http://www.ripe.net/ripe/maillists/archives/routing-wg/2009/msg00120.html Cheers, Rob From tore at linpro.no Fri Oct 16 07:02:21 2009 From: tore at linpro.no (Tore Anderson) Date: Fri, 16 Oct 2009 14:02:21 +0200 Subject: ISP customer assignments In-Reply-To: <20091016001754.GB793724@hiwaay.net> References: <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <877585b00910131147v4160b79et207549ecd83947c4@mail.gmail.com> <20091013232620.GB612455@hiwaay.net> <20091014004817.GA75629@ussenterprise.ufp.org> <20091014011440.GC612455@hiwaay.net> <4ED49A24-0786-4E27-9277-A0428C0F13A8@daork.net> <20091014024957.GD612455@hiwaay.net> <877585b00910151651p374e29e5r4845de4ca699570e@mail.gmail.com> <20091016001754.GB793724@hiwaay.net> Message-ID: <4AD860CD.7060906@linpro.no> * Chris Adams > This brings up something else I'm trying to figure out. We're not a > huge ISP; I've got our /32 but I don't see us using more. We have two > main POPs, each with Internet links, plus a link between the two. Our > IPv4 allocations are larger than the minimum, so I split our IPv4 space > between the two POPs and avertise a smaller block out of the smaller of > the two POPs. > > This has worked okay and handles the POP-to-POP link going down; when > that happens, our POP-to-POP traffic (not a large precentage of our > traffic) goes across our Internet connections, but Internet traffic for > each POP goes to directly to the POP. > > With IPv6, we've got our single /32. From what I understand, if I try > to advertise a /33 from the smaller POP, many (most?) will drop it (if > my upstreams even take it). If I advertise the /32 from both routers, > when that link goes down, my IPv6 traffic will be pretty much hosed. What you can do is to set up a tunnel between the sites (can be encrypted if necessary) through your upstream(s), and include it in your IGP - making sure that it has a higher cost/metric than the dedicated circuit. If then the dedicated circuit goes down, the traffic between the PoPs is redirected through the tunnel, and no connectivity is lost. You might need to upgrade the capacity of the dedicated circuit though, since there's no avoiding that some inbound packets will be delivered to the wrong PoP. Also you should make sure that the ports to your upstreams have enough available burst capacity (and preferably a roomy percentile-based charging scheme so that a bit of downtime on the dedicated circuit won't cost you anything). If you're single-homing to the the same upstream AS at both sites, another solution is to announce the aggregate /32 from both PoPs and at the same time a more specific route from each of them tagged with the no-export community (assuming your upstream will accept the deaggregated route in both locations). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From rjoffe at centergate.com Fri Oct 16 08:37:48 2009 From: rjoffe at centergate.com (Rodney Joffe) Date: Fri, 16 Oct 2009 06:37:48 -0700 Subject: RFC 2468 Message-ID: <7D036E1E-C34B-41C3-B4E7-47AC7502E36E@centergate.com> It's been 11 years. Sigh. From jmamodio at gmail.com Fri Oct 16 08:49:04 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 16 Oct 2009 08:49:04 -0500 Subject: RFC 2468 In-Reply-To: <7D036E1E-C34B-41C3-B4E7-47AC7502E36E@centergate.com> References: <7D036E1E-C34B-41C3-B4E7-47AC7502E36E@centergate.com> Message-ID: <202705b0910160649s5a8f6c9eqd09bf943a25ca6b4@mail.gmail.com> and icann still don't get it ... sad departure, great memories. On Fri, Oct 16, 2009 at 8:37 AM, Rodney Joffe wrote: > It's been 11 years. Sigh. From toolb0x.security at gmail.com Fri Oct 16 09:06:25 2009 From: toolb0x.security at gmail.com (tOoLb0x) Date: Fri, 16 Oct 2009 14:06:25 +0000 Subject: RFC 2468 Message-ID: <1785217726-1255701969-cardhu_decombobulator_blackberry.rim.net-1634569909-@bda049.bisx.prod.on.blackberry> Thank you, Jon. ------Original Message------ From: Jorge Amodio To: Rodney Joffe Cc: NANOG Subject: Re: RFC 2468 Sent: Oct 16, 2009 06:49 and icann still don't get it ... sad departure, great memories. On Fri, Oct 16, 2009 at 8:37 AM, Rodney Joffe wrote: > It's been 11 years. Sigh. From cscora at apnic.net Fri Oct 16 13:27:17 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Oct 2009 04:27:17 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200910161827.n9GIRHlw015104@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 17 Oct, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 300381 Prefixes after maximum aggregation: 140850 Deaggregation factor: 2.13 Unique aggregates announced to Internet: 148722 Total ASes present in the Internet Routing Table: 32446 Prefixes per ASN: 9.26 Origin-only ASes present in the Internet Routing Table: 28188 Origin ASes announcing only one prefix: 13763 Transit ASes present in the Internet Routing Table: 4258 Transit-only ASes present in the Internet Routing Table: 104 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 565 Unregistered ASNs in the Routing Table: 128 Number of 32-bit ASNs allocated by the RIRs: 292 Prefixes from 32-bit ASNs in the Routing Table: 217 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 192 Number of addresses announced to Internet: 2114870368 Equivalent to 126 /8s, 14 /16s and 92 /24s Percentage of available address space announced: 57.1 Percentage of allocated address space announced: 64.7 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 79.4 Total number of prefixes smaller than registry allocations: 144438 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72024 Total APNIC prefixes after maximum aggregation: 25287 APNIC Deaggregation factor: 2.85 Prefixes being announced from the APNIC address blocks: 68525 Unique aggregates announced from the APNIC address blocks: 30332 APNIC Region origin ASes present in the Internet Routing Table: 3821 APNIC Prefixes per ASN: 17.93 APNIC Region origin ASes announcing only one prefix: 1041 APNIC Region transit ASes present in the Internet Routing Table: 586 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 462426016 Equivalent to 27 /8s, 144 /16s and 15 /24s Percentage of available APNIC address space announced: 78.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 126924 Total ARIN prefixes after maximum aggregation: 66963 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 101444 Unique aggregates announced from the ARIN address blocks: 38562 ARIN Region origin ASes present in the Internet Routing Table: 13302 ARIN Prefixes per ASN: 7.63 ARIN Region origin ASes announcing only one prefix: 5154 ARIN Region transit ASes present in the Internet Routing Table: 1309 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 707408384 Equivalent to 42 /8s, 42 /16s and 50 /24s Percentage of available ARIN address space announced: 62.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 69231 Total RIPE prefixes after maximum aggregation: 40421 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 62717 Unique aggregates announced from the RIPE address blocks: 41918 RIPE Region origin ASes present in the Internet Routing Table: 13610 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7088 RIPE Region transit ASes present in the Internet Routing Table: 2058 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 402187968 Equivalent to 23 /8s, 248 /16s and 230 /24s Percentage of available RIPE address space announced: 74.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 25837 Total LACNIC prefixes after maximum aggregation: 6363 LACNIC Deaggregation factor: 4.06 Prefixes being announced from the LACNIC address blocks: 24132 Unique aggregates announced from the LACNIC address blocks: 13313 LACNIC Region origin ASes present in the Internet Routing Table: 1192 LACNIC Prefixes per ASN: 20.24 LACNIC Region origin ASes announcing only one prefix: 381 LACNIC Region transit ASes present in the Internet Routing Table: 193 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 67348480 Equivalent to 4 /8s, 3 /16s and 168 /24s Percentage of available LACNIC address space announced: 66.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5911 Total AfriNIC prefixes after maximum aggregation: 1540 AfriNIC Deaggregation factor: 3.84 Prefixes being announced from the AfriNIC address blocks: 4303 Unique aggregates announced from the AfriNIC address blocks: 1571 AfriNIC Region origin ASes present in the Internet Routing Table: 328 AfriNIC Prefixes per ASN: 13.12 AfriNIC Region origin ASes announcing only one prefix: 99 AfriNIC Region transit ASes present in the Internet Routing Table: 67 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12591360 Equivalent to 0 /8s, 192 /16s and 33 /24s Percentage of available AfriNIC address space announced: 37.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1764 6996 458 Korea Telecom (KIX) 17488 1466 138 143 Hathway IP Over Cable Interne 4755 1266 292 145 TATA Communications formerly 9583 1102 87 531 Sify Limited 4134 1012 18169 392 CHINANET-BACKBONE 18101 980 204 33 Reliance Infocom Ltd Internet 7545 892 199 101 TPG Internet Pty Ltd 9829 849 661 20 BSNL National Internet Backbo 17974 789 248 93 PT TELEKOMUNIKASI INDONESIA 24560 778 286 165 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4161 3626 312 bellsouth.net, inc. 4323 3704 1037 385 Time Warner Telecom 1785 1770 714 139 PaeTec Communications, Inc. 7018 1567 5846 1061 AT&T WorldNet Services 20115 1487 1481 676 Charter Communications 6478 1368 276 419 AT&T Worldnet Services 2386 1304 637 943 AT&T Data Communications Serv 3356 1229 10964 439 Level 3 Communications, LLC 11492 1135 208 12 Cable One 22773 1114 2604 67 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 512 94 207 Evolva Telecom 35805 458 40 5 United Telecom of Georgia 3292 450 1908 394 TDC Tele Danmark 12479 429 578 6 Uni2 Autonomous System 702 420 1822 338 UUNET - Commercial IP service 9198 393 138 12 Kazakhtelecom Data Network Ad 8866 358 110 23 Bulgarian Telecommunication C 3320 356 7068 304 Deutsche Telekom AG 3301 351 1412 308 TeliaNet Sweden 3215 349 3144 111 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1513 2899 244 UniNet S.A. de C.V. 10620 1018 227 100 TVCABLE BOGOTA 28573 767 651 87 NET Servicos de Comunicao S.A 7303 654 346 100 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 475 310 61 Instituto Costarricense de El 11172 442 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 428 858 29 Telecomunicacoes da Bahia S.A 6471 421 96 31 ENTEL CHILE S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 989 188 7 TEDATA 24863 932 96 67 LINKdotNET AS number 3741 273 857 234 The Internet Solution 2018 191 183 117 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 140 14 6 Ci Telecom Autonomous system 33776 124 7 11 Starcomms Nigeria Limited 5536 122 8 13 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 24835 108 46 9 RAYA Telecom - Egypt Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4161 3626 312 bellsouth.net, inc. 4323 3704 1037 385 Time Warner Telecom 1785 1770 714 139 PaeTec Communications, Inc. 4766 1764 6996 458 Korea Telecom (KIX) 7018 1567 5846 1061 AT&T WorldNet Services 8151 1513 2899 244 UniNet S.A. de C.V. 20115 1487 1481 676 Charter Communications 17488 1466 138 143 Hathway IP Over Cable Interne 6478 1368 276 419 AT&T Worldnet Services 2386 1304 637 943 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3704 3319 Time Warner Telecom 1785 1770 1631 PaeTec Communications, Inc. 17488 1466 1323 Hathway IP Over Cable Interne 4766 1764 1306 Korea Telecom (KIX) 8151 1513 1269 UniNet S.A. de C.V. 11492 1135 1123 Cable One 4755 1266 1121 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1114 1047 Cox Communications, Inc. 8452 989 982 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:24 /11:63 /12:176 /13:357 /14:630 /15:1207 /16:10697 /17:4881 /18:8438 /19:17490 /20:21039 /21:21018 /22:27426 /23:26869 /24:157288 /25:923 /26:1096 /27:553 /28:153 /29:8 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2693 4161 bellsouth.net, inc. 4323 2354 3704 Time Warner Telecom 4766 1437 1764 Korea Telecom (KIX) 1785 1235 1770 PaeTec Communications, Inc. 17488 1227 1466 Hathway IP Over Cable Interne 11492 1058 1135 Cable One 18566 1043 1062 Covad Communications 9583 954 1102 Sify Limited 10620 924 1018 TVCABLE BOGOTA 7018 923 1567 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:223 12:2142 13:7 15:22 16:3 17:5 20:36 24:1184 32:52 34:2 38:603 40:97 41:1749 43:1 44:2 46:1 47:20 52:6 55:2 56:2 57:25 58:604 59:640 60:440 61:1078 62:1017 63:2006 64:3632 65:2383 66:4091 67:1811 68:984 69:2758 70:568 71:154 72:1689 73:2 74:1946 75:182 76:358 77:863 78:579 79:388 80:905 81:809 82:488 83:434 84:525 85:1001 86:377 87:695 88:389 89:1516 90:70 91:2602 92:414 93:1228 94:1260 95:1130 96:174 97:271 98:346 99:30 109:58 110:232 111:455 112:145 113:152 114:265 115:422 116:1076 117:550 118:355 119:776 120:131 121:789 122:1291 123:780 124:1039 125:1364 128:220 129:220 130:131 131:421 132:76 133:10 134:186 135:42 136:224 137:170 138:174 139:82 140:437 141:123 142:385 143:340 144:368 145:48 146:391 147:172 148:548 149:203 150:151 151:176 152:216 153:156 154:2 155:271 156:166 157:310 158:90 159:357 160:292 161:171 162:279 163:172 164:279 165:512 166:476 167:389 168:752 169:163 170:463 171:42 172:2 173:397 174:372 175:1 178:1 180:84 182:1 186:145 187:175 188:1185 189:604 190:3102 192:5763 193:4274 194:3324 195:2755 196:1158 198:3555 199:3357 200:5199 201:1364 202:7868 203:8229 204:3921 205:2194 206:2403 207:2977 208:3963 209:3484 210:2565 211:1135 212:1603 213:1623 214:195 215:39 216:4406 217:1327 218:415 219:457 220:1133 221:449 222:312 End of report From j13park at hotmail.com Fri Oct 16 15:26:26 2009 From: j13park at hotmail.com (Jonathan Park) Date: Fri, 16 Oct 2009 20:26:26 +0000 Subject: AT&T prefix flapping? Message-ID: Hi all, For the past two months, it seems that AS7132 (SBIS-AT&T) announces and withdraws about 1,500 prefixes to AS7018 (AT&T) monitor every ~80 seconds. This observation is based on AT&T's monitor peering with RouteViews and RIPE. Does anyone know what's going on? Thanks, Jonathan _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/ From dgolding at t1r.com Fri Oct 16 15:51:26 2009 From: dgolding at t1r.com (Daniel Golding) Date: Fri, 16 Oct 2009 16:51:26 -0400 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> Message-ID: <8B29BFB1-38D3-43F1-A081-E9182D1F7656@t1r.com> The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students. Scarier: I was teaching graduate students. - Dan On Oct 13, 2009, at 7:53 AM, Joe Abley wrote: > > On 2009-10-13, at 07:39, Scott Morris wrote: > >> No idea, I haven't looked at that stuff in a while. But I would >> assume >> so, as it's easier to build a foundation than jumping straight to >> something difficult? > > I've found RIP to be a reasonable way to teach the concept of a > routing protocol, since the protocol is very simple and you can > always close with "don't ever use this". > > But teaching classful routing and addressing is just moronic. It's a > foundation that nothing is built on any more, and makes no sense to > teach outside of a history class. > >> Or did you learn calculus in grade school? Just askin' ;) > > Yes, since you asked, but your presumption is faulty. > > > Joe > > From bjohnson at drtel.com Fri Oct 16 15:58:34 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 16 Oct 2009 15:58:34 -0500 Subject: ISP customer assignments In-Reply-To: <8B29BFB1-38D3-43F1-A081-E9182D1F7656@t1r.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net><4AD3F4C7.70103@emanon.com><0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au><4AD46702.3040605@emanon.com> <8B29BFB1-38D3-43F1-A081-E9182D1F7656@t1r.com> Message-ID: <29A54911243620478FF59F00EBB12F4701A60FC4@ex01.drtel.lan> I actually think that CIDR is easier to understand than classful addressing. Do the subject completely in binary. It makes complete sense then. - Brian BTW: If the grad students don't get it, fail them! I don't want an engineer who can't grasp basic binary math. > -----Original Message----- > From: Daniel Golding [mailto:dgolding at t1r.com] > Sent: Friday, October 16, 2009 3:51 PM > To: Joe Abley > Cc: NANOG > Subject: Re: ISP customer assignments > > > The big problem here is that CIDR is tough to teach, even to > engineering students. This seems bizarre and counterintuitive, but its > true. I know this because I've done it. Its really easy to teach > classful addressing, on the other hand. Other problems include the > issue that many of the folks teaching have never had to use CIDR in > real life, textbook age, and, in some cases, lack of mathematical > preparation and inclination on the part of students. > > Scarier: I was teaching graduate students. > > - Dan > From walter.keen at rainierconnect.net Fri Oct 16 16:02:13 2009 From: walter.keen at rainierconnect.net (Walter Keen) Date: Fri, 16 Oct 2009 14:02:13 -0700 Subject: ISP customer assignments In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60FC4@ex01.drtel.lan> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net><4AD3F4C7.70103@emanon.com><0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au><4AD46702.3040605@emanon.com> <8B29BFB1-38D3-43F1-A081-E9182D1F7656@t1r.com> <29A54911243620478FF59F00EBB12F4701A60FC4@ex01.drtel.lan> Message-ID: <4AD8DF55.3010501@rainierconnect.net> I've got to agree with Brian, especially in an ISP environment, why would anyone hire or keep someone who couldn't grasp the concept of CIDR? You certainly wouldn't want to have them maintaining a core router with lots of v4 routes, since router-router links are almost always numbered in subnets as small as logic dictates. On 10/16/2009 01:58 PM, Brian Johnson wrote: > I actually think that CIDR is easier to understand than classful > addressing. Do the subject completely in binary. It makes complete sense > then. > > - Brian > > BTW: If the grad students don't get it, fail them! I don't want an > engineer who can't grasp basic binary math. > > > >> -----Original Message----- >> From: Daniel Golding [mailto:dgolding at t1r.com] >> Sent: Friday, October 16, 2009 3:51 PM >> To: Joe Abley >> Cc: NANOG >> Subject: Re: ISP customer assignments >> >> >> The big problem here is that CIDR is tough to teach, even to >> engineering students. This seems bizarre and counterintuitive, but its >> true. I know this because I've done it. Its really easy to teach >> classful addressing, on the other hand. Other problems include the >> issue that many of the folks teaching have never had to use CIDR in >> real life, textbook age, and, in some cases, lack of mathematical >> preparation and inclination on the part of students. >> >> Scarier: I was teaching graduate students. >> >> - Dan >> >> > -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 From owen at delong.com Fri Oct 16 16:19:36 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Oct 2009 14:19:36 -0700 Subject: ISP customer assignments In-Reply-To: <8B29BFB1-38D3-43F1-A081-E9182D1F7656@t1r.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> <8B29BFB1-38D3-43F1-A081-E9182D1F7656@t1r.com> Message-ID: <2C964F6B-9ADE-4AD8-9C1F-2542EC85C79D@delong.com> I've taught both. If you try to teach it in Decimal, Hex, or Octal, you're right, it's hard to teach CIDR and easy to teach classful. If you teach it in binary, I have found that not to be an issue. Once you teach it in binary, it's fairly easy to move on to showing how octal and hex are just different representations of binary. Then you show dotted decimal as a really old-fashioned way of representing groups of 8 bits. I've had no trouble teaching it this way, even to people who knew nothing about technology. Owen On Oct 16, 2009, at 1:51 PM, Daniel Golding wrote: > > The big problem here is that CIDR is tough to teach, even to > engineering students. This seems bizarre and counterintuitive, but > its true. I know this because I've done it. Its really easy to teach > classful addressing, on the other hand. Other problems include the > issue that many of the folks teaching have never had to use CIDR in > real life, textbook age, and, in some cases, lack of mathematical > preparation and inclination on the part of students. > > Scarier: I was teaching graduate students. > > - Dan > > On Oct 13, 2009, at 7:53 AM, Joe Abley wrote: > >> >> On 2009-10-13, at 07:39, Scott Morris wrote: >> >>> No idea, I haven't looked at that stuff in a while. But I would >>> assume >>> so, as it's easier to build a foundation than jumping straight to >>> something difficult? >> >> I've found RIP to be a reasonable way to teach the concept of a >> routing protocol, since the protocol is very simple and you can >> always close with "don't ever use this". >> >> But teaching classful routing and addressing is just moronic. It's >> a foundation that nothing is built on any more, and makes no sense >> to teach outside of a history class. >> >>> Or did you learn calculus in grade school? Just askin' ;) >> >> Yes, since you asked, but your presumption is faulty. >> >> >> Joe >> >> > > From james.cutler at consultant.com Fri Oct 16 16:44:59 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Fri, 16 Oct 2009 17:44:59 -0400 Subject: ISP customer assignments - and CIDR In-Reply-To: <2C964F6B-9ADE-4AD8-9C1F-2542EC85C79D@delong.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD3F4C7.70103@emanon.com> <0FE1293A-33CB-41BA-B4F2-FAFD6A0993A6@internode.com.au> <4AD46702.3040605@emanon.com> <8B29BFB1-38D3-43F1-A081-E9182D1F7656@t1r.com> <2C964F6B-9ADE-4AD8-9C1F-2542EC85C79D@delong.com> Message-ID: <40BFDB63-BA5A-49B7-82B9-4BA4F6B8313C@consultant.com> On Oct 16, 2009, at 5:19 PM, Owen DeLong wrote: > I've taught both. If you try to teach it in Decimal, Hex, or Octal, > you're right, it's hard > to teach CIDR and easy to teach classful. It really does not matter the representation as long as you divide your Address Pie with a Binary Knife. Once you understand that -- 1/2, 1/2 of 1/2, 1/2 of 1/2 of 1/2, ... -- then you should understand CIDR. Then, as Owen suggests, deal with the representation. Works for IPv4, IPv6, and, probably, IPv8. ;) Warning, strong opinion follows: One should never have to mention Classful addressing except to note that it is archaic, anachronistic, and used only by those who remain ignorant by preference. James R. Cutler james.cutler at consultant.com From cidr-report at potaroo.net Fri Oct 16 17:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Oct 2009 22:00:02 GMT Subject: BGP Update Report Message-ID: <200910162200.n9GM02kv042384@wattle.apnic.net> BGP Update Report Interval: 08-Oct-09 -to- 15-Oct-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS10176 61264 4.0% 181.8 -- TENET-AS Taejon Institute of Education Science 2 - AS9198 43178 2.8% 192.8 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - AS9829 36112 2.4% 45.8 -- BSNL-NIB National Internet Backbone 4 - AS6389 33154 2.2% 10.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS9531 28004 1.8% 5600.8 -- GEDU-AS-KR Kwangju City Office Of Education 6 - AS35805 18358 1.2% 40.3 -- UTG-AS United Telecom AS 7 - AS8452 18228 1.2% 24.9 -- TEDATA TEDATA 8 - AS41661 15605 1.0% 380.6 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 9 - AS4538 15103 1.0% 56.8 -- ERX-CERNET-BKB China Education and Research Network Center 10 - AS6478 12570 0.8% 8.9 -- ATT-INTERNET3 - AT&T WorldNet Services 11 - AS17488 12084 0.8% 9.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS7018 11531 0.8% 9.5 -- ATT-INTERNET4 - AT&T WorldNet Services 13 - AS4249 10832 0.7% 62.3 -- LILLY-AS - Eli Lilly and Company 14 - AS19262 9624 0.6% 10.0 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 15 - AS2386 8809 0.6% 8.7 -- INS-AS - AT&T Data Communications Services 16 - AS17974 8654 0.6% 12.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS30969 8586 0.6% 536.6 -- TAN-NET TransAfrica Networks 18 - AS4755 8400 0.6% 9.9 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 19 - AS8151 8265 0.5% 7.1 -- Uninet S.A. de C.V. 20 - AS18101 7196 0.5% 10.9 -- RIL-IDC Reliance Infocom Ltd Internet Data Centre, TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9531 28004 1.8% 5600.8 -- GEDU-AS-KR Kwangju City Office Of Education 2 - AS45406 6764 0.4% 3382.0 -- AJU-AS-KR AJU Internet Technology 3 - AS36239 2994 0.2% 2994.0 -- EXIGEN-CANADA - Exigen Canada 4 - AS5691 2459 0.2% 2459.0 -- MITRE-AS-5 - The MITRE Corporation 5 - AS38703 7147 0.5% 1786.8 -- KTB-AS-KR KTBnetwork Co., Ltd. 6 - AS43008 1754 0.1% 1754.0 -- TREND-AS TREND IMPORT-EXPORT SRL 7 - AS5050 5979 0.4% 1195.8 -- PSC-EXT - Pittsburgh Supercomputing Center 8 - AS41060 1065 0.1% 1065.0 -- PRIMBANK-AS Joint-Stock Commercial Bank Primorye 9 - AS27667 899 0.1% 899.0 -- Universidad Autonoma de la Laguna 10 - AS17070 802 0.1% 802.0 -- UBSW-CHICAGO - UBS AG 11 - AS4628 1288 0.1% 644.0 -- ASN-PACIFIC-INTERNET-IX Pacific Internet Ltd 12 - AS30969 8586 0.6% 536.6 -- TAN-NET TransAfrica Networks 13 - AS2642 2097 0.1% 524.2 -- LEG-CA-GOV - State of California 14 - AS49317 523 0.0% 523.0 -- KSPAB Kallmyra System & Produktion AB 15 - AS41035 520 0.0% 520.0 -- CPH-AS CPH Banque's AS 16 - AS5963 3531 0.2% 392.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - AS41661 15605 1.0% 380.6 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 18 - AS43880 375 0.0% 375.0 -- LITECH-AS Laboratory of Information Technologies LLC 19 - AS17658 3215 0.2% 357.2 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 20 - AS43704 312 0.0% 312.0 -- PINCOM-AS PINCOM d.o.o. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 5918 0.4% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 210.217.224.0/19 5604 0.3% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 3 - 211.253.68.0/22 5600 0.3% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 4 - 211.253.72.0/21 5600 0.3% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 5 - 210.218.64.0/19 5600 0.3% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 6 - 210.218.0.0/18 5600 0.3% AS9531 -- GEDU-AS-KR Kwangju City Office Of Education 7 - 95.59.3.0/24 4689 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 89.218.220.0/23 4688 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.2.0/23 4685 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 95.59.4.0/22 4685 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - 89.218.218.0/23 4681 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 12 - 95.59.8.0/23 4680 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 13 - 92.46.244.0/23 4661 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 14 - 88.204.221.0/24 4639 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 15 - 95.59.1.0/24 4605 0.3% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 16 - 210.111.224.0/19 4330 0.3% AS10176 -- TENET-AS Taejon Institute of Education Science 17 - 210.204.107.0/24 4324 0.3% AS10176 -- TENET-AS Taejon Institute of Education Science 18 - 211.253.176.0/20 4324 0.3% AS10176 -- TENET-AS Taejon Institute of Education Science 19 - 210.95.136.0/22 4324 0.3% AS10176 -- TENET-AS Taejon Institute of Education Science 20 - 210.100.212.0/23 4323 0.3% AS10176 -- TENET-AS Taejon Institute of Education Science Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 16 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Oct 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200910162200.n9GM00Ix042371@wattle.apnic.net> This report has been generated at Fri Oct 16 21:11:14 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-10-09 305384 187310 10-10-09 305219 187459 11-10-09 305101 187628 12-10-09 305258 187510 13-10-09 305206 187591 14-10-09 305348 188095 15-10-09 305545 188160 16-10-09 305625 188519 AS Summary 32603 Number of ASes in routing system 13866 Number of ASes announcing only one prefix 4313 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89682176 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 16Oct09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 305850 188556 117294 38.4% All ASes AS6389 4163 327 3836 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4313 1841 2472 57.3% TWTC - tw telecom holdings, inc. AS4766 1880 583 1297 69.0% KIXS-AS-KR Korea Telecom AS17488 1466 285 1181 80.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1114 73 1041 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1770 826 944 53.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1515 600 915 60.4% Uninet S.A. de C.V. AS4755 1266 390 876 69.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1062 244 818 77.0% COVAD - Covad Communications Co. AS19262 1021 231 790 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 989 254 735 74.3% TEDATA TEDATA AS6478 1368 669 699 51.1% ATT-INTERNET3 - AT&T WorldNet Services AS3356 1227 548 679 55.3% LEVEL3 Level 3 Communications AS18101 980 358 622 63.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS10620 1018 421 597 58.6% TV Cable S.A. AS4804 680 90 590 86.8% MPX-AS Microplex PTY LTD AS4808 758 189 569 75.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 655 100 555 84.7% Telecom Argentina S.A. AS17908 638 92 546 85.6% TCISL Tata Communications AS24560 777 232 545 70.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9498 651 109 542 83.3% BBIL-AP BHARTI Airtel Ltd. AS22047 545 18 527 96.7% VTR BANDA ANCHA S.A. AS11492 1135 615 520 45.8% CABLEONE - CABLE ONE, INC. AS7018 1568 1062 506 32.3% ATT-INTERNET4 - AT&T WorldNet Services AS5668 804 318 486 60.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS9443 525 83 442 84.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 562 125 437 77.8% GIGAINFRA Softbank BB Corp. AS4780 558 139 419 75.1% SEEDNET Digital United Inc. AS7011 1025 617 408 39.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS28573 769 364 405 52.7% NET Servicos de Comunicao S.A. Total 36802 11803 24999 67.9% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.72.112.0/20 AS19166 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.248.74.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.76.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.77.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.78.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.79.0/24 AS11730 CIL-ASN - Circle Internet LTD 91.198.127.0/24 AS8972 PLUSSERVER-AS PlusServer AG, Germany 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 96.8.127.0/24 AS19166 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 125.0.0.0/8 AS5432 BELGACOM-SKYNET-AS Belgacom regional ASN 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 180.149.236.0/23 AS1221 ASN-TELSTRA Telstra Pty Ltd 180.149.238.0/23 AS1221 ASN-TELSTRA Telstra Pty Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.77.128.0/24 AS4323 TWTC - tw telecom holdings, inc. 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.162.0/24 AS4841 202.140.168.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK Wind International Services SA 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.72.116.0/22 AS40907 CAPIT-159-AS01 - Tech Solutions 208.73.88.0/21 AS36835 208.75.0.0/22 AS40907 CAPIT-159-AS01 - Tech Solutions 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jzp-sc at rsuc.gweep.net Fri Oct 16 21:32:04 2009 From: jzp-sc at rsuc.gweep.net (Joe Provo) Date: Fri, 16 Oct 2009 22:32:04 -0400 Subject: [NANOG-announce] Health reminder... Message-ID: <20091017023203.GB17538@gweep.net> Hey folks! With the increased attention to seasonal flu, as well as the H1N1 novel influenza A strain in 2009, we would like to remind attendees to utilize their best judgment attending NANOG. We recommend visiting the CDC.gov and FLU.gov websites for information. If you are sick, please stay home and avoid contact with others and do attend remotely via the streams. Keep an eye on the agenda for links! http://www.nanog.org/meetings/nanog47/agenda.php Your help in making the NANOG (and ARIN) meetings enjoyable for all attendees is appreciated. Cheers! Joe Provo for the Steering Committee -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From neil at domino.org Sat Oct 17 05:58:58 2009 From: neil at domino.org (Neil J. McRae) Date: Sat, 17 Oct 2009 11:58:58 +0100 (BST) Subject: Data Centers in England In-Reply-To: <828517.67207.qm@web30805.mail.mud.yahoo.com> References: <828517.67207.qm@web30805.mail.mud.yahoo.com> Message-ID: <33793.217.169.55.80.1255777138.squirrel@webmail2.domino.org> On Wed, October 7, 2009 22:33, Philip Lavine wrote: > Anyone know a good DC on England that caters to financial industry > clients? Cable and Wireless (who I work for) and COLT (who I used to work for). The only other place worth considering is Equinix but from a proximity viewpoint they are just too far away from the square mile. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From leigh.porter at ukbroadband.com Sat Oct 17 06:31:29 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sat, 17 Oct 2009 12:31:29 +0100 Subject: Data Centers in England References: <828517.67207.qm@web30805.mail.mud.yahoo.com> <33793.217.169.55.80.1255777138.squirrel@webmail2.domino.org> Message-ID: Is there still the Global Crossing place on the junction of New Oxford Street and Tottenham Court Road? -- Leigh Porter -----Original Message----- From: Neil J. McRae [mailto:neil at domino.org] Sent: Sat 10/17/2009 11:58 AM To: Philip Lavine Cc: nanog Subject: Re: Data Centers in England On Wed, October 7, 2009 22:33, Philip Lavine wrote: > Anyone know a good DC on England that caters to financial industry > clients? Cable and Wireless (who I work for) and COLT (who I used to work for). The only other place worth considering is Equinix but from a proximity viewpoint they are just too far away from the square mile. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From leigh.porter at ukbroadband.com Sat Oct 17 08:43:00 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sat, 17 Oct 2009 14:43:00 +0100 Subject: Data Centers in England Message-ID: <07b801ca4f2f$b78a40ce$0324a8c0@ukbroadband.com> And frink-a-basement in Fulham is quite good. They have water cooling when the sewer floods and upto 22Mb/s when there is no water in the junction box. --- original message --- From: "Trefor Davies" Subject: RE: Data Centers in England Date: 17th October 2009 Time: 12:38:33 pm There's IOMART in Old Street -----Original Message----- From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] Sent: 17 October 2009 12:31 To: neil at domino.org; Philip Lavine Cc: nanog Subject: RE: Data Centers in England Is there still the Global Crossing place on the junction of New Oxford Street and Tottenham Court Road? -- Leigh Porter -----Original Message----- From: Neil J. McRae [mailto:neil at domino.org] Sent: Sat 10/17/2009 11:58 AM To: Philip Lavine Cc: nanog Subject: Re: Data Centers in England On Wed, October 7, 2009 22:33, Philip Lavine wrote: > Anyone know a good DC on England that caters to financial industry > clients? Cable and Wireless (who I work for) and COLT (who I used to work for). The only other place worth considering is Equinix but from a proximity viewpoint they are just too far away from the square mile. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From rps at maine.edu Sat Oct 17 19:55:28 2009 From: rps at maine.edu (Ray Soucy) Date: Sat, 17 Oct 2009 20:55:28 -0400 Subject: IPv6 Deployment for the LAN Message-ID: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. This allows us to be fairly confident that extending IPv6 to edge networks will not impact production services, and focus on DHCPv6 for host configuration and address assignment. We have no problem using a 64-bit prefix and letting SLAAC take care of addressing for certain networks where we actually manage the hosts, so that has been included as an exception. All other networks, however, will make use of DHCPv6 or manual configuration to receive native IPv6. So far, this has proven to work well with testing of various hosts and applications. Has anyone run into issues with applications in not using a 64-bit prefix? Of course, the other challenge here is proper DHCPv6 client implementations for host operating systems. Linux, Windows Server 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. Windows XP has a poor implementation of IPv6 but has the option of using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a challenge; it currently has no option for DHCPv6, though newer releases provide for manual configuration of IPv6 addressing. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. I think the hope is that more systems, like Windows 7, will begin including mature DHCPv6 clients which are enables when the M flag for a router advertisement is set and perhaps make it the default behavior. Is this likely to happen or am I being too optimistic? Anyway, just thought I'd bounce it to NANOG and get some feedback. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From herrin-nanog at dirtside.com Sat Oct 17 20:28:13 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 17 Oct 2009 21:28:13 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> Message-ID: <3c3e3fca0910171828y1ec82b00u6cb26a1b1a4c5fb1@mail.gmail.com> On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy wrote: > As it turns out delivering IPv6 to the edge in an academic setting has > been a challenge. ?Common wisdom says to rely on SLAAC for IPv6 > addressing, and in a perfect world it would make sense. Ray, Common wisdom says that? > Our current IPv6 allocation schema provides for a 64-bit prefix for > each network. ?Unfortunately, this enables SLAAC; yes, you can > suppress the prefix advertisement, and set the M and O flags, but that > only prevents hosts that have proper implementations of IPv6 from > making use of SLAAC. ?The concern here is that older hosts with less > than OK implementations will still enable IPv6 without regard for the > stability and security concerns associated with IPv6. I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like "ipv6 nd suppress-ra" in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rps at maine.edu Sat Oct 17 20:38:26 2009 From: rps at maine.edu (Ray Soucy) Date: Sat, 17 Oct 2009 21:38:26 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <3c3e3fca0910171828y1ec82b00u6cb26a1b1a4c5fb1@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <3c3e3fca0910171828y1ec82b00u6cb26a1b1a4c5fb1@mail.gmail.com> Message-ID: <7a6830090910171838u63aa4c24h3889af66727e6a78@mail.gmail.com> > I thought someone had to respond to router solicitations for stateless > autoconfig of global scope addresses to happen. On Linux you just > don't run the radvd. On Cisco I think it's something like "ipv6 nd > suppress-ra" in the interface config. Does that fail to prevent > stateless autoconfig? Or is there a problem with the operation of > DHCPv6 if router advertisements aren't happening from the router? The "ipv6 nd suppress-ra" config will only suppress unsolicited RA, it will still respond to RA solicitations. Load it up in Wireshark and you'll see. A lot of host implementations of IPv6 seem to enable SLAAC as soon as they see any 64-bit prefix regardless of what flags are set. Making assumptions about IPv6 has proven to be unwise in my experience. So far, the only thing that I've seen that is close to working is to configure the router to not advertise the 64-bit prefix using "ipv6 nd prefix no-advertise", but at that point it seems easier to just go with a 80-bit prefix and remove any doubt. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From nanog at daork.net Sat Oct 17 22:22:37 2009 From: nanog at daork.net (Nathan Ward) Date: Sun, 18 Oct 2009 16:22:37 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <3c3e3fca0910171828y1ec82b00u6cb26a1b1a4c5fb1@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <3c3e3fca0910171828y1ec82b00u6cb26a1b1a4c5fb1@mail.gmail.com> Message-ID: <52FF33CA-7868-4E8D-A2CE-A0B2AF9B365A@daork.net> On 18/10/2009, at 2:28 PM, William Herrin wrote: > On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy wrote: >> As it turns out delivering IPv6 to the edge in an academic setting >> has >> been a challenge. Common wisdom says to rely on SLAAC for IPv6 >> addressing, and in a perfect world it would make sense. > > Ray, > > Common wisdom says that? > >> Our current IPv6 allocation schema provides for a 64-bit prefix for >> each network. Unfortunately, this enables SLAAC; yes, you can >> suppress the prefix advertisement, and set the M and O flags, but >> that >> only prevents hosts that have proper implementations of IPv6 from >> making use of SLAAC. The concern here is that older hosts with less >> than OK implementations will still enable IPv6 without regard for the >> stability and security concerns associated with IPv6. > > I thought someone had to respond to router solicitations for stateless > autoconfig of global scope addresses to happen. On Linux you just > don't run the radvd. On Cisco I think it's something like "ipv6 nd > suppress-ra" in the interface config. Does that fail to prevent > stateless autoconfig? Or is there a problem with the operation of > DHCPv6 if router advertisements aren't happening from the router? RA is generally required whether you use stateless or stateful autoconfiguration. You have to tell the hosts to send a DHCPv6 DISCOVER message by turning on the managed flag in the RA. RA does not mean that SLAAC happens. Ray, do you have examples of hosts or stacks that ignore AdvAutonomousFlag? -- Nathan Ward From joelja at bogus.com Sat Oct 17 22:39:24 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 17 Oct 2009 20:39:24 -0700 Subject: UPDATE: NANOG 47 PGP signing party. Message-ID: <4ADA8DEC.9050206@bogus.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a quick note, The NANOG pgp key signing party will be making an appearance at NANOG 47. The keysigning sessions are going to be held during the monday and tuesday morning break (11:00 - 11:30) in the Desoto Foyer. It is likely that we'll invite the various CA cert notaries to join in the fun. If you plan to participate in the pgp keysigning, please add your key to the keyring at: http://biglumber.com/x/web?ev=97301 Then come to one or both sessions with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. While printouts will probably be available at the sessions, feel free to add your key to the keyring right up to the time of the last keysigning event. Thanks Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrajeYACgkQ8AA1q7Z/VrJk6ACeKmcNBgr2kWnkJOiKCIyayudJ E6UAnj2k9jfF8Yx4ZzlgO8ugcth/bcC8 =0DEQ -----END PGP SIGNATURE----- From kauer at biplane.com.au Sat Oct 17 22:51:00 2009 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 18 Oct 2009 14:51:00 +1100 Subject: IPv6 Deployment for the LAN Message-ID: <1255837860.18603.1008.camel@karl> On Sat, 2009-10-17 at 20:55 -0400, Ray Soucy wrote: > making use of SLAAC. The concern here is that older hosts with less > than OK implementations will still enable IPv6 without regard for the > stability and security concerns associated with IPv6. Some hosts - very dumb ones or very old ones, probably embedded stacks - may do SLAAC even with a prefix other than 64 bits! Once a stack is broken,, anything is possible, so I'm not sure you win much here. Zig to avoid one dud, you'll have to zag to avoid thenext, and before you know it your life is nothing but dodging. Take the high ground instead. Better to find and cure/replace/isolate broken hosts than break your entire network just to accommodate them. If you start doing the "wrong thing" to accommodate broken hosts, you will never find peace. Zig to avoid one dud; you'll have to zag to avoid the next and before you know it your life is nothing but dodging. Take the high ground instead. Do the advertisements "right", advise sysadmins that hosts should not do SLAAC, and (if you are really concerned about broken hosts) collect MAC address information from your switches and do an automated test of reachability on all SLAAC addresses. You can generate the addresses yourself easily enough from the prefix and the MAC. None should be reachable, and any that are - well, you now know where they are and can take appropriate action. And then block all SLAAC addresses at your routers or firewalls, that'll larn 'em :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From swmike at swm.pp.se Sat Oct 17 23:54:29 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 18 Oct 2009 06:54:29 +0200 (CEST) Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> Message-ID: On Sat, 17 Oct 2009, Ray Soucy wrote: > Given that historically we have relied on DHCP for a means of NAC and > host registration, like many academic institutions, the idea of sweeping > changes to accommodate IPv6 was just not going to happen in the near > future. IETF has historically dropped the ball on delivering IPv4/v6 services securely, and all the development for IPv4 done outside the IETF hasn't been integrated into IPv6, which now shows when people are trying to deploy it. There is now some working going on though, you should look into the SAVI working group, they have some nice work going on both for v4 and v6 in this space. The v6ops WG is also producing deployment models for securely deploying v6 in ISP environment. -- Mikael Abrahamsson email: swmike at swm.pp.se From cluestore at gmail.com Sun Oct 18 00:15:47 2009 From: cluestore at gmail.com (Clue Store) Date: Sun, 18 Oct 2009 00:15:47 -0500 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> Message-ID: <580af3b90910172215j5e9fc625t4e1f54950f2f0ed@mail.gmail.com> >Since the goal for this initial wave is to make IPv6 available to >those who request it or have a need for it, we feel its acceptable >that there will need to be some user participation in enabling IPv6 >for a host. To me, from a small ISP perspective, this is where the largest delima is.... what 'vendor' is already depolying end user equipment that is ipv6 ready?? Then there's the 'delivering the customer' their ipv6 block (hopefully alongside their ipv4 block). Dual stack seems the way to go... To me, there's still a lot of wiggle room on how this should be deployed to the absolute edge. What's folks experience in rolling this out the the customer ... be it DHCP or SLAAC?? Also from a BBA perspective?? On Sat, Oct 17, 2009 at 7:55 PM, Ray Soucy wrote: > Looking for general feedback on IPv6 deployment to the edge. > > As it turns out delivering IPv6 to the edge in an academic setting has > been a challenge. Common wisdom says to rely on SLAAC for IPv6 > addressing, and in a perfect world it would make sense. > > Given that historically we have relied on DHCP for a means of NAC and > host registration, like many academic institutions, the idea of > sweeping changes to accommodate IPv6 was just not going to happen in > the near future. > > The only solution that lets us expand our roll out IPv6 to the edge > without major changes to the production IPv4 network seems to point to > making use of DHCPv6, so the effort has been focused there. > > Our current IPv6 allocation schema provides for a 64-bit prefix for > each network. Unfortunately, this enables SLAAC; yes, you can > suppress the prefix advertisement, and set the M and O flags, but that > only prevents hosts that have proper implementations of IPv6 from > making use of SLAAC. The concern here is that older hosts with less > than OK implementations will still enable IPv6 without regard for the > stability and security concerns associated with IPv6. > > Needless to say, the thought of being able to enable IPv6 on a > per-host basis is met with far less resistance than opening up the > floodgates and letting SLAAC take control. > > Ultimately, the best solution that I've been able to come up with is > to preserve the IPv6 allocation schema and reserve a 64-bit prefix for > each network, but for the initial deployment use an 80-bit one in its > place with the extra 16 bits given a value of 1. The advantages of > this: Guarantee that SLAAC will not be initiated for the prefix; > Allow for a migration path to 64-bit prefixes in the future; and, Make > it easy to identify a network that us making use of an 80-bit prefix > by setting the extra bits to a value of 1. > > This allows us to be fairly confident that extending IPv6 to edge > networks will not impact production services, and focus on DHCPv6 for > host configuration and address assignment. > > We have no problem using a 64-bit prefix and letting SLAAC take care > of addressing for certain networks where we actually manage the hosts, > so that has been included as an exception. All other networks, > however, will make use of DHCPv6 or manual configuration to receive > native IPv6. > > So far, this has proven to work well with testing of various hosts and > applications. > > Has anyone run into issues with applications in not using a 64-bit prefix? > > Of course, the other challenge here is proper DHCPv6 client > implementations for host operating systems. Linux, Windows Server > 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. > Windows XP has a poor implementation of IPv6 but has the option of > using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a > challenge; it currently has no option for DHCPv6, though newer > releases provide for manual configuration of IPv6 addressing. > > Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS > X? > > Since the goal for this initial wave is to make IPv6 available to > those who request it or have a need for it, we feel its acceptable > that there will need to be some user participation in enabling IPv6 > for a host. I think the hope is that more systems, like Windows 7, > will begin including mature DHCPv6 clients which are enables when the > M flag for a router advertisement is set and perhaps make it the > default behavior. Is this likely to happen or am I being too > optimistic? > > Anyway, just thought I'd bounce it to NANOG and get some feedback. > > -- > > Ray Soucy > Communications Specialist > > +1 (207) 561-3526 > > Communications and Network Services > > University of Maine System > http://www.maine.edu/ > > From andy at nosignal.org Sun Oct 18 03:03:12 2009 From: andy at nosignal.org (Andy Davidson) Date: Sun, 18 Oct 2009 09:03:12 +0100 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> Message-ID: <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> On 18 Oct 2009, at 01:55, Ray Soucy wrote: > The only solution that lets us expand our roll out IPv6 to the edge > without major changes to the production IPv4 network seems to point > to making use of DHCPv6, so the effort has been focused there. [...] > Needless to say, the thought of being able to enable IPv6 on a per- > host basis is met with far less resistance than opening up the > floodgates and letting SLAAC take control. Hi, Roy -- Good summary, thanks for the write-up. I reluctantly just use SLAAC on our own office LANs because, we're still quite a small and nimble team, therefore we can secure our network against our SLAAC security concerns by locking down access to the network. I realise this isn't going to work for everyone, as it doesn't fit well for the security needs of your much larger campus network. It also doesn't work for some of our customers who have DHCP in their toolbox for provision certain hosting environments. DHCPv6 today lacks default-router option support, so you are left with some pretty awful choices if you don't want to use the router solicitation/advertisement, err, 'features' in SLAAC : - Static route on the device - Actually, you could use the *same* link-local address to keep this the same on all devices on your network, which you continue to support long after a "better" protocol comes along. This reduces your support overhead. - end user runs some routing protocol - I don't want to give my router the extra work though. And it feels like a stupid idea. And end user OSes don't tend to have them installed. - Don't roll v6 beyond engineering teams, until something better comes along - Sadly, I think that this is the option people are taking. :-( I don't know the history of the process that led to DHCPv6 ending up crippled, and I have to admit that it's not clear how I signal this and to whom, but for the avoidance of doubt: this operator would like his tools back please. Support default-routing options for DHCPv6 ! Andy -- Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com NetSumo Specialist ISP/networks consultancy, Whitelabel 24/7 NOC From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Oct 18 03:22:47 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 18 Oct 2009 18:52:47 +1030 Subject: IPv6 Deployment for the LAN In-Reply-To: <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: <20091018185247.50967833@opy.nosense.org> On Sun, 18 Oct 2009 09:03:12 +0100 Andy Davidson wrote: > > On 18 Oct 2009, at 01:55, Ray Soucy wrote: > > The only solution that lets us expand our roll out IPv6 to the edge > > without major changes to the production IPv4 network seems to point > > to making use of DHCPv6, so the effort has been focused there. > [...] > > Needless to say, the thought of being able to enable IPv6 on a per- > > host basis is met with far less resistance than opening up the > > floodgates and letting SLAAC take control. > > Hi, Roy -- > > Good summary, thanks for the write-up. > > I reluctantly just use SLAAC on our own office LANs because, we're > still quite a small and nimble team, therefore we can secure our > network against our SLAAC security concerns by locking down access to > the network. I realise this isn't going to work for everyone, as it > doesn't fit well for the security needs of your much larger campus > network. It also doesn't work for some of our customers who have DHCP > in their toolbox for provision certain hosting environments. > > DHCPv6 today lacks default-router option support, so you are left with > some pretty awful choices if you don't want to use the router > solicitation/advertisement, err, 'features' in SLAAC : > I'm curious what the issue is with not having a default-router option in DHCPv6? If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA "servers". > - Static route on the device > - Actually, you could use the *same* link-local address to keep > this the same on all devices on your network, which you continue to > support long after a "better" protocol comes along. This reduces your > support overhead. > > - end user runs some routing protocol > - I don't want to give my router the extra work though. And it > feels like a stupid idea. And end user OSes don't tend to have them > installed. > > - Don't roll v6 beyond engineering teams, until something better > comes along > - Sadly, I think that this is the option people are taking. :-( > > I don't know the history of the process that led to DHCPv6 ending up > crippled, and I have to admit that it's not clear how I signal this > and to whom, but for the avoidance of doubt: this operator would like > his tools back please. Support default-routing options for DHCPv6 ! > > Andy > > > > > -- > Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com > NetSumo Specialist ISP/networks consultancy, Whitelabel 24/7 NOC > > From nanog at daork.net Sun Oct 18 03:23:49 2009 From: nanog at daork.net (Nathan Ward) Date: Sun, 18 Oct 2009 21:23:49 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: <2E2DC85D-D81A-4874-89E4-3D2341148916@daork.net> On 18/10/2009, at 9:03 PM, Andy Davidson wrote: > I don't know the history of the process that led to DHCPv6 ending up > crippled, and I have to admit that it's not clear how I signal this > and to whom, but for the avoidance of doubt: this operator would > like his tools back please. Support default-routing options for > DHCPv6 ! I think what you really want is an on-link prefix option in DHCPv6. Or at least, you'd need that as well as a default router option. As I've said before, RA does not mean SLAAC. DO NOT use the two words interchangeably. We have two address configuration mechanisms, RA is the transport for one (SLAAC) and is the hint to use another (DHCPv6 stateful). The use of RA does NOT require the use of either mechanism. Without RA, we don't know which to use, without manual configuration. I for one don't want to have to fool around every time I move to a new network, and I'm a tech guy. Can we put this in to a FAQ somewhere, I write this in almost every IPv6 thread that comes up on NANOG. The reason Ray's perceived problem exists is that when using DHCPv6 stateful for address configuration, you should also include the prefix in an RA message. This is because DHCPv6 doesn't give out prefix lengths, it only gives out addresses. There is an option (the A bit) with each prefix in an RA message, which says whether this prefix can be used for SLAAC or not (1 = SLAAC). Ray's perception (fear?) is that there are some implementations that will ignore the contents of this bit, and use the prefix for SLAAC regardless. I'm interested to see if these implementations actually exist, I haven't come across any myself or heard of any - but I've not been looking. Anyway, start here for a discussion of prefix lengths in DHCPv6: http://www.ietf.org/mail-archive/web/dhcwg/current/msg07412.html -- Nathan Ward From nanog at daork.net Sun Oct 18 03:29:41 2009 From: nanog at daork.net (Nathan Ward) Date: Sun, 18 Oct 2009 21:29:41 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091018185247.50967833@opy.nosense.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> Message-ID: On 18/10/2009, at 9:22 PM, Mark Smith wrote: > I'm curious what the issue is with not having a default-router option > in DHCPv6? This mechanism is provided by RA. RA is needed to tell a host to use DHCPv6, so RA is going to be there whenever you have DHCPv6. There's no point putting a default router option in to DHCPv6 at this point. > If it's because somebody could start up a rogue router and announce > RAs, I think a rogue DHCPv6 server is (or will be) just as much a > threat, if not more of one - I think it's more likely server OSes will > include DHCPv6 servers than RA "servers". Perhaps, but if you're operating a LAN segment you're going to want to filter rouge RA and DHCPv6 messages from your network, just like you do with DHCP in IPv4. Filtering RA and DHCPv6 are done in very similar ways. -- Nathan Ward From cra at WPI.EDU Sun Oct 18 03:52:17 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 18 Oct 2009 04:52:17 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> Message-ID: <20091018085217.GC9100@angus.ind.WPI.EDU> On Sun, Oct 18, 2009 at 09:29:41PM +1300, Nathan Ward wrote: > Perhaps, but if you're operating a LAN segment you're going to want to > filter rouge RA and DHCPv6 messages from your network, just like you do > with DHCP in IPv4. > Filtering RA and DHCPv6 are done in very similar ways. Unfortunately, no. Many/most LAN switches don't support filtering IPv6 traffic yet. Of those that do, most only support TCP/UDP ports but not ICMPv6 types or RA specifically. Therefore, right now it is probably easier to find support to filter DHCPv6 (udp source port 547) than it is to find support to filter RA. This is a real problem even for people who are not using IPv6 right now and have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue box on the LAN, breaking access to dual-stack servers on the Internet. The impact is worse when you start trying to roll out IPv6 dual-stack to selected servers on your own LAN. From nanog at daork.net Sun Oct 18 04:02:47 2009 From: nanog at daork.net (Nathan Ward) Date: Sun, 18 Oct 2009 22:02:47 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091018085217.GC9100@angus.ind.WPI.EDU> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <20091018085217.GC9100@angus.ind.WPI.EDU> Message-ID: On 18/10/2009, at 9:52 PM, Chuck Anderson wrote: > On Sun, Oct 18, 2009 at 09:29:41PM +1300, Nathan Ward wrote: >> Perhaps, but if you're operating a LAN segment you're going to want >> to >> filter rouge RA and DHCPv6 messages from your network, just like >> you do >> with DHCP in IPv4. >> Filtering RA and DHCPv6 are done in very similar ways. > > Unfortunately, no. Many/most LAN switches don't support filtering > IPv6 traffic yet. Of those that do, most only support TCP/UDP ports > but not ICMPv6 types or RA specifically. Therefore, right now it is > probably easier to find support to filter DHCPv6 (udp source port 547) > than it is to find support to filter RA. This is a real problem even > for people who are not using IPv6 right now and have no desire to use > IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue > box on the LAN, breaking access to dual-stack servers on the Internet. > The impact is worse when you start trying to roll out IPv6 dual-stack > to selected servers on your own LAN. This is true for now until we get switches with code to do this, and also doesn't change my point. -- Nathan Ward From andy at nosignal.org Sun Oct 18 05:02:23 2009 From: andy at nosignal.org (Andy Davidson) Date: Sun, 18 Oct 2009 11:02:23 +0100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091018185247.50967833@opy.nosense.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> Message-ID: <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> On 18 Oct 2009, at 09:22, Mark Smith wrote: > If it's because somebody could start up a rogue router and announce > RAs, I think a rogue DHCPv6 server is (or will be) just as much a > threat, if not more of one - I think it's more likely server OSes > will include DHCPv6 servers than RA "servers". Disagree - rogue offers affect people without a lease, so the impact of an attack is not immediate. Filtering DHCP on v4 is well understood, an update to current operational practice rather than a new system. On 18 Oct 2009, at 09:29, Nathan Ward wrote: > RA is needed to tell a host to use DHCPv6 This is not ideal. Andy From nanog at daork.net Sun Oct 18 05:05:34 2009 From: nanog at daork.net (Nathan Ward) Date: Sun, 18 Oct 2009 23:05:34 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> Message-ID: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: > On 18 Oct 2009, at 09:29, Nathan Ward wrote: > >> RA is needed to tell a host to use DHCPv6 > > This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. -- Nathan Ward From trejrco at gmail.com Sun Oct 18 06:55:36 2009 From: trejrco at gmail.com (TJ) Date: Sun, 18 Oct 2009 07:55:36 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091018085217.GC9100@angus.ind.WPI.EDU> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <20091018085217.GC9100@angus.ind.WPI.EDU> Message-ID: <002401ca4fe9$e85eed70$b91cc850$@com> "This is a real problem even for people who are not using IPv6 right now and have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue box on the LAN" Answer = "RA Guard" - push your vendor-of-choice to implement it :). /TJ -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Sunday, October 18, 2009 4:52 AM To: nanog at nanog.org Subject: Re: IPv6 Deployment for the LAN Unfortunately, no. Many/most LAN switches don't support filtering IPv6 traffic yet. Of those that do, most only support TCP/UDP ports but not ICMPv6 types or RA specifically. Therefore, right now it is probably easier to find support to filter DHCPv6 (udp source port 547) than it is to find support to filter RA. This is a real problem even for people who are not using IPv6 right now and have no desire to use IPv6 yet, because Rogue RAs will redirect all IPv6 traffic to a rogue box on the LAN, breaking access to dual-stack servers on the Internet. The impact is worse when you start trying to roll out IPv6 dual-stack to selected servers on your own LAN. From trejrco at gmail.com Sun Oct 18 06:58:00 2009 From: trejrco at gmail.com (TJ) Date: Sun, 18 Oct 2009 07:58:00 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> Message-ID: <002501ca4fea$3de04550$b9a0cff0$@com> "> RA is needed to tell a host to use DHCPv6 This is not ideal." That is entirely a matter of opinion, and one frequently debated still. FWLIW - I think RAs are a perfectly fine way to distribute information about the router itself, and to provide hints about the environment (e.g. - "Yes, we do Stateful DHCPv6 here ("+M", and "+O' as well" ...) /TJ -----Original Message----- From: Andy Davidson [mailto:andy at nosignal.org] Sent: Sunday, October 18, 2009 6:02 AM To: NANOG list Subject: Re: IPv6 Deployment for the LAN On 18 Oct 2009, at 09:22, Mark Smith wrote: > If it's because somebody could start up a rogue router and announce > RAs, I think a rogue DHCPv6 server is (or will be) just as much a > threat, if not more of one - I think it's more likely server OSes > will include DHCPv6 servers than RA "servers". Disagree - rogue offers affect people without a lease, so the impact of an attack is not immediate. Filtering DHCP on v4 is well understood, an update to current operational practice rather than a new system. On 18 Oct 2009, at 09:29, Nathan Ward wrote: > RA is needed to tell a host to use DHCPv6 This is not ideal. Andy From owen at delong.com Sun Oct 18 07:10:37 2009 From: owen at delong.com (Owen DeLong) Date: Sun, 18 Oct 2009 05:10:37 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> Message-ID: <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: > On 18/10/2009, at 11:02 PM, Andy Davidson wrote: > >> On 18 Oct 2009, at 09:29, Nathan Ward wrote: >> >>> RA is needed to tell a host to use DHCPv6 >> >> This is not ideal. > > Why? > Remember RA does not mean SLAAC, it just means RA. > > -- > Nathan Ward Because RA assumes that all routers are created equal. Because RA is harder to filter. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. I think those are the top 3. I can't think of the rest of the list off the top of my head as my brain still thinks it's 5 AM. Owen From trejrco at gmail.com Sun Oct 18 07:27:01 2009 From: trejrco at gmail.com (TJ) Date: Sun, 18 Oct 2009 08:27:01 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> Message-ID: <002f01ca4fee$4ba9a420$e2fcec60$@com> "Because RA assumes that all routers are created equal. Because RA is harder to filter. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns." Off the top of my head, the easiest answers are: Default Router Preference, well supported on hosts and routers, doesn't cover 100% of every corner case, but then again - nothing does :) RA Guard - push vendors to implement (otherwise, other monitoring/preventative measures are available - but 3rd party) And I still think the router is in a (much) better position to inform hosts about the router's and link's information than some server three hops ---> that way. /TJ -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Sunday, October 18, 2009 8:11 AM To: Nathan Ward Cc: NANOG Subject: Re: IPv6 Deployment for the LAN On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: > On 18/10/2009, at 11:02 PM, Andy Davidson wrote: > >> On 18 Oct 2009, at 09:29, Nathan Ward wrote: >> >>> RA is needed to tell a host to use DHCPv6 >> >> This is not ideal. > > Why? > Remember RA does not mean SLAAC, it just means RA. > > -- > Nathan Ward Because RA assumes that all routers are created equal. Because RA is harder to filter. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. I think those are the top 3. I can't think of the rest of the list off the top of my head as my brain still thinks it's 5 AM. Owen From nanog at daork.net Sun Oct 18 07:39:29 2009 From: nanog at daork.net (Nathan Ward) Date: Mon, 19 Oct 2009 01:39:29 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> Message-ID: On 19/10/2009, at 1:10 AM, Owen DeLong wrote: > On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: > >> On 18/10/2009, at 11:02 PM, Andy Davidson wrote: >> >>> On 18 Oct 2009, at 09:29, Nathan Ward wrote: >>> >>>> RA is needed to tell a host to use DHCPv6 >>> >>> This is not ideal. >> >> Why? >> Remember RA does not mean SLAAC, it just means RA. > > Because RA assumes that all routers are created equal. RFC4191 > Because RA is harder to filter. DHCP in IPv4 was hard to filter before vendors implemented it, too. > Because the bifercated approach to giving a host router/mask > information and address information > creates a number of unnecessary new security concerns. Security concerns would be useful to explore. Can you expand on this? -- Nathan Ward From kloch at kl.net Sun Oct 18 10:45:22 2009 From: kloch at kl.net (Kevin Loch) Date: Sun, 18 Oct 2009 11:45:22 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> Message-ID: <4ADB3812.6050805@kl.net> Nathan Ward wrote: > > On 19/10/2009, at 1:10 AM, Owen DeLong wrote: > >> On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: >> >>> On 18/10/2009, at 11:02 PM, Andy Davidson wrote: >>> >>>> On 18 Oct 2009, at 09:29, Nathan Ward wrote: >>>> >>>>> RA is needed to tell a host to use DHCPv6 >>>> >>>> This is not ideal. >>> >>> Why? >>> Remember RA does not mean SLAAC, it just means RA. >> >> Because RA assumes that all routers are created equal. > > RFC4191 In some cases different devices on a segment need a different default router (for default). This is the fundamental problem with RA's, they shotgun the entire segment. > >> Because RA is harder to filter. > > DHCP in IPv4 was hard to filter before vendors implemented it, too. > >> Because the bifercated approach to giving a host router/mask >> information and address information >> creates a number of unnecessary new security concerns. > > Security concerns would be useful to explore. Can you expand on this? What would be useful would be having the option to give a default router to a dhcpv6 client, and having vrrpv6 work without RA's. Why can't we have those options in our toolbox in addition to this continuously evolving RA+hacks? - Kevin From rps at maine.edu Sun Oct 18 11:26:41 2009 From: rps at maine.edu (Ray Soucy) Date: Sun, 18 Oct 2009 12:26:41 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <4ADB3812.6050805@kl.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> <4ADB3812.6050805@kl.net> Message-ID: <7a6830090910180926u1e04af9uf88c8ce308fef064@mail.gmail.com> I generally agree with the design of RA and using DHPCv6 as a supplement to it. The problems here seem to be more along the lines of implementation in clients. I suspect it will take some time for the dust to settle and vendors to get their act together. I notice that Cisco has a "prefix no-autoconfig" statement in some releases in addition to no-advertise. The code I'm running doesn't seem to support this yet. I'll have to dig deeper to see what series support it and how it interacts with hosts. If hosts actually do respect it, it will likely lead to our migration to using /64s, though a lot will depend on the time tables we can set to move to code that will support this on our routers. I do remember seeing some notes about some implementations of IPv6 simply ignoring that flag for the prefix, though, so I'm still hesitant to endorse it until I've had a chance to test a wide variety of hosts in this configuration. Still, using a prefix other than a /64, but maintaining a migration path to /64 in the future, seems to be the best way to get IPv6 rolled out to the edge from a political standpoint. It's easier to make the case to extend IPv6 if you can be fairly certain that it won't cause hosts to suddenly start using IPv6 on their own. I have yet to run into an IPv6 implementation that will use SLAAC with a prefix other than a /64, thankfully. >From what I've been told, Cisco is actively working on RA-gaurd for their managed switching platforms, which will be nice to see. Reading a bit of the discussions regarding IPv6 in the Apple world, it seems that they're after supporting DNS server information in RA using RFC 5006. I think RFC 5006 is a very bad idea personally. DHCPv6 was designed to work in harmony with RA, and providing host configuration is beyond the scope of RA. I hope that we don't start seeing implementations of this as it will lead to an environment where some clients support DHCPv6 and some do not. The SLAAC vs. DHCPv6 war all seems a bit silly. They're both tools that are designed to compliment one another, and both have their uses. DHCPv6 does complicate things with the DUID rather than using the physical address, but I can appreciate the problems they're trying to overcome. It just makes this a little more complicated for those of us who would like to maintain associations between a hosts IP and IPv6 information in a dual-stack environment. On Sun, Oct 18, 2009 at 11:45 AM, Kevin Loch wrote: > Nathan Ward wrote: >> >> On 19/10/2009, at 1:10 AM, Owen DeLong wrote: >> >>> On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: >>> >>>> On 18/10/2009, at 11:02 PM, Andy Davidson wrote: >>>> >>>>> On 18 Oct 2009, at 09:29, Nathan Ward wrote: >>>>> >>>>>> RA is needed to tell a host to use DHCPv6 >>>>> >>>>> This is not ideal. >>>> >>>> Why? >>>> Remember RA does not mean SLAAC, it just means RA. >>> >>> Because RA assumes that all routers are created equal. >> >> RFC4191 > > In some cases different devices on a segment need a different > default router (for default). ?This is the fundamental > problem with RA's, they shotgun the entire segment. > >> >>> Because RA is harder to filter. >> >> DHCP in IPv4 was hard to filter before vendors implemented it, too. >> >>> Because the bifercated approach to giving a host router/mask information >>> and address information >>> ? ?creates a number of unnecessary new security concerns. >> >> Security concerns would be useful to explore. Can you expand on this? > > What would be useful would be having the option to give a default > router to a dhcpv6 client, and having vrrpv6 work without RA's. > Why can't we have those options in our toolbox in addition to > this continuously evolving RA+hacks? > > - Kevin > > -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From kmedcalf at dessus.com Sun Oct 18 11:52:28 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 18 Oct 2009 13:52:28 -0300 Subject: OT: Any PALM e-mail administrators Message-ID: I have tried contacting PALM through their listed contact phone numbers and by email to their postmaster, all to no avail. I am having problems with their SMTP servers being unable to communicate with my domain configured SMTP server using Mxed addessing (ie, to kmedcalf at dessus.com) although sending directly to the mail server (kmedcalf at mail.dessus.com) works correctly. This issue is limited to PALM and their configuration and I cannot duplicate (nor have I ever come across such a misconfiguration anywhere else, ever). Even adding A records directly to the domain record itself does not result in success. I have had no success contacting anyone with clue at palm for about three weeks now despite numerous attempts to do so. Anyone with an internal contact, or if anyone from PALM is here, off-list contact info would be appreciated. (mail sent via PALM SMTP servers will have to be sent to the incorrect -- direct mailbox on the SMTP server -- address kmedcalf at mail.dessus.com or your misconfigured servers will not even attempt to send the message). Now, back to our regularly scheduled programming ... -- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From trejrco at gmail.com Sun Oct 18 12:29:54 2009 From: trejrco at gmail.com (TJ) Date: Sun, 18 Oct 2009 13:29:54 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <4ADB3812.6050805@kl.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> <4ADB3812.6050805@kl.net> Message-ID: <006c01ca5018$9bbd1da0$d33758e0$@com> > In some cases different devices on a segment need a different > default router (for default). This is the fundamental This capability is also defined, "more specific routes" - but no one encouraged any vendors that I know of to support it - so they don't. Big demand? > problem with RA's, they shotgun the entire segment. As opposed to a standard deployment, where the DHCP server provides the same information to every host on that link ... ??? > What would be useful would be having the option to give a default > router to a dhcpv6 client, and having vrrpv6 work without RA's. These are separate problems. Host configuration vs. first-hop redundancy, and we can solve them independently. > Why can't we have those options in our toolbox in addition to > this continuously evolving RA+hacks? You say hacks, others see it as relatively-speaking simple additions of more functionality. You can define any options you want for DHCPv6, write a draft and get community support. I don't see how that ("continuously evolving DHCPv6 hacks") is any better than what is happening with RAs? I, for one, am just fine with RAs being the first step - leading to either SLAAC or (some mode of) DHCPv6 ... /TJ From trejrco at gmail.com Sun Oct 18 12:33:52 2009 From: trejrco at gmail.com (TJ) Date: Sun, 18 Oct 2009 13:33:52 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910180926u1e04af9uf88c8ce308fef064@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> <4ADB3812.6050805@kl.net> <7a6830090910180926u1e04af9uf88c8ce308fef064@mail.gmail.com> Message-ID: <006d01ca5019$2981b010$7c851030$@com> > I notice that Cisco has a "prefix no-autoconfig" statement in some Yes, advertise it as on-link but not suitable for autoconfig. You would want to do this (along with the M & O bits) for a stateful-DHCPv6 segment ... > >From what I've been told, Cisco is actively working on RA-gaurd for > their managed switching platforms, which will be nice to see. And not just Cisco, IIRC it is an open standard anyone can implement ... ? > The SLAAC vs. DHCPv6 war all seems a bit silly. They're both tools > that are designed to compliment one another, and both have their uses. ++1 (And if I could vote "yes" on that statement more than once on that I would ...) /TJ From rps at maine.edu Sun Oct 18 12:38:27 2009 From: rps at maine.edu (Ray Soucy) Date: Sun, 18 Oct 2009 13:38:27 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <006d01ca5019$2981b010$7c851030$@com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> <4ADB3812.6050805@kl.net> <7a6830090910180926u1e04af9uf88c8ce308fef064@mail.gmail.com> <006d01ca5019$2981b010$7c851030$@com> Message-ID: <7a6830090910181038o360adebbq29c294ab7da297dc@mail.gmail.com> > And not just Cisco, IIRC it is an open standard anyone can implement ... ? Here is the work being done on RA-Gaurd: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-03 -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From nick at foobar.org Sun Oct 18 12:43:54 2009 From: nick at foobar.org (Nick Hilliard) Date: Sun, 18 Oct 2009 18:43:54 +0100 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> Message-ID: <4ADB53DA.2000804@foobar.org> On 18/10/2009 11:05, Nathan Ward wrote: > Remember RA does not mean SLAAC, it just means RA. This is not ideal because two protocols are being mandated instead of just one: RA for client-side autoconfiguration and DHCPv6 for everything else. This is pointless. We have a good working model in ipv4: namely, the Joesoap in charge of the LAN decides what addressing parameters are to be used on the network, and it all uses a single protocol: dhcpv4. you can filter it out from rogue clients using dhcp-guard on a decent switch, and everyone is happy with it. However, in IPv6, we are being told that this is not good enough: that there need to be two protocols, one of which tells the client enough information about the network so that the client can choose its own address, route packets but not enough to allow DNS (i.e. functional internet connectivity). So then we decided that we needed another protocol to give the client everything else that it needed. And in order to avoid egos from tripping over other egos, each camp kept on their own turf: dhcp6 was hobbled to the extent that it couldn't feasibly be called a host configuration protocol (no default route, no address assignment and no subnet size options), and the RA folks at least initially tried to keep useful functionality out of the RA spec. Or at least this was the plan. Of course, it was a completely broken plan for a variety of reasons, including: - there were two protocols required for stateless network management instead of one - we already had a really good working model in ipv4 - address selection was performed by the client, not the administrator - we found out in the early 1990s with RIP that you need to be careful about announcing default routes, and because you now have to protect against two protocols instead of just one, this makes things more difficult - no-one thought it might be useful to ask the operators what they thought about using two protocols instead of one. Did it ever occur to the people defining the standards that most LAN operators are not particularly smart people, and that they would have trouble with this? So, as a result, RA grew about 6 arms and 8 legs (most of them the left-side variant), and the DHCPv6 camp continued with their diplomatic tip-toeing around the RA camp until one day, someone threw King Looie Katz's tail into the dirt: no longer were Hooie, Fooie or Kooie Katz going to play nice! So, now we have protocol proposals in the pipeline that will enable DHCPv6 to be sufficient to functionally run stateless address configuration rather than to continue to be nothing more than a necessary headache. Hooray! Of course, there are still several people in ietf-land who think that this is all a terrible mistake, and that RA and DHCPv6 should have been complementary to each other. To these people, I will be happy to listen to their opinions on condition that they do two things: 1) agree to filter out all ethertypes except 0x86dd on their laptops at ietf meetings (and spare me the platitudes that they aren't responsible for what the vendors implement) and 2) attempt to run a large IPv6 multi-lan network with current operating systems and switching gear for a period of one month. Most seriously, there's not nearly enough eating-one's-own-dog-food going on here. So, if someone in protocol standards-land had actually asked the operators what they wanted, they would have been told that they needed a protocol which took decisions about addressing and configuration away from the client. You plonk your computer on a lan, and you are told what address to use and what configuration parameters to use. You don't start inventing your own, because honestly, it's a pain to manage. I appreciate there are conflicting views on this particular point; I've heard the arguments and remain entirely unconvinced that RA + anything makes for a better stateless host configuration protocol than dhcpv6 will, or ought to have from day one. Meanwhile, because of all this pointless bickering about whether dhcpv6 should have had this or that or the other option, we're 13 years down the road since ipv6 was defined and we still don't have what I would consider to be a sane and fully standardised host auto-configuration model. I find it amusing that sane autoconfiguration was supposed to be one of the primary selling points of ipv6 in the first place. Nick From bburke at merit.edu Sun Oct 18 12:48:06 2009 From: bburke at merit.edu (Betty Burke) Date: Sun, 18 Oct 2009 13:48:06 -0400 (EDT) Subject: [NANOG-announce] NANOG47 Reminders In-Reply-To: <1836171717.4941391255886920291.JavaMail.root@crono> Message-ID: <1135845338.4953631255888086824.JavaMail.root@crono> Hi Everyone: On behalf of Merit, the NANOG SC, PC and MLC we remind you to take advantage of the 2009 Election process. The 2009 SC and Charter amendments Elections are now open, and will remain open until closing at 09:15 EDT on Wednesday, 10-21-09. The Ballot is linked from http://nanog.org/governance/elections/2009elections/index.php and will require your NANOG Registration id and password for final access to the ballot. The list of eligible voters is found at http://nanog.org/governance/elections/2009elections/2009_voters.php. If you have any problems with the process, please send a note to elections at nanog.org and we will be sure to get right back to you. Also, a reminder, PC Candidate nominations will close on Sunday, 10-19-09 at 9 am. Please get those nominations in, or if you have nominated someone and do not find their name at http://nanog.org/governance/elections/2009elections/2009pc_candidates.php, please send a note to nominations at nanog.org. In addition, nominations for the MLC is also open. Again, send nominations to the MLC and/or questions to nominations at nanog.org. Best of luck to all the candidates! Sincerely, Betty Sincerely, Betty Merit Network Inc. NANOG Community Project Manager _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From kloch at kl.net Sun Oct 18 13:10:51 2009 From: kloch at kl.net (Kevin Loch) Date: Sun, 18 Oct 2009 14:10:51 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <006c01ca5018$9bbd1da0$d33758e0$@com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> <4ADB3812.6050805@kl.net> <006c01ca5018$9bbd1da0$d33758e0$@com> Message-ID: <4ADB5A2B.9080903@kl.net> TJ wrote: >> In some cases different devices on a segment need a different >> default router (for default). This is the fundamental > > This capability is also defined, "more specific routes" - but no one > encouraged any vendors that I know of to support it - so they don't. Big > demand? by "Default" I meant 0.0.0.0/0, not more specifics. >> problem with RA's, they shotgun the entire segment. > > As opposed to a standard deployment, where the DHCP server provides the same > information to every host on that link ... ??? Not always. The DHCP server can be aware of specific clients by mac address and give different options (and even pseudo-static IPs). DHCP server is not always running on a router so adding this functionality to routers won't help. - Kevin From trejrco at gmail.com Sun Oct 18 13:17:58 2009 From: trejrco at gmail.com (TJ) Date: Sun, 18 Oct 2009 14:17:58 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <4ADB53DA.2000804@foobar.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <4ADB53DA.2000804@foobar.org> Message-ID: <007901ca501f$526c7bd0$f7457370$@com> > > Remember RA does not mean SLAAC, it just means RA. > > This is not ideal because two protocols are being mandated instead of > just > one: RA for client-side autoconfiguration and DHCPv6 for everything > else. Um, DHCPv6 does configure the client - perhaps not until the +M or +O option is recieved. > This is pointless. We have a good working model in ipv4: namely, the > Joesoap in charge of the LAN decides what addressing parameters are to > be used on the network, and it all uses a single protocol: dhcpv4. You can > filter it out from rogue clients using dhcp-guard on a decent switch, > and everyone is happy with it. And RA Guard will fix it for IPv6. Did we have DHCP Guard @ day 1? > However, in IPv6, we are being told that this is not good enough: that > there need to be two protocols, one of which tells the client enough > information about the network so that the client can choose its own > address, route packets but not enough to allow DNS (i.e. functional > internet connectivity). So then we decided that we needed another > protocol > to give the client everything else that it needed. And in order to > avoid > egos from tripping over other egos, each camp kept on their own turf: > dhcp6 was hobbled to the extent that it couldn't feasibly be called a > host > configuration protocol (no default route, no address assignment and no Incorrect, DHCPv6 can assign addresses. > subnet size options), and the RA folks at least initially tried to keep > useful functionality out of the RA spec. > > Or at least this was the plan. Of course, it was a completely broken > plan > for a variety of reasons, including: > > - there were two protocols required for stateless network management > instead of one > - we already had a really good working model in ipv4 Perhaps, But I submit that "good" and "working" do not mean "ideal". > - address selection was performed by the client, not the administrator If SLAAC is chosen, yes. > - we found out in the early 1990s with RIP that you need to be careful > about announcing default routes, and because you now have to protect > against two protocols instead of just one, this makes things more > difficult > - no-one thought it might be useful to ask the operators what they > thought > about using two protocols instead of one. Did it ever occur to the > people > defining the standards that most LAN operators are not particularly > smart > people, and that they would have trouble with this? With the addition of RFC5006, you can actually choose just one (once hosts implement it). Just not the one you seem to favor. > So, as a result, RA grew about 6 arms and 8 legs (most of them the > left-side variant), and the DHCPv6 camp continued with their diplomatic > tip-toeing around the RA camp until one day, someone threw King Looie > Katz's tail into the dirt: no longer were Hooie, Fooie or Kooie Katz > going > to play nice! So, now we have protocol proposals in the pipeline that > will > enable DHCPv6 to be sufficient to functionally run stateless address > configuration rather than to continue to be nothing more than a > necessary > headache. Hooray! And I am OK with all that as well, although THAT also complicates scenarios for implementers. (Now hosts will need to support two discrete host-configuration protocols that actively step on each others' capabilities). > Of course, there are still several people in ietf-land who think that > this > is all a terrible mistake, and that RA and DHCPv6 should have been > complementary to each other. To these people, I will be happy to > listen to > their opinions on condition that they do two things: 1) agree to filter > out > all ethertypes except 0x86dd on their laptops at ietf meetings (and > spare > me the platitudes that they aren't responsible for what the vendors > implement) and 2) attempt to run a large IPv6 multi-lan network with > current operating systems and switching gear for a period of one month. I'll filter all non-0x86dd if you filter all non-0x800. And I will be more successful as you are then blocking ARP :). The other missing piece of that is most of us aren't going "IPv6 ONLY" just yet - so if we need to rely on IPv4 for a bit longer that is, while far from optimal, atleast "kinda OK". (e.g. - cheating off of IPv4 for DNS). > > Most seriously, there's not nearly enough eating-one's-own-dog-food > going > on here. Totally agree there! > So, if someone in protocol standards-land had actually asked the > operators > what they wanted, they would have been told that they needed a protocol > which took decisions about addressing and configuration away from the > client. You plonk your computer on a lan, and you are told what > address to > use and what configuration parameters to use. You don't start > inventing > your own, because honestly, it's a pain to manage. It is still the router, a piece of managed infrastructure sending out the information - not like we are encouraging hosts to make up their own prefix info here ... and hosts choosing the low-order bits shouldn't matter that much. > I appreciate there are conflicting views on this particular point; > I've > heard the arguments and remain entirely unconvinced that RA + anything > makes for a better stateless host configuration protocol than dhcpv6 > will, > or ought to have from day one. Meanwhile, because of all this > pointless > bickering about whether dhcpv6 should have had this or that or the > other > option, we're 13 years down the road since ipv6 was defined and we > still > don't have what I would consider to be a sane and fully standardised > host > auto-configuration model. Well, obviously not _fully_ standardized as we are still adding stuff ... but I would argue the sanity part is OK. And again, it still (esthetically and architecturally) seems to make a lot of sense for the router to send out information about the router. With the added bonus of "it can and does work today", regardless of the arguments for/against it. /TJ From rps at maine.edu Sun Oct 18 13:20:53 2009 From: rps at maine.edu (Ray Soucy) Date: Sun, 18 Oct 2009 14:20:53 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <19CD9923-D0BF-43B0-8FB0-2556F802B642@acm.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <19CD9923-D0BF-43B0-8FB0-2556F802B642@acm.org> Message-ID: <7a6830090910181120k8476f1ewe208de5186d6b039@mail.gmail.com> Thought this off-list reply would be of interest to many here: On Sun, Oct 18, 2009 at 1:43 PM, Daniel G. Kluge wrote: > Hello Ray, > on the Subject on DHCPv6 for MacOS, there were some discussions on the > IPv6-dev lists on Apple, with the usual comment from Apple engineers, that > they are not authorized to discuss plans on product features. If you have a > substantial MacOS population, I'd recommend to join the discussion, and > chime in for support of DHCPv6 on MacOS. > The two recent threads on DHCPv6 are: > http://lists.apple.com/archives/Ipv6-dev/2009/Sep/msg00018.html > http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00003.html > The first one is from the perspective of service providers, the latter one > from the perspective of enterprises and educational networks > Cheers, > -daniel I'd like to urge everyone to send in bug reports to Apple as described in the mailing list posts above requesting DHCPv6 in OS X. Thank you, Dan. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From matthew at eeph.com Sun Oct 18 15:18:27 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Sun, 18 Oct 2009 13:18:27 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <007901ca501f$526c7bd0$f7457370$@com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <4ADB53DA.2000804@foobar.org> <007901ca501f$526c7bd0$f7457370$@com> Message-ID: <4ADB7813.8010701@eeph.com> TJ wrote: > It is still the router, a piece of managed infrastructure sending out the > information - not like we are encouraging hosts to make up their own prefix > info here ... and hosts choosing the low-order bits shouldn't matter that > much. But that's the fatal flaw of autoconfiguration. "Hosts chosing the low-order bits" works great until either A) one of those hosts wants a semi-permanent name lodged in a DNS server and the IT guy wants to semi-permanently assign an IP address to it without having to touch the host configuration or B) the RIAA/MPAA/FBI/etc. comes and asks to see the logs which show which user on the subnet had a particular address and then goes to the local court and claims that you're using this newfangled protocol so as to avoid making information available that has "always" been available before. If *both* of these problems were fixed as well as DHCP fixes them for IPv4, there'd be a whole lot more support for letting the hosts choose their low-order bits. Matthew Kaufman From smb at cs.columbia.edu Sun Oct 18 15:28:42 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 18 Oct 2009 16:28:42 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> Message-ID: <42D04CD7-6313-4A9A-A675-ABF48DB8CC62@cs.columbia.edu> On Oct 17, 2009, at 8:55 PM, Ray Soucy wrote: > Looking for general feedback on IPv6 deployment to the edge. > > As it turns out delivering IPv6 to the edge in an academic setting has > been a challenge. Common wisdom says to rely on SLAAC for IPv6 > addressing, and in a perfect world it would make sense. > > Given that historically we have relied on DHCP for a means of NAC and > host registration, like many academic institutions, the idea of > sweeping changes to accommodate IPv6 was just not going to happen in > the near future. ... My question is this: what are your goals? What are you trying to achieve? Force all authorized machines to register? If so, why? We'll leave out for now whether or not there's even much point to that. My university -- and I'm just a user of campus computing facilities; I don't run them -- has concluded that there's no particular benefit to requiring registration or permission; it's one more server complex to run, one more database to maintain, and one more thing to break, and the benefits don't seem to be worth the cost. And given that we've had incidents of IP and MAC address spoofing, where it took the switch logs to figure out what was going on, I'm very far from convinced that registration is of any benefit anyway. In other words -- yes, I agree with the campus policy -- but that's not the question I'm asking. I ask because there may be other ways to achieve your actual goal, but without knowing that it's hard to make recommendations. The most obvious answer is accountability, but physical port number may be a better approach there, depending on how the campus network is run. --Steve Bellovin, http://www.cs.columbia.edu/~smb From rps at maine.edu Sun Oct 18 16:38:26 2009 From: rps at maine.edu (Ray Soucy) Date: Sun, 18 Oct 2009 17:38:26 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <42D04CD7-6313-4A9A-A675-ABF48DB8CC62@cs.columbia.edu> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <42D04CD7-6313-4A9A-A675-ABF48DB8CC62@cs.columbia.edu> Message-ID: <7a6830090910181438y2481652cr2264809861940e13@mail.gmail.com> Thanks for the response, if only to force me put my thoughts down into words. On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin wrote: > ... > > My question is this: what are your goals? ?What are you trying to achieve? > ?Force all authorized machines to register? ?If so, why? ?We'll leave out > for now whether or not there's even much point to that. ?My university -- > and I'm just a user of campus computing facilities; I don't run them -- has > concluded that there's no particular benefit to requiring registration or > permission; it's one more server complex to run, one more database to > maintain, and one more thing to break, and the benefits don't seem to be > worth the cost. ?And given that we've had incidents of IP and MAC address > spoofing, where it took the switch logs to figure out what was going on, I'm > very far from convinced that registration is of any benefit anyway. ?In > other words -- yes, I agree with the campus policy -- but that's not the > question I'm asking. Not my place to implement policy; I'm not a lawyer. We already have monitoring in place for accountability that maps each address used on a network (regardless of IP or IPv6) to a device and interface for incident response. The greater concern is that SLAAC makes IPv6 available to hosts that may not be prepared for it. If administrators are asked if they would like IPv6 enabled, having been explained the implications of such if SLAAC is used for configuration, the majority of the time they come back and say "thanks, but no thanks." In this situation, SLAAC is holding back deployment of IPv6. I suspect other have seen this as well. Part of the problem here is that IPv6 isn't new; it's old. Implementations have been in place for years on certain systems without proper testing as they have gone largely unused. We've seen cases where older versions of Linux can be crashed by enabling SLAAC on a network being one example. By using DHCPv6 we gain some advantages: We can automatically update DNS for hosts so that IPv4 records and IPv6 records match; We have the ability to roll out DHCPv6 on a per-host basis without causing problems on the production IP network; and we can roll it in to our existing [home grown] tools for network management in a way that is easy for users of the system to understand (keep in mind, we provide tools to delegate network control to hundreds of sub-administrators throughout the State). The original question here wasn't SLAAC vs. DHCPv6. I think many network operators here who are tasked with managing anything of scale will agree that SLAAC doesn't quite cut it and is often a step backwards. The overhead of implementing and administering such a system at this scale generally wins out over not doing so. The question I was mainly concerned with was if anyone has encountered issues with the use of an 80-bit prefix to prevent SLAAC from being active. While the prefix advertisement does have the autonomous flag which can be set to false, the underlying problem of IPv6 implementations not being consistent across hosts operating systems yet doesn't change. I'm not convinced that there aren't implementations out there that will enable SLAAC regardless of what the prefix flag is set to, so using a prefix other than a 64 provides an easy way to [attempt to] avoid this, all the while allowing for us to eventually migrate to a 64-bit prefix when host support improves. Another concern is that we certainly don't want to use SLAAC for servers, and I'm hesitant to promote the use of manual IP configuration as it can quickly become a nightmare if you need to move networks (admittedly there should be less need for network moves, but all the same). DHCP has long solved many of these issues in the IP world, and it is perfectly reasonable, and desirable, to apply them to IPv6 though the use of DHCPv6. Perhaps in the future, as we see less legacy hosts online we'll be in a position to make use of both SLAAC and DHCPv6 for host configuration, but in all honesty, once DHCPv6 is in place, why would you want to use SLAAC? My other question was DHCPv6 support from Apple (who seems to be one of the few in resistance of DHCPv6). This list managed to point me in the right direction to nag them about it. > I ask because there may be other ways to achieve your actual goal, but > without knowing that it's hard to make recommendations. ?The most obvious > answer is accountability, but physical port number may be a better approach > there, depending on how the campus network is run. > > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From mpetach at netflight.com Sun Oct 18 17:42:04 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 18 Oct 2009 15:42:04 -0700 Subject: 2009.10.18 NANOG47 Community Meeting notes Message-ID: <63ac96a50910181542s5647008am4caa83702f93b34b@mail.gmail.com> Here's my notes from tonight's Community Meeting from NANOG47. Short and sweet, for those who couldn't attend in person. :) Matt 2009.10.18 NANOG 47 community meeting notes NOTES: Joe Provo calls the meeting to order at 1740 hours Eastern Time. Welcome to Dearborn, haven't been here since NANOG 13. Hotel is very, very different. Thanks for coming to the community meeting, and caring enough to show up. AGENDA: Steering Committee Report--Joe Provo Program Committee Report--Dave Meyer Mailing List Committee Report--Kris Foster Marketing Working Group Report--Patrick Gilmore Merit Report--Betty Burke This is an election meeting, later on in the session we'll have candidates for SC come up to speak for a few minutes. The mics are live, they want a dialog, not a lecture. Steering committee members have blue badges. Betty Burke Steve Feldman Kris Foster Patrick. W. Gilmore, etc. Highlights since NANOG 46 elusive network experiment policy reached fruition annual Postel scholarship was awarded (could use additional funding to allow it to continue) Operator of Tomorrow partnership Preparation for this meeting Work on future meetings. Austin, San Francisco, Atlanta finalized and published--next three are in the pipeline Elections--why this is so brief! SC candidates will have a few minutes each here during the Elections portion SC and charter ballot voting is open So are PC and MLC nominations. Get your nominations in now, if you know people who can help contribute. nominations at nanog.org program committee--Dave Meyer review process -- 47 talks, 80 submitted. People submit great ideas, but never submit slides or even outline slides. Program committee openings questions for us? If you know people who would be good for the PC, please nominate them; it takes some amount of time committment, but it's an essential part of making the meetings happen. They try to rate the talks based on what is submitted, but at times, the material submitted is very light, and the final slides don't arrive until very late. They had submissions that weren't complete; why not turn them into lightning talks? That's generally what they do with the short/incomplete ones. Louie--of the people who submitted good topics, they might not want to do the work until they know their outline was accepted... They are notified that their talk has been accepted so they can work on it. Ren notes that sometimes they get similar topics, so they might try to get the two sets of people to work together. Todd Underwood, for context, he'll note that it's a standoff--really good presenters playing chicken with the program committee. If the narrative of the story isn't in the slides, nobody who doesn't know you will understand it from just the slides; you'll need to give some idea of the narrative along with the slides. And the archives are hugely important; make sure the presentation tells the story even if you aren't presenting it. Josh, Rodney, Lane, Todd, and others have done a great job over the years supporting the meetings and reading through Joel Jaeggli, outgoing PC member...the people leaving have generally been around for 2 years. They've been around since the new charter was instituited. Procedures within the PC remain adhoc but not arbitrary reliance on precedent willingness on the part of participants to routinely alter the division of labour responsive to SC input, but not beholden to them (within limits) Transparency The minutes are out there, but nobody but Martin Hannigan reads them...and he stands up to say even he doesn't do that anymore. Points of Friction over the past few years. EArlier availability of agenda: means CFP is earlier, ability to respond to industry events is more constrained, etc. programming of joint activities ARIN SC Distributing ownership of repeating program elements and increasing depth of the bench inclusivenes new program elements. Big Wins Lightning Talks more breadth in presentations now Peering track better representation from more people Newcomers (Ren) Program quality MLC members Randy Epstein Steve Feldman -- SC liason Kris Foster -- Chair Sue Joiner -- Merit Appointee Simon Lyall Updates Policies were updated in August to reflect the thread moderation policy http://www.nanog.org/mailinglist/warningpolicy.php If you have questions/issues with it, raise them on nanog-futures mailing list. Very light since last meeting. A few thread moderations, but not many. 10,448 subscribers currently on the list. Volunteers needed Kris Foster and Simon Lyall's terms are ending Possibly a third seat opening up depending on what gets decided later. If you don't subscribe, read, or post, please tell us why! Marketing Working Group Report -- Patrick What is it? Email updates are sent to NANOG-futures Idea is to raise more money to reduce costs. Need a new chair! New ideas for NANOG 47 and onward Party Promotion party on agenda, tickets handed out at registration mentioned by moderator Water Bottles print name on bottles of water, or to-go cups Break slides name on screen during break nanog-marketing at nanog.org Volunteers It's not as bad as it looks Who wants to help make NANOG better? Merit Report Betty Burke Thanks to the hosts, Merit Network and Arbor Networks This is her first time hosting a NANOG! It is a bit of work to make it happen, it's not just a nothing job. A big thanks to those who have hosted in the past--thanks to Lisa from Arbor for helping with the hosting, it's been a challenging and rewarding effort! Contributors and Sponsors...big slide of people helping keep the registration fees for the conference at a reasonable level. Volunteer help and actual dollars were both forthcoming. Thank you! Merit Staff Onsite -- if you see them in the hallways, thank them--they're already busy planning the next NANOG! Merit Leadership Merit Community Memberss (many university members are able to come and see what the NANOG activity is about since it's back in Michigan now) Attendee List -- online and sortable now! Attendance Stats -- Online good for trending data, SC and PC look at them for planning out venues. Needed for contract negotiations well ahead of time. Meeting Survey -- Online essential that people do fill these out--it really helps shape what direction future meetings will take. Financial -- Year End Highlights. NANOG 46, PHilly Revenues 289k expenses 278k salaries: 119k NANOG 46 balance, $10,869.30 FY 2009 year end audit NANOG44 and NANOG45 difference of $3,512 due to unpaid registrations NANOG46: $10,869.30 Total: $47,853.84 Steve Feldman asks what Merit will do with the $47k? It is carried forward as a basis for future contracts that get written for venues. Todd asks what the total account balance is, if this is fiscal year balance. Joel Jaeggli asks how many contracts they carry? There are 3 in now, and 2 more on the way. So they're about 5x over-leveraged on the account; it's not enough to cover even one contract, really. Future Meetings: NANOG48 Feb 21-24 Austin TX, Foundry and GigaNews NANOG49 June 13-16 San Francisco Netflix NANOG50 Oct 3-6 Atlanta TelX (with ARIN) NANOG51 Feb 2011 Terremark, possibly Miami NANOG52 June 2011 need a host NANOG53 October 2011 Possibly Comcast, possibly philly again? Lowes in Philly? Educause will be there too, so may be more challenging to get a contract. Election process--Betty Burke During the revolution of a few years ago, it was recognized that this needed to move into more of a partnership relationship; and it's been mostly a success, though there's a few challenges that came up. The charter is what guides the actions of all the committees and merit on our behalf. Think about the ballot changes during the elections. >From the charter: 6.4 elections Delections will occur annually, at the last NANOG meeting in a given calendar year. Elections will be held via electronic voting on the NANOG web site during that NANOG meeting, with voting to occur over a period of no less than 48 hours....etc. The website shows all the dates agreed to back in May; it's run by the SC chair and by Merit, with input solicited from many, many people within the community; it really is a partnership on behalf of the entire community. Per the charter, the registration team puts the logic into the sytem to determine who is eligible to vote in each election. The data is gathered electronically, and then Merit announces the results at the end of NANOG. But with the joint meeting, how do we know when NANOG actually ends this time around? So, we'll stay open on the voting until Weds AM until 9am this time around, with election results announced shortly thereafter. There is a transfer of knowledge that happens with the current SC team meeting the incoming SC team; a new chair for the SC is appointed, and the new program committee is organized, including a new PC chair. Merit helps facilitate and run the elections, but it's all controlled by the charter. Steve is up next. 2009-1: concurrent membership on mailing list and program committees. Summary: removes restrictions preventing membership in both committees simultaneously. 2009-2: change name and duties of mailing list committee Summary: changes the name of "Mailing List Commitee" to the "Communications Committee" and expands the scope to cover other forms of electronic communication 2009-3: clarification of Nomination Procedure Summary: allows any member of the NANOG committee to nominate candidates for the steering committee. So, go out and vote!! SC candidate Statements from those who are present. Steve Feldman, CBS Interactive He's done work on amendment shepherding, he wants to make sure that the SC stays true to the spirit of NANOG, he wants transparency, and he wants to build a stable business model to help keep the meetings affordable for people. Henry Kilmer Dorian Kim Sylvie LaPierre Michael Lucking, Telx He's been involved for years; they've hosted one NANOG already in New York, they'll be hosting another one in Atlanta, and he'd like to get more involved in the community. Christopher Quesada, S&D He's hosted a NANOG in Seattle, NANOG34; also many evening get-togethers; they continue to host and sponsor those, to bring the community together, to help foster the community. He'd like to help make NANOGs easier for people to attend, by looking at some form of annual sponsorship, so a company with multiple employees could pre-pay for the whole year for employees, rather than individual payments. Tom Vest Duane Wessels, Domain Name System Operations Analysis and Research Center He's not a network operator per se, he first came to talk about data analysis, and now he's doing even more of that on the DNS side. Lixia Zhang, UCLA So, go out and vote now! And survey survey survey!! Betty wanted to also recognize that Susan R. Harris is here at the meeting; she's been working on NANOG meetings for many, many years while she was at Merit; make sure you stop by and say hi! If you have questions, come to the mic, and ask! Busses will be out in front starting at 1845 leaving every 10 minutes--so come join us at the social! Meeting wraps up at 1638 hours Pacific time. From gem at rellim.com Sun Oct 18 18:07:27 2009 From: gem at rellim.com (Gary E. Miller) Date: Sun, 18 Oct 2009 16:07:27 -0700 (PDT) Subject: OT: Any PALM e-mail administrators In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Keith! On Sun, 18 Oct 2009, Keith Medcalf wrote: > I have tried contacting PALM through their listed contact phone > numbers and by email to their postmaster, all to no avail. Contact me off list. I have been working this problem for over a month and have some contact info. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFK25+xBmnRqz71OvMRAuyxAKDQ6bKTNL82vgLGwHt2/lsgMCEcAQCg3fhB n2IDndq+ek32I+dyFUISjJc= =sDjJ -----END PGP SIGNATURE----- From cra at WPI.EDU Sun Oct 18 18:15:12 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 18 Oct 2009 19:15:12 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <006c01ca5018$9bbd1da0$d33758e0$@com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> <37998969-1C18-47FB-81F2-D3CA11501F2E@nosignal.org> <7434E004-E1E1-4FD7-A9A4-2E2C6140F3F4@delong.com> <4ADB3812.6050805@kl.net> <006c01ca5018$9bbd1da0$d33758e0$@com> Message-ID: <20091018231512.GB16845@angus.ind.WPI.EDU> On Sun, Oct 18, 2009 at 01:29:54PM -0400, TJ wrote: > You say hacks, others see it as relatively-speaking simple additions of more > functionality. > You can define any options you want for DHCPv6, write a draft and get > community support. > I don't see how that ("continuously evolving DHCPv6 hacks") is any better > than what is happening with RAs? The difference is that I don't have to wait for my switch/router vendor to implement RA extensions, I can just implement it myself in an open source DHCPv6 server. Software that is embedded in hardware is very hard to get changed. From mohacsi at niif.hu Mon Oct 19 02:52:51 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 19 Oct 2009 09:52:51 +0200 (CEST) Subject: IPv6 Deployment for the LAN In-Reply-To: <20091018185247.50967833@opy.nosense.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <20091018185247.50967833@opy.nosense.org> Message-ID: On Sun, 18 Oct 2009, Mark Smith wrote: > On Sun, 18 Oct 2009 09:03:12 +0100 > Andy Davidson wrote: > >> >> On 18 Oct 2009, at 01:55, Ray Soucy wrote: >>> The only solution that lets us expand our roll out IPv6 to the edge >>> without major changes to the production IPv4 network seems to point >>> to making use of DHCPv6, so the effort has been focused there. >> [...] >>> Needless to say, the thought of being able to enable IPv6 on a per- >>> host basis is met with far less resistance than opening up the >>> floodgates and letting SLAAC take control. >> >> Hi, Roy -- >> >> Good summary, thanks for the write-up. >> >> I reluctantly just use SLAAC on our own office LANs because, we're >> still quite a small and nimble team, therefore we can secure our >> network against our SLAAC security concerns by locking down access to >> the network. I realise this isn't going to work for everyone, as it >> doesn't fit well for the security needs of your much larger campus >> network. It also doesn't work for some of our customers who have DHCP >> in their toolbox for provision certain hosting environments. >> >> DHCPv6 today lacks default-router option support, so you are left with >> some pretty awful choices if you don't want to use the router >> solicitation/advertisement, err, 'features' in SLAAC : >> > > I'm curious what the issue is with not having a default-router option > in DHCPv6? There is a draft: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00 Implementation is not there yet.... > > If it's because somebody could start up a rogue router and announce > RAs, I think a rogue DHCPv6 server is (or will be) just as much a > threat, if not more of one - I think it's more likely server OSes will > include DHCPv6 servers than RA "servers". Identified problems and hopefully published RFCs soon about the problem and possible fixes: http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-rogue-ra/ http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ra-guard/ Best Regards, Janos Mohacsi From invite+2wgak2ma at facebookmail.com Mon Oct 19 07:10:26 2009 From: invite+2wgak2ma at facebookmail.com (Gustavo Santos) Date: Mon, 19 Oct 2009 05:10:26 -0700 Subject: =?UTF-8?Q?Quero_que_voc=C3=AA_entre_no_Facebook?= Message-ID: <01d45f7ee5aba49dd368f9e97451ba2e@localhost.localdomain> Ol? nanog at merit.edu, Criei um perfil no Facebook com minhas fotos, v?deos e eventos e quero adicionar-lhe aos amigos para que voc? possa ver meu perfil. Primeiro, voc? precisa cadastrar-se no Facebook! Uma vez cadastrado, voc? tamb?m poder? criar o seu pr?prio perfil. Obrigada, Gustavo Para se cadastrar no Facebook, clique no link abaixo: http://www.facebook.com/p.php?i=634104286&k=43A4YZUSST6AY1B1SC3T2USVV3FG5TX&r Already have an account? Add this email address to your account http://www.facebook.com/n/?merge_accounts.php&i=634104286&k=43A4YZUSST6AY1B1SC3T2USVV3FG5TX.nanog at merit.edu foi convidado a participar do Facebook por Gustavo Santos. Caso n?o queira receber este tipo de e-mail do Facebook no futuro, clique no link a seguir para cancelar o recebimento. http://www.facebook.com/o.php?k=21df21&u=1662602138&mid=1465460G63194b9aG0G8 Os escrit?rios do Facebook est?o localizados na 1601 S. California Ave., Palo Alto, CA 94304. From trejrco at gmail.com Mon Oct 19 07:19:57 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Mon, 19 Oct 2009 12:19:57 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910181438y2481652cr2264809861940e13@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com><42D04CD7-6313-4A9A-A675-ABF48DB8CC62@cs.columbia.edu><7a6830090910181438y2481652cr2264809861940e13@mail.gmail.com> Message-ID: <579739791-1255954795-cardhu_decombobulator_blackberry.rim.net-2017047010-@bda575.bisx.prod.on.blackberry> IPv6 is an opportunity/excuse to make networks make sense - think about what you really want your architecture to be, plan it and start migrating to that. IF that means adding something to v6, great - do it, solve problems. I am not saying "the way we do it know" is always just a bad excuse, but when it is _just_ that maybe the situation needs another look :) ... (Specifically - on an enterprise side - Align "life cycle refresh" and IPv6 deployment; once the "IPv4 only things" are identified they will simply not be migrated to new dual-stack segments ... Easy!) (Oh - As for SLAAC, you can just do the default gateway part and still use DHCPv6 for the rest ... I have yet to see implementations that ignore A=0, and have never tried of using ~/80s to force non-autoconf.(My gut says the odds of hosts mis-handling a /80 are far greater than ignoring A=0 :) )) In the end - I agree that SLAAC and DHCPv6 both fulfill valid roles ... /TJ ... Not (just) an idealist :) Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Ray Soucy Date: Sun, 18 Oct 2009 17:38:26 To: Steven Bellovin Cc: Subject: Re: IPv6 Deployment for the LAN Thanks for the response, if only to force me put my thoughts down into words. On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin wrote: > ... > > My question is this: what are your goals? ?What are you trying to achieve? > ?Force all authorized machines to register? ?If so, why? ?We'll leave out > for now whether or not there's even much point to that. ?My university -- > and I'm just a user of campus computing facilities; I don't run them -- has > concluded that there's no particular benefit to requiring registration or > permission; it's one more server complex to run, one more database to > maintain, and one more thing to break, and the benefits don't seem to be > worth the cost. ?And given that we've had incidents of IP and MAC address > spoofing, where it took the switch logs to figure out what was going on, I'm > very far from convinced that registration is of any benefit anyway. ?In > other words -- yes, I agree with the campus policy -- but that's not the > question I'm asking. Not my place to implement policy; I'm not a lawyer. We already have monitoring in place for accountability that maps each address used on a network (regardless of IP or IPv6) to a device and interface for incident response. The greater concern is that SLAAC makes IPv6 available to hosts that may not be prepared for it. If administrators are asked if they would like IPv6 enabled, having been explained the implications of such if SLAAC is used for configuration, the majority of the time they come back and say "thanks, but no thanks." In this situation, SLAAC is holding back deployment of IPv6. I suspect other have seen this as well. Part of the problem here is that IPv6 isn't new; it's old. Implementations have been in place for years on certain systems without proper testing as they have gone largely unused. We've seen cases where older versions of Linux can be crashed by enabling SLAAC on a network being one example. By using DHCPv6 we gain some advantages: We can automatically update DNS for hosts so that IPv4 records and IPv6 records match; We have the ability to roll out DHCPv6 on a per-host basis without causing problems on the production IP network; and we can roll it in to our existing [home grown] tools for network management in a way that is easy for users of the system to understand (keep in mind, we provide tools to delegate network control to hundreds of sub-administrators throughout the State). The original question here wasn't SLAAC vs. DHCPv6. I think many network operators here who are tasked with managing anything of scale will agree that SLAAC doesn't quite cut it and is often a step backwards. The overhead of implementing and administering such a system at this scale generally wins out over not doing so. The question I was mainly concerned with was if anyone has encountered issues with the use of an 80-bit prefix to prevent SLAAC from being active. While the prefix advertisement does have the autonomous flag which can be set to false, the underlying problem of IPv6 implementations not being consistent across hosts operating systems yet doesn't change. I'm not convinced that there aren't implementations out there that will enable SLAAC regardless of what the prefix flag is set to, so using a prefix other than a 64 provides an easy way to [attempt to] avoid this, all the while allowing for us to eventually migrate to a 64-bit prefix when host support improves. Another concern is that we certainly don't want to use SLAAC for servers, and I'm hesitant to promote the use of manual IP configuration as it can quickly become a nightmare if you need to move networks (admittedly there should be less need for network moves, but all the same). DHCP has long solved many of these issues in the IP world, and it is perfectly reasonable, and desirable, to apply them to IPv6 though the use of DHCPv6. Perhaps in the future, as we see less legacy hosts online we'll be in a position to make use of both SLAAC and DHCPv6 for host configuration, but in all honesty, once DHCPv6 is in place, why would you want to use SLAAC? My other question was DHCPv6 support from Apple (who seems to be one of the few in resistance of DHCPv6). This list managed to point me in the right direction to nag them about it. > I ask because there may be other ways to achieve your actual goal, but > without knowing that it's hard to make recommendations. ?The most obvious > answer is accountability, but physical port number may be a better approach > there, depending on how the campus network is run. > > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From jmaimon at ttec.com Mon Oct 19 08:39:40 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 19 Oct 2009 09:39:40 -0400 Subject: Trouble with the rtsp vlc feed? Message-ID: <4ADC6C1C.8080909@ttec.com> Anyone else having trouble with that? From will at harg.net Mon Oct 19 08:57:04 2009 From: will at harg.net (Will Hargrave) Date: Mon, 19 Oct 2009 14:57:04 +0100 Subject: Trouble with the rtsp vlc feed? In-Reply-To: <4ADC6C1C.8080909@ttec.com> References: <4ADC6C1C.8080909@ttec.com> Message-ID: <4ADC7030.2080403@harg.net> Joe Maimon wrote: > Anyone else having trouble with that? Not had any luck on either the unicast or multicast RTSP feeds. Flash works fine, though. From ron at spawar.navy.mil Mon Oct 19 09:04:02 2009 From: ron at spawar.navy.mil (Ron Broersma) Date: Mon, 19 Oct 2009 07:04:02 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910181438y2481652cr2264809861940e13@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <42D04CD7-6313-4A9A-A675-ABF48DB8CC62@cs.columbia.edu> <7a6830090910181438y2481652cr2264809861940e13@mail.gmail.com> Message-ID: On Oct 18, 2009, at 2:38 PM, Ray Soucy wrote: > On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin > wrote: > >> My question is this: what are your goals? What are you trying to >> achieve? > As I read this whole thread, I had similar questions coming to mind. > The greater concern is that SLAAC makes IPv6 available to hosts that > may not be prepared for it. If administrators are asked if they would > like IPv6 enabled, having been explained the implications of such if > SLAAC is used for configuration, the majority of the time they come > back and say "thanks, but no thanks." In this situation, SLAAC is > holding back deployment of IPv6. I suspect other have seen this as > well. I do not understand the big concern here, but that is probably because my own perspective and approach is somewhat different than yours. In my humble opinion, those of us that are network operators need to provide robust IPv6 connectivity and services to our customers today, and customers with IPv6-enabled devices should automatically have IPv6 connectivity (i.e. automatically get an address and default route) with minimal hassle and configuration effort on their side. If they decide they don't want IPv6, it is up to them to disable it, because they are the exception, not the rule. Besides, systems administrators are probably the wrong ones to ask, because they will most often opt for "don't change anything that might break something or make me do more work". I just don't see how SLAAC is holding back deployment. In my experience, SLAAC is your friend, given that DHCPv6 is not yet available for most of the client world (i.e. Windows XP, Mac OSX). I've seen only one case out of thousands of customers where enabling IPv6 on the client broke access to a single remote web site, but that was because of a flaw in the DNS implementation for that remote site. Wait, there was one other case where the problem turned out to be a bad NIC. I think you are overly concerned about breaking someone by enabling SLAAC on all your nets. Rather, focus on making sure that you have robust IPv6 connectivity and infrastructure and peering/ transit. If you do find situations where something breaks, then put your energies into resolving those situations, which benefits the whole community. Our philosophy has been "aggressive IPv6-enablement is the right thing to do, and don't be afraid to break some glass". > Part of the problem here is that IPv6 isn't new; it's old. > Implementations have been in place for years on certain systems > without proper testing as they have gone largely unused. We've seen > cases where older versions of Linux can be crashed by enabling SLAAC > on a network being one example. Those cases are increasingly rare, and can be fixed. Don't let such concerns stop you from IPv6-enabling your nets. As a network operator, you are doing the right thing by enabling IPv6 on all your nets, and it is not your fault if sys admins aren't keeping their systems patched. > By using DHCPv6 we gain some advantages: We can automatically update > DNS for hosts so that IPv4 records and IPv6 records match; We have the > ability to roll out DHCPv6 on a per-host basis without causing > problems on the production IP network; and we can roll it in to our > existing [home grown] tools for network management in a way that is > easy for users of the system to understand (keep in mind, we provide > tools to delegate network control to hundreds of sub-administrators > throughout the State). When I started rolling out IPv6 to my nets many years ago, I was of the same mindset. I wanted the same mechanisms for managing addresses and DNS as I had in place for IPv4, and do dynamic DNS updates out of DHCP. But, I quickly changed my approach after seeing the huge lack of client side support for DHCPv6, and serious interoperability issues where it did exist. What we did find is a fairly simple means to use SLAAC and still keep DNS updated automatically for IPv6 addresses by polling the routers and doing the mapping to clone the IPv4 DNS entries for IPv6. That works very well for us. > The original question here wasn't SLAAC vs. DHCPv6. I think many > network operators here who are tasked with managing anything of scale > will agree that SLAAC doesn't quite cut it and is often a step > backwards. The overhead of implementing and administering such a > system at this scale generally wins out over not doing so. > > The question I was mainly concerned with was if anyone has encountered > issues with the use of an 80-bit prefix to prevent SLAAC from being > active. While the prefix advertisement does have the autonomous flag > which can be set to false, the underlying problem of IPv6 > implementations not being consistent across hosts operating systems > yet doesn't change. I'm not convinced that there aren't > implementations out there that will enable SLAAC regardless of what > the prefix flag is set to, so using a prefix other than a 64 provides > an easy way to [attempt to] avoid this, all the while allowing for us > to eventually migrate to a 64-bit prefix when host support improves. I would be more concerned with deviating from the mainstream of /64, and the potential problems you will encounter when doing so, than I would be for the few machines that might break when encountering SLAAC. > Another concern is that we certainly don't want to use SLAAC for > servers, and I'm hesitant to promote the use of manual IP > configuration as it can quickly become a nightmare if you need to move > networks (admittedly there should be less need for network moves, but > all the same). Using SLAAC for servers has not been a problem for us at all. Many server admins also want to use manual IPv6 addressing, and that is perfectly fine with us if that is their choice. I just don't see a problem with this. > DHCP has long solved many of these issues in the IP world, and it is > perfectly reasonable, and desirable, to apply them to IPv6 though the > use of DHCPv6. Perhaps in the future, as we see less legacy hosts > online we'll be in a position to make use of both SLAAC and DHCPv6 for > host configuration, but in all honesty, once DHCPv6 is in place, why > would you want to use SLAAC? Until every network device has a built-in DHCPv6 client, I need SLAAC. Even then, I have a number of special case networks where DHCP is overkill if I have SLAAC available to me. But on the other hand, for some network situations (like if you are using IVI as a transition mechanism for your net) then DHCPv6 is mandatory. So I argue that we need both. > My other question was DHCPv6 support from Apple (who seems to be one > of the few in resistance of DHCPv6). This list managed to point me in > the right direction to nag them about it. I agree that this is a huge shortcoming on the part of Apple. Everyone needs to file appropriate bug reports with Apple and complain about lack of DHCPv6 support. Good luck on your IPv6 deployment efforts. Regards, --Ron From jnegro at billtrust.com Mon Oct 19 09:32:47 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Mon, 19 Oct 2009 10:32:47 -0400 Subject: Advice about Qwest, Cogent, and Equinix facilities Message-ID: <3C5B084431653D4A9C469A22AFCDB5B903E9B7CE@LOGAN.billtrust.local> My company is planning on implementing a new strategy for our web application deployment. My goal is to choose a datacenter/collocation provider who has facilities in the NY and Chicago regions, so that I can have a Primary and DR site connect by at least a 100M line. So far I have identified Qwest, Cogent and Equinix as possible providers. As I have only dealt with Equinix in the past, I would welcome any advice or experiences other nanog members may have with regards to these providers, as well as any suggestions about other providers that may fit the bill. Thank you in advance for your input. Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jnegro at billtrust.com From leland at taranta.discpro.org Mon Oct 19 10:07:20 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Mon, 19 Oct 2009 17:07:20 +0200 Subject: Cisco VSS-1440 migration query Message-ID: <1255964840.6372.19.camel@leland-gandi> Hi All, Trying to find an answer to a single technical point concerning a migration of a fleet of Catalyst 6500's to VSS-1440. I've had a scan through the documentation on CCO (whitepapers, config guides, migration guides, etc.) but cannot find anything dealing with this one specific point. Background: Assume that on both stand-alone chassis, you have a specific vlan interface with L3 configuration, such as: switch1: vlan 10 name testing ! interface vlan10 ip address 10.100.100.1 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! switch2: vlan 10 name testing ! interface vlan10 ip address 10.100.100.2 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! Once switch 1 is converted to VSS mode and is brought up as ACTIVE/MASTER, it will keep it's layer3 configuration on the VLAN interface. The question is what happens to the L3 configuration on switch2 when it comes up in STANDBY/SLAVE? I can foresee one of two possibilities, but not sure which to expect before trying to do this in a live enviroment: either: 1. switch2 will boot up straight into NSF/SSO, inheriting its [new L3] configuration from the active master, overwriting the pre-VSS L3 configuration. (would be preferable). or 2. switch2 will boot up and enter RPR mode with incompatible configuration for the interface, forcing me to have to manually remove the L3 configuration from the interface before I can proceed with the migration. (not really ideal with hundreds of vlans on these things...) Any idea which one of these would be the case ? (the glbp will be retained, as it will be running between two VSS pairs with 10G trunks between them). Thanks in advance Leland From sergevautour at yahoo.ca Mon Oct 19 10:39:40 2009 From: sergevautour at yahoo.ca (Serge Vautour) Date: Mon, 19 Oct 2009 08:39:40 -0700 (PDT) Subject: Maximum devices in OSPF area 0 Message-ID: <101360.13674.qm@web53608.mail.re2.yahoo.com> Hello, We are looking to deploy a greenfield MPLS network with OSPF as the IGP. I'm told OSPF areas don't play well with OSPF TED. For this reason, we are looking at?using only area 0.?Only Loopback interfaces and p-p core?ethernet links will be in?OSPF.?What are the maximum number of Routers & Links that folks would be comfortable with putting in 1 area??If folks are already using this type of approach, could you share your current numbers? Thanks, Serge __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com From ras at e-gerbil.net Mon Oct 19 10:46:26 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 19 Oct 2009 10:46:26 -0500 Subject: Maximum devices in OSPF area 0 In-Reply-To: <101360.13674.qm@web53608.mail.re2.yahoo.com> References: <101360.13674.qm@web53608.mail.re2.yahoo.com> Message-ID: <20091019154626.GF51443@gerbil.cluepon.net> On Mon, Oct 19, 2009 at 08:39:40AM -0700, Serge Vautour wrote: > Hello, > > We are looking to deploy a greenfield MPLS network with OSPF as the > IGP. I'm told OSPF areas don't play well with OSPF TED. For this > reason, we are looking at?using only area 0.?Only Loopback interfaces > and p-p core?ethernet links will be in?OSPF.?What are the maximum > number of Routers & Links that folks would be comfortable with putting > in 1 area??If folks are already using this type of approach, could you > share your current numbers? If you aren't abusing your IGP with hundreds of thousands of routes, or running some massive network with thousands of nodes on the edge, there is no reason you can't (and shouldn't) run with a single area. IMHO areas should be the anti-default, "if you has to ask, the answer is no". The scenarios you see with lots of areas in books and labs are for educational and testing purposes, not for sensible network design. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sfouant at gmail.com Mon Oct 19 10:46:44 2009 From: sfouant at gmail.com (Stefan Fouant) Date: Mon, 19 Oct 2009 11:46:44 -0400 Subject: Maximum devices in OSPF area 0 In-Reply-To: <101360.13674.qm@web53608.mail.re2.yahoo.com> References: <101360.13674.qm@web53608.mail.re2.yahoo.com> Message-ID: <2bbf8c3f0910190846i2f3b3009w2f2d88c9d4260bf0@mail.gmail.com> On Mon, Oct 19, 2009 at 11:39 AM, Serge Vautour wrote: > Hello, > > We are looking to deploy a greenfield MPLS network with OSPF as the IGP. > I'm told OSPF areas don't play well with OSPF TED. Yep, OSPF-TE uses Type 10 LSAs, which only has an area flooding scope. > For this reason, we are looking at using only area 0. Only Loopback > interfaces and p-p core ethernet links will be in OSPF. What are the maximum > number of Routers & Links that folks would be comfortable with putting in 1 > area? If folks are already using this type of approach, could you share your > current numbers? > I've seen single areas with as many as ~600 routers and as many as 6-7k LSAs in the LSDB that functioned without any problems. -- Stefan Fouant From morrowc.lists at gmail.com Mon Oct 19 10:52:15 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 19 Oct 2009 11:52:15 -0400 Subject: Maximum devices in OSPF area 0 In-Reply-To: <101360.13674.qm@web53608.mail.re2.yahoo.com> References: <101360.13674.qm@web53608.mail.re2.yahoo.com> Message-ID: <75cb24520910190852j79f87836ya18b84854096440f@mail.gmail.com> On Mon, Oct 19, 2009 at 11:39 AM, Serge Vautour wrote: > Hello, > > We are looking to deploy a greenfield MPLS network with OSPF as the IGP. I'm told > OSPF areas don't play well with OSPF TED. For this reason, we are looking at?using you said .. greenfield.. why use OSPF? > only area 0.?Only Loopback interfaces and p-p core?ethernet links will be > in?OSPF.?What are the maximum number of Routers & Links that folks would be > comfortable with putting in 1 area??If folks are already using this type of approach, > could you share your current numbers? > > Thanks, > Serge > > > ? ? ?__________________________________________________________________ > Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com > > From rps at maine.edu Mon Oct 19 11:15:10 2009 From: rps at maine.edu (Ray Soucy) Date: Mon, 19 Oct 2009 12:15:10 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <42D04CD7-6313-4A9A-A675-ABF48DB8CC62@cs.columbia.edu> <7a6830090910181438y2481652cr2264809861940e13@mail.gmail.com> Message-ID: <7a6830090910190915m7df530aeh273cc50a8ec19ce0@mail.gmail.com> It wasn't my intention to turn this into a debate of SLAAC vs DHCPv6 but that seems to be what it has become... I agree, SLAAC is the easy way out. I once drank the Kool-Aid and was a "SLAACer" as well. My attitude is that if there is a problem with DHCPv6 support let's fix it, not abandon it. Ultimately, DHCPv6 has a valid role to fill, and creating elaborate systems to monitor IPv6 traffic and populate DNS, or adding extensions to RA to provide DNS server configuration in an effort to turn SLAAC into a DHCPv6 replacement is a little ridiculous. If DHCPv6 worked properly on every system are you trying to argue that you wouldn't want to make use of it over SLAAC for large environments? Or are you just basing your argument on the fact that vendors are lagging behind on support for DHCPv6. Rather than rolling out IPv6 at all costs and making sacrifices to do so, we should be actively involved in engaging vendors and developers to fix their systems so that we don't have to make these compromises. We still have time, and as a group we have the ability to ignite such change. SLAAC does have a place byond residential networks, and perhaps in the future we'll be at a point where we can run SLAAC and DHCPv6 side by side to provide support for legacy systems, but at this point I think that giving up on DHCPv6 in favor of SLAAC is the wrong path to take. On Mon, Oct 19, 2009 at 10:04 AM, Ron Broersma wrote: > > On Oct 18, 2009, at 2:38 PM, Ray Soucy wrote: > > On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin > wrote: > > My question is this: what are your goals? ?What are you trying to achieve? > > As I read this whole thread,?I?had?similar?questions?coming?to?mind. > > The greater concern is that SLAAC makes IPv6 available to hosts that > may not be prepared for it. ?If administrators are asked if they would > like IPv6 enabled, having been explained the implications of such if > SLAAC is used for configuration, the majority of the time they come > back and say "thanks, but no thanks." ?In this situation, SLAAC is > holding back deployment of IPv6. ?I suspect other have seen this as > well. > > I do not understand the big concern here, but that is probably because my > own perspective and approach is > somewhat?different?than?yours.??In?my?humble?opinion,?those?of?us?that?are?network?operators?need?to?provide?robust?IPv6?connectivity?and?services?to?our?customers?today,?and?customers?with?IPv6-enabled?devices?should?automatically?have?IPv6?connectivity?(i.e.?automatically?get?an?address?and?default?route)?with?minimal?hassle?and?configuration?effort?on?their?side. > ?If they decide they don't want IPv6, it is up to them to disable it, > because they are the exception, not the rule. ?Besides, systems > administrators are probably the wrong ones to ask, because they will most > often opt for "don't change anything that might break something or make me > do more work". > I just don't see how SLAAC is holding back deployment. ?In my experience, > SLAAC is your friend, given that DHCPv6 is not yet available for most of the > client world (i.e. Windows XP, Mac OSX). ?I've seen only one case out of > thousands of customers where enabling IPv6 on the client broke access to a > single remote web site, but that was because of a flaw in the DNS > implementation for that remote site. ?Wait, there was one other case where > the problem turned out to be a bad NIC. ?I think you are overly concerned > about breaking someone by enabling SLAAC on all your nets. ?Rather, focus on > making sure that you have robust IPv6 connectivity and infrastructure and > peering/transit. ?If you do find situations where something breaks, then put > your energies into resolving those situations, which benefits the whole > community. ?Our philosophy has been "aggressive IPv6-enablement is the right > thing to do, and don't be afraid to break some glass". > > Part of the problem here is that IPv6 isn't new; it's old. > Implementations have been in place for years on certain systems > without proper testing as they have gone largely unused. ?We've seen > cases where older versions of Linux can be crashed by enabling SLAAC > on a network being one example. > > Those cases are increasingly rare, and > can?be?fixed.??Don't?let?such?concerns?stop?you?from?IPv6-enabling?your?nets.??As?a?network?operator,?you?are?doing?the?right?thing?by?enabling?IPv6?on?all?your?nets,?and?it?is?not?your?fault?if?sys?admins?aren't?keeping?their?systems?patched. > > By using DHCPv6 we gain some advantages: We can automatically update > DNS for hosts so that IPv4 records and IPv6 records match; We have the > ability to roll out DHCPv6 on a per-host basis without causing > problems on the production IP network; and we can roll it in to our > existing [home grown] tools for network management in a way that is > easy for users of the system to understand (keep in mind, we provide > tools to delegate network control to hundreds of sub-administrators > throughout the State). > > When I started rolling out IPv6 to my nets many years ago, I was of the same > mindset. ?I wanted the same mechanisms for managing addresses and DNS as I > had in place for IPv4, and do dynamic DNS updates out of DHCP. ?But, I > quickly changed my approach after seeing the huge lack of client side > support for DHCPv6, and serious interoperability issues where it did exist. > ?What we did find is a fairly simple means to use SLAAC and still keep DNS > updated automatically for IPv6 addresses by polling the routers and doing > the mapping to clone the IPv4 DNS entries for IPv6. ?That works very well > for us. > > The original question here wasn't SLAAC vs. DHCPv6. ?I think many > network operators here who are tasked with managing anything of scale > will agree that SLAAC doesn't quite cut it and is often a step > backwards. ?The overhead of implementing and administering such a > system at this scale generally wins out over not doing so. > > The question I was mainly concerned with was if anyone has encountered > issues with the use of an 80-bit prefix to prevent SLAAC from being > active. ?While the prefix advertisement does have the autonomous flag > which can be set to false, the underlying problem of IPv6 > implementations not being consistent across hosts operating systems > yet doesn't change. ?I'm not convinced that there aren't > implementations out there that will enable SLAAC regardless of what > the prefix flag is set to, so using a prefix other than a 64 provides > an easy way to [attempt to] avoid this, all the while allowing for us > to eventually migrate to a 64-bit prefix when host support improves. > > I would be more concerned with deviating from the mainstream of /64, and the > potential problems you will encounter when doing so, than I would be for the > few machines that might break when encountering SLAAC. > > Another concern is that we certainly don't want to use SLAAC for > servers, and I'm hesitant to promote the use of manual IP > configuration as it can quickly become a nightmare if you need to move > networks (admittedly there should be less need for network moves, but > all the same). > > Using SLAAC for servers has not been a problem for us at all. ?Many server > admins also want to use manual IPv6 addressing, and that is perfectly fine > with us if that is their choice. ?I just don't see a problem with this. > > DHCP has long solved many of these issues in the IP world, and it is > perfectly reasonable, and desirable, to apply them to IPv6 though the > use of DHCPv6. ?Perhaps in the future, as we see less legacy hosts > online we'll be in a position to make use of both SLAAC and DHCPv6 for > host configuration, but in all honesty, once DHCPv6 is in place, why > would you want to use SLAAC? > > Until every network device has a built-in DHCPv6 client, I need SLAAC. ?Even > then, I have a number of special case networks where DHCP is overkill if I > have SLAAC available to me. ?But on the other hand, for some network > situations (like if you are using IVI as a transition mechanism for your > net) then DHCPv6 is mandatory. ?So I argue that we need both. > > My other question was DHCPv6 support from Apple (who seems to be one > of the few in resistance of DHCPv6). ?This list managed to point me in > the right direction to nag them about it. > > I agree that this is a huge shortcoming on the part of Apple. ?Everyone > needs to file appropriate bug reports with Apple and complain about lack of > DHCPv6 support. > Good luck on your IPv6 deployment efforts. > Regards, > --Ron > -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From sthaug at nethelp.no Mon Oct 19 11:27:13 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 19 Oct 2009 18:27:13 +0200 (CEST) Subject: Maximum devices in OSPF area 0 In-Reply-To: <75cb24520910190852j79f87836ya18b84854096440f@mail.gmail.com> References: <101360.13674.qm@web53608.mail.re2.yahoo.com> <75cb24520910190852j79f87836ya18b84854096440f@mail.gmail.com> Message-ID: <20091019.182713.74751564.sthaug@nethelp.no> > > We are looking to deploy a greenfield MPLS network with OSPF as the IGP. I'm told > > OSPF areas don't play well with OSPF TED. For this reason, we are looking at?using > > you said .. greenfield.. why use OSPF? I was thinking the same. If you run OSPF and want IPv6 some time in the future you'll need to run OSPFv3 in addition. Much simpler to just run IS-IS from day 1 and be done. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mpetach at netflight.com Mon Oct 19 12:00:15 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 19 Oct 2009 10:00:15 -0700 Subject: Trouble with the rtsp vlc feed? In-Reply-To: <4ADC7030.2080403@harg.net> References: <4ADC6C1C.8080909@ttec.com> <4ADC7030.2080403@harg.net> Message-ID: <63ac96a50910191000t4c698fc5l22f0f44bd2a97d60@mail.gmail.com> On Mon, Oct 19, 2009 at 6:57 AM, Will Hargrave wrote: > Joe Maimon wrote: > > Anyone else having trouble with that? > > Not had any luck on either the unicast or multicast RTSP feeds. Flash works > fine, though. > > > For those who had trouble with the feed, I took some notes this morning from the first half of today's talks. Lunch break now, rest of the talks will be captured in separate mail at the end of the day. Matt 2009.10.19 NANOG notes, Monday Dave Meyer welcomes everyone to NANOG 47 at 0932 hours Eastern time. Everyone please take note of the hosts of NANOG 47, Arbor and Merit--thanks for coming out and supporting it! And next up, Betty Burke with some brief comments. Betty thanks the Merit president for allowing them to host NANOG again--this is the traditional thank you award given to the host. Lisa Quimby from Arbor has done a lot of work putting together the rest of the conference, so a big thank you to them as well! If you'd like to see the home base for Merit to see the datacenter and some facilities, contact Betty, she'll make arrangements, it's about 30 minutes from here. Don Welch from Merit has a few words now to talk about what Merit is. Formed in 1966 by 3 universities in Michigan In 80s and 90s worked with IBM and MCI to run the NSFnet June 3-4, 1994, NANOG 1 was held in Ann Arbor. Non-profit, serve research and education networks; provide a neutral ground for otherwise competitive companies to come together. Provide networking to libraries, universities, and research organizations. Mostly fiber based, provide layer 1, 2, and 3 services. Awaiting AARA grants to build out more services. Also providing additional services up the stack. ATT is providing a 50Mb circuit to Ann Arbor, and there out to the rest of the world via 10G. Farnam Jahanian co-founder of Arbor, welcome to NANOG47, and thanks to the co-hosts. Much of the work behind Arbor came from work and research done under Merit in the early days. Exciting new era of innovation from 1988 to 2009, from communication focusing on voice to a massive explosion of different communication systems and styles. Information technology is integrating more deeply into society, we have new ways to communicate, collaborate, and share information. Networking will continue to be at the center of this societal transformation. Traffic growing rapidly on fixed and mobile networks. IP traffic will double every 2 years through 2011 Video Internet drives much of the growth Google serving more than a billion videos a day now. Security threats clog bandwidth and increase costs Pricing for data is fixed or dropping Yesterday: the era of "look at me" attacks primary motivation of hackers was bragging rights worms and viruses were intended to simply wreak havoc on the infrastructure These were availablity attacks: impacting network access and services, and often, reputations. Today: Botnets, Mobility, Clouds, and Social Media Profit motives and new opportunities malware takes control of targets, enable C&C infrastructure, and enable malware deployment Coordinate attacks Political and Financial gains. Tomorrow: 2009 and beyond Future security challenges will follow internet adoption patterns Profit motives here to stay Politically motivated attacks are 21st century form of street protest. Protecting cloud infrastructure is key to long term adoption. Collaboration is more important than ever NANOG itself is example of collaborative nature of our work Cooperation and information sharing between private and public sector will be critical Cyber will grow to be ever more important to our economic security and prosperity. Craig Labovitz is up next, was one in a long line of program chairs for NANOG ATLAS Internet Observatory, 2009 annual report This was a 2 year effort, Arbor, UMich, and Merit working together. Largest internet monitoring infrastructure in thew orld Global deployment across 110+ ISPs/Content Providers near realtime traffic and routing statistics -- 14Tbps leverages commercial security/traffic engineering infrastructure Participation voluntary and all data sources anonymous ATLAS observatory report Few observations are completely unique/new growth of video, flatter internet, Google, etc. by press, academic papers, analysts, and NANOG may be first to quantitatively measure these trends First global traffic engineering study of Internet evolution There's been other work as well Akamai Bill Norton others Observatory Data Details Within a given ISP, commercial probe infrastructure Monitors Netflow/Jflow/etc and routing across possible hundreds of routers Probes topology aware of ISP, backbone, and customer boundries There's nothing in the files that shows which customer it comes from. No fine-grained data--not the NSA! What it observes Relative inter-domain traffic between ISPs based on small sample of ASNs and weighted towards core roughly matches analyst ISP market data/distribution data representative of global inter-domain traffic focus on "market share" as opposed to absolute data Inter-domain traffic volumes and ratios provide important design/engineering metric negotiation/business strategy Doesn't measure web hits, tweets, transactions, customers, etc. no internal traffic ISP success nor profitability Major Findings Consolidation of Content Contributors content migrated out of enterprise/edge to aggregators consolidation of large Internet properties Now only 150 origin ASNs now contribute 50% of traffic Consolidation of Applications Browser increasingly application front end (eg mail, vid) Applications migrate to HTTP of Flash ports/protocols All other ports/app groups decline (except games and VPN) Evolution of Internet Core and Economic Innovation Majority of traffic direct between consumer and Market shifts focus to higher value services (MSSP, VPN, CDN) Experimentation with paid transit Experimentation with paid content End-to-end internet battle has been fought and lost; even XBox 360 has moved to all port 80. BGP hop count gone from average of 4 to 3.5 to 3, and still down. ISPs moving from transport/transit to higher value services Evolution of the Internet Core 1995 to 2007, picture of the hierarchical network core from the end of the NSFnet era, still taught, was somewhat true into early to mid 2000s. ATLAS 10 in 2007: Level3, GX, ATT, Sprint, NTT, Cogent, Verizon, TeliaSonera, Savvis, AboveNet based on analysis of anonymous ASN origin/transit data. But between 2005 and 2010, the world started to change. collapse of wholesale transit grwoth of advertisement supported content collapse of price of cloud hosting and CDN (panther) Scarcity of datacenter capacity cooling/power/virtualization made old datacenters less useful; bar raised for new facilities. Market Forces in new Internet Price of IP wholesale transit is dropping towards zero Revenue from Internet Advertisement is going up. DrPeering site has these graphs. Key macro level trends shaping how ISPs approach their business. ATLAS 10 today: Level3, GX, Google (5.2%), XXX,XXX, Comcast, rest ommitted. Comcast and Google have joined the top 10, weren't even in top 20 in 2007. These are non-tier 1 companies according to Wikipedia, but Google is one of the fastest growing origin ASNs, and is now #3; and Comcast is climbing as well. Tier1s are still large, and are still somewhat profitable, and are carrying significant volumes of traffic. Consolidation of Content 2007, thousands of ASNs contributed 50% of content in 2009, 150 ASNs contribute 50% of all Internet traffic Approximates a power law distribution. The knee of the curve has changed. This is the most dramatic change that has occurred in the Internet. Hypergiants--big ASNs at far left side. Limelinght Akamai Panther BitGravity Highwinds Top five pure-play CDN origin ASN groups increasingly blurred lines between ISP and CDN significant competition and new entrants Only includes Akamai inter-domain traffic (likely 1/4 or less of all traffic) As category, CDNs represent close to 10% of all Internet traffic What's Happening Commoditization of IP and hosting/CDN drop price of wholesale transit drop price of video/CDN economics and scale drive enterprise to 'cloud' Consolidation Bigger get bigger Google, Yahoo, MSFT acquisitions Success of bundling / Higher Value Services Triple and quad play New economic models Paid content (ESPN 360), paid peering, etc. difficult to quantify due to NDA/commercial privacy Disintermediation direct interconnection of content and consumer driven by both cost and increasingly, performance Direct peering is driving traffic distance closer to zero Google, Akamai, others looking both at cost and performance, as SLA-based metrics start to push content closer to consumer The new Internet is a densely meshed cloud of ISPs, tier1/tier2s, global backbones, and HyperGiants--large content, consumer, and CDN providers. Google's weighted percentage average traffic vs YouTube Over time, Google absorbs YouTube traffic, Google now accounts for 6% of all Internet traffic globally Google one of the fastest growing origin ASNs Comcast In 2007, Comcast looked like a traditional MSO Lacked a nationwide network backbone Focused on residential services depended on upstream transit 2009, Comcast is different Net contributor of internet traffic 6th largest origin/transit group by volume Evidence of new business models triple play transit/wholesale service Traffic ratio shifted from inbound, to outbound; more content then eyeball network Increasingly blurred lines between content and consumer networks. Application consolidation Top ATLAS Global applications 2007-2009 Web, Video, VPN, Email, News, P2P, Games, SSH, DNS, FtP, Other, Unclassificed see the slide for exact numbers. Some like P2P is hard to categorize as it keeps moving, and some like Video don't necessarily catch it all, as much of it moves to Flash video over HTTP. P2P is fastest shrinking; most moving to flash or port 80 now. Global P2P trends Ports 6346, 6882, 6881, 4662 Global media cast P2P as the boogeyman, the driver around network neutrality, etc. back in 2007. By 2009, the great evil boogeyman of the internet is falling, and falling fast; losing market share, and turns out to have been mostly FUD. Asia is slower to decline in P2P than other parts of the world. P2P still has significant volumes slower growth, and some absolute decline why? provider traffic management (rate shaping, port limiting, etc.) improved P2P clients/algorithms (smarter clients localize traffic, etc.) migration to other content sources (peer to peer is a pain; is it shaky camera rip, or true HD movie? Now, direct download, direct CDN, hulu, iPlayer, etc. are taking over) P2P replaced by direct download Carpathia Hosting now represents 0.5% of all internet traffic MegaUpload MegaErotica, etc. Conclusion Internet is at an inflection point Transition from focus on connectivity to content old global internet models are evolving new entrants are reshaping definition/value of connectivity New technologies are reshaping definition of network "web" desktop apps, "cloud", CDN changes mean significant new commercial, security, and engineering challenges this is just the beginning Rate of change is accelerating!! QA. Bill Norton: video is a much larger amount of traffic for a given interaction; lots of MB vs reading an email, twitter, etc. Does that skew the analysis? Anyone carrying video traffic will show up very high on the list; this would discount anyone not carrying video, right? A: Yes, this shows very much that Video has dominated the internet now, even if it's t Q: Akamai asks if measurements do backbone to eyeball edge, external traffic, etc.? A: they try to capture as close to the edge S: Akamai's edge traffic less than 20% now. Q: When you rank networks by traffic, does it ignore the vector of the traffic, and just look at number of bits? A: It was ranking in+out; though in comcast, you see some of the in vs out delta. The tech report has some in vs out breakdown. Q: Are numbers peak, average, 95th? A: Mostly average. Many thanks Intenet Operations and ARIN Policy--is there convergence? Panel Mark Kosters starts off the panel (ARIN CTO) The oncoming runout of v4 addresses is really driving a lot of these discussions. Policy issues that affect you 4 byte ASNs ARIN using 4 byte ASN; scary how many people can't peer with them yet because of that. Whois cleanup old cruft in records; many people don't really know about looming events coming on the horizon; the easy landing period is getting shorter and shorter. ARIN is membership based org, we as members make the policies. Stay for the meeting, or at least join the Tuesday night session! IPv6 Policies Relaxed Transfer Policies etc. Focus on two policies 2 30 minute sessions First session: focus on relaxed transfer policy second, focus on IPv6 policy Tom Daly, Igor Gashinsky, Kevin Epperson, Aaron Hughes, RFC2050 doesn't mention purchasing space NRPM section 8.3 added based on policy proposal 2009.1 8.3 allows the transfer (outside merger or acquisition) of internet number resource registration rights to an operator who can justify it. Slippery slope to a market-based economy for address space? Tom Daly Dynamic Network Services ARIN relaxed transfer policy Removes M&A requirements on address transfers, permits "arbitrary" transfer continues to require justification of need Keeps ARIN as transfer agent Does this create a grey market for address space? "I'll trade your tainted, RBL-ed IPs for some clean ones" Concerns about deaggregation upon exchange --RIB size Does ARIN become a title agency for IP address space? new business opportunity for ARIN Does his create new precedent for policies Igor--Relaxed IP transfer policy is a good thing. allows businesses to continue growing even after v4 run out point. This could be a profit center for some companies Can also help companies who cannot afford to migrate to IPv6 quickly stay functioning. Concerns? Why is the policy written in such a way that it takes legal counsel to really understand what it means! Can we have simple english policy? Who will handle the market? when will it be set up? what's the impact on the routing system? should ARIN care? Do the benefits outweigh the tradeoffs? For us, most definitely! It may make it more expensive, but very possible. Oh. Maximizing slides would be good! Aaron Hughes is up next, 6connect.net transfers are happening, regardless of LIR or RIR support. There are companies which will need IPv4 resources to survive post IANA and RIR run-out Operational impacts with or without policy in place. Closing a sale now involves IPv4 resources Justification process harder on our customers and on staff Neither SBGP nor signing authorities in place There are bad people trying to make money from: resources they are assigned resources they are NOT assigned LIRs are not very good at tracking resource assignments today (LOAs, IRR, whois checks) most of these updates are easy to spoof. We don't check LOAs very carefully when customers show up and ask space to be routed. IRRs mostly are mail-from, so adding new records, or updating them, are far too easy. M&A will be much harder to determine net worth of asset (more work for legal and due diligence) Company officers all over the world now know they need more space (intent to educate about IPv6) fiduciary responsibility to not run out their staff objecting to IPv6 higher potential for fraudulent resource utilization reporting higher potential to waste IPv4 resources now to justify space long before need (NAT flips) Contact information is more likely to be accurate with a system that updates upon transfer. Clean transfers will have higher value than black market transfers Stay inb Force better tools and policy to verify assignment SBGP/SoBGP, Routing table growth will force cleanup of de-aggregated prefixes that do not *need* to be Potentially force conditional route-maps/routing policies to be enforced to reduce announcements except when needed Actions: validate current process prepare for some flavour of signing inform your sales staff and modify process as needed. inform your abuse staff going to get harder to manage spammers If you haven't already, start using IPv6 to reduce the impact of transfers! Dan Alexander, Comcast Cable Transfer policy--enables new entrants to obtain IPv4 space during the transition Primary goal of the transfer policy is NOT to extend or perpetuate the use of IPv4; we're still supposed to be focusing on the migration to IPv6. Transfers likely to be of little use to large ISPs This would at most cover about 6 months coverage at the current global use. Long term, IPv6 is the long term solution IPv4 resources don't scale, given the number of new devices joining the Internet. Kevin Oberman speaking for himself It's already happening; if you have a commodity or anything that has some value, someone will be interested in buying it, legally or otherwise. If the supply is limited, price will rise to the point where someone will sell Prohibition does not work! How badly it works is proportional to the level of demand (not volume) History shows how badly prohibition fails. Choice: black-market: ad-hoc no controls white-market transparent controlled Summary when a /18 stands between you and the continued existence of your business, would you buy an address block on the black market? Q: Heather Schiller, Verizon Business -- black market will exist for 2 reasons; one for shady purposes, and one if they don't have justification requirements. A: No, the idea is to make sure that you don't force a significant portion of the consumer base to create a black market. Q: do you support the current justification levels in the transfer policy? A: Yes, the current justification requirement is reasonable; the current market is small; that's what keeps it workable; if the black market gets larger, the system starts to break down. Q: Martin Hannigan; when you talk about markets, recognize that it happens now; people will do what they can to get around ARIN if they can make some money off this. We need to wake up a bit and realize it's not a tiny market. A: Yes, we need to figure out how the operational people will play in this space; right now, there's some amount of registry involvement; but we need to have some way to validate the authenticity of transfers. Q: Jason Schiller, Verizon; ARIN does *not* make it more difficult to get IP space as we get near depletion; if you want to see rationing, get involved in the conversations; at the moment, the current plan of record is to have same level of justification we've always had. Q: Sandra Murphy, Sparta--how will this affect the RPKICIDR work? This should work within that framework without issue, so long as ARIN is part of process. A: Yes, if ARIN is no longer the transfer agent, it becomes quite a challenge. Q: RPKI system allows an entity to transfer all its resources; but to ensure that the resources can't be pulled back could be a challenge. Q: Manish--this doesn't take into consideration growth in the size of the global routing table. In the past, ARIN has been uninvolved in this; but as time goes on, this will cause the global table to grow. A: Table growth will occur, period; this is about keeping the contact information up to date. And you'll just need to keep growing your router gear to keep up, that's part and parcel of doing business on the internet today. Q: Dave Meyer--second half of panel at 11:30. Second part of policy panel Mark Kosters: IPv6 polices--not a lot of operational experience to back up policy Big discussion on assignment sizes Route Filtering /32s or /48s? Should routing policy affect ARIN assignment/allocation policies? --should route filtering be based around ARIN assignments? vice versa? Are v6 policies hindering v6 rollouts? Igor is up first IPv6 policy If you're an established ISP, getting IPv6 space is really easy can take less than 20 minutes The bad: The "must announce a single aggregate" policy is causing some people to delay deployment Not everyone is willing to put all their eggs in a single /32 announcement hijacking traffic engineering anycast multiple discreet networks what about multiple non-connected datacenters? how about branch offices? There is hope! 2009-5: IPv6 Multiple discrete networks should help somewhat 2009-7: open access to IPv6 removes the "single aggregate requirements" please discuss and vote! these policy changes help shape v6 rollout. Dan Alexander He's not saying IPv6 is easy and doesn't need policy support. ARIN policies and IPv6 mandates Some have suggested ARIN policies should mandate IPv6 deployment upon future requests for iPv4 resources ARIN should strive for consistent RIR policies that facilitate it Frustration...a matter of priorities It does require significant resources to make it happen. timing--v6 deployments increasing even before we hit the run-out point. IPv6 is being deployed. Comcast is connecting to other networks using IPv6 Trials will continue in to 2010 If you're not already working on IPv6, you need to start now; it'll be too late if you wait until we hit the IPv4 runout point. Kevin Oberman: Should ARIN make routing policy? ARIN staff and the AC often say that ARIN does not do routing policy BUT the policy stating that a single /32 announcement is all you shall make, is indeed routing policy. Announcing a single prefix to everyone at every location breaks all current models of traffic engineering. Mainly an issue for those with a geographically large footprint. if all your stuff is in one location, not a problem. But enterprises have similar issues with load balancing; a single address doesn't allow for load balancing easily. ES.net advertises two /17s with specific metrics, with a /16 covering. They move huge single-streams, where latency changes have a massive impact. So, with no way to localize traffic, with no way to balance traffic, with no way send metrics for closest exit, traffic doesn't do the right things; ARIN doesn't know how to run our networks, and shouldn't be telling us how to route things. Tom Daly is up next. IPv6--all eggs in one basket. huge risks hijacking flap dampening Deaggs filtered in some operator networks limit techniques for TE moves, adds, deletes, changes less flexibility in overall routing policy by operators not every network is a subscriber access network. MicroAllocations for critical infrastructure doesn't work for enterprises. NPRM 4.10 Allocations up to /28? That policy will do more to hurt the routing table size than v6 PI space. BCP 16 cannot be satisfied to maximum level; separate LAN segments internally, single external announcement No multiple networks supported. Aaron, last speaker IPv6 policy vs operations same slides as everyone else, so he just talks. ARIN vs NANOG; why do we seem to come from different sides of the issue? Some people want a v6 internet that looks just like the v4 internet, with NAT and RFC1918. Others want the old central backbone back again, going back 20 years ago. If you're not in giving your vote, you're not being heard! You need to vote, and show up! Why is it VERSUS instead of AND? Why do we have two different meetings? The policy breaks multihoming, yes. But people aren't following that. Some providers will take your /48 and will announce it. Others in the room follow the policy, and block the advertisement. We're lying to our registry; there are policies that we've agreed to that we don't follow. There's 2100 prefixes in v6, and half of them are for TE. Why can't we write a document that makes sense, that follows what we'll actually do? Oh. And you have to be a "known ISP" to get v6 space; he had to justify a need for v4 IP space and ASN before he could get v6 space. This will continue to be a headache as we go forward! Five minutes for questions. Cathy Aaronson--ARIN advisory council. They really need everyone to participate. This is a very old policy, from when Kim Hubbard ran ARIN. It doesn't meet our needs, so there's a proposal written by Aaron's wife to change this. They really do need people to stick around and join the ARIN meeting, and help write and pass more reasonable policies! A: Tuesday night there will be a session to read about the new policies. Q: Owen DeLong, HE.net and ARIN advisory council. Having policy at ARIN level reflect routing is a very bad place to do control of routing policy. There's talk of more policy to control route table growth; it would be good for operator community to get more involved in the ARIN process. A: Aaron notes that today we don't have a place to document best network operations practices. There is no document repository for operator policies genereally speaking. Tom notes that he's in a relatively new organization, which doesn't have a strong institutional knowledge background; there's no place to look up to see why /24 was a boundry line, and why /32 and /48 were picked for IPv6, etc. Cathy is back up again. The reason there is routing policy in ARIN, when the policy was writtin, everyone on the AC worked in routing, and was concerned about table bloat. They were trying to bring operator input at the time, because at the time, that seemed to be the right thing to do. Q: Alain, speaking for himself. Allocation policy and routing policy is the same thing. If we have transfers happening, there will be pressure for smaller and smaller blocks to be announced and accepted. It doesn't mean that ARIN has to do the routing, it just means that if ARIN has agreed to allocate the space to you, there's a need for it to be reachable! Lee Howard, ARIN board of trustees, TWTC. Thanks to ARIN for writing a best practices policy document! ARIN will do the words we send them that get discussed by the community; you need to send better words to the community!! Jason Schiller, Verizon; Why do we route /24s across the board? Because we created a swamp by allocating /24s to individual companies. We're about to create the same thing in IPv6 by allowing /48's from PI holders. Soon each v4 ASN announces on average 9 prefixes; if we do similar in v6, we'll see similar breakups in /32s, and then soon in PI /48s doing /52s or /56s. The routing table will definitely get big if we do that. It's not clear when, but at some point in the forseeable future, there will be a significant number of the v4 ASNs also doing v6, and when that happens, you will need to be looking at doing swapouts of your entire network routing infrastructure to handle it. Once we create a swamp, there's no way to drain it, and there won't be a chance to implement a different solution. Igor responds: perhaps the answer to some of that is that the refresh cycle needs to be shrunk down, and the cost of business needs to reflect that. Responding to Igor, he looks at the impact of lost customers if they don't route the space vs if they do make the upgrades. Kevin notes that most of us are business providers; we will make a business decision as to whether or not we can make the decision to route a million prefixes or not. It will not be driven by what ARIN decides, or by what NANOG decides, it'll be driven by Marla Azingera--what we do is what goes; one of our two charters needs to be that one of the organizations writes routing policy. So, do we modify NANOG charter, do we modify ARIN charter to write routing policy, do we create a third entity to do that? Randy has last question? How did we come up with the /19? It used to be /19 for registries, then /20, then /21; it was a bunch of operators and registry people who got together, and came to some level of agreement. And at some point, the limitations of silicon kick in. RAS is up next. Scripting on Routers On-box automation with JunOS Phil Shafer phil at juniper.net Problem statement configuration is increasingly complex network operators have custom design rules no enforcement mechanism cost of failure increasing Off-nework managemnet Database of Record push the config from central system. Goals for Scripting tighter integration promote high-level concepts and views XML API JunoScript XML API NetCONF standard XML to text rendering happens at CLI Commit scripts: automatic part of commit process Op scripts add new commands Event scripts trigger on specific events. Commit scripts Internals in XLST internally, actions are in XML example--you can have constraints that require certain conditions to hold true, like all LDP enabled interfaces must have IGP running on them. apply-macro statement "apply-macro no-ldp" for example can appear anywhere, takes a name as an argument you can also repair/change configs around it. you can fix problems before they occur. transient config config that is published to software components, but not seen by the user "show | display commit-scripts" ex-iso.slax example enforces constraints on ISO and MPLS use the "jcs:emit-change" helper template. can warn you about what it is fixing. it inspects configuration in XML uses XPath expresssions to local interesting nodes call jcs:emit-change pass in required arguments $content $dot There's a 1:1 mapping between config and XML representation. XML config as tree, XPath allows you to find things in the tree. Macro Expansion example Three common threads get better information display to user diagnose issues standard operating procedures codify best practices in a script testing Configuration example may appear in configuration may appear in the script itself dead-peers example op dead-peers shows last dead reason, can try to bring it back up, etc. Remote RPCs network issues are seldom one sided diagnose scripts need access to remote device compare config to ensure both sides are consistent inspect remote state to see where problem lies access to intermediate devices as well "intelligent" traceroute shows information about each hop by RPC'ing to it. Interactive scripts op scripts can ask the user for input var $response = jcs:get-input var $password = jcs:get-secret simple questions, or complex interactions New "wizard" framework Single point of configuration run an op script in one location to deploy a service in multiple locations Event overview up-down syslog events time-based events pic-restart triggered events pic-restart.slax script to restart pic after issue Event script possiblities change config jcs:dampen SNMP generate traps More examples: http://tinyurl.com/ykb9x07 RAS why script on routers? get benefits of automation without blocking people from logging into the router. Anything you can automate makes the network run better and run cheaper. Automated BGP policy generation Automated BGP prefix-limit management Support case data gathering scripts example of building BGP policy generation script builds per-ASN communities/policies for prepend AS-PATH 1x prepend AS-PATH 2x Automated BGP policy generation Also useful for building AS-PATH leak filters define a list of major ASNs you only want to hear "directly" block any route with one of these reserved ASNs in in the AS-PATH if the route didn't come directly from one of those ASNs Useful for preventing leaks and suboptimal routing If I peer directly with 701, I don't ever want to accept their route from someone else. Also useful for building policy frameworks script can scan for the existence of a policy with a standard name for each BGP neighbor script automatically generates and maintains 44 lines of new router configuration for every configured BGP peer Automated BGP prefix-limit management. operators use BGP prefix-limits as policy safety nets if a BGP neighbor sends more prefixes than we believe is normal, drop the BGP session for a certain period of time. Somewhat effective at protecting against leaks But difficult to maintain over time. concept of "normal" is always modifying. prefix limit based on current prefixes sent plus an overhead factor, like (PfxCnt*1.25)+500 Uses a time-weighted average Run the script once a night allow manual runs if needed. Automated support cases opening vendor support cases gather most common log files and support components, and automatically upload them to vendor via FTP How effective is this? router configs are 62% smaller than if the commit scripts aren't used. questions to ras at nlayer.net Q: Aaron Hughes--good talk; would be nice to check peeringDB and set max prefix based on that. While this is nice, companies are afraid to deploy scripts; handing off control to scripts causes a lot of consternation. A: should be possible for script to pull information from an external source like peeringDB, yes. Lorenzo: As far as fear of scripts goes...human make mistakes slowly. Scripts make mistakes...really fast. RAS notes that you shouldn't do your scripting ad-hoc. Do it in the lab, test carefully, and then deploy the script carefully. Jared notes that some vendors don't have commit or rollback in their portfolio. We need to explain to our vendors that they are losing business by not having that support. They push automated config to their startup-config instead. ^_^; It would be nice if the vendor could support some of these scripts, or provide them with the software so they could be used more widely. Chris Morrow--people get most scared of breaking the entire network; it's usually tactical stuff that breaks that way. Well planned, well tested, staged, there's no reason not to do it. Another person states that they've seen ISPs that have "coders" who write horrible code; we have a lack of competent talent backing up our scripts on routers and support scripts. Any coder who writes something has to have a good understanding of the platform they're coding on; the people who have that intersection of skillsets is very, *very* small! More training in coding for routers would be a really good thing. Having a repository that those few, really good people could contribute to would be nice. http://juniper.cluepon.net/ has good repository of scripts Randy Bush--it's not a 'coder', it's a software engineer; it's easier to teach a software engineer about networking than coding. Informal BOFs after lunch! Return to the room by 2:30. From jgiles at e-dialog.com Mon Oct 19 12:06:16 2009 From: jgiles at e-dialog.com (Jason Giles) Date: Mon, 19 Oct 2009 13:06:16 -0400 Subject: Cisco VSS-1440 migration query In-Reply-To: <1255964840.6372.19.camel@leland-gandi> References: <1255964840.6372.19.camel@leland-gandi> Message-ID: >From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands. Switch 1 is intact with the new naming convention as well as SVI's. I cannot comment on glbp as I do not run it. /Jason -----Original Message----- From: Leland Vandervort [mailto:leland at taranta.discpro.org] Sent: Monday, October 19, 2009 11:07 AM To: nanog at nanog.org Subject: Cisco VSS-1440 migration query Hi All, Trying to find an answer to a single technical point concerning a migration of a fleet of Catalyst 6500's to VSS-1440. I've had a scan through the documentation on CCO (whitepapers, config guides, migration guides, etc.) but cannot find anything dealing with this one specific point. Background: Assume that on both stand-alone chassis, you have a specific vlan interface with L3 configuration, such as: switch1: vlan 10 name testing ! interface vlan10 ip address 10.100.100.1 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! switch2: vlan 10 name testing ! interface vlan10 ip address 10.100.100.2 255.255.255.0 glbp 1 ip 10.100.100.254 glbp 1 preempt glbp 1 load-balancing round-robin ! Once switch 1 is converted to VSS mode and is brought up as ACTIVE/MASTER, it will keep it's layer3 configuration on the VLAN interface. The question is what happens to the L3 configuration on switch2 when it comes up in STANDBY/SLAVE? I can foresee one of two possibilities, but not sure which to expect before trying to do this in a live enviroment: either: 1. switch2 will boot up straight into NSF/SSO, inheriting its [new L3] configuration from the active master, overwriting the pre-VSS L3 configuration. (would be preferable). or 2. switch2 will boot up and enter RPR mode with incompatible configuration for the interface, forcing me to have to manually remove the L3 configuration from the interface before I can proceed with the migration. (not really ideal with hundreds of vlans on these things...) Any idea which one of these would be the case ? (the glbp will be retained, as it will be running between two VSS pairs with 10G trunks between them). Thanks in advance Leland From mike at m5computersecurity.com Mon Oct 19 12:43:09 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Mon, 19 Oct 2009 17:43:09 +0000 Subject: NetFlow analyzer software Message-ID: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> All, I am looking for decent netflow analyzer and reporting software with good support for AS data. ManagEngine's product crashes or locks up my browser when I try to list/sort the AS info because it's too large of a list and there is no way to tell it to show just the top x results. Plixer's Scrutenizer, while it seems like it's a pretty decent product, is no longer supporting Linux... We are a Linux shop (servers, desktops, laptops). What else is there that I might want to look at? Thanks! Mike M5Hosting.com Sent from my Verizon Wireless BlackBerry From leland at taranta.discpro.org Mon Oct 19 12:45:40 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Mon, 19 Oct 2009 19:45:40 +0200 Subject: Cisco VSS-1440 migration query In-Reply-To: References: <1255964840.6372.19.camel@leland-gandi> Message-ID: <1255974340.17380.3.camel@leland-gandi> On Mon, 2009-10-19 at 13:06 -0400, Jason Giles wrote: > >From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands. This one is alarming, especially given that there may well be some physical interfaces that are only present/used on one of the two chassis in the group. Would be interesting to see if they are defaulted to factory or not. (I would expect unused ports to be defaulted, but not ones actually configured and actively in use). Don't suppose you're able to test that one? However, this sounds like good news for the VLAN/virtual interfaces though. > > Switch 1 is intact with the new naming convention as well as SVI's. > > I cannot comment on glbp as I do not run it. The glbp isn't really that much of a worry since those are being converted from HSRP anyway so will have to manually do those. > > > > > /Jason > Thanks dude... sounds like it partially answers my question, but raises another ;) L. From chris at uplogon.com Mon Oct 19 12:46:05 2009 From: chris at uplogon.com (Chris Gotstein) Date: Mon, 19 Oct 2009 12:46:05 -0500 Subject: NetFlow analyzer software In-Reply-To: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> References: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> Message-ID: <4ADCA5DD.4000203@uplogon.com> Not sure if this will get you all the info you are looking for, but it's open source and works well for our needs. http://nfsen.sourceforge.net/ ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com Michael J McCafferty wrote: > All, > I am looking for decent netflow analyzer and reporting software with good support for AS data. > ManagEngine's product crashes or locks up my browser when I try to list/sort the AS info because it's too large of a list and there is no way to tell it to show just the top x results. > Plixer's Scrutenizer, while it seems like it's a pretty decent product, is no longer supporting Linux... We are a Linux shop (servers, desktops, laptops). > What else is there that I might want to look at? > > Thanks! > Mike > M5Hosting.com > Sent from my Verizon Wireless BlackBerry > From markcciejackson at gmail.com Mon Oct 19 12:46:52 2009 From: markcciejackson at gmail.com (mark jackson) Date: Mon, 19 Oct 2009 10:46:52 -0700 Subject: NetFlow analyzer software In-Reply-To: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> References: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> Message-ID: <7105816464611609144@unknownmsgid> What's up gold Mrtpg Scrtinizer Nagios Riverbed Cascade Solarwinds Sent from my iPhone Please excuse spelling errors On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" wrote: > All, > I am looking for decent netflow analyzer and reporting software > with good support for AS data. > ManagEngine's product crashes or locks up my browser when I try to > list/sort the AS info because it's too large of a list and there is > no way to tell it to show just the top x results. > Plixer's Scrutenizer, while it seems like it's a pretty decent > product, is no longer supporting Linux... We are a Linux shop > (servers, desktops, laptops). > What else is there that I might want to look at? > > Thanks! > Mike > M5Hosting.com > Sent from my Verizon Wireless BlackBerry > From sjk at sleepycatz.com Mon Oct 19 12:50:09 2009 From: sjk at sleepycatz.com (sjk) Date: Mon, 19 Oct 2009 12:50:09 -0500 Subject: NetFlow analyzer software In-Reply-To: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> References: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> Message-ID: <4ADCA6D1.1060300@sleepycatz.com> We currently use nfsen - http://nfsen.sourceforge.net/ -- It works pretty well, not as fancy as others I've worked with, but provides the basic analytical needs. Michael J McCafferty wrote: > All, > I am looking for decent netflow analyzer and reporting software with good support for AS data. > ManagEngine's product crashes or locks up my browser when I try to list/sort the AS info because it's too large of a list and there is no way to tell it to show just the top x results. > Plixer's Scrutenizer, while it seems like it's a pretty decent product, is no longer supporting Linux... We are a Linux shop (servers, desktops, laptops). > What else is there that I might want to look at? > > Thanks! > Mike > M5Hosting.com > Sent from my Verizon Wireless BlackBerry > From scott at sberkman.net Mon Oct 19 13:12:12 2009 From: scott at sberkman.net (Scott Berkman) Date: Mon, 19 Oct 2009 14:12:12 -0400 Subject: NetFlow analyzer software In-Reply-To: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> References: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> Message-ID: <004e01ca50e7$af0b20d0$0d216270$@net> NetFlow Auditor. The free stuff tends to choke as you add a lot of flow traffic. It's not free, but if you want support this is a great option. http://netflowauditor.com/ -Scott -----Original Message----- From: Michael J McCafferty [mailto:mike at m5computersecurity.com] Sent: Monday, October 19, 2009 1:43 PM To: nanog at nanog.org Subject: NetFlow analyzer software All, I am looking for decent netflow analyzer and reporting software with good support for AS data. ManagEngine's product crashes or locks up my browser when I try to list/sort the AS info because it's too large of a list and there is no way to tell it to show just the top x results. Plixer's Scrutenizer, while it seems like it's a pretty decent product, is no longer supporting Linux... We are a Linux shop (servers, desktops, laptops). What else is there that I might want to look at? Thanks! Mike M5Hosting.com Sent from my Verizon Wireless BlackBerry From brwatters at absfoc.com Mon Oct 19 12:45:58 2009 From: brwatters at absfoc.com (Brian R. Watters) Date: Mon, 19 Oct 2009 10:45:58 -0700 (PDT) Subject: NetFlow analyzer software In-Reply-To: <7105816464611609144@unknownmsgid> References: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> <7105816464611609144@unknownmsgid> Message-ID: <00fd01ca50e8$ae1f44c0$0a5dce40$@com> We have used this product with great success and its reasonable in pricing and well supported. http://www.manageengine.com/products/netflow/index.html BRW -----Original Message----- From: mark jackson [mailto:markcciejackson at gmail.com] Sent: Monday, October 19, 2009 10:47 AM To: mike at m5computersecurity.com Cc: nanog at nanog.org Subject: Re: NetFlow analyzer software What's up gold Mrtpg Scrtinizer Nagios Riverbed Cascade Solarwinds Sent from my iPhone Please excuse spelling errors On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" wrote: > All, > I am looking for decent netflow analyzer and reporting software > with good support for AS data. > ManagEngine's product crashes or locks up my browser when I try to > list/sort the AS info because it's too large of a list and there is > no way to tell it to show just the top x results. > Plixer's Scrutenizer, while it seems like it's a pretty decent > product, is no longer supporting Linux... We are a Linux shop > (servers, desktops, laptops). > What else is there that I might want to look at? > > Thanks! > Mike > M5Hosting.com > Sent from my Verizon Wireless BlackBerry > From mike at m5computersecurity.com Mon Oct 19 13:36:43 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Mon, 19 Oct 2009 18:36:43 +0000 Subject: NetFlow analyzer software Message-ID: <120987315-1255977397-cardhu_decombobulator_blackberry.rim.net-439977971-@bda543.bisx.prod.on.blackberry> ManageEngine's product is the one that kills browsers because you can tell it to list the top X ASNs. ------Original Message------ From: Brian R. Watters To: nanog at nanog.org Cc: nanog at nanog.org ReplyTo: Brian R. Watters Subject: RE: NetFlow analyzer software Sent: Oct 19, 2009 10:45 AM We have used this product with great success and its reasonable in pricing and well supported. http://www.manageengine.com/products/netflow/index.html BRW -----Original Message----- From: mark jackson [mailto:markcciejackson at gmail.com] Sent: Monday, October 19, 2009 10:47 AM To: mike at m5computersecurity.com Cc: nanog at nanog.org Subject: Re: NetFlow analyzer software What's up gold Mrtpg Scrtinizer Nagios Riverbed Cascade Solarwinds Sent from my iPhone Please excuse spelling errors On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" wrote: > All, > I am looking for decent netflow analyzer and reporting software > with good support for AS data. > ManagEngine's product crashes or locks up my browser when I try to > list/sort the AS info because it's too large of a list and there is > no way to tell it to show just the top x results. > Plixer's Scrutenizer, while it seems like it's a pretty decent > product, is no longer supporting Linux... We are a Linux shop > (servers, desktops, laptops). > What else is there that I might want to look at? > > Thanks! > Mike > M5Hosting.com > Sent from my Verizon Wireless BlackBerry > Sent from my Verizon Wireless BlackBerry From jloiacon at csc.com Mon Oct 19 13:42:52 2009 From: jloiacon at csc.com (Joe Loiacono) Date: Mon, 19 Oct 2009 14:42:52 -0400 Subject: NetFlow analyzer software In-Reply-To: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> References: <836360950-1255974183-cardhu_decombobulator_blackberry.rim.net-854955329-@bda543.bisx.prod.on.blackberry> Message-ID: Try opensource flowtools/FlowViewer. All sorts of reports, graphs, and RRDtool-like long-term series graphs, for AS'es. The flowtools capture/analyzer software can handle high volumes of netflow exports from many exporters. http://ensight.eos.nasa.gov/FlowViewer/ Joe "Michael J McCafferty" 10/19/2009 01:43 PM Please respond to mike at m5computersecurity.com To "nanog at nanog.org" cc Subject NetFlow analyzer software All, I am looking for decent netflow analyzer and reporting software with good support for AS data. ManagEngine's product crashes or locks up my browser when I try to list/sort the AS info because it's too large of a list and there is no way to tell it to show just the top x results. Plixer's Scrutenizer, while it seems like it's a pretty decent product, is no longer supporting Linux... We are a Linux shop (servers, desktops, laptops). What else is there that I might want to look at? Thanks! Mike M5Hosting.com Sent from my Verizon Wireless BlackBerry From joelja at bogus.com Mon Oct 19 13:47:13 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 19 Oct 2009 11:47:13 -0700 Subject: UPDATE: NANOG 47 PGP signing party. Message-ID: <4ADCB431.1080502@bogus.com> The second session for the NANOG 47 pgp key signing party will be during the tuesday morning break (11:00 - 11:30) in the Desoto Foyer. If you wish to participate in the pgp keysigning there is still time to add your key to the keyring at: http://biglumber.com/x/web?ev=97301 Then come to the last session with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. Thanks Joel From Victor.Esposito at deltacom.com Mon Oct 19 15:01:37 2009 From: Victor.Esposito at deltacom.com (Esposito, Victor) Date: Mon, 19 Oct 2009 15:01:37 -0500 Subject: IPv6 Allocations Message-ID: Since there is a lot of conversation about IPv6 flying about, does anyone have a document or link to a good high level allocation structure for v6? It seems there are 100 different ways to sub allocate the /32, and I am trying to find a simple but scalable method... . Thanks! Victor Esposito From patrick at ianai.net Mon Oct 19 15:05:15 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 19 Oct 2009 16:05:15 -0400 Subject: Science vs. bullshit Message-ID: Lightning talk followup because I want to make sure there was not a miscommunication. A two sentence comment at the mic while 400+ of your not-so-close friends are watching does not a rational discussion make. The talk in question: The disagreement is whether Renesys can reliably find out how many transit providers an AS has. Remember, we are discussing transit providers here, not peers. My point is if an AS has _transit_, then it must be visible in the global table (assuming a reasonably large set of vantage points), or it would not be transit. Of course, this is not perfect, but it is a pretty close approximation for fitting curves over 10s of 1000s of ASes. So things like "I have two transit providers, and one buys transit from the other" is a small number and not relevant to fitting curves. (It also means you are an idiot, or in a corner of the Internet where you should probably be considered as having only one provider.) Majdi has pointed out other corner cases where transit is not viewable through systems like Rensys. For instance, announcing prefixes to Provider 2 with a community to local-pref the announcement below peer routes. That means only one transit is visible in BGP data. There were several reasons some of us did not think edge cases like this were important. For instance, Renesys keeps -every- update ever, so if Provider 1 ever flaps, Rensys will see Provider 2. Also, when looking for the number of providers, a "backup path" may not be relevant since no packets take that path. More importantly, I thought the point of the talk was to show that the table was growing during the recession and people were still getting more providers. The result is a curve, not a hard-and-fast number. Corner cases like the one above are barely noise, so the curve it still valid. It is true that finding peering edges with things like route-views is problematic at best, so finding ASes with one transit plus peering might be problematic. But since I do not think that was the point of the talk, I do not consider that problem. If anyone who still thinks the problems with finding transit edges somehow make the talk 'bullshit' could clarify their position, I would be grateful. -- TTFN, patrick From justin at justinshore.com Mon Oct 19 15:06:06 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 19 Oct 2009 15:06:06 -0500 Subject: Webcasts of NANOG47 Message-ID: <4ADCC6AE.7070107@justinshore.com> Does anyone know if there will be video streams of the events from rooms other than what's in the Grand room? For example I would like to see the ISP Security Track BOF or the one tomorrow on Peering. I don't see a way to select those specific feeds though. Thanks Justin From simon.perreault at viagenie.ca Mon Oct 19 15:23:42 2009 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Mon, 19 Oct 2009 16:23:42 -0400 Subject: IPv6 Allocations In-Reply-To: References: Message-ID: <4ADCCACE.6060509@viagenie.ca> Esposito, Victor wrote, on 2009-10-19 16:01: > Since there is a lot of conversation about IPv6 flying about, does > anyone have a document or link to a good high level allocation structure > for v6? See RFC 3531 and here: http://www.ipv6book.ca/allocation.html Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From nanog at daork.net Mon Oct 19 15:25:22 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 20 Oct 2009 09:25:22 +1300 Subject: IPv6 Allocations In-Reply-To: References: Message-ID: <9B2A035D-901A-442A-9DF3-506F76DD32CE@daork.net> On 20/10/2009, at 9:01 AM, Esposito, Victor wrote: > Since there is a lot of conversation about IPv6 flying about, does > anyone have a document or link to a good high level allocation > structure > for v6? > > It seems there are 100 different ways to sub allocate the /32, and I > am > trying to find a simple but scalable method... . This discussion has been done a bunch of times. Here is my scheme, which has been adopted (sometimes with small modifications) by quite a few providers I have spoken with. http://mailman.nanog.org/pipermail/nanog/2009-August/012681.html Read the whole thread because there was a bit of confusion. -- Nathan Ward From rubensk at gmail.com Mon Oct 19 15:37:43 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 19 Oct 2009 18:37:43 -0200 Subject: NetFlow analyzer software In-Reply-To: <120987315-1255977397-cardhu_decombobulator_blackberry.rim.net-439977971-@bda543.bisx.prod.on.blackberry> References: <120987315-1255977397-cardhu_decombobulator_blackberry.rim.net-439977971-@bda543.bisx.prod.on.blackberry> Message-ID: <6bb5f5b10910191337x46f52447q6c43eabe5d4f49b@mail.gmail.com> Manage Engine flow receiver with no user sessions viewing statistics runs at 100% CPU for 200+ Mbps unsampled traffic. It's suited to SMBs only. Rubens On Mon, Oct 19, 2009 at 4:36 PM, Michael J McCafferty wrote: > ManageEngine's product is the one that kills browsers because you can tell it to list the top X ASNs. > ------Original Message------ > From: Brian R. Watters > To: nanog at nanog.org > Cc: nanog at nanog.org > ReplyTo: Brian R. Watters > Subject: RE: NetFlow analyzer software > Sent: Oct 19, 2009 10:45 AM > > > We have used this product with great success and its reasonable in pricing > and well supported. > > http://www.manageengine.com/products/netflow/index.html > > BRW > > > > -----Original Message----- > From: mark jackson [mailto:markcciejackson at gmail.com] > Sent: Monday, October 19, 2009 10:47 AM > To: mike at m5computersecurity.com > Cc: nanog at nanog.org > Subject: Re: NetFlow analyzer software > > What's up gold > Mrtpg > Scrtinizer > Nagios > Riverbed Cascade > Solarwinds > > Sent from my iPhone > Please excuse spelling errors > > On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" > ?> wrote: > >> All, >> ? I am looking for decent netflow analyzer and reporting ?software >> with good support for AS data. >> ? ManagEngine's product crashes or locks up my browser when I try to >> list/sort the AS info because it's too large of a list and there is >> no way to tell it to show just the top x results. >> ? Plixer's Scrutenizer, while it seems like it's a pretty decent >> product, is no longer supporting Linux... We are a Linux shop >> (servers, desktops, laptops). >> ? What else is there that I might want to look at? >> >> Thanks! >> Mike >> M5Hosting.com >> Sent from my Verizon Wireless BlackBerry >> > > > > > Sent from my Verizon Wireless BlackBerry From Jason.Mishka at UToledo.Edu Mon Oct 19 16:04:14 2009 From: Jason.Mishka at UToledo.Edu (Mishka, Jason) Date: Mon, 19 Oct 2009 17:04:14 -0400 Subject: Cisco VSS-1440 migration query In-Reply-To: <1255974340.17380.3.camel@leland-gandi> References: <1255964840.6372.19.camel@leland-gandi> <1255974340.17380.3.camel@leland-gandi> Message-ID: On Mon, 2009-10-19 at 13:06 -0400, Jason Giles wrote: > >From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands. When you convert to vss mode the interfaces are renamed. The interface in switch 2 that was g1/1 becomes 2/1/1. Any configuration applied to g1/1 will be rejected because that interface no longer exists. If you intended to keep interface configuration, you will need to reapply that to the new interface name. Jason From jnegro at billtrust.com Mon Oct 19 16:07:30 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Mon, 19 Oct 2009 17:07:30 -0400 Subject: NetFlow analyzer software In-Reply-To: <6bb5f5b10910191337x46f52447q6c43eabe5d4f49b@mail.gmail.com> References: <120987315-1255977397-cardhu_decombobulator_blackberry.rim.net-439977971-@bda543.bisx.prod.on.blackberry> <6bb5f5b10910191337x46f52447q6c43eabe5d4f49b@mail.gmail.com> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B903F65284@LOGAN.billtrust.local> Yes my experience was the same on with Manage Engine. Although, they do have an article buried in their archives that shows how to tweak the mysql and java memory settings on start of the app. We found that helped a bit. We were successfully using it for netflows from more than 100Mbps, so I would say it can handle a bit more than typical SMB traffic. I don't know if anyone mentioned it, but a good commercial product a former customer of mine used to use was Solarwinds Orion. Jeffrey -----Original Message----- From: Rubens Kuhl [mailto:rubensk at gmail.com] Sent: Monday, October 19, 2009 4:38 PM To: Nanog Subject: Re: NetFlow analyzer software Manage Engine flow receiver with no user sessions viewing statistics runs at 100% CPU for 200+ Mbps unsampled traffic. It's suited to SMBs only. Rubens On Mon, Oct 19, 2009 at 4:36 PM, Michael J McCafferty wrote: > ManageEngine's product is the one that kills browsers because you can tell it to list the top X ASNs. > ------Original Message------ > From: Brian R. Watters > To: nanog at nanog.org > Cc: nanog at nanog.org > ReplyTo: Brian R. Watters > Subject: RE: NetFlow analyzer software > Sent: Oct 19, 2009 10:45 AM > > > We have used this product with great success and its reasonable in pricing > and well supported. > > http://www.manageengine.com/products/netflow/index.html > > BRW > > > > -----Original Message----- > From: mark jackson [mailto:markcciejackson at gmail.com] > Sent: Monday, October 19, 2009 10:47 AM > To: mike at m5computersecurity.com > Cc: nanog at nanog.org > Subject: Re: NetFlow analyzer software > > What's up gold > Mrtpg > Scrtinizer > Nagios > Riverbed Cascade > Solarwinds > > Sent from my iPhone > Please excuse spelling errors > > On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" > ?> wrote: > >> All, >> ? I am looking for decent netflow analyzer and reporting ?software >> with good support for AS data. >> ? ManagEngine's product crashes or locks up my browser when I try to >> list/sort the AS info because it's too large of a list and there is >> no way to tell it to show just the top x results. >> ? Plixer's Scrutenizer, while it seems like it's a pretty decent >> product, is no longer supporting Linux... We are a Linux shop >> (servers, desktops, laptops). >> ? What else is there that I might want to look at? >> >> Thanks! >> Mike >> M5Hosting.com >> Sent from my Verizon Wireless BlackBerry >> > > > > > Sent from my Verizon Wireless BlackBerry From mpetach at netflight.com Mon Oct 19 16:32:01 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 19 Oct 2009 14:32:01 -0700 Subject: 2009.10.19 NANOG47 Monday notes, second half Message-ID: <63ac96a50910191432s74c07549vc680202632de5239@mail.gmail.com> Here's my notes from second half of NANOG today. Now off to bear and gear. :) Matt 2009.10.19 NANOG 47 Monday notes, part 2 Mike Hughes starts things off after lunch at 1436 hours Pacific time. Few bits of administrivia still. If you want to submit a lightning talk, you can do it up until 7pm today. Please vote for the committee members! PC nominations close this evening as well; if you'd like to be on it, do that as well, as much help as possible is needed. 3 lightning talks next up. First up is Ernest McCracken http://netlabs.cs.memphis.edu NetViews: real time visualization of Internet Path Dynamics for Network Management Started doing this as part of his undergrad work. Goal was to help researchers visualize network paths. Topology mapping typically try to represent internet architectures. Scatter, skitter, Rocket Fuel, CAIDA, why graph in realtime? monitor realtime reachability spot anomalous depeering identify route hijacking and misconfigurations developing next-gen routing monitor system. BGPMon -- realtime lightweight BGP monitor with over 70 peers--allows for fast updates NetViews - visualizes both control plane paths (via BGP updates) and forwarding paths (via active probing) BGPMon is running, you connect to it, get the routing updates; data broker sends BGP updates. Prober probes target network from BGP peers to get path updates. GeoCoder and IP crawler get geographic info, and traceable IPs for probing. Slide showing data pathway They probe during routing events; a timeline showing BGP updates during the timeline. They keep probing until they see no additional updates. Visualization filters to show networks based on the number of ASes an AS connects to. You can see the updates scroll in realtime on the live map as the updates come into the system. Blue is path additions/changes, Red for changes. They can also visualize forwarding paths, but there's challenges in inferring forwarding paths based on traceroutes. Future work: correlate forwarding and routing dynamics to create a classification model for internet paths add scalability by having clients run traceroute jobs in a P2P fashion Give client users the ability to communicate with each other Funded by NSF, and collaborating with UCLA, ColoState and UofO on BGPMon system. Any questions? Q: Dave Meyer--can it be run internally? What infrastructure do you need? Server portal runs in lab, clients can run on any java client. Synch up with him afterwards if you have any summer internships available. Next talk Jim Cowie from Renesys The recession and the routing table Reading the tea leaves They dig into the routing tables to see what's happening. Tough times, tough questions We konw that internet transit purchases are sensitive to business conditions (2000 crash) is the 2008-2009 recession affecting growth in the global/regional routing tables Should be some sign of pullback in the routing tables like in 2000. 3 years of North American routing--it's still going up, there's no depression visible. Why did the table keep growing? Enterprises don't cut costs by leaving the internet, they cut costs by reducing diversity cheap transit getting cheaper acts like "easy money" prospect of v4 runout may result in "use it or lose it" addition of routes into table. Half the table is just hanging out with 1 provider. Number of prefixes with 4 or more providers is going up. The 1 provider networks either go to no-longer-advertised or shift to 2 or 3 providers. More go to the "no-longer-seen" pool; fewer upgrade to the next category up. People postpone getting to multihoming. Triple-homing seems to be sweet spot. 4 or more provider pool is getting larger and more stable over time; you don't tend to decrease over time. Global recession might give more of a break before v4 exhaustion Cheap transit killed that theory some evidence of single- and dual- homed customers putting off the move to higher order multihoming in 2007 and 2008 "obviously practicing for IPv6 transition, after which apparently multihoming becomes unnecessary" Otherwise, growth continues apae Bring on the post-IPv4 marketplace! Q: Randy Bush--BGP is a great data hiding system; it doesn't tell you much about the real topology of the internet. How do you determine how a prefix has a single upstream? A: ask him afterwards. Q: is this transit AS? A: Yes Q: You have to have seen the AS through another AS, that's how you can count the upstreams. Joe Abley up to the front from ICANN DNSSec for the Root Zone Matt Larson, from VeriSign. Info update for those who care about DNSSec collaboration between ICANN and VeriSign with DoC ICANN is IANA functions operator Manages the Key Signing Key Accepts DS records from TLD operators Verifies and processes request Sends update requests to DoC for authorization and to VeriSign for implementation DoC NTIA Authorizes changes to the root zone DS records Root key sets DNSSec updates VeriSign manages the zone signing key Proposed Approach to protect the KSK CPS--certificate practice statement DPS, DNSSEC policy and practice statement basically, to assure people the practices are adequate to protect it. community trust proposal that community representatives have an active role in management of the KSK as crypto officers needed to activate the KSK as backup key share holders protecting shares of the symmetric keys in case of disaster recovery Auditing and Transparency Third-party auditors check that ICANN... webcast of sessions KSK is 2048 bit RSA key rolled every 2-5 years RFC5011 for automatic key rollovers propose using signatures based on SHA-256 but there's no shipping code based on this Zone signing Key (held by verisign) ZSK is 1024-bit RSA rolled once a quarter SHA-256 signature Signature validityRRSIG validity 15 days resign every 10 days Other RRSIG validity 7 days resign twice a day Key Ceremonies Key Generation Generation of new KSK Every 2-5 years Processing of ZSK signing request (KSR) signing ZSK for the next upcoming quarter Root Trust Anchor published on a web site by ICANN as XML-wrapped and plain DS record to facilitate automatic processing PKCS#10 certificate signing request Roll Out incremental roll out of the signed root groups of root server "letters" at a time watch the query profile to all root servers as roll out progresses Listen to community feedback for any issues No validation Real keys will be replaced by dummy keys while rolling out the signed root signatures not valid during roll out actual keys will be published at end of rollout Timeline December 1, 2009 root zone signed initially signed zone stays internal to ICANN and Verisign ICANN Jan-July 2010 incremental roll out of signed root July 1, 2010 KSK rolled out root trust anchor ISP Security BOF later today will talk about it. Full architectural documents around the process will be published in the next few weeks. Next speaker is Paul Francis, talking about Virtual Aggregation. Reducing FIB Size with Virtual Aggregation (VA) ISPs often want to extend the life of old routers Routers that have inadequate FIB but otherwise are still useful A common approach--use old routers as customer PE, default to core Other FIB/RIB shrinking tips Filter out more specific routes For lower-tier ISPs, default to transit ISPs ie use 0/0 and load balance among transit ISPs BUT leads to non-optimal routes lots of configuration (peer routes, "important" routes like Google) Can't be used by transit ISPs themselves Mitigating non-optimal default routes Use more-specific "semi-defaults" AS3303 Swisscom IP-Plus point 62/8, 80/7, 21/7, etc. to EU transit ISP ARIN space to US transit class B 128/3, 160/5, 168/6 to US transit IETF working on a more general solution: virtual agg GROW working group draft-ietf-grow-va-00 -va-gre-00 -va-mpls-00 -va-perf-00 VA is a way to control FIB size in routers DFZ FIB, not VPN tables does not shrink RIB size Tight control of FIB size for any or all routers no coordination between ISPs works with legacy routers Important today--possibly critical tomorrow? looking forward, BGP RIB growth rate could increase substantially exhaustion of v4 erodes aggregation because of pressure to shrink default prefix size uptake of v6 VA can help ease these pressures VA not perfect Requires configuration of its own Entails a traffic load/FIB size tradeoff which can be quite good academic study on large transit ISP 10x fib reduction with negligible latency/load penalty But in general we don't know how easy to achieve this-- configuration... Why this talk? You can help us define VA certain protocols or configuration details alternative ways to deploy or tell us that VA is useless encourage your vendor to implement VA current implementations from Huawei and ?? VA Basic Idea Define "Virtual Prefixes" (VP) These are shorter (bigger) than real prefixes think of /6s, /7s, /8s Assign different routers to be "responsible" for different virtual prefixes ie, they need to know how to route everything in the VP FIB-suppression BGP runs as normal all routers have full RIB important to not muck with BGP operation per se suppress updates to FIB for more specifics of virtual prefixes APR (aggregation point router) for 22/8 originate route to 22/8 with nexthop being itself it FIB-installs all sub-prefixes within 22/8 other routers FIB-suppress all prefixes within 22/8 This just tunnel-maps from one router to another out to the egress point. The only router with the need to know how to route that packet was APR1 (well, that, and the ingress router) The packet takes a bit of a longer path to do this with simple aggregates. You can add "popular prefixes" to routers to point them along "better" paths. Types of tunnels defined MPLS (using LDP) GRE ... A deployment example Robert Rasuzck at Cisco shows a POP site with 4 PE customer agg routers, 2 Rs, 2 RRs; core can use tunnels between them already. Use RRs as APRs -- can optionally FIB-install routes for which PE is egress If you do FIB suppression at the RR layer Then need to install popular prefixes at the PE layer--GROW looking to automate that part. VA from our point of view Figure out where you need FIB reduction Based on this, design your deployment select VPs assign routers as APRs, configure configure "VIP-list" New IETF GROW WG work item for FIB suppression Q: Patrick, Akamai--this seems very complex; couldn't we just take prefixes out of the FIB that are covered by a shorter prefix with same next-hop; wouldn't that be much easier to do, and save FIB space? Could we maybe ask vendors to look into doing that? A: Lixia may have done some looking into that; she says that two people on her team, they found out that you can compress your FIB between 10 and 50% by simply suppressing more specifics with same next hops. She was going to give a talk at GROW at the next meeting that would do this. Q: Doni from PeakWeb, was asking vendors for this around the 200,000 routes in the FIB; the vendors were wanting to simply sell more hardware. Which routers need the full FIB in the drawing? A: None of them need full routes. Generally got about 10X saving in all of them. Q: Owen deLong--if you already have all the routers everywhere, it might make sense; if you have just 2 routers in a POP, this looks like a distributed CAM load, to have multiple routers pretend to look like one router A: yes, it's like that. Q: RAS--remember the 8k Foundry boxes? They had 8k CAM table, and their solution was to either have just default, or break it up into /12s; this is similar, it just limits based on number of next-hops they have. Could we get benefits from doing more simple aggregation like that? Q: Igor notes you can probably just upgrade for cheaper than transferring all sorts of routes back and forth and paying for additional interconnect ports. Q: Anton Kapella, have they considered looking about Auto-TE QoS stuff internally? If packets are being redirected around internally, it does mean something for link-loading; how will this interact with QoS, since this will transport packets along links not originally planned for it? In what they saw, very few packets used the non-optimal paths. Next up. We'll do coffee break at 1615, BOFs at 1645 BGP# - a system for dynamic route control in data centers tenants and landlords one landlord owner and manager of the datacenter many tenants internal users search, email, gaming external users utility computing customers empower tenants to control routing decisions Routing tensions tenants have different goals tenant goal--spread traffic or migrate traffic from one server to another current system, tenant submits tickets to get routing changed. whole ticket flow is shown Tenants have limited control over routing A better system allow for automated route control allow tenants independent and safe route control ensure scalability allow for maintenance changes BGP# simple speakers (multispeaker) peer with BGP routers send route announcements/withdrawls (ECMP capable) Stateful controller (controller) controls coordinates speakers custom API ("applications") Application runs on tenant box; speaks to controller via API; controller speaks to multispeaker which peers with router to send the update to spread traffic, similar thing; application uses API to ask controller which asks mutispeaker; it has 2 sessions to router, with 2 next hops for prefix. Automated route control controller API allows for custom applications Application can automatically manage routes Independent and safe route control only allow a tenant to change their own prefixes. Scalability Multispeaker and controller not placed in machines handling user trafic eliminates need for one policy controller per machine reduces peering sessions to router eliminate per-ticket manual intervention Resiliency ensure system continues operating instantiate multiple multispeakers single multispeaker failure doesn't affect other MS ability separate multispeaker and controller prefix resiliency -- ensure prefix stays available announce same prefix from mutiple multispeaker router retains prefix even if one MS fails Automation service could deploy a new multispeaker with same config if one dies. No inconsistency with multiple Multispeakers suppose some multispeakers become unresponsive BGP# listening tool detects the lack of router readvertisement suppose multispeaker reboots and is in different state? get config and state from persistent store Alternate approach each tenant sets up its own BGP instances needs one session per machine landlord may need to deal with many BGP peers Conclusions: Tenants have more power Landlord retains responsibility for validation of routes. system achieves stability and resiliency Q: Francis asks if BGP is an awfully coarsegrained tool to use for something like this--what about using MPLS for setting up flows. A: BGP finite state machine is much simpler to follow and update. We'll go into coffee break now; BOFs start at 1645 hours Eastern time. SC elections, JUST DO IT!! PC nominations open for 3 more hours! 1800 hours in Regency for Bear and Gear. BOFs, Mobile Data Track, ISP Security BOF, and DNS BOF will be upstairs in DeSoto room. Tuesday we start at 0830 again with breakfast. For now, I head over to the DNS thingie BoF IPv6 and resolvers; how do we make it less painful? For most people, rolling out IPv6 can't break IPv4, and separate hostnames isn't scaleable long term. Per Google, 0.078% users are impacted by enabling quad A on machines. Assuming a user base of 600M that's 470K users that get broken, which isn't acceptable. Right now, in browsers, IPv4 fallback is on the order of 21 seconds to 181 seconds, which is for most SLA numbers considered "broken" Options? Don't roll out IPv6 prefer A over AAAA accept the breakage what about checking for working IPv6 connectivity before sending back AAAA record. Only way to know if user has working v6 transport is if the AAAA request came via IPv6 instead of IPv4 Recursive servers need to be set to only return AAAA *only* when request came in via IPv6; otherwise, return A record only. Now, auth DNS server only has to worry about IPv6 reachability to the recursive server. We've asked if ISC can write this; ISC has done this, it'll be in BIND 9.7; it'll be in a second beta coming out in early November; if you want to check it out, if you're on user list or beta list, you'll get notification; otherwise, check ISC site in early november and it should be there. Feature will be a knob you have to turn on. There's an additional check put in; if DNSSEC is set, it won't forge DNS answers unless there's a knob set "BREAKDNSSEC" that you can turn on, the knob is going to be very well documented. But if you've gone through the work of setting up DNSSEC, you should know how to troubleshoot it yourself. This should be be set up for resolvers facing customers, not for internal services that have odd configurations. What about having an ACL for controlling behaviour for different subnets? If they fit in a view statement, you already have that capability. Will this be available within a view? Yes, you can do it there. But the ACL idea is interesting, and could be better than pushing people towards views. This really goes on the recursive side. We need to try to convince ISPs to use these options. If a request comes from a 6to4 address; the source is a 6to4 address; do you respond with AAAA or not. How about ACLs with flexibility to see if it's over v4 but from a 6to4 address to send different responses. A simple default policy is good, but the flexibility is good for more experienced sites. Simple on-or-off knob is in 9.7b2; more granular control will be needed for later versions... what about 6rd? They would get no AAAA results in that scenario. We might need a DNSv6 option for DHCPv4 which would be able to give back the v6 DNS servers. Should we put together an information draft for IETF; we can draft one up, so the three of them should talk; Igor Gashinksi, Yahoo, Larissa Shapiro, ISC, Alain Durand, Comcast OARC meeting, Beijing, Jason Fesler will be there to talk about it. ISOC meeting in Paris next week, we'll be there to talk about it as well. Internet2 joint techs talked about it as well. General consensus is that this is a necessary evil hack. If we can get it working with 6rd, it'll be an interesting working solution to a common problem. What about shoving JavaScript code into web pages to report DNS lookups back via REST infrastructure to get an idea what the types of breakage. OS, browser, IP, and which test cases break or not. We could do a series of test queries, and see which ones break or not. Give A Give AAAA Result of the query comes into the beacon server, so we can see if they saw the reply or not. It would be better for the javascript to reply back with what *it* saw, as well as see what the server log sees. There's some javascript coding challenges with collecting this data. If we can at least break it down to 3 buckets 6to4 teredo native it would help really pin down where the breakage. Do note that the percentage shown wasn't Yahoo data, that was Google's data, so we don't have that breakdown ourselves. Would going to AS level be too specific for people? We'd need to consider carefully privacy issues and anonymizing the data as per our privacy rules. What about running an experiment in partnerships for specific ASNs? Point is, this is coming out, do share the data, this will be going into mainline code release. It's opt-in, defaulted off. The *actual* names for the config options are... This will apply to just the RR set, not the glue set; if glue returns AAAA, it'll still come back intact. The tests are really testing recursive lookup server to the last proxy device in front of the client. But what if the recursive server to auth server breakage happens? If the recursive server lookup side, can we turn the knob on in the other direction? This is an interesting challenge; we'll have to see how much additional work this will need, and how much additional funding will be needed to cover for it. ISC will...look into the feasability of doing that. The IETF draft cutoff is tonight for Paris, so maybe it'll be done for the Anaheim one, at which point we'll have working code out there, and a bit more time for writing the draft. We wrap up the BOF at 1724 hours Pacific time. (what about a switch for auth servers that allows for turning off "don't send AAAA records to ZZZZZ"?) From Chris.Sieber at qwest.com Mon Oct 19 16:36:37 2009 From: Chris.Sieber at qwest.com (Sieber, Chris) Date: Mon, 19 Oct 2009 15:36:37 -0600 Subject: NANOG Digest, Vol 21, Issue 72 In-Reply-To: References: Message-ID: <3DCA89987EA48149B9E6378D1E1BFEF74CC0D38831@qtdenexmbm21.AD.QINTRA.COM> -----Original Message----- From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] Sent: Monday, October 19, 2009 3:32 PM To: nanog at nanog.org Subject: NANOG Digest, Vol 21, Issue 72 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. UPDATE: NANOG 47 PGP signing party. (Joel Jaeggli) 2. IPv6 Allocations (Esposito, Victor) 3. Science vs. bullshit (Patrick W. Gilmore) 4. Webcasts of NANOG47 (Justin Shore) 5. Re: IPv6 Allocations (Simon Perreault) 6. Re: IPv6 Allocations (Nathan Ward) 7. Re: NetFlow analyzer software (Rubens Kuhl) 8. RE: Cisco VSS-1440 migration query (Mishka, Jason) 9. RE: NetFlow analyzer software (Jeffrey Negro) 10. 2009.10.19 NANOG47 Monday notes, second half (Matthew Petach) ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 Oct 2009 11:47:13 -0700 From: Joel Jaeggli Subject: UPDATE: NANOG 47 PGP signing party. To: NANOG list Message-ID: <4ADCB431.1080502 at bogus.com> Content-Type: text/plain; charset=UTF-8 The second session for the NANOG 47 pgp key signing party will be during the tuesday morning break (11:00 - 11:30) in the Desoto Foyer. If you wish to participate in the pgp keysigning there is still time to add your key to the keyring at: http://biglumber.com/x/web?ev=97301 Then come to the last session with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. Thanks Joel ------------------------------ Message: 2 Date: Mon, 19 Oct 2009 15:01:37 -0500 From: "Esposito, Victor" Subject: IPv6 Allocations To: Message-ID: Content-Type: text/plain; charset="US-ASCII" Since there is a lot of conversation about IPv6 flying about, does anyone have a document or link to a good high level allocation structure for v6? It seems there are 100 different ways to sub allocate the /32, and I am trying to find a simple but scalable method... . Thanks! Victor Esposito ------------------------------ Message: 3 Date: Mon, 19 Oct 2009 16:05:15 -0400 From: "Patrick W. Gilmore" Subject: Science vs. bullshit To: NANOG list Message-ID: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Lightning talk followup because I want to make sure there was not a miscommunication. A two sentence comment at the mic while 400+ of your not-so-close friends are watching does not a rational discussion make. The talk in question: The disagreement is whether Renesys can reliably find out how many transit providers an AS has. Remember, we are discussing transit providers here, not peers. My point is if an AS has _transit_, then it must be visible in the global table (assuming a reasonably large set of vantage points), or it would not be transit. Of course, this is not perfect, but it is a pretty close approximation for fitting curves over 10s of 1000s of ASes. So things like "I have two transit providers, and one buys transit from the other" is a small number and not relevant to fitting curves. (It also means you are an idiot, or in a corner of the Internet where you should probably be considered as having only one provider.) Majdi has pointed out other corner cases where transit is not viewable through systems like Rensys. For instance, announcing prefixes to Provider 2 with a community to local-pref the announcement below peer routes. That means only one transit is visible in BGP data. There were several reasons some of us did not think edge cases like this were important. For instance, Renesys keeps -every- update ever, so if Provider 1 ever flaps, Rensys will see Provider 2. Also, when looking for the number of providers, a "backup path" may not be relevant since no packets take that path. More importantly, I thought the point of the talk was to show that the table was growing during the recession and people were still getting more providers. The result is a curve, not a hard-and-fast number. Corner cases like the one above are barely noise, so the curve it still valid. It is true that finding peering edges with things like route-views is problematic at best, so finding ASes with one transit plus peering might be problematic. But since I do not think that was the point of the talk, I do not consider that problem. If anyone who still thinks the problems with finding transit edges somehow make the talk 'bullshit' could clarify their position, I would be grateful. -- TTFN, patrick ------------------------------ Message: 4 Date: Mon, 19 Oct 2009 15:06:06 -0500 From: Justin Shore Subject: Webcasts of NANOG47 To: NANOG Message-ID: <4ADCC6AE.7070107 at justinshore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Does anyone know if there will be video streams of the events from rooms other than what's in the Grand room? For example I would like to see the ISP Security Track BOF or the one tomorrow on Peering. I don't see a way to select those specific feeds though. Thanks Justin ------------------------------ Message: 5 Date: Mon, 19 Oct 2009 16:23:42 -0400 From: Simon Perreault Subject: Re: IPv6 Allocations To: nanog at nanog.org Message-ID: <4ADCCACE.6060509 at viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Esposito, Victor wrote, on 2009-10-19 16:01: > Since there is a lot of conversation about IPv6 flying about, does > anyone have a document or link to a good high level allocation structure > for v6? See RFC 3531 and here: http://www.ipv6book.ca/allocation.html Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org ------------------------------ Message: 6 Date: Tue, 20 Oct 2009 09:25:22 +1300 From: Nathan Ward Subject: Re: IPv6 Allocations To: NANOG Message-ID: <9B2A035D-901A-442A-9DF3-506F76DD32CE at daork.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 20/10/2009, at 9:01 AM, Esposito, Victor wrote: > Since there is a lot of conversation about IPv6 flying about, does > anyone have a document or link to a good high level allocation > structure > for v6? > > It seems there are 100 different ways to sub allocate the /32, and I > am > trying to find a simple but scalable method... . This discussion has been done a bunch of times. Here is my scheme, which has been adopted (sometimes with small modifications) by quite a few providers I have spoken with. http://mailman.nanog.org/pipermail/nanog/2009-August/012681.html Read the whole thread because there was a bit of confusion. -- Nathan Ward ------------------------------ Message: 7 Date: Mon, 19 Oct 2009 18:37:43 -0200 From: Rubens Kuhl Subject: Re: NetFlow analyzer software To: Nanog Message-ID: <6bb5f5b10910191337x46f52447q6c43eabe5d4f49b at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Manage Engine flow receiver with no user sessions viewing statistics runs at 100% CPU for 200+ Mbps unsampled traffic. It's suited to SMBs only. Rubens On Mon, Oct 19, 2009 at 4:36 PM, Michael J McCafferty wrote: > ManageEngine's product is the one that kills browsers because you can tell it to list the top X ASNs. > ------Original Message------ > From: Brian R. Watters > To: nanog at nanog.org > Cc: nanog at nanog.org > ReplyTo: Brian R. Watters > Subject: RE: NetFlow analyzer software > Sent: Oct 19, 2009 10:45 AM > > > We have used this product with great success and its reasonable in pricing > and well supported. > > http://www.manageengine.com/products/netflow/index.html > > BRW > > > > -----Original Message----- > From: mark jackson [mailto:markcciejackson at gmail.com] > Sent: Monday, October 19, 2009 10:47 AM > To: mike at m5computersecurity.com > Cc: nanog at nanog.org > Subject: Re: NetFlow analyzer software > > What's up gold > Mrtpg > Scrtinizer > Nagios > Riverbed Cascade > Solarwinds > > Sent from my iPhone > Please excuse spelling errors > > On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" > ?> wrote: > >> All, >> ? I am looking for decent netflow analyzer and reporting ?software >> with good support for AS data. >> ? ManagEngine's product crashes or locks up my browser when I try to >> list/sort the AS info because it's too large of a list and there is >> no way to tell it to show just the top x results. >> ? Plixer's Scrutenizer, while it seems like it's a pretty decent >> product, is no longer supporting Linux... We are a Linux shop >> (servers, desktops, laptops). >> ? What else is there that I might want to look at? >> >> Thanks! >> Mike >> M5Hosting.com >> Sent from my Verizon Wireless BlackBerry >> > > > > > Sent from my Verizon Wireless BlackBerry ------------------------------ Message: 8 Date: Mon, 19 Oct 2009 17:04:14 -0400 From: "Mishka, Jason" Subject: RE: Cisco VSS-1440 migration query To: Message-ID: Content-Type: text/plain; charset="US-ASCII" On Mon, 2009-10-19 at 13:06 -0400, Jason Giles wrote: > >From my test, all physical interfaces configs on switch 2 are factory defaulted and SVI interfaces deleted on switch 2 upon running the conversion commands. When you convert to vss mode the interfaces are renamed. The interface in switch 2 that was g1/1 becomes 2/1/1. Any configuration applied to g1/1 will be rejected because that interface no longer exists. If you intended to keep interface configuration, you will need to reapply that to the new interface name. Jason ------------------------------ Message: 9 Date: Mon, 19 Oct 2009 17:07:30 -0400 From: "Jeffrey Negro" Subject: RE: NetFlow analyzer software To: "Rubens Kuhl" , "Nanog" Message-ID: <3C5B084431653D4A9C469A22AFCDB5B903F65284 at LOGAN.billtrust.local> Content-Type: text/plain; charset="iso-8859-1" Yes my experience was the same on with Manage Engine. Although, they do have an article buried in their archives that shows how to tweak the mysql and java memory settings on start of the app. We found that helped a bit. We were successfully using it for netflows from more than 100Mbps, so I would say it can handle a bit more than typical SMB traffic. I don't know if anyone mentioned it, but a good commercial product a former customer of mine used to use was Solarwinds Orion. Jeffrey -----Original Message----- From: Rubens Kuhl [mailto:rubensk at gmail.com] Sent: Monday, October 19, 2009 4:38 PM To: Nanog Subject: Re: NetFlow analyzer software Manage Engine flow receiver with no user sessions viewing statistics runs at 100% CPU for 200+ Mbps unsampled traffic. It's suited to SMBs only. Rubens On Mon, Oct 19, 2009 at 4:36 PM, Michael J McCafferty wrote: > ManageEngine's product is the one that kills browsers because you can tell it to list the top X ASNs. > ------Original Message------ > From: Brian R. Watters > To: nanog at nanog.org > Cc: nanog at nanog.org > ReplyTo: Brian R. Watters > Subject: RE: NetFlow analyzer software > Sent: Oct 19, 2009 10:45 AM > > > We have used this product with great success and its reasonable in pricing > and well supported. > > http://www.manageengine.com/products/netflow/index.html > > BRW > > > > -----Original Message----- > From: mark jackson [mailto:markcciejackson at gmail.com] > Sent: Monday, October 19, 2009 10:47 AM > To: mike at m5computersecurity.com > Cc: nanog at nanog.org > Subject: Re: NetFlow analyzer software > > What's up gold > Mrtpg > Scrtinizer > Nagios > Riverbed Cascade > Solarwinds > > Sent from my iPhone > Please excuse spelling errors > > On Oct 19, 2009, at 10:43 AM, "Michael J McCafferty" > ?> wrote: > >> All, >> ? I am looking for decent netflow analyzer and reporting ?software >> with good support for AS data. >> ? ManagEngine's product crashes or locks up my browser when I try to >> list/sort the AS info because it's too large of a list and there is >> no way to tell it to show just the top x results. >> ? Plixer's Scrutenizer, while it seems like it's a pretty decent >> product, is no longer supporting Linux... We are a Linux shop >> (servers, desktops, laptops). >> ? What else is there that I might want to look at? >> >> Thanks! >> Mike >> M5Hosting.com >> Sent from my Verizon Wireless BlackBerry >> > > > > > Sent from my Verizon Wireless BlackBerry ------------------------------ Message: 10 Date: Mon, 19 Oct 2009 14:32:01 -0700 From: Matthew Petach Subject: 2009.10.19 NANOG47 Monday notes, second half To: nanog at nanog.org Message-ID: <63ac96a50910191432s74c07549vc680202632de5239 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Here's my notes from second half of NANOG today. Now off to bear and gear. :) Matt 2009.10.19 NANOG 47 Monday notes, part 2 Mike Hughes starts things off after lunch at 1436 hours Pacific time. Few bits of administrivia still. If you want to submit a lightning talk, you can do it up until 7pm today. Please vote for the committee members! PC nominations close this evening as well; if you'd like to be on it, do that as well, as much help as possible is needed. 3 lightning talks next up. First up is Ernest McCracken http://netlabs.cs.memphis.edu NetViews: real time visualization of Internet Path Dynamics for Network Management Started doing this as part of his undergrad work. Goal was to help researchers visualize network paths. Topology mapping typically try to represent internet architectures. Scatter, skitter, Rocket Fuel, CAIDA, why graph in realtime? monitor realtime reachability spot anomalous depeering identify route hijacking and misconfigurations developing next-gen routing monitor system. BGPMon -- realtime lightweight BGP monitor with over 70 peers--allows for fast updates NetViews - visualizes both control plane paths (via BGP updates) and forwarding paths (via active probing) BGPMon is running, you connect to it, get the routing updates; data broker sends BGP updates. Prober probes target network from BGP peers to get path updates. GeoCoder and IP crawler get geographic info, and traceable IPs for probing. Slide showing data pathway They probe during routing events; a timeline showing BGP updates during the timeline. They keep probing until they see no additional updates. Visualization filters to show networks based on the number of ASes an AS connects to. You can see the updates scroll in realtime on the live map as the updates come into the system. Blue is path additions/changes, Red for changes. They can also visualize forwarding paths, but there's challenges in inferring forwarding paths based on traceroutes. Future work: correlate forwarding and routing dynamics to create a classification model for internet paths add scalability by having clients run traceroute jobs in a P2P fashion Give client users the ability to communicate with each other Funded by NSF, and collaborating with UCLA, ColoState and UofO on BGPMon system. Any questions? Q: Dave Meyer--can it be run internally? What infrastructure do you need? Server portal runs in lab, clients can run on any java client. Synch up with him afterwards if you have any summer internships available. Next talk Jim Cowie from Renesys The recession and the routing table Reading the tea leaves They dig into the routing tables to see what's happening. Tough times, tough questions We konw that internet transit purchases are sensitive to business conditions (2000 crash) is the 2008-2009 recession affecting growth in the global/regional routing tables Should be some sign of pullback in the routing tables like in 2000. 3 years of North American routing--it's still going up, there's no depression visible. Why did the table keep growing? Enterprises don't cut costs by leaving the internet, they cut costs by reducing diversity cheap transit getting cheaper acts like "easy money" prospect of v4 runout may result in "use it or lose it" addition of routes into table. Half the table is just hanging out with 1 provider. Number of prefixes with 4 or more providers is going up. The 1 provider networks either go to no-longer-advertised or shift to 2 or 3 providers. More go to the "no-longer-seen" pool; fewer upgrade to the next category up. People postpone getting to multihoming. Triple-homing seems to be sweet spot. 4 or more provider pool is getting larger and more stable over time; you don't tend to decrease over time. Global recession might give more of a break before v4 exhaustion Cheap transit killed that theory some evidence of single- and dual- homed customers putting off the move to higher order multihoming in 2007 and 2008 "obviously practicing for IPv6 transition, after which apparently multihoming becomes unnecessary" Otherwise, growth continues apae Bring on the post-IPv4 marketplace! Q: Randy Bush--BGP is a great data hiding system; it doesn't tell you much about the real topology of the internet. How do you determine how a prefix has a single upstream? A: ask him afterwards. Q: is this transit AS? A: Yes Q: You have to have seen the AS through another AS, that's how you can count the upstreams. Joe Abley up to the front from ICANN DNSSec for the Root Zone Matt Larson, from VeriSign. Info update for those who care about DNSSec collaboration between ICANN and VeriSign with DoC ICANN is IANA functions operator Manages the Key Signing Key Accepts DS records from TLD operators Verifies and processes request Sends update requests to DoC for authorization and to VeriSign for implementation DoC NTIA Authorizes changes to the root zone DS records Root key sets DNSSec updates VeriSign manages the zone signing key Proposed Approach to protect the KSK CPS--certificate practice statement DPS, DNSSEC policy and practice statement basically, to assure people the practices are adequate to protect it. community trust proposal that community representatives have an active role in management of the KSK as crypto officers needed to activate the KSK as backup key share holders protecting shares of the symmetric keys in case of disaster recovery Auditing and Transparency Third-party auditors check that ICANN... webcast of sessions KSK is 2048 bit RSA key rolled every 2-5 years RFC5011 for automatic key rollovers propose using signatures based on SHA-256 but there's no shipping code based on this Zone signing Key (held by verisign) ZSK is 1024-bit RSA rolled once a quarter SHA-256 signature Signature validityRRSIG validity 15 days resign every 10 days Other RRSIG validity 7 days resign twice a day Key Ceremonies Key Generation Generation of new KSK Every 2-5 years Processing of ZSK signing request (KSR) signing ZSK for the next upcoming quarter Root Trust Anchor published on a web site by ICANN as XML-wrapped and plain DS record to facilitate automatic processing PKCS#10 certificate signing request Roll Out incremental roll out of the signed root groups of root server "letters" at a time watch the query profile to all root servers as roll out progresses Listen to community feedback for any issues No validation Real keys will be replaced by dummy keys while rolling out the signed root signatures not valid during roll out actual keys will be published at end of rollout Timeline December 1, 2009 root zone signed initially signed zone stays internal to ICANN and Verisign ICANN Jan-July 2010 incremental roll out of signed root July 1, 2010 KSK rolled out root trust anchor ISP Security BOF later today will talk about it. Full architectural documents around the process will be published in the next few weeks. Next speaker is Paul Francis, talking about Virtual Aggregation. Reducing FIB Size with Virtual Aggregation (VA) ISPs often want to extend the life of old routers Routers that have inadequate FIB but otherwise are still useful A common approach--use old routers as customer PE, default to core Other FIB/RIB shrinking tips Filter out more specific routes For lower-tier ISPs, default to transit ISPs ie use 0/0 and load balance among transit ISPs BUT leads to non-optimal routes lots of configuration (peer routes, "important" routes like Google) Can't be used by transit ISPs themselves Mitigating non-optimal default routes Use more-specific "semi-defaults" AS3303 Swisscom IP-Plus point 62/8, 80/7, 21/7, etc. to EU transit ISP ARIN space to US transit class B 128/3, 160/5, 168/6 to US transit IETF working on a more general solution: virtual agg GROW working group draft-ietf-grow-va-00 -va-gre-00 -va-mpls-00 -va-perf-00 VA is a way to control FIB size in routers DFZ FIB, not VPN tables does not shrink RIB size Tight control of FIB size for any or all routers no coordination between ISPs works with legacy routers Important today--possibly critical tomorrow? looking forward, BGP RIB growth rate could increase substantially exhaustion of v4 erodes aggregation because of pressure to shrink default prefix size uptake of v6 VA can help ease these pressures VA not perfect Requires configuration of its own Entails a traffic load/FIB size tradeoff which can be quite good academic study on large transit ISP 10x fib reduction with negligible latency/load penalty But in general we don't know how easy to achieve this-- configuration... Why this talk? You can help us define VA certain protocols or configuration details alternative ways to deploy or tell us that VA is useless encourage your vendor to implement VA current implementations from Huawei and ?? VA Basic Idea Define "Virtual Prefixes" (VP) These are shorter (bigger) than real prefixes think of /6s, /7s, /8s Assign different routers to be "responsible" for different virtual prefixes ie, they need to know how to route everything in the VP FIB-suppression BGP runs as normal all routers have full RIB important to not muck with BGP operation per se suppress updates to FIB for more specifics of virtual prefixes APR (aggregation point router) for 22/8 originate route to 22/8 with nexthop being itself it FIB-installs all sub-prefixes within 22/8 other routers FIB-suppress all prefixes within 22/8 This just tunnel-maps from one router to another out to the egress point. The only router with the need to know how to route that packet was APR1 (well, that, and the ingress router) The packet takes a bit of a longer path to do this with simple aggregates. You can add "popular prefixes" to routers to point them along "better" paths. Types of tunnels defined MPLS (using LDP) GRE ... A deployment example Robert Rasuzck at Cisco shows a POP site with 4 PE customer agg routers, 2 Rs, 2 RRs; core can use tunnels between them already. Use RRs as APRs -- can optionally FIB-install routes for which PE is egress If you do FIB suppression at the RR layer Then need to install popular prefixes at the PE layer--GROW looking to automate that part. VA from our point of view Figure out where you need FIB reduction Based on this, design your deployment select VPs assign routers as APRs, configure configure "VIP-list" New IETF GROW WG work item for FIB suppression Q: Patrick, Akamai--this seems very complex; couldn't we just take prefixes out of the FIB that are covered by a shorter prefix with same next-hop; wouldn't that be much easier to do, and save FIB space? Could we maybe ask vendors to look into doing that? A: Lixia may have done some looking into that; she says that two people on her team, they found out that you can compress your FIB between 10 and 50% by simply suppressing more specifics with same next hops. She was going to give a talk at GROW at the next meeting that would do this. Q: Doni from PeakWeb, was asking vendors for this around the 200,000 routes in the FIB; the vendors were wanting to simply sell more hardware. Which routers need the full FIB in the drawing? A: None of them need full routes. Generally got about 10X saving in all of them. Q: Owen deLong--if you already have all the routers everywhere, it might make sense; if you have just 2 routers in a POP, this looks like a distributed CAM load, to have multiple routers pretend to look like one router A: yes, it's like that. Q: RAS--remember the 8k Foundry boxes? They had 8k CAM table, and their solution was to either have just default, or break it up into /12s; this is similar, it just limits based on number of next-hops they have. Could we get benefits from doing more simple aggregation like that? Q: Igor notes you can probably just upgrade for cheaper than transferring all sorts of routes back and forth and paying for additional interconnect ports. Q: Anton Kapella, have they considered looking about Auto-TE QoS stuff internally? If packets are being redirected around internally, it does mean something for link-loading; how will this interact with QoS, since this will transport packets along links not originally planned for it? In what they saw, very few packets used the non-optimal paths. Next up. We'll do coffee break at 1615, BOFs at 1645 BGP# - a system for dynamic route control in data centers tenants and landlords one landlord owner and manager of the datacenter many tenants internal users search, email, gaming external users utility computing customers empower tenants to control routing decisions Routing tensions tenants have different goals tenant goal--spread traffic or migrate traffic from one server to another current system, tenant submits tickets to get routing changed. whole ticket flow is shown Tenants have limited control over routing A better system allow for automated route control allow tenants independent and safe route control ensure scalability allow for maintenance changes BGP# simple speakers (multispeaker) peer with BGP routers send route announcements/withdrawls (ECMP capable) Stateful controller (controller) controls coordinates speakers custom API ("applications") Application runs on tenant box; speaks to controller via API; controller speaks to multispeaker which peers with router to send the update to spread traffic, similar thing; application uses API to ask controller which asks mutispeaker; it has 2 sessions to router, with 2 next hops for prefix. Automated route control controller API allows for custom applications Application can automatically manage routes Independent and safe route control only allow a tenant to change their own prefixes. Scalability Multispeaker and controller not placed in machines handling user trafic eliminates need for one policy controller per machine reduces peering sessions to router eliminate per-ticket manual intervention Resiliency ensure system continues operating instantiate multiple multispeakers single multispeaker failure doesn't affect other MS ability separate multispeaker and controller prefix resiliency -- ensure prefix stays available announce same prefix from mutiple multispeaker router retains prefix even if one MS fails Automation service could deploy a new multispeaker with same config if one dies. No inconsistency with multiple Multispeakers suppose some multispeakers become unresponsive BGP# listening tool detects the lack of router readvertisement suppose multispeaker reboots and is in different state? get config and state from persistent store Alternate approach each tenant sets up its own BGP instances needs one session per machine landlord may need to deal with many BGP peers Conclusions: Tenants have more power Landlord retains responsibility for validation of routes. system achieves stability and resiliency Q: Francis asks if BGP is an awfully coarsegrained tool to use for something like this--what about using MPLS for setting up flows. A: BGP finite state machine is much simpler to follow and update. We'll go into coffee break now; BOFs start at 1645 hours Eastern time. SC elections, JUST DO IT!! PC nominations open for 3 more hours! 1800 hours in Regency for Bear and Gear. BOFs, Mobile Data Track, ISP Security BOF, and DNS BOF will be upstairs in DeSoto room. Tuesday we start at 0830 again with breakfast. For now, I head over to the DNS thingie BoF IPv6 and resolvers; how do we make it less painful? For most people, rolling out IPv6 can't break IPv4, and separate hostnames isn't scaleable long term. Per Google, 0.078% users are impacted by enabling quad A on machines. Assuming a user base of 600M that's 470K users that get broken, which isn't acceptable. Right now, in browsers, IPv4 fallback is on the order of 21 seconds to 181 seconds, which is for most SLA numbers considered "broken" Options? Don't roll out IPv6 prefer A over AAAA accept the breakage what about checking for working IPv6 connectivity before sending back AAAA record. Only way to know if user has working v6 transport is if the AAAA request came via IPv6 instead of IPv4 Recursive servers need to be set to only return AAAA *only* when request came in via IPv6; otherwise, return A record only. Now, auth DNS server only has to worry about IPv6 reachability to the recursive server. We've asked if ISC can write this; ISC has done this, it'll be in BIND 9.7; it'll be in a second beta coming out in early November; if you want to check it out, if you're on user list or beta list, you'll get notification; otherwise, check ISC site in early november and it should be there. Feature will be a knob you have to turn on. There's an additional check put in; if DNSSEC is set, it won't forge DNS answers unless there's a knob set "BREAKDNSSEC" that you can turn on, the knob is going to be very well documented. But if you've gone through the work of setting up DNSSEC, you should know how to troubleshoot it yourself. This should be be set up for resolvers facing customers, not for internal services that have odd configurations. What about having an ACL for controlling behaviour for different subnets? If they fit in a view statement, you already have that capability. Will this be available within a view? Yes, you can do it there. But the ACL idea is interesting, and could be better than pushing people towards views. This really goes on the recursive side. We need to try to convince ISPs to use these options. If a request comes from a 6to4 address; the source is a 6to4 address; do you respond with AAAA or not. How about ACLs with flexibility to see if it's over v4 but from a 6to4 address to send different responses. A simple default policy is good, but the flexibility is good for more experienced sites. Simple on-or-off knob is in 9.7b2; more granular control will be needed for later versions... what about 6rd? They would get no AAAA results in that scenario. We might need a DNSv6 option for DHCPv4 which would be able to give back the v6 DNS servers. Should we put together an information draft for IETF; we can draft one up, so the three of them should talk; Igor Gashinksi, Yahoo, Larissa Shapiro, ISC, Alain Durand, Comcast OARC meeting, Beijing, Jason Fesler will be there to talk about it. ISOC meeting in Paris next week, we'll be there to talk about it as well. Internet2 joint techs talked about it as well. General consensus is that this is a necessary evil hack. If we can get it working with 6rd, it'll be an interesting working solution to a common problem. What about shoving JavaScript code into web pages to report DNS lookups back via REST infrastructure to get an idea what the types of breakage. OS, browser, IP, and which test cases break or not. We could do a series of test queries, and see which ones break or not. Give A Give AAAA Result of the query comes into the beacon server, so we can see if they saw the reply or not. It would be better for the javascript to reply back with what *it* saw, as well as see what the server log sees. There's some javascript coding challenges with collecting this data. If we can at least break it down to 3 buckets 6to4 teredo native it would help really pin down where the breakage. Do note that the percentage shown wasn't Yahoo data, that was Google's data, so we don't have that breakdown ourselves. Would going to AS level be too specific for people? We'd need to consider carefully privacy issues and anonymizing the data as per our privacy rules. What about running an experiment in partnerships for specific ASNs? Point is, this is coming out, do share the data, this will be going into mainline code release. It's opt-in, defaulted off. The *actual* names for the config options are... This will apply to just the RR set, not the glue set; if glue returns AAAA, it'll still come back intact. The tests are really testing recursive lookup server to the last proxy device in front of the client. But what if the recursive server to auth server breakage happens? If the recursive server lookup side, can we turn the knob on in the other direction? This is an interesting challenge; we'll have to see how much additional work this will need, and how much additional funding will be needed to cover for it. ISC will...look into the feasability of doing that. The IETF draft cutoff is tonight for Paris, so maybe it'll be done for the Anaheim one, at which point we'll have working code out there, and a bit more time for writing the draft. We wrap up the BOF at 1724 hours Pacific time. (what about a switch for auth servers that allows for turning off "don't send AAAA records to ZZZZZ"?) ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 21, Issue 72 ************************************* From leigh.porter at ukbroadband.com Mon Oct 19 17:06:17 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 19 Oct 2009 23:06:17 +0100 Subject: Webcasts of NANOG47 References: <4ADCC6AE.7070107@justinshore.com> Message-ID: Hey, I don't know for sure but I think only the Grand Room is televised. Get somebody there with a webcam to do ustream.tv or livestream.com or whatever ;-) -- Leigh -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Mon 10/19/2009 9:06 PM To: NANOG Subject: Webcasts of NANOG47 Does anyone know if there will be video streams of the events from rooms other than what's in the Grand room? For example I would like to see the ISP Security Track BOF or the one tomorrow on Peering. I don't see a way to select those specific feeds though. Thanks Justin From wbailey at gci.com Mon Oct 19 17:08:57 2009 From: wbailey at gci.com (Warren Bailey) Date: Mon, 19 Oct 2009 14:08:57 -0800 Subject: Webcasts of NANOG47 Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D1089710F8@DTN1EX01.gci.com> Or just fly out ;) lol ----- Original Message ----- From: Leigh Porter To: Justin Shore ; NANOG Sent: Mon Oct 19 14:06:17 2009 Subject: RE: Webcasts of NANOG47 Hey, I don't know for sure but I think only the Grand Room is televised. Get somebody there with a webcam to do ustream.tv or livestream.com or whatever ;-) -- Leigh -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: Mon 10/19/2009 9:06 PM To: NANOG Subject: Webcasts of NANOG47 Does anyone know if there will be video streams of the events from rooms other than what's in the Grand room? For example I would like to see the ISP Security Track BOF or the one tomorrow on Peering. I don't see a way to select those specific feeds though. Thanks Justin From justin at justinshore.com Mon Oct 19 17:12:13 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 19 Oct 2009 17:12:13 -0500 Subject: Webcasts of NANOG47 In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D1089710F8@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D1089710F8@DTN1EX01.gci.com> Message-ID: <4ADCE43D.4010002@justinshore.com> I'd love to! However it's sometimes hard enough getting funds allocated for training events. Industry meetings aren't the easiest thing to convince people to let you attend... :-( Justin Warren Bailey wrote: > Or just fly out ;) lol > > > > ----- Original Message ----- > From: Leigh Porter > To: Justin Shore ; NANOG > Sent: Mon Oct 19 14:06:17 2009 > Subject: RE: Webcasts of NANOG47 > > > Hey, > > I don't know for sure but I think only the Grand Room is televised. > > Get somebody there with a webcam to do ustream.tv or livestream.com or > whatever ;-) From tom at dyn.com Mon Oct 19 17:15:43 2009 From: tom at dyn.com (Tom Daly) Date: Mon, 19 Oct 2009 18:15:43 -0400 (EDT) Subject: Webcasts of NANOG47 In-Reply-To: <29129279.245191255990498956.JavaMail.root@mail.corp> Message-ID: <28797723.245211255990543668.JavaMail.root@mail.corp> Hi Folks, Here's the skinny: Sunday tutorials were not live broadcast, but were recorded, and will be encoded and placed online shortly after the meeting. The General Session from Monday and Tuesday was/will be broadcasted live. Also, Dani Rosiman's talk on Tuesday on the BGP Metric System will be broadcasted. The ISP Security Track and Peering Track are not broadcast live, no recorded. Regards, Tom Daly ----- "Warren Bailey" wrote: > Or just fly out ;) lol > > > > ----- Original Message ----- > From: Leigh Porter > To: Justin Shore ; NANOG > Sent: Mon Oct 19 14:06:17 2009 > Subject: RE: Webcasts of NANOG47 > > > Hey, > > I don't know for sure but I think only the Grand Room is televised. > > Get somebody there with a webcam to do ustream.tv or livestream.com or > whatever ;-) > > -- > Leigh > > > -----Original Message----- > From: Justin Shore [mailto:justin at justinshore.com] > Sent: Mon 10/19/2009 9:06 PM > To: NANOG > Subject: Webcasts of NANOG47 > > Does anyone know if there will be video streams of the events from > rooms > other than what's in the Grand room? For example I would like to see > > the ISP Security Track BOF or the one tomorrow on Peering. I don't > see > a way to select those specific feeds though. > > Thanks > Justin From adrian at creative.net.au Mon Oct 19 18:08:07 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 20 Oct 2009 07:08:07 +0800 Subject: Science vs. bullshit In-Reply-To: References: Message-ID: <20091019230807.GK18551@skywalker.creative.net.au> On Mon, Oct 19, 2009, Patrick W. Gilmore wrote: > Corner cases like the one above are barely noise, so the curve it > still valid. Strictly speaking, with the subject of "Science vs bullshit", you and msa have named a hypothesis, no? Can either of you think of a way to disprove that, and if so, where's your data? :) Adrian From mike.lyon at gmail.com Mon Oct 19 18:26:44 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 19 Oct 2009 16:26:44 -0700 Subject: Any Google Mail admins on the list? Message-ID: <1b5c1c150910191626k6b99b07fna20608bbe4c628e0@mail.gmail.com> Howdy All, Trying to resolve a possible Google Mail blockage from a certain domain. Would like to check to see if you are blocking this domain or not. If you are with google and could help, please hit me up off-list. Cheers, Mike From cowie at renesys.com Mon Oct 19 18:59:44 2009 From: cowie at renesys.com (Jim Cowie) Date: Mon, 19 Oct 2009 19:59:44 -0400 Subject: Science vs. bullshit In-Reply-To: References: Message-ID: <6762a99d0910191659q765fe7a2s489f2ceb25dbe127@mail.gmail.com> Randy's right that it can be somewhat difficult to agree on a single methodology for generating accurate assessments of how many transit providers a particular network uses at a particular moment in time. There are at least two knobs to turn: how long you integrate updates (we like to use at least 24 hours of continuous time in order to flush out backup routes, but it's sensible to look for weeks or longer to get the real rarities to show their heads), and how much peer diversity you require in order to call a provider relationship 'globally visible transit' for a given prefix (I used 50+ peers as a rough rule of thumb, but you can pick lower/higher numbers and get arguably meaningful answers). It's like asking, "how big is the global routing table .. REALLY?" Depends on how you count. The thing about the data I presented, however, is that it is _differential_ ... it says "set your knobs, look at four days over four years, and let's see if the migration among populations seems consistent." In fact, the recurrence is pretty stable -- the same percentage of people in "diversity class X" tend to end up in "diversity class Y" twelve months later, over multiple years, with small changes that we can identify as trends. This gives confidence that the knobs are set in such a way that they are achieving some meaningful classification of the prefix population. To Patrick's point, the shape of the curve tells us useful things, even if the precise boundaries among diversity classes can be drawn in subtly different ways. And that's exactly why we look for techniques that can give information about trends (for example, my point that some dual-homed ASNs appear to be postponing their decision to attain higher degrees of multihoming) even in the presence of some classification uncertainty at the single-prefix level. I'm glad to have sparked so much excitement with a 10-minute talk. Imagine if I had dragged it out to 30 minutes! cheers, ---jim On Mon, Oct 19, 2009 at 4:05 PM, Patrick W. Gilmore wrote: > Lightning talk followup because I want to make sure there was not a > miscommunication. A two sentence comment at the mic while 400+ of your > not-so-close friends are watching does not a rational discussion make. > > The talk in question: > > < > http://nanog.org/meetings/nanog47/presentations/Lightning/Cowie_Recession_lightning_N47.pdf > > > > The disagreement is whether Renesys can reliably find out how many transit > providers an AS has. Remember, we are discussing transit providers here, > not peers. > > My point is if an AS has _transit_, then it must be visible in the global > table (assuming a reasonably large set of vantage points), or it would not > be transit. Of course, this is not perfect, but it is a pretty close > approximation for fitting curves over 10s of 1000s of ASes. So things like > "I have two transit providers, and one buys transit from the other" is a > small number and not relevant to fitting curves. (It also means you are an > idiot, or in a corner of the Internet where you should probably be > considered as having only one provider.) > > Majdi has pointed out other corner cases where transit is not viewable > through systems like Rensys. For instance, announcing prefixes to Provider > 2 with a community to local-pref the announcement below peer routes. That > means only one transit is visible in BGP data. > > There were several reasons some of us did not think edge cases like this > were important. For instance, Renesys keeps -every- update ever, so if > Provider 1 ever flaps, Rensys will see Provider 2. Also, when looking for > the number of providers, a "backup path" may not be relevant since no > packets take that path. > > More importantly, I thought the point of the talk was to show that the > table was growing during the recession and people were still getting more > providers. The result is a curve, not a hard-and-fast number. Corner cases > like the one above are barely noise, so the curve it still valid. > > It is true that finding peering edges with things like route-views is > problematic at best, so finding ASes with one transit plus peering might be > problematic. But since I do not think that was the point of the talk, I do > not consider that problem. > > > If anyone who still thinks the problems with finding transit edges somehow > make the talk 'bullshit' could clarify their position, I would be grateful. > > -- > TTFN, > patrick > > > From mpetach at netflight.com Mon Oct 19 20:22:39 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 19 Oct 2009 18:22:39 -0700 Subject: IPv6 Allocations In-Reply-To: <4ADCCACE.6060509@viagenie.ca> References: <4ADCCACE.6060509@viagenie.ca> Message-ID: <63ac96a50910191822r27b011dh633f661527f7ed5c@mail.gmail.com> On Mon, Oct 19, 2009 at 1:23 PM, Simon Perreault < simon.perreault at viagenie.ca> wrote: > Esposito, Victor wrote, on 2009-10-19 16:01: > > Since there is a lot of conversation about IPv6 flying about, does > > anyone have a document or link to a good high level allocation structure > > for v6? > > See RFC 3531 and here: > > http://www.ipv6book.ca/allocation.html > > Simon > I'm sure I'm just dumb, but no matter what numbers I put into that tool, it only spits out a series of /32s on the HTML output. That doesn't seem terribly useful, as most of us aren't going to be allocating multiple /32s, we'll be splitting up a single /32 into smaller bits. Matt From cordmacleod at gmail.com Mon Oct 19 20:27:06 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Mon, 19 Oct 2009 18:27:06 -0700 Subject: IPv6 Allocations In-Reply-To: <63ac96a50910191822r27b011dh633f661527f7ed5c@mail.gmail.com> References: <4ADCCACE.6060509@viagenie.ca> <63ac96a50910191822r27b011dh633f661527f7ed5c@mail.gmail.com> Message-ID: <10147BC2-C742-4B45-82EA-B7275D3DB5FE@gmail.com> The tool is aware of the prefix length you insert. So instead of /32, put /64 or /48 etc. On Oct 19, 2009, at 6:22 PM, Matthew Petach wrote: > On Mon, Oct 19, 2009 at 1:23 PM, Simon Perreault < > simon.perreault at viagenie.ca> wrote: > >> Esposito, Victor wrote, on 2009-10-19 16:01: >>> Since there is a lot of conversation about IPv6 flying about, does >>> anyone have a document or link to a good high level allocation >>> structure >>> for v6? >> >> See RFC 3531 and here: >> >> http://www.ipv6book.ca/allocation.html >> > >> Simon >> > > I'm sure I'm just dumb, but no matter what numbers I put into that > tool, it only spits out a series of /32s on the HTML output. That > doesn't seem terribly useful, as most of us aren't going to be > allocating > multiple /32s, we'll be splitting up a single /32 into smaller bits. > > Matt From mpetach at netflight.com Mon Oct 19 20:46:59 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 19 Oct 2009 18:46:59 -0700 Subject: Maximum devices in OSPF area 0 In-Reply-To: <75cb24520910190852j79f87836ya18b84854096440f@mail.gmail.com> References: <101360.13674.qm@web53608.mail.re2.yahoo.com> <75cb24520910190852j79f87836ya18b84854096440f@mail.gmail.com> Message-ID: <63ac96a50910191846ua21fe8fg3a2a9727cf6fd620@mail.gmail.com> On Mon, Oct 19, 2009 at 8:52 AM, Christopher Morrow wrote: > On Mon, Oct 19, 2009 at 11:39 AM, Serge Vautour > wrote: > > Hello, > > > > We are looking to deploy a greenfield MPLS network with OSPF as the IGP. > I'm told > > OSPF areas don't play well with OSPF TED. For this reason, we are looking > at using > > you said .. greenfield.. why use OSPF? > > Yet another vote in favour of doing IS-IS if you're going to do a greenfield build; it'll make your IPv6 native rollout go *so* much more smoothly (and you *are* planning for IPv6 now, since it's a greenfield rollout, right? Matt From nonobvious at gmail.com Mon Oct 19 21:02:34 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 19 Oct 2009 19:02:34 -0700 Subject: ISP customer assignments In-Reply-To: <4AD4A3F9.6010904@justinshore.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> Message-ID: <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> If you've got an addressing system with enough bits that you don't have to start stealing them, it makes sense to pick some boundary length between our-problem : their-problem 128 bits is long enough, and changing protocols is nasty enough, that it should let you Never Have To Do It Again. Originally with IPv6, the boundary was a nice round 64 bits, with the ISP on the network side and MAC48-based autoaddressing on the user side, with the user side looking suspiciously similar to Novell Netware and giving ~64K subnets, and this was back before DHCP had taken over the world and it was expected that all kinds of weird little toasters would be using IPv6. But some relatively sensible people proposed using the (ugly) EUI-64 64-bit MAC, because they Never Wanted To Have To Do This Again Either. And unfortunately, because it's a good enough idea to be worth accepting, it pushes the network boundary somewhat to the left, because it's pretty obvious that an average household may have multiple devices that want to autoconfigure themselves, so you probably will end up needing multiple subnets. And unfortunately, there's no obviously correct boundary, and no particular reason for all ISPs to use the same boundary, so there are endless arguments about it on NANOG and elsewhere. In general, /48's big enough for most large complex businesses (except ISPs), and /60's more than big enough for a household and for many small businesses, but we've got enough bits that it's worth using octet-aligned addresses, so /56 is the magic number for them, except at ISPs that simply don't want to bother giving out anything except /48s. There may be special cases for assigning /64s to end users, such as IPv6-equipped cell phones, but that's a matter for specialized carriers to provide, or for internal network managers at enterprises. And if you're big enough to get Provider Independent Address Space and an AS#, you're big enough to have a /48 of your own. Now, IPv6 was supposed to allow the development of other indistinguishable-from-magically advanced technology, such as getting rid of the growth of routing tables by convincing everybody to be happy with hierarchically assigned provider-aligned address space, and unfortunately that hasn't matched the needs of businesses, which need multihoming for reliability (so they'll be non-provider-aligned for at least n-1 of their ISPs), plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. So that problem shows no sign of going away (in spite of shim6..) From nanog at daork.net Mon Oct 19 21:07:39 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 20 Oct 2009 15:07:39 +1300 Subject: ISP customer assignments In-Reply-To: <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> Message-ID: On 20/10/2009, at 3:02 PM, Bill Stewart wrote: > plus want the ability to take their address > space with them when they change ISPs (because there are too many > devices and applications that insist on having hard-coded IP addresses > instead of using DNS, and because DNS tends to get cached more often > than you'd sometimes like. That's why we have Unique Local Addresses. -- Nathan Ward From bmanning at vacation.karoshi.com Mon Oct 19 21:10:16 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Oct 2009 02:10:16 +0000 Subject: ISP customer assignments In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> Message-ID: <20091020021016.GA2718@vacation.karoshi.com.> On Tue, Oct 20, 2009 at 03:07:39PM +1300, Nathan Ward wrote: > On 20/10/2009, at 3:02 PM, Bill Stewart wrote: > > >plus want the ability to take their address > >space with them when they change ISPs (because there are too many > >devices and applications that insist on having hard-coded IP addresses > >instead of using DNS, and because DNS tends to get cached more often > >than you'd sometimes like. > > That's why we have Unique Local Addresses. > but Nathan, they are only statistically unique. --bill From nanog at daork.net Mon Oct 19 21:12:11 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 20 Oct 2009 15:12:11 +1300 Subject: ISP customer assignments In-Reply-To: <20091020021016.GA2718@vacation.karoshi.com.> References: <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <20091020021016.GA2718@vacation.karoshi.com.> Message-ID: <1E879B18-DE73-46E2-86E7-3BBB2C609E65@daork.net> On 20/10/2009, at 3:10 PM, bmanning at vacation.karoshi.com wrote: > On Tue, Oct 20, 2009 at 03:07:39PM +1300, Nathan Ward wrote: >> On 20/10/2009, at 3:02 PM, Bill Stewart wrote: >> >>> plus want the ability to take their address >>> space with them when they change ISPs (because there are too many >>> devices and applications that insist on having hard-coded IP >>> addresses >>> instead of using DNS, and because DNS tends to get cached more often >>> than you'd sometimes like. >> >> That's why we have Unique Local Addresses. >> > > but Nathan, they are only statistically unique. Sure, but I don't think that changes my point. Also if you want to increase your chances of uniqueness (which are already pretty good if you're not using subnet 0 or 1 or whatever) you can jump on to somewhere on the sixxs site and announce that you're using a specific ULA prefix. -- Nathan Ward From mpetach at netflight.com Mon Oct 19 21:18:21 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 19 Oct 2009 19:18:21 -0700 Subject: IPv6 Allocations In-Reply-To: <10147BC2-C742-4B45-82EA-B7275D3DB5FE@gmail.com> References: <4ADCCACE.6060509@viagenie.ca> <63ac96a50910191822r27b011dh633f661527f7ed5c@mail.gmail.com> <10147BC2-C742-4B45-82EA-B7275D3DB5FE@gmail.com> Message-ID: <63ac96a50910191918o1bd2c7d3sa2a7842f3a243cbc@mail.gmail.com> On Mon, Oct 19, 2009 at 6:27 PM, Cord MacLeod wrote: > The tool is aware of the prefix length you insert. So instead of /32, put > /64 or /48 etc. Ah! So, the instructions are wrong; instead of saying "1. Enter the start prefix (i.e. 2001:db8::/32)." it should say "1. Enter the start prefix (i.e. 2001:db8::/40)." since the example is talking about allocating /40's for downstreams. Thanks--now it works a bit more coherently. :) Matt From kizmet at kizmet.id.au Mon Oct 19 23:30:50 2009 From: kizmet at kizmet.id.au (Cody Appleby) Date: Tue, 20 Oct 2009 15:30:50 +1100 Subject: Hotmail/MSN Issues Message-ID: Can a Hotmail/MSN admin please contact me off-list. From bbillon-ml at splio.fr Tue Oct 20 01:11:32 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Tue, 20 Oct 2009 08:11:32 +0200 Subject: Hotmail/MSN Issues In-Reply-To: References: Message-ID: <4ADD5494.1000007@splio.fr> That doesn't work that way with them, please check my reply on mailop ml for further information. Cody Appleby a ?crit : > Can a Hotmail/MSN admin please contact me off-list. > From bbillon-ml at splio.fr Tue Oct 20 01:15:47 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Tue, 20 Oct 2009 08:15:47 +0200 Subject: Any Google Mail admins on the list? In-Reply-To: <1b5c1c150910191626k6b99b07fna20608bbe4c628e0@mail.gmail.com> References: <1b5c1c150910191626k6b99b07fna20608bbe4c628e0@mail.gmail.com> Message-ID: <4ADD5593.4070501@splio.fr> Please tell me if you get any feedback, as far as I know Gmail admins are not more connected to the world than hotmail's. Still, Gmail relies on domainkey/dkim, which could save your day. Mike Lyon a ?crit : > Howdy All, > > Trying to resolve a possible Google Mail blockage from a certain domain. > Would like to check to see if you are blocking this domain or not. If you > are with google and could help, > please hit me up off-list. > > Cheers, > Mike > From leland at taranta.discpro.org Tue Oct 20 01:18:43 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Tue, 20 Oct 2009 08:18:43 +0200 Subject: Cisco VSS-1440 migration query In-Reply-To: References: <1255964840.6372.19.camel@leland-gandi> <1255974340.17380.3.camel@leland-gandi> Message-ID: <1256019523.4788.37.camel@leland-gandi> Thanks to all on this. I've pretty much mitigated this by creating a VSS-ized version of the interface configs (chassis/slot/port) which I can then re-inject back into the system config after conversion. Shame that switch1 keeps its config and simply renumbers the interfaces, but switch2 just says "I here am new" .. but oh well. Leland On Mon, 2009-10-19 at 17:04 -0400, Mishka, Jason wrote: > > On Mon, 2009-10-19 at 13:06 -0400, Jason Giles wrote: > > >From my test, all physical interfaces configs on switch 2 are factory > defaulted and SVI interfaces deleted on switch 2 upon running the > conversion commands. > > When you convert to vss mode the interfaces are renamed. The interface > in switch 2 that was g1/1 becomes 2/1/1. Any configuration applied to > g1/1 will be rejected because that interface no longer exists. If you > intended to keep interface configuration, you will need to reapply that > to the new interface name. > > Jason From matthew at walster.org Tue Oct 20 03:51:42 2009 From: matthew at walster.org (Matthew Walster) Date: Tue, 20 Oct 2009 09:51:42 +0100 Subject: 109/8 - not a BOGON In-Reply-To: <20091010103159.GY3191@hezmatt.org> References: <20091010103159.GY3191@hezmatt.org> Message-ID: 2009/10/10 Matthew Palmer > A pingable address in the problem range would help people to quickly > evaluate whether they have a problem in their network or upstreams... > The router has the address "109.68.64.1" - saves giving out customer's IP. Does anyone have any recommendations for dealing with BOGON space that hasn't been defiltered by networks? Any ideas how to get people to update filter lists? Matthew Walster From shane at short.id.au Tue Oct 20 07:01:19 2009 From: shane at short.id.au (Shane Short) Date: Tue, 20 Oct 2009 20:01:19 +0800 Subject: 109/8 - not a BOGON In-Reply-To: References: <20091010103159.GY3191@hezmatt.org> Message-ID: I've found pinging a polite email to the whois contact on the ASN - sometimes- gives useful results, but not always. Be aware that you're not only dealing with router black-holes, but seemingly some people have applied bogon filtering to their BIND name servers also. If you can provide a non bogon IP within the same AS, it can be useful for the person at the other end-- shows them they have a problem. -Shane On 20/10/2009, at 4:51 PM, Matthew Walster wrote: > 2009/10/10 Matthew Palmer > >> A pingable address in the problem range would help people to quickly >> evaluate whether they have a problem in their network or upstreams... >> > > The router has the address "109.68.64.1" - saves giving out > customer's IP. > > Does anyone have any recommendations for dealing with BOGON space that > hasn't been defiltered by networks? Any ideas how to get people to > update > filter lists? > > Matthew Walster From randy at psg.com Tue Oct 20 09:36:10 2009 From: randy at psg.com (Randy Bush) Date: Tue, 20 Oct 2009 10:36:10 -0400 Subject: Science vs. bullshit In-Reply-To: <6762a99d0910191659q765fe7a2s489f2ceb25dbe127@mail.gmail.com> References: <6762a99d0910191659q765fe7a2s489f2ceb25dbe127@mail.gmail.com> Message-ID: > The thing about the data I presented, however, is that it is _differential_ > ... it says "set your knobs, look at four days over four years, and let's > see if the migration among populations seems consistent." as we discussed this morning, this has the problem of not knowing how much of the change is in the lens through which you are looking and how much is in that at which you are looking. bgp is way too damned good at information hiding. randy From twilde at cymru.com Tue Oct 20 09:46:04 2009 From: twilde at cymru.com (Tim Wilde) Date: Tue, 20 Oct 2009 10:46:04 -0400 Subject: 109/8 - not a BOGON In-Reply-To: References: <20091010103159.GY3191@hezmatt.org> Message-ID: <4ADDCD2C.9060906@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/2009 8:01 AM, Shane Short wrote: > I've found pinging a polite email to the whois contact on the ASN > -sometimes- gives useful results, but not always. > > Be aware that you're not only dealing with router black-holes, but > seemingly some people have applied bogon filtering to their BIND name > servers also. > > If you can provide a non bogon IP within the same AS, it can be useful > for the person at the other end-- shows them they have a problem. References to documents on bogon best practices are a good idea when trying to contact WHOIS contacts as well - our bogon reference page and the IANA IPv4 address space assignments page are probably good places to start on that: http://www.team-cymru.org/Services/Bogons/ http://www.iana.org/assignments/ipv4-address-space/ Shane makes a good point about BIND and other configs - we actually stopped including static bogons in our BIND and BGP/JunOS templates earlier this year because we found they were being used and not updated, despite our warnings not to do so. Best regards, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrdzSwACgkQluRbRini9tgJaACfRnjhFKCv7sKUuNc98r+sn0cG DDUAn2K5ASv8Pmi+UCbLw0NM6k64r+AF =Lo8x -----END PGP SIGNATURE----- From bburke at merit.edu Tue Oct 20 10:13:57 2009 From: bburke at merit.edu (Betty Burke) Date: Tue, 20 Oct 2009 11:13:57 -0400 (EDT) Subject: [NANOG-announce] 2009 Elections In-Reply-To: <1503217005.5336991256051549108.JavaMail.root@crono> Message-ID: <936160195.5337271256051637659.JavaMail.root@crono> Everyone: Hope all at NANOG47 in person or remote are enjoying a great Program!! A couple of reminders.... PC Nominations have closed. Merit is working to process the last minute nominations and acceptance. As soon we we catch up the information will be posted on the website. MLC Nominations continue. 2009 Election process closes at 9:15 Wednesday am. Please do support the process, it is your community... so VOTE! http://nanog.org/governance/elections/2009elections/ Lastly, we need your input, do take a moment and complete the survey! http://www.surveymonkey.com/s.aspx?sm=OGYmCMKmi88ROAl_2fPAlEHw_3d_3d All Best. Betty Merit and SC representative _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mpetach at netflight.com Tue Oct 20 12:08:41 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 20 Oct 2009 10:08:41 -0700 Subject: 2009.10.20 NANOG47 Day 2 notes, morning sessions Message-ID: <63ac96a50910201008n1afa0ba4rd806fe48c886c11c@mail.gmail.com> Here's my notes from this morning's sessions. :) Off to lunch now! Matt 2009.10.20 NANOG day 2 notes, first half Dave Meyer kicks things off at 0934 hours Eastern time. Survey! Fill it out! http://tinyurl.com/nanog47 Cathy Aaronson will start off with a rememberance of Abha Ahuja. She mentored, chaired working groups, she helped found the net-grrls group; she was always in motion, always writing software to help other people. She always had a smile, always had lots to share with people. If you buy a tee shirt, Cathy will match the donation. John Curran is up next, chairman of ARIN Thanks to NANOG SC and Merit for the joint meeting; Add your operator perspective! Vote today in the NRO number council election! You can vote with your nanog registration email. https://www.arin.net/app/election Join us tonight for open policy hour (this room) and happy hour (rotunda) Participate in tomorrow's IPv6 panel discussion and the rest of the ARIN meeting. You can also talk to the people at the election help desk. During the open policy hour, they'll discuss the policies currently on the table. And please join in the IPv6 panel tomorrow! If you can, stay for the ARIN meeting, running through Friday. This includes policy for allocation of ASN blocks to RIRs Allocation of IPv4 blocks to RIRs Open access to IPv6 (make barriers even lower) IPv6 multiple discrete networks (if you have non connected network nodes) Equitable IPv4 run-out (what happens when the free pool gets smaller and smaller!) Tomorrow's Joint NANOG panel IPv6--emerging success stories Whois RESTful web service Lame DNS testing Use of ARIN templates consultation process ongoing now; do we want to maintain email-based access for all template types? Greg Hankins is up next for 40GbE and 100GbE standards update--IEEE P802.3ba Lots of activity to finalize the new standards specs many changes in 2006-2008 as objectives first developed After draft 1.0, less news to report as task force started comment resolution and began work towards the final standard Finished draft 2.2 in august, crossing Is, dotting Ts Working towards sponsor ballot and draft 3.0 On schedule for delivery in June 2010 Copper interface moved from 10meter to 7meter. 100m on multimode, added 125m on OM4 fiber, slightly better grade. CFP is the module people are working towards as a standard. Timeline slide--shows the draft milestones that IEEE must meet. It's actually hard to get hardware out the door based around standards definitions. If you do silicon development and you jump in too fast, the standard can change under you; but if you wait too long, you won't be ready when the standard is fully ratified. July 2009, Draft 2 (2.2), no more technical changes, so MSAs have gotten together and started rolling out pre-standard cards into market. Draft 3.0 is big next goal, it goes to ballot for approval for final standards track. After Draft 3.0, you'll see people start ramping up for volume production. Draft 2.x will be technically complete for WG ballot tech spec finalized first gen pre-standard components have hit market technology demonstrations and forums New media modules: QSFP modules created for high density short reach interfaces (came from Infiniband) Used for 40GBASE-CR4 and 40GBASE-SR4 CXP modules proposed for infiniband and 100GE 12 channels 100GbE uses 10 of 12 channels used for 100GBASE-10 CFP Modules long reach apps big package used for SR4, LR4, SR10, LR4, ER4 about twice the size of a Xenpak 100G and 40G options for it. MPO/MTP cable multi-fiber push-on high-density fiber option 40GBASE-SR4 12 fiber MPO uses 8 fibers 100GBASE-SR10 24 fiber MPO cable, uses 20 fibers this will make cross connects a challenge Switches and Routers several vendors working on pre-standard cards, you saw some at beer and gear last night. Alcatel, Juniper First gen tech will be somewhat expensive and low density geared for those who can afford it initially and really need it. Nx10G LAG may be more cost effective higher speed interfaces will make 10GbE denser and cheaper Density improves as vendors develop higher capacity systems to use these cards density requires > 400Gbps/slot for 4x100GbE ports Cost will decrease as new technology becomes feasible. Future meetings September 2009, Draft 2.2 comment resolution Nov 2009 plenary Nov 15-20, Atlanta Draft 3.0 and sponsor ballot http://grouper.ieee.org/groups/802/3/ba/index.html You have to go to meeting to get password for the draft, unfortunately. Look at your roadmap for next few years get timelines from your vendors optical gear, switches, routers server vendors transport and IP transit providers, IXs Others? figure out what is missing and ask for it will it work with your optical systems what about your cabling infrastructure 40km 40GbE Ethernet OAM Jumbo frames? There's no 40km offering now; if you need it, start asking for it! Demand for other interfaces standard defines a flexible architecture, enables many implementations as technology changes Expect more MSAs as tech develops and becomes cost effective serial signaliing spec duplex MMF spec 25Gbps signalling for 100GbE backplane and copper apps Incorporation of Energy Efficient Ethernet (P802.3az) to reduce energy consumption during idle times. Traffic will continue to increase Need for TbE is already being discussed by network operations Ethernet will continue to evolve as network requirements change. Question, interesting references. Dani Roisman, PeakWeb RSTP to MST spanning tree migration in a live datacenter Had to migrate from a Per-vlan RSTP to MST on a highly utilized network So, minimal impact to a live production network define best practices for MST deployment that will yield maximal stability and future flexibility Had minimal reference material to base this on Focus on this is about real-world migration details read white papers and vendor docs for specs on each type. The environment: managed hosting facility needed flexibility of any vlan to any server, any rack each customer has own subnet, own vlan Dual-uplinks from top-of-rack switches to core. High number of STP logical port instances using rapid pvst on core Multiple VLAN*interface count = logical port instances Too many spanning tree instances for layer 3 core switch concerns around CPU utilization, memory, other resource exhaustion at the core. Vendor support: per-vlan STP Cisco: per-vlan is the default config, cannot switch to single-instance STP foundry/brocade offers per vlan mode to interoperate with cisco Juniper MX and EX offers vstp to interoperate Force10 FTOS Are we too spoiled with per-vlan spanning tree? don't need per-vlan spanning tree, don't want to utilize alternate path during steady-state since we want to guarantee 100% capacity during failure scenario options: collapse from per-vlan to single-instance STP Migrate to standards-based 802.1s MSTP (multiple spanning tree--but really going to fewer spanning trees!) MST introduces new configuration complexity all switches within region must have same vlan-to-mst mapping means any vlan or mst change must be done universally to all devices in site. issues with change control; all rack switches must be touched when making single change. Do they do one MST that covers all vlans? Do they pre-create instances? do all vendors support large instance numbers? No, some only support instances 1-16 Had to do migration with zero downtime if possible Used a lab environment with some L3 and L2 gear Found a way to get it down to one STP cycle of 45secs Know your roots! Set cores to "highest" STP priority (lowest value) Set rack switches to lower-than-default to ensure they never become root. Start from roots, then work your way down. MSTP runs RSTP for backwards compatability choose VLAN groups carefully. Instance numbering some only support small number, 1-16 starting point all devices running 802.1w core 1 root at 8192 core 2 root at 16384 You can pre-config all the devices with spanning tree mapping, but they don't go live until final command is entered Don't use vlan 1! set mst priority for your cores and rack switches. don't forget MST 0! vlan 1 hangs out in MST 0! First network hit; when you change core 1 to spanning mode mst step 2, core2 moves to mst mode; brief blocking moment. step 3; rack switches, one at a time, go into brief blocking cycle. Ongoing maintenance all new devices must be pre-configured with identical MST params any vlan to instance mapping changes, do to core 1 first no protocol for MST config propagation vtp follow-on? MST adds config complexity MST allows for great multi-vendor interoperability in a layer 2 datacenter only deployed a few times--more feedback would be good. Q: Leo Bicknell, ISC; he's done several; he points half rack switches at one core, other half at other core; that way in core failure, only half of traffic sloshes; also, on that way with traffic on both sides, failed links showed up much more quickly. Any device in any rack has to support any vlan is a scaling problem. Most sites end up going to Layer3 on rack switches, which scales much better. A: Running hot on both sides, 50/50 is good for making sure both paths are working; active/ standby allows for hidden failures. But since they set up and then leave, they needed to make sure what they leave behind is simple for the customer to operate. The Layer3 move is harder for managed hosting, you don't know how many servers will want in a given rack switch. Q: someone else comes to mic, ran into same type of issue. They set up their network to have no loops by design. Each switch had 4x1G uplinks; but when they had flapping, it tended to melt CPU. Vendor pushed them towards Layer3, but they needed flexibility for any to any. They did pruning of vlans on trunk ports; but they ended up with little "islands" of MST where vlans weren't trunked up. Left those as odd 'separate' root islands, rather than trying to fix them. A: So many services are built around broadcast and multicast style topologies that it's hard to mode to Layer3, especially as virtualization takes off; the ability to move instances around the datacenter is really crucial for those virtualized sites. David Maltz, Microsoft Research Datacenter challenges--building networks for agility brief characterization of "mega" cloud datacenters based on industry studies costs pain-points traffic pattern characteristics in data centers VL2--virtual layer 2 network virtualization uniform high capacity Cloud service datacenter 50k-200k servers scale-out is paramount; some services have 10s of servers, others 10s of 1000s. servers divided up among hundreds of services Costs for servers dominates datacenter cost: servers 45%, power ifrastructure 25%, maximiize useful work per dollar spent ugly secret: 10-30% CPU utilization considered "good" in datacenters servers not doing anything at all cause server are purchased rarely (quarterly) reassigning servers is hard every tenant hoards servers solution: more agility: any server, any service Network diagram showing L3/L2 datacenter model higher in datacenter, more expensive gear, designed for 1+1 redundancy, scale-up model, higher in model handles higher traffic levels. Failure higher in model is more impactful. 10G off rack level, rack level 1G Generally about 4,000 servers per L2 domain network pod model keeps us from dynamically growing/shrinking capacity VLANs used to isolate properties from each otehr IP addresses topologically determined by ARs Reconfig of IPs and vlan trunks is painful, error-prone, and takes time. No performance isolation (vlan is reachability isolation only) one service sending/receiving too much stomps on other services Less and less capacity available for each server as you go to higher levels of network: 80:1 to 240:1 oversubscriptions 2 types of apps: inward facing (HPC) and outward facing. 80% of traffic is internal traffic; data mining, ad relevance, indexing, etc. dynamic reassignment of servers and map/reduce style computations means explicit TE is almost impossible. Did a detailed study of 1500 servers on 79 ToR switches. Look at every 5-tuple for every connection. Most of the flows are 100 to 1000 bytes; lots of bursty, small traffic. But most bytes are part of flows that are 100MB are larger. Huge dichotomy not seen on internet at large. median of 10 flows per server to other servers. how volatile is traffic? cluster the traffic matrices together. IF you use 40-60 clusters, cover a day's worth of traffic. More clusters gives better fit. traffic patterns change nearly constantly. 80th percentile is 100s; 99 percentile is 800s server to server traffic matrix; most of the traffic is diagonal; servers that need to communicate tend to be grouped to same top of rack switch. but off-rack communications slow down the whole set of server communications. Faults in datacenter: high reliability near top of tree, hard to accomplish maintenance window, unpaired router failed. 0.3% of failure events knocked out all members of a network redundancy group typically at lower layers of network, but not always objectives: developers want network virtualization; want a model where all their servers, and only their servers are plugged into an ethernet switch. Uniform high capacity Performance isolation Layer2 semantics flat addressing; any server use any IP address broadcast transmissions VL2: distinguishing design principles randomize to cope with volatility separate names from locations leverage strengths of end systems build on proven network technology what enables a new solution now? programmable switches with high port density Fast, cheap, flexible (broadcom, fulcrum) 20 port 10G switch--one big chip with 240G List price, $10k small buffers (2MB or 4MB packet buffers) small forwarding table; 10k FIB entries flexible environment; general purpose network processor you can control. centralized coordination scale-out datacenters are not like enterprise networks centralized services already control/monitor health and role of each server (Autopilot) Centralized control of traffic Clos network: ToR connect to aggs, aggs connect to intermediate node switches; no direct cross connects. The bisection bandwidth between each layer is the same, so there's no need for oversubscription You only lose 1/n chunk of bandwidth for a single box; so you can have automated reboot of a device to try to bring it back if it wigs out. Use valiant load balancing every flow is bounced off a random intermediate switch provably hotspot free for any admissable traffic matrix works well in practice. Use encapsulation on cheap dumb devices. two headers; outer header is for intermediate switch, intermediate switch pops outer header, inner header directs packet to destination rack switch. MAC-in-MAC works well. leverage strength of endsystems shim driver at NDIS layer, trap the ARP, bounce to VL2 agent, look up central system, cache the lookup, all communication to that dest no longer pays the lookup penalty. You add extra kernel drivers to network stack when you build the VM anyhow, so it's not that crazy. Applications work with application addresses AAs are flat names; infrastructure addresses invisible to apps How to implement VLB while avoiding need to update state to every host on every topology change? many switches are optimized for uplink passthrough; so it seems to be better to bounce *all* traffic through intermediate switches, rather than trying to short-circuit locally. The intermediate switches all have same IP address, so they all send to the same intermediate IP, it picks one switch. You get anycast+ECMP to get fast failover and good valiant load balancing. They've been growing this, and found nearly perfect load balancing. All-to-all shuffle of 500MB shuffle among 75 servers; get within 94% of perfect balancing; they charge for the extra overhead for extra headers. NICs aren't entirely full duplex; about 1.8Gb not 2Gb bidrectional. Provides good performance isolation as well; as one service starts up, it has no impact on the service being running steady state. VLB does as well as adaptive routing (TE using oracle) on datacenter traffic worst link is 20% busier with VLB; median is same. And that's assuming perfect knowledge of future traffic flows. Related work: OpenFlow wow that went fast! Key to economic data is agility! any server any service network is largest blocker right network model to create is virtual layer 2 per service VL2 uses: randomization name-location separation end systems Q: Joe Provo--shim only applied to intra-datacenter traffic; external traffic is *NOT* encapsulated? A: Yes! Q: This looks familiar to 802.1aq in IEEE; when you did the test case, how many did you look at moving across virtualized domains? A: because they punt to centralized name system, there is no limit to how often servers are switched, or how many servers you use; you can have 10 servers or 100,000 servers; they can move resources on 10ms granularity. Scalability is how many servers can go into VL2 "vlan" and update the information. In terms of number of virtual layer 2 environments, it's looking like 100s to 1000s. IEEE is looking at MAC-in-MAC for silicon based benefits; vlans won't scale, so they use 802.1h header, gives them 16M possibility, use IS-IS to replace spanning tree. Did they look at moving entire topologies, or just servers? They don't want to move whole topology, just movement in the leaves. Todd Underwood, Google; separate tenants, all work for the same company, but they all have different stacks, no coordination among them. this sounds like a competing federation within the same company; why does microsoft need this? A: If you can handle this chaos, you can handle anything! And in addition to hosting their own services, they also do hosting of other outsourced services like exchange and sharepoint. Microsoft has hundreds of internal properties essentially. Q: this punts on making the software side working together, right? Makes the network handle it at the many to many layer. Q: Dani, Peakweb--how often is the shim lookup happening, is it start of every flow? A: Yes, start of every flow; that works out well; you could aggregate, have a routing table, but doing it per dest flow works well. Q: Is it all L3, or is there any spanning tree involved? A: No, network is all L3. Q: Did you look at woven at all? A: Their solution works to about 4,000 servers, but it doesn't scale beyond that. Break for 25 minutes now, 11:40 start time. We'll pop in a few more lightning talks. Somebody left glasses at beer and gear, reg desk has them. :) Break now! Vote for SC members!! Next up, Mirjam Kuhne, RIPE NCC, RIPE Labs, new initiative of RIPE NCC First there was RIPE, the equivalent of NANOG, then NCC came into existence to handle the meeting cordination, registrar, handled mailing lists, etc. RIPE Labs is a website, and a platform and a tool for the community You can test and evaluate new tools and prototypes contribute new ideas why RIPE labs? faster, tighter innovation cycle provide useful prototypes to you earlier adapt to the changing environment more quickly closer involvement of the community openness make feedback and suggestions faster and more effective http://labs.ripe.net/ many of the talks here are perfect candidates for material to post on labs, to get feedback from your colleagues, get research results, post new findings. How can it benefit you? get involved, share information, discover others working on similar issues, get more exposure. Few rules: free and civil discussion between individuals anyone can read content register before contributing no service guarantee content can disappear based on community feedback legal or abuse issues too little resources What's on RIPE Labs? DNS Lameness measurement tool REX, the resource explorer Intro to internet number resource database IP address usage movies 16-bit ASN exhaustion data NetSent next gen information service Please take a look and participate! mir at ripe.net or labs at ripe.net Q: Cathy Aaronson notes that ISP security BOF is looking for place to disseminate information; but they should probably get in touch with you! Kevin Oberman is up next, from ESnet DNSSec Basics--don't fear the signer! why you should sign your data sooner rather than later this is your one shot to experiment with signing when you can screw up and nobody will care! later, you screw up, you disappear from the net. DNSSEC uses public crypto, similar to SSH DNSSEC uses anchor trust system, NOT PKI! No certs! Starts at root, and traces down. Root key is well known Root knows net key net knows es key es key signs *.es.net Perfect time to test and experiment without fear. Once you publish keys, and people validate, you don't want to experiment and fail--you will disappear! signing your information has no impact. Only when you publish your keys will it have impact. It is REALLY getting closer! Root will be signed 2010 Org and Gov are signed now com and net should be signed 2011 Multiple ccTLDs are signed; .se led the way, and have lots of experience; only once did they disappear, and that was due to missing dot in config file; not at all DNSSEC related. Registration issues still being worked on transfers are of particular concern an unhappy losing registrar could hurt you! Implementation Until your parent is ready Develop signing policies and procedures test, test, and test some more key re-signing key rolls management tools find out how to transfer the initial key to your parent (when parent decides) this is a trust issue--are you really "big-bank.com" If you're brave you can test validation (very few doing it--test on internal server first!!) -- if this breaks, your users will hurt (but not outside world) You can give your public keys to the DLV (or ITARs) this can hurt even more! (DLV is automated, works with BIND out of box, it's simpler, but you can chose which way to go) What to sign? Forward zone is big win reverse zone has less value may not want to sign some or all reverse or forward zones signing involves 2 types of keys ZSK, KSK, zone data key and key for sending keys to parent keys need to be rolled regularly if all keys and signatures expire, you lose all access, period. use two active keys data resigned by 2 newest keys sign at short intervals compared to expiration to allow time to fix things. new keys require parent to be notified. ksks are 'safe', not on network (rotate annually) Wait for BIND 9.7, it'll make your life much easier. There are commerical shipping products out there. Make sure there are at least 2 people who can run it, in case one gets hit by a bus. Read NIST SP800-81 SP800-81r1 is out for comment now Read BIND admin reference manual. Once in a lifetime opportunity!! Arien Vijin, AMS-IX an MPLS/VPLS based internet exchange (started off as a coax cable between routers) then became Cisco 5500 switch, AMSIX version 1, then 2001 went to Foundry switches at gig, version 2, version 3 has optical switching AMSIX version 3 vs AMSIX vs 4 June 2009 version 3 six sites, 2 with core switches in middle two star networks E, FE, GE, N*GE connections on BI-15K or RX8 switches N*10GE connextions resilient connected on switching platform (MLX16 or MLX32) two separate networks, one active at any moment in time. selection of active network by VSRP inactive network switch blocks ports to prevent loops photonic switch basically flips from one network to the other network. Network had some scaling problems at the end. Until now, they could always just buy bigger boxes in the core to handle traffic. Summer of 2009, they realized there was no sign of a bigger switch on the horizon to replace the core. core switches fully utilized with 10GE ports limits ISL upgrade no other switches on market platform failover introduces short link flap on all 10GE customer ports--this leads to BGP flaps with more 10G customers this becomes more of an issue AMSIX version 4 requirements scale to 2x port count keep resilience in platform, but reduce impact on failover (photonic switch layer) increase amount of 10G customer ports on access switches more local switching migrate to single architecture platform reduce management overhead use future-proof platform that supports 40GE and 100GE 2010/2011 fully standardized They moved to 4 central core switches, all meshed together; every edge switch has 4 links, one to each core. Photonic switch for 10G members, to have redundancy for customers. MPLS/VPLS-based peering platform scaling of core switches by adding extra switches in parallel 4 LSPs between each pair of access switches primary and secondary (backup) paths defined OSPF bfd for fast detection of link failures RSVP-TE signalled LSPs over predefined paths primary/secondary paths defined VPLS instance per vlan static defined VPLS peers (LDP signalle) load balanced over parallel LSPs over all core routers Layer 2 ACLs instead of port security manual adjustment for now (people have to call with new MAC addresses) Now they're P/PE routers, not core and access switches. ^_^; Resilience is handled by LSP switchover from primary to secondary path; totally transparent to access router. If whole switch breaks down, photonic switch is used to flip all customers to the secondary switch. So, they can only run switches at 50% to allow for photonic failover of traffic. How to migrate the platform without customer impact? Build new version of photonic switch control daemon (PSCD) No VSRP traps, but LSP state in MPLS cloud develop configuration automation describe network in XML, generate configuration from this Move non MPLS capable access switches behind MPLS routers and PXC as a 10GE customer connection Upgrade all non MPLS capable 10GE access switches to Brocade MLX hardware Define migration scenario with no customer impact 2 colocation sites only for simplicity double L2 network VSRP for master/slave selection and loop protection Move GE access behind PXC Migrate one half to MPLS/VPLS network Use PXC to move traffic to MPLS/VPLS network, test for several weeks. After six weeks, did the second half of the network. Now, two separate MPLS/VPLS networks. Waited for traffic on all backbone links to drop below 50%; split uplinks to hit all the core P devices; at that point, traffic then began using paths through all 4 P router cores. Migration--Conclusion Traffic load balancing over multiple core switches solves scaling issues in the core Increased stability of the platform Backbone failures are handled in the MPLS cloud and not seen at the access level Access switch failures are handled by PXC for single pair of switches only Operational experience BFD instability High LC CPU load caused BFD timeouts resolved by increasing timers Bug: ghost tunnels double "up" event for LSP path results in unequal load balancing should be fixed in next patch release multicast replication replication done on ingress PE, not in core only uses 1st link of aggregate of 1st LSP with PIM-SM snooping traffic is balanced over multiple links but has serious bugs bugfixes and load balancing fixes scheduled for future code releases. Ripe TTM boxes used to measure delay through the fabric, GPS timestamps. Enormous amounts of jitter in the fabric, delays up to 40ms in the fabric. Attempts from TTM, send 2 packets per minute, with some entropy change (source port changes) VPLS CAM age out after 60s for 24-port aggregates, traffic often passes a port without programming (CPU learning), high delay does not affect real-world traffic, hopefully will look to change CAM timing packet is claustraphobic? customer stack issue increased stability backbone failures handled by MPLS (not seen by customers) access switch failures handled for a single pair of switches now easier debugging of customer ports swap to different using glimmerglass config generation absolute necessity due to large size MPLS/VPLS configs Scalability (future options) bigger core more ports Some issues were found, but nothing that materially impacted customer traffic Traffic load-sharing over multiple links is good. Q: did anything change for gigE access customers, or are they still homed to one switch? A: nothing changed for gigE customers; glimmerglass is single-mode optical only, and they're too expensive for cheap GigE ports. no growth in 1G ports; no more FE ports; it's really moving to a 10G only fabric. RAS and Avi are up next Future of Internet Exchange Points Brief recap of history of exchange points 0th gen--throw cable over wall; PSI and Sprint conspire to bypass ANS; third network wanted in, MAE-East was born 1st commercial gen: FDDI, ethernet; multi-access, had head of line blocking issues. 2nd gen: ATM exchange points, from AADS/PBNAP to the MAEs, peermaker 3rd gen: GigE exchange points, mostly nonblocking internal switches, PAIX, rise of Equinix, LINX, AMS-iX 4th gen: 10G exchange points, upgrades, scale-out of existing IXes through 2 or 3 revs of hardware Modern exchange points are almost exclusively ethernet based; cheap, no ATM headaches 10GE and Nx10GE have been primary growth for years. Primarily flat L2 VLAN IX has IP block (/24 or so) each member router gets 1 IP any member can talk to any other via L2 some broadcast (ARP) traffic is needed well policed Large IX toplogy (LINX), running 8x10G or 16x10G trunks between locations What's the problem? L2 networks are easy to disrupt forwarding loops easy to create broadcast storms easy to create, no TTL takes down not only exchange point, but overwhelms peering router control plane as well today we work around these issues by locking down port to single MAC hard coded, or learn single MAC only single directly connected router port allowed careful monitoring of member traffic with sniffers good IXes have well trained staff for rapid responses Accountablility most routers have poor L2 stat tracking options in use: Netflow from member router no MAC layer info, can't do inbound traffic some platforms can't do netflow well at all SFlow from member routers or from IX operator still sampled, off by 5% or more MAC accounting from member router not available on vast majority of platforms today None integrate well with provider 95th percentile billing systems IXs are a poor choice for delivering billed services If you can't bill, you can't sell services over the platform. Security Anyone can talk to anyone else vulnerable to traffic injection poor accounting options make this hard to detect. when detected, easy to excuse less security available for selling paid transit Vulnerable to Denial of Service attacks can even be delivered from the outside world if the IX IP block is announced (as is frequently the case) Vulnerable to traffic interception, ARP/CAM manipulation Scalability difficult to scale and debug large layer 2 networks redundancy provided through spanning-tree or similar backup-path protocols large portions of network placed into blocking mode to provide redundancy. Managability poor controls over traffic rates and or QoS difficult to manage multi-router redundancy multiple routers see the same IX/24 in multiple places creates an "anycast" effect to the peer next-hops can result in blackholing if there is an IX segmentation or if there is an outage which doesn't drop link state. Other issues: inter-network jumbo-frames support is difficult no ability to negotiate per-peer MTU almost impossible to find common acceptable MTU for everyone service is constrained to IP only between two routers can't use for L2 transport handoff Avi talks about shared broadcast domain architecture on the exchange points today. Alternative is to use point to point virtual circuits, like the ATM exchanges. Adds overhead to setup process adds security, accountablity advantages Under ethernet, you can do vlans using 802.1q handoff multiple virtual circuit vlans. Biggest issue is limited VLAN ID space limited to 4096 possible IDs--12-bit ID space vlan stacking can scale this in transport but VLANs in this are global across system Means a 65 member exchange would completely fill up the VLAN ID with a full mesh. Traditional VLAN rewrites don't help either. Now, the exchange also has to be arbiter of all the VLANs used on the exchange. Many customers use layer3 switch/routers, so the vlan may be global across the whole device. To get away from broadcast domain without using strict vlans, we need to look at something else. MPLS as transport rather than Ethernet solves vlan scaling problems MPLS pseudowires are 32bits; 4billion VCs VLAN ID not carried with the packet, used only on handoffs VLAN IDs not a shared resource anymore Solves VLAN ID conflict problems members chose vlan ID per VC handoff no requirements for vlan IDs to match on each end solves network scaling problems using MPLS TE far more flexible than L2 protocols allows the IX to build more complex topologies, interconnect more locations, and more efficiently utilize resources. The idea is to move the exchange from L2 to L3 to scale better, give more flexibility, and do better debugging. You can get better stats, you can do parallel traffic handling for scaling and redundancy, and you see link errors when they happen, they aren't masked by blocked ports. Security each virtual circuit would be isolated and secure no mechanism for a third party to inject or sniff traffic significantly reduced DOS potential Accountability Most provide SNMP measurement for vlan subints Members can accurately meaasure traffic on each VC without "guestimation" capable of integrating with most billing systems. Now you can start thinking about selling transport over exchange points, for example Takes the exchange point out of the middle of the traffic accounting process. Services with more accountability and security, you can offer paid services support for "bandwidth on demand" now possible no longer constrained to IP-only or one-router-only can be used to connect transport circuits, SANs, etc. JumboFrame negotiation possible, since MTU is per interconnect Could interconnect with existing metro transport Use Q-in-Q vlan stacking to extend the network onto third party infrastructures imagine a single IX platform to service thousands of buildings! Could auto-negotiate VC setup using a web portal Current exchanges mostly work with careful engineering to protect the L2 core with limited locations and chassis siwth significant redundancy overhead for IP services only A new kind of exchange point would be better could transform a "peering only" platform into a new "ecosystem" to buy and sell services on. Q: Arien from AMS-IX asks about MTU--why does it matter? A: it's for the peer ports on both sides. Q: they offer private interconnects at AMS-IX, but nobody wants to do that, they don't want to move to a tagged port. They like having a single vlan, single IP to talk to everyone. A: The reason RAS doesn't do it is that it's limited in scale, you have to negotiate the vlan IDs with each side; there's a slow provisioning cycle for it; it needs to have same level of speed as what we're used to on IRC. Need to eliminate the fees associated with the VLAN setup, to make it more attractive. It'll burn IPs as well (though for v6, that's not so much of an issue) Having people peer with the route-server is also useful for people who don't speak the language who use the route servers to pass routes back and forth. The question of going outside amsterdam came up, but the member forbade it, so that it wouldn't compete with other transit and transport providers. But within a metro location, it could open more locations to participate on the exchange point. The challenge in doing provisioning to many locations is something that there is a business model for within the metro region. Anything else, fling your questions at lunch; return at 1430 hours! LUNCH!! And Vote! And fill out your survey!! From jmaimon at ttec.com Tue Oct 20 15:14:32 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 20 Oct 2009 16:14:32 -0400 Subject: streaming problems Message-ID: <4ADE1A28.40406@ttec.com> Or is it just me? None seem to come up now. From joelja at bogus.com Tue Oct 20 15:23:09 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 20 Oct 2009 13:23:09 -0700 Subject: streaming problems In-Reply-To: <4ADE1A28.40406@ttec.com> References: <4ADE1A28.40406@ttec.com> Message-ID: <4ADE1C2D.2040507@bogus.com> afternoon general session is done now. Joe Maimon wrote: > Or is it just me? > > None seem to come up now. > From jmaimon at ttec.com Tue Oct 20 15:42:59 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 20 Oct 2009 16:42:59 -0400 Subject: streaming problems In-Reply-To: <4ADE1C2D.2040507@bogus.com> References: <4ADE1A28.40406@ttec.com> <4ADE1C2D.2040507@bogus.com> Message-ID: <4ADE20D3.6090506@ttec.com> Its all good and working again, watching Dani now. Thanks Joel Jaeggli wrote: > afternoon general session is done now. > > Joe Maimon wrote: >> Or is it just me? >> >> None seem to come up now. >> > > From sil at infiltrated.net Tue Oct 20 16:40:39 2009 From: sil at infiltrated.net (J. Oquendo) Date: Tue, 20 Oct 2009 17:40:39 -0400 Subject: Amazon's EC2 Security contact Message-ID: <4ADE2E57.9030608@infiltrated.net> Hey all, apologies for shooting this on this list, but I've had greater success here. Anyone have a SECURITY contact for "Amazon Web Services, Elastic Compute Cloud, EC2" outside of the typical: whois -h whois.arin.net $THEIRSPACE|grep "@" I'm looking at a delicate situation here and would appreciate any OOB/non-tech-sup-spool-box contact. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From mpetach at netflight.com Tue Oct 20 18:09:41 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 20 Oct 2009 16:09:41 -0700 Subject: 2009.10.20 NANOG47 day 2, second half Message-ID: <63ac96a50910201609o1472d06do3ba9da6aff8d040b@mail.gmail.com> Here's my notes from the second half of the second day at NANOG, including the peering BoF and the ARIN open policy hour. Now for some dinner. ^_^; More on the morrow. Matt 2009.10.20 NANOG day 2 notes, second half FILL OUT YOUR SURVEY!! http://tinyurl.com/nanog47 VOTE!! http://bit.ly/nanogelect Kevin Epperson welcomes everyone back from lunch at 1432 hours Eastern time. Don't forget the survey and the voting! BJ Neal from FCC will talk about national broadband plan. Relax, he's not a lawyer, he's not here to regulate, he's here to get information from us. Looking to get input from some of the membership here at how they should look at traffic engineering on backhaul and shared portions of the network. In early 2009, President and Congress tasked FCC to put plan together for broadband access for all americans, focusing on rural and underserved areas. Feb 17, 2010 the plan is due before Congress. 3 basic components to BB team: deployment team: technology purposes, funding sources, policy levers national purpose: healthcare, hospitals, schools, adoption: what needs to be done to encourage adoption of BB technology for the underserved and unserved broadband plan is data driven. FCC looking for as much real world data as possible as inputs to the plan as possible. Need to make sure the plan addresses all three elements as much as possible, to be as complete as possible. On the adoption side, it may be that some people may have inside wire issues, may need education, may not be able to afford a computer to connect, etc. US has a complex mix of broadband assets DSL, cable, wireless, FTTp, power line networking on last mile Second mile access is copper Xport, fiber Xport, wireless point-to-point, hybrid copper/fiber middle mile access is dedicated internet access, ATM, frame relay, managed IP/MPLS/VPLS, dedicated private line, DS3, OCn, Traffic engineering on "shared" portions: how should BB team tihnk about traffic engineering, or sizing of the shared or "backhaul" portions of the network. Significant impact to the cost of a National BB network architecture. Obviously it is very important to size network properly. Possibly need an equivalent "erlang" model for public IP traffic mix; what is the formula for this? NANOG member's views on the traffic engineering and network dimensioning. Q: Randy Bush, IIJ; fun visiting third world country; in Tokyo, you just have fiber, and the last 100meters is 100baseT, and he can get 80mbits from Tokyo to westin Seattle. He has a third world connection in Seattle from a house there, he can get almost 600 from Seattle to Westin, costs 3x as much. How to do traffic engineering? Provision it, and you don't have to do traffic engineering. A: overprovisioning comes with significant cost, especially if that means deploying new fiber. Q: We said same thing about rural rollouts of telco; now, farms get upset at busy signals. Q: Igor from Yahoo notes that traffic engineering is wrong term; he really means how to plan how much to provision, not which pathways to send traffic along. A: He's looking for oversubscription ratio for a given set of users with a given set of applications along the backhaul to a public interconnection point. Q: In that case, pick a starting point, and then build to what the customers use, and bill them accordingly. A: FCC doesn't have any traffic numbers to look at, so they need a starting point. Q: RAS notes the backhaul from lower tier city to where you really want to go is really cheap and easy; most of the cost is last mile. So build backhaul with as much capacity as you need; the government is going to get bad deals no matter what anyhow. The vast majority of the cost really is the last mile. Q: Jay Moran, AOL, they're looking at many broadband proposals coming from various people. Just need to submit the questions to people who are sending out the VTOP applications. BGPbotz IM-based route view bot Manish Karir Route Views Generally web or telnet based provides a looking glass for BGP from different vantage points (routers) Disadvantages Have to remember telnet/web addresses route-server.ip.att.net route-views.ab.bb.telus.com "more" is a pain. BGPbotz is up on iM, you can type in similar commands to it. It'll give links back if the output is too long; output survives for an hour, then disappears. Commands: show ip bgp show bgp view (router) ipv6 ping traceroute aslookup whois grep Architecture Python chat protocols: AIM, Jabber(XMPP) single thread per user Results 400+ screen names from both protocols Results: "show ip bgp" was most popular command! Talk to BGPbotz AIM: bgpbotz Jabber: bgpbotz at jabber.research.merit.edu He shows a realtime demo of it Still looking for more views source available: http://bigbotz.merit.edu Q: Patrick, Akamai, would you do in-addr resolution on traceroutes? A: it really makes it slow; they wanted it to be pretty quick. Could take a while with long traceroutes. Q: Matt, Yahoo, could he add other messenger platforms like Yahoo or MSN? A: yes, if the module can provide a python interface, it can be plugged in. Geoff Sisson, Duane Wessels DNS OARC Root Zone historical trends NS records, A records, IPv6 AAAA records, TLDs. In the past year, breaking away from the trend of one AAAA per TLD. Interesting times for the DNS root. IPv6 Glue DNSSec New TLDs IDNs Also... Continued Anycast deployment continued increase in query rates. This study of root zone changes ICANN hired OARC to simulate changes to the root zone and explore how they affect: The size of the root zone Server response latency Server start and reload times Hardware: DNS OARC testbed 16 HP prliant DL140 G3 servers 4 3Ghz cores Software testing BIND 9.6.0P1, and NSD 3.2.1 Centos 5.3, FreeBSD 7.1 dnsperf, etc. Zone file configs 5 types of zone content unsigned, mostly v4 glue unsigned, v4 and v6 glue signed, v6 glue, 10% DS records signed, v6 glue, 50% DS records signed, v6 glue, 100% DS records five zone sizes 1K, 10K, 100K, 1M, 10M Memory usage How do root zone changes affect zone size and memory usage? Process memory usage measured with pmap. includes code memory and shared lib memory BIND increases at 10K to linear curve. smaller sizes have more overhead compared to entries. NSD, 32G RAM couldn't load 10M signed TLD zones. memory usage proportional to zone size signed zone uses twice as much memory. NSD needs more than 32G to hold 10M signed zone response latency how does latency of an L-root analog vary as function of zone size? BIND, unsigned zone, different sizes generally about a quarter ms. Performance does not change as zone size increases. NSD, similar graph, very consistent; NSD is slightly lower latency, .1ms BIND with signed zone, not as consistent; histograms drop consistently. He did cumulative distribution graph Only 70% of queries get answered within 4 seconds. NSD on signed zones, more consistent, but can't do 10M zones. CDF says similar cutoff for NSD; does a bit better. BIND performance is stable for all sizes of signed zones Some degredation at higher sized zones. BIND performance issue; only with NSEC; no problems with NSEC3 Only with a zone like the root which is likely to have a large number of glue owner names that get sorted between non-glue Only for a larger (ie 100K TLD) root zone Plenty of time until this fix will really be needed in production. shows example problematic zone...linear search that wasn't optimized as well. Task 3; start and reload times how does nameserver startup and reload vary over zone file size. Above 100k, takes noticeable load time; same for reload time. With 32G, they couldn't do a reload for BIND on 10M signed file Again, proportional to zone file size. bandwidth transfer size vs size on disk the cases below the 100% mark are NSD; it does name compresson in transfers, whereas BIND doesn't. For zone transfers of signed zones, takes much more bandwidth than doing simple rsync. zone transfers take much longer in face of packet loss. TCP usage to what extent will DNSSec increase TCP at roots? Current root zone became signed, looked at number of TCP retries; 0.3% of requests. Then they re-ran it with 1M TLDs in it, again rate of truncation increases response sizes, truncated vs non-truncated; EDNS512 vs larger EDNS size 650, 700, most was a bit more than 800. Root servers can expect about an order of magnitude increas in queries per second. A.root will go from 5/sec to 50/sec increasing number of TLDs apears to increase TCP traffic https://www.dns-oarc.net/files/rzaia/rzaia_report.pdf or email them at the addresses on the slides. Manish Karir, PE-ARP--port enhanced ARP for IPv4 address sharing. Can we put ARP to more use? Address the notion of what an endpoint identifier is; is it IP address, or MAC address? Looming IPv4 exhaustion IPv6 adoption is ramping up, but how long is enough? IPv4->CIDR->NAT-today->exhaustion->IPv6 moving from era of plenty to exhaustion what can we squeeze more utility out of? question long-standing ideas, scavenge more. Range of valid source ports; 65k; largely unused. at most, a few hundred used. end stations have 2 unique IDs; a MAC address and an IP. Can we use MAC as unique ID, and share IPs? It's the application/service that needs it, not the host itself. Can you hand single IP to multiple hosts if you limit port ranges? What needs to change on end host, on local network, in ARP tables, and support to find services on the network. PE-ARP components are on end host. port range management on end hosts. DHCP modified to hand ranges back. ARP protocol needs to be modified for getting port numbers in requests/responses Modified ARP table; in additional to MAC to IP, need port info in it as well Need DNS service for service location when port number is part of reply. SRV records are exactly what is needed in this case. testbed: All 3 nodes share same IP, with limited port ranges. outbound packets work, and internal cluster communications also work. Outbound is easy, it just has a smaller range of source ports. Inbound traffic does both IP address and port range lookup; running prototype on linux 2.6.29 kernel Mostly arp changes, some routing, forwarding code, to look at the port info coming in. works well in both directions, both scenarios, How to deploy this? router on the network edge: modified ARP on linux router kernel forwarding packets between interfaces Bridge solution. Don't rely on anyone else to get better utilization out of your IP ranges. Incremental deployment E2E consistency--still there Breaks one to one mapping of IP to ARP Single IP address can be shared thousands of times. Related work: CIDR NAT CGN-NAT++ Port scavaging resolution: conclusion: PE-ARP does break things based on old assumptions. It can buy more time for transitions Packets are not modified once they leave the end host. Scott Liebrand, Internap Sounds like openWRTg access point could be tweaked to do this; A: Yes, it's on the map to do it; currently, just for Linux kernel, but it's definitely doable! PEERING BOF: We have virtual martin in the room with us! If you haven't registered for the peering forum, register now--and if you've register, you can re-register again. It's at the Ford House--follow the red light, just past TGIFridays--might be buses here. Your reasons for being here are unique, there are two microphones here; try to get the mic before you ask your question. First peering meeting for him was 3 years ago, it's amazing what can happen in 3 years. Keep the discussion going--if we run over, we'll impinge on our drinking time. IPv4 peering personals (and IPv4 IPv6 dual-stack) Airstream: nmc at wins.net CHE and MIN he's in peeringdb, AS11796 eyeballs. Egecast: AS 15133 peering at edgecast.com, content/CDN network 100G network, open Stacy Hugehs nuspeering at neustar.biz AS12008 DNS provider, small but mighty! kloch at carpathiahost.com Carpathia hosting AS 29748 about 500G today, looking for AP, LA peers No backbone today; if you're in LA, ASH, it may be good to talk to him. Selective; would like to see a few hundred megs of traffic between us. Crossconnects questions and futures. Do you pre-wire your gear to panels? Does it help? Is there a need for LC crossconnect support? What about MTP? (from greg's presentation this morning) Is crossconnect delivery getting better? is polarity correct? do you get light readings when handed over How well do you manage your inventory of crossconnects? Most people don't prewire, it turns out. It doesn't help that much, and often has to be re-done anyhow. What about LC cross-connects; will people only do SC handoffs, or are more and more LC cross connects getting run? You can't field-terminate LCs; small, difficult. SC terminations can be done with c-core kits on site. If you replace stock panel, you can do SC panels with good density, and then you can get SC to LC patches. Field techs, every time they touch LC panels, everything gets messed around it. :/ What about MTP? You'll never get MTP field-terminated; so you'll never see cross connects over MTP; too hard to do it on custom length cables. Look at how fast VSR cables died off. You can't flip polarity on LC easily, either! Mike Hughes notes that if you flood wire, it's a short patch lead at each end; keeps the wiring mess minimized. At the end, it's up to you to patch it into your gear; you provide patch hood. Is cross-connect delivery getting better? Yes, but polarity is often wrong. With no light, it's a 50/50 guess on the facility people's end. If you leave light on, they can give light readings on the fiber. They often can't see the fiber at either end. In order to prevent the NOC from getting lots of alerts during turnups, some people leave the port down until the cross connect is done, to limit the errors from flapping. Photonic switch providers, can they monitor light levels for customers? They can, but don't. Different optics have different thresholds, though. How well do you manage your inventory of cross connects? Nobody has the full on database. Database that is mostly up to date. Database has some data, but is not very complete. If they have issues, they'll open a ticket Know they have cross connects, but that's it. Igor, peering at yahoo-inc.com AS10310 content heavy, peeringDB is updated with all v6 addresses. Scott Liebrand, Internap, AS22212 similar to igor; get sessions up, build it and they will come. PeeringDB is now up to date Guy Tal, LimeLight, AS22822 peering at llnw.com CDN, had v6 up for 4 months now; AMSIX for EU networks, rolling out across all exchanges, and will do PNIs. PeeringDB needs to be updated, but will be soon. Owen DeLong HE.net, peering at he.net, AS6939 Yes, they do peer, it's an open peering policy, even for Telia and Cogent. And yes, they baked a cake for Cogent to try to get them to turn peering up; there's pictures to prove it, everyone in the room has seen it. :D IX Updates and News Terremark, Josh Snowhorn Bogota is growing strong. ISTIX, Istanbul IX, turkish traffic, ME traffic come show up! NOTA, 200G there, they have F10 switches, need to upgrade. Looking for new switches there Cara Mascini, AMS-IX, they have the new MPLS/VPLS platform about 25 new members since last NANOG, 340 members, about 600 ports, half 10G, Over 1000 ports active Traffic is over 800G, 2G of IPv6 traffic. New site, interaxion, is in build up, need interswitch links, and then it'll be live. New web site, new member portal going live in a few weeks; new pricing for 2010 on website. General meeting, Nov 18th, talk to her about specifics. Mike Hughes, LINX, he waves to Martin Also on Slough, not just London--diverse from docklands now 10 sites total, 3 non-docklands sites. better resilience. THW facility will be 20,000 meters opening next year Brocade and Extereme still, will be 15 in november. They still have lots of 10/100 ports. Equinix, Eric Bell--3 regions, 12 metros, globally hit about 380G, traffic continues to grow; Exascale deployed in DC, now switches in DC5 as well as DC2. MPLPP, their version of route server, could be a solution for HE and cogent for v6. :D Hong Kong, opened new exchange Telehouse 2, 2Gigs there Looking to build requirements to expand into certain metros; how do they expand? Greg, Switch and Data--he joined 20 days ago Peter has H1N1 unfortunately. Customer1 portal, all the way on right aggregate traffic across sites peer-finder tool (who you peer/don't peer with) participant list mailing lists for each metro site; portal has a sign-up site, it's moderated list. held advisory council meeting, got input, aiming roadmap for next year; route servers and route collectors getting rolled out; peer with them, helps them figure out who is up, who is down. Nov 23, Jan 3rd, network moratorium over holidays Michael Lucking, Telx releasing new peering portal next week; will have way to interface and interact with other peers Everyone on switch will have access to it. About 20% of customers are doing IPv6, it's growing; not much traffic there yet. SIX, Patrick Gilmore, gone through changes as of late; added Nexus 5020, have 8x10GE between main switch and Nexus, with 7G on it; come peer, help fill it up. Did renumbering, v6 was instant v4 not so instant; 3 stragglers who still haven't renumbered. Did not buy space off Bill Manning. was a lot less painful than people thought; don't fear renumbering. 133 AS active, 45G active. Price drop! $5k for 10G port, plus optic, then free thereafter. TOR-IX, Jon 120 peers now, 5 years ago at 2G, today it's at 20G averages 15-20 peers a year joining. 72 FE ports, 34 gig ports, 10 multigig, and 6 10G port, and 1 20G port. IPv4 and IPv6 on route server portal is great, works on mobile devices Arnold Nipper from DECIX, still an ethernet switch. IPv6 is 300 customers. lots of eastern europe, biggest location for eastern european traffic. Changed pricing model, simplified it, GE down to 500EU, 3rd interaxtion site at frankfurt 5 later this year. Marice Dean, France-IX--initiative in Paris, to try to consolidate existing exchanges there; 11 or 12 active exchanges there. Exchanges are free to use, but you get what you pay for. Trying to build metro fabric to extend to interesting locations there. There's a lot of fiber that drops near there, but not much interconnection. Started negotiations with existing ISPs designed something, working to deploy it. First effort was to get a logo; always the most important bit. Launch date, Dec 15th, French NOG in Paris setting up legal structure, non profit interest group and working to turn stuff up. Slide showing first 8 nodes goes up. Fibers with DWDM. Force10 switches. info at france-ix.fr Not still free. Cost for ports will be designed to create a surplus for re-investment into future. will track other exchanges, including 100Mb ports for free Do they want to consolidate all exchanges? Long tail of locations, provide easy migration path out of. Will launch with 120 participants. Started as group of individuals, Shintaro Kojima AS7521, JPNAP, IIJ and NTT primary Also Tokyo major ICP and IXP investor. 70 v4 customers plus 30 v6 customers traffic today is about 30Gb Tokyo and 50Gb in Osaka Also Equinix in Tokyo in and Osaka Customer ports available. Switches will look at optic power for customers as well. No route servers yet. So, nothing really new this time, hope for better updates next NANOG. Innovation at peeringDB from RAS. he wrote it, people seem to be using it. nothing to unveil yet. working on a wide variety of things. Aiming for total re-write, but preserve existing data. Looking for a couple more admins; current workload for peering DB is rising; Patrick is doing most of it and is looking burned out. If you're into masochism, and want to answer lots of email, let him know, let people take a break. Hopefully soon, will be cool innovations. Maurice now has standing policy that in order to peer with Google, you have to have a peeringDB entry. ME and AP folks having trouble registering. They feel they're not getting responded to. Could be challenges getting approvals for accounts. The interface is only in English, it might be something that Google could help with translating for them. Patrick was on vacation in China for 3 weeks, so he's behind. This project that we started as a freebie in the community needs more support. There's challenges to taking money for the project. Translation--they don't get too many requests from people about getting other languages supported. If someone wants to volunteer to regionalize the pages during the rewrite, then they'll see if they can feed it in. There's several people helping out; Randy Epstein from host.net, Terry R, and some other admins like Josh that are never around. What's the criteria for being an admin? Patrick and RAS have a religious stance of it being 100% agnostic; must be objective store of data you put in it. Has to be someone who has the same level of belief and won't abuse the trust. Send email to admin at peeringdb.com if you'd like to help out with admin role. What is workload like? Many hands make light work; many emails a day. Right now, a couple of hours a day. Please be as clear as possible when doing clear text requests; 30% is people leaving roles, mergers, acquisitions, etc; no indication of who represents a given company. If you've got skills in detecting issues with people's peering knowledge, you can help out. Why do people have 13 peeringDB accounts? Why not have role accounts? Will have a limit on how many people can have accounts on the system. If you send a request in for a change for ownership in system, if you want someone else's record changed, have documentation to back it up. Closing moments; final Q&A? Mail questions to nanog47 at corbe.tt AS20144--administrated by ICANN, DNS admin team, for root server; live at 10G at 3 locations, v4 and v6, looking for 2 more sites. Need to expand Europe footprint, looking to see if he can get transport services. DNSSec is coming, nobody knows how the traffic will grow; before root is sign, l.root will be signed first, they want to make sure there's enough capacity to make sure it'll work. Open peering policy! Joe notes everyone should vote; the whole voting population is less than room count. That's it, see you in austin! OK, back down to Grand ballroom for the ARIN open policy hour. They fire it off at 1805 hours Pacific time. Preview of draft policies on agenda policy experience report will get moved to Thursday Policy Proposal BoF your time recent list discussions Leslie Nobile, a few items from PPML list, NANOG list, and other places, and will solicit some feedback from the room on those. Anything that we want to bring to the mics? Nothing from anyone so far. Preview first, then BoF proper. Draft policy review 5 on agenda for this week. not for discussion at this BoF please read them, if you haven't already have staff and legal review draft policies have been on public list will be presented at full meeting. Don't talk about them tonight, save it for the list or tomorrow! Policy development process, flow chart are in it as well. 2009-3: Global proposal allocation of IPv4 blocks to RIRs been submitted to all 5 RIRs; must be accepted by all 5 RIRs, and then ICANN board will review and adopt. All 5 RIRs have it; this is the ARIN version. Right now, RIR can go to IANA, show what they use, and they get get more, usually 1 or 2 /8s. Once there's no more IANA /8s in free pool. At that point, RIRs return IPv4 space to IANA when they get it back to build new free pool Once every 6 months, RIR can ask for 1/10th of free pool as allocation. 2009-5: multiple discrete networks allow IPv6 initial and subsequent requests for discrete, independent networks /32 for ISPs, /48s for end users (and larger) 2009-6: Global: IANA policy for allocation of ASN blocks to RIRs. Right now, 2 pools; 16bit and 32bit as one pool gets lower, they can go to IANA and request more of that type. After Jan 1, 2010, all RIRs will be locked into same pool; will have to show usage of all ASNs before getting more. This would extend ability to get ASNs of each type for one more year. Submitted to all 5 RIRs. 2009-7: Open access to IPv6 removes to rules for initial allocation removes requirement to advertise single aggregate allocation remove requirement to be a known ISP in ARIN region or to have plane to make 200 assignments in 5 years. 2009-8: equitable IPv4 runout slows distribution of IPv4 space ISPs that come to ARIN, and that have been members for a year, can request a 12 month supply. This would reduce supply period based on how many available /8s IANA has left. At 20 /8s, goes down to 6 months supply. At 10 /8s, everyone stuck with 3 month need. Sets maximium prefix size based on ARINs free pool; 1/4 of ARIN's free pool, rounded down. Read the summaries, draft policies, staff assessments, etc, come to meetings prepared to discuss them. Now, on to Policy BoF Informal setting presentation of ideas discussion and feedback (5 minutes total) No committments at this time! Going forward your choice: do nothing continue discussions informally take the discussion to PPML submit a policy proposal. So...that's the rules--who has something to talk about? Remote participation is allowed too...but nobody's in the room. Lee Howard, TWC, ARIN board of trustees, the trustees not allowed to propose, so he's just breaking the ice. Some discussion during NANOG portion of week; routing considerations around ARIN policies. Should ARIN policies take into consideration any routing considerations? Dani from PeakWeb The precedent from IPv4 side is that ARIN doesn't guarantee routing; it just does registration services. That's really where it needs to be. We're smarter now, we need to take the language out. Not enough of us were really watching when the 2bit to 4bit ASNs transition happened; we need to start getting involved sooner, and speak up earlier in the process. We need to focus on proper sizing of allocations, and let business determine usage. In IPv4 world, we were trying to deaggregate class Bs...it eventually worked its way out in IPv4 world, it'll be able to work its way out in IPv6 if we let it. Jason Schiller, Verizon; ARIN is chartered to shape policy; and policies will shape routing decisions. If ARIN starts allocating /30s, they may not guarantee routability, but once ARIN starts giving them out, and one ISP routes them, the pressure will be there for everyone to route them. It's useful to be able to take ARIN policy back to help sell best practices inside your company. Jon, Internet society If we're walking in the space of a policy that will be discussed later...the transfer policy was difficult for the panelists to understand; they had to call in lawyers to try to interpret it. That kind of feedback from NANOG panelists doesn't fit with the 3 goals of ARIN. Clear, technically sound, and useful. The routing policy question--obligation of ARIN and other RIRs that they not just conserve scarce resource, but conserve slots in the routing table which is a shared commons, globally. There will be more discussion of economics during the week. The tragedy of the commons is well known, and is well documented; there's economic incentive for each, but if it happens unbounded, the commons get destroyed, and they all die. The global routing table is a global commons; adding to it will be in the interests of every individual network access provider. There is an obligation to preserve slots in the global routing table... Aggregation is a goal in the number resource model, but it's not a criteria. Cathy Aaronson--irony of statement. The aggregate part in statement was to preserve global routing table slots. That was the intent at the time. John Curran, president, CEO of ARIN. The incorporation and bylaws are wide-reaching, and talk about technical coordination, which is very vast. There are things tied to number allocation which are in NRPM, but talk about visibility of information in whois. the ability to abide by NRPM can be used to decide if people get new resources, or get to keep existing resources. If this group wants to govern what goes into the routing table, it can go in. But the community needs to decide if that's a space we get involved in adding and enforcing via the NRPM. We can put constraints on routing in NRPM, like we do with whois visibility. It's up to us. Ed Kern--he'd love to have it in the policy to make Jason to route all the /30s. :D The v6 allocation was BCP in the policy strategy. It should be taken out now, and moved to a BCP status. IETF and ITU aren't the right forums for this. Leo Bicknell, ARIN advisory council we have the discussions repeatedly. The numbers agency and network operators exist in symbiotic relationship; the numbers are needed for routing, and without routing, there's no need for number resource registration. As with any symbiotic relationship, both parties need to understand the other's needs; both sides need to keep the other healthy. ARIN community needs to understand the limitations of routers and policies that operators are using. It is not useful for ARIN community to dictate to operators how to configure their devices...in general. Operators need to understand implications of policy on a 50 year span, not just next year. Provide useful information on when routers are likely to fall over back to policy team. More information sharing, and less dictating needs to happen. Dave Farmer, ARIN AC. Everyone needs to chill out just a little bit. It's your routers, your policies, yes. But you have to let ARIN know what policies make routing policies possible. It wouldn't be possible to be able to take /48s for critical infrastructure if it didn't come from one little corner. "For this piece of stuff, this is what you can do" ARIN needs to assign numbers in a reasonable fashion to allow operators to make decisions around the numbers. The ability we have to write policies stems from ARIN's allocations of addresses in a coherent fashion. Cathy again. She's super-excited that people noticed the IPv6 allocation policy, since it's been there for 10 years! finally, people are looking! When they went from /19 to /20, they put notes in saying they were going to look at routing tables, and retract if it caused too much pain. Lee Howard--delighted with feedback to that topic of conversation. People need to send email indicating the words to arin.ppml at arin.net; if you don't know how to write the words, they will help you write the words. Their job is to help you write clear, concise, useful words. And vote for him on Friday! New topic from Cathy Something for ARIN to answer; with v6 allocations, they are not being sparsely allocated, they are consecutively being allocated. Is this on purpose? A: yes, it's on purpose. No sparse allocation in v6. Only 1 RIR is doing sparse, that's APNIC. They do need to discuss it, John is nodding, they will discuss it but have not done it yet. Doni again Question about if ARIN wants to move from consecutive to sparse, is that policy based, or can ARIN just move to do that internally? A: ARIN can do that internally; Dave Conrad notes that the initial goal was to use sparse allocation, so it is a goal, but also a work in progress. Leah Roberts, ARIN AC Increment between them could be bumped up before moving to sparse allocations; could it be moved up a few bits to a nibble boundry at least? /29 doesn't map very well. Anything else from community members, policy-wise? Martin Hannigan Recovery; should we revisit it today? it's becoming aparent there will be 2 internets out there; you'll need both addresses for quite some time. There will be a market for v4 addresses; it would be better to see it be rational and fair. There's operators, policy, and there are shareholders as well. Some want to be good, but others have to keep the economy going, and get our paycheck. We'll probably see /28s on the internet so v4 can still 'grow' while the move to v6 trundles along. How do we manage /8s locally, not just under global policy. Scott Liebrand There have been several policies to take baby steps along the path--what suggestions does he have for moving in that direction? Martin replies: Bite off the low hanging fruit--just define what it is. Stragglers, things out there that aren't in routing table, no valid contacts, etc. We've had a mishmash, but no coherent plan. This needs to not be tied into other policies. Needs to strictly be about reclamation. Start low, and then move to high stuff. Lee Howard you said recovery a few times; do you mean recovery of IPv4 unused or underused space? Unused is very different from underused. We don't have any policy about underuse of space; you need to have minimal use to get *more* space. NRPR section 12--John Curran notes that you should read the manual; he looks at it many times, and comes away shaking. Policy provides ARIN the necessary tool to do a few things: it's up to ARIN staff organization to use that policy; they use it now for addresses that are not legitimately held by anyone at all. They can prevent unheld resources from being held by a party. If that's low hanging fruit, as it is brought to ARIN, ARIN is attempting to make sure they don't get legitimized by ARIN updating records. But that's reactive based on suspicious requests coming in. Other case is resources that aren't being used, but are legitimately held, even if it's not being used, never routed, etc. Those unused or heavily underutilized resources are *not* being touched right now. They have a legacy RSA agreement, that once signed, prevents ARIN from ever doing anything with that block. So, no legitimate holder they can catch. But the ones with legitimate holders, they cannnot both offer a legacy RSA, and simultaneously move against those resources. To move against resources, we need to resolve that against legacy RSA agreements. 300 RSA signers, but that covers more than 25% of the legacy space; so there's more and more coverage of that space; once signed, they're part of the system, and by contract, they is no method to do reclamation on that space. If we're going to change the legacy RSA, he needs to know now! Chris Grundeman, TWC There was a policy after last meeting, 2008-7, enacted after last meeting, the intention was to help identify the fallow space. The tool will be there to help identify it for reclamation. Owen DeLong, HE.net section 12 para 5 attempts to reconcile issues; ARIN can reclaim space allocated by ARIN for under use when legacy RSA is signed. Leo Bicknell--the legacy space is mired in issues. non-legacy space, RSA states that if ARIN believes the space is not being used for the original purpose, you may need to re-justify it, and if it cannot be justified, ARIN may reclaim it. John: they go after such resources *when* they come to ARIN and attention is drawn to them. They have reviewed and revoked resources based on that, but they are not going out and looking for space that would fall under those terms. Most reporting to ARIN is under fraud reporting process. It only is used if people feel that fraudulent claims are made to ARIN in the application process; any other legal issues are *not* moved on. John, ISOC Low hanging fruit may still be on tree because it is rotten. APNIC talks about audit trails for space that is recovered. If you reallocate it to someone, and it turns it is ACL'd off or blacklisted for places they need to reach, they are not better off for getting the space. When space is recovered, can its history go with the block, so that potential recipients know what they are getting. Leslie Nobile notes that space reclaimed through various means is held for 1 full year, and they use RBLs, checking 140 RBLs and lists, and noting that it has been fallow for a year; they attempt to ensure they are issuing clean space as much as possible. they are very aware of this, it's not a policy, but it's an internal proceedure. Martin policies and procedures are great, perhaps if ARIN could wave the flag and let us know, that would be great. There's some low-hanging fruit that isn't caught by the policies; if you're the POC, and the company went bankrupt, it's really easy for POC to just hold onto the space. He thinks there's some low hanging fruit we may be stepped on. Also, legacy /8s getting returned need a local, non global policy to handle them. XXX from Jamaica, covers issues around ICT, learning a lot at ARIN meeting. Reading mission statement up on wall, a question to the staff and community. How do you draw line between a watchdog or deal with issues, when one main activity is to facilitate the advancement of Internet while outreach and education is a primary goal. It seems the Internet is such a huge monster, it needs this broad-based consensus at all times. The issues are overwhelming, the v4 to v6 migration needs even more education and outreach around it. She's learning a lot, and hopes ARIN can help educate even more about how these issues can be addressed and handled in the Carribean region. We're out of time; it's a few minutes after seven. Beer and pizza party up in rotunda, first elevator on the left, runs from 7pm to 9pm. Thanks to everyone who brought questions to the microphone today!! From sbradcpa at pacbell.net Tue Oct 20 18:32:22 2009 From: sbradcpa at pacbell.net (Susan Bradley) Date: Tue, 20 Oct 2009 16:32:22 -0700 Subject: Subject: Amazon's EC2 Security contact Message-ID: <4ADE4886.2050402@pacbell.net> security at amazon.com Little birdies from Amazon said that's the best contact point. Message: 4 >> Date: Tue, 20 Oct 2009 17:40:39 -0400 >> From: "J. Oquendo" >> Subject: Amazon's EC2 Security contact >> To: NANOG list >> Message-ID: <4ADE2E57.9030608 at infiltrated.net> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> Hey all, apologies for shooting this on this list, but I've had greater >> success here. >> >> Anyone have a SECURITY contact for "Amazon Web Services, Elastic Compute >> Cloud, EC2" outside of the typical: whois -h whois.arin.net >> $THEIRSPACE|grep "@" >> >> I'm looking at a delicate situation here and would appreciate any >> OOB/non-tech-sup-spool-box contact. >> From nonobvious at gmail.com Tue Oct 20 18:38:58 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Tue, 20 Oct 2009 16:38:58 -0700 Subject: ISP customer assignments In-Reply-To: References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> Message-ID: <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward wrote: > On 20/10/2009, at 3:02 PM, Bill Stewart wrote: >> plus want the ability to take their address >> space with them when they change ISPs (because there are too many >> devices and applications that insist on having hard-coded IP addresses >> instead of using DNS, and because DNS tends to get cached more often >> than you'd sometimes like. > > That's why we have Unique Local Addresses. This is the opposite problem - ULAs are for internal devices, and what businesses often want is globally routable non-provider-owned public addresses. If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. And even though most enterprises these days only use registered addresses outside the firewall and not inside the firewall, it's still a pain to have to renumber everything and wait for everybody's DNS caches to expire, so if you're using Provider-independent IP addresses, it's much easier to tell your ISP "Sorry, ISP A, I've got a better price from ISP B and I'll move all my stuff if you don't beat their price." (Of course, customers like that are often telling ISP B "You'll have to be X% cheaper/faster/somethinger than ISP A or I'll just stay where I am" and telling ISP C "My main choices are ISP A and ISP B but I'd take a lowball quote very seriously...") -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From marka at isc.org Tue Oct 20 18:51:52 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Oct 2009 10:51:52 +1100 Subject: ISP customer assignments In-Reply-To: Your message of "Tue, 20 Oct 2009 16:38:58 PDT." <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> Message-ID: <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> In message <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e at mail.gmail.com>, Bill Stewart writes: > On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward wrote: > > On 20/10/2009, at 3:02 PM, Bill Stewart wrote: > >> plus want the ability to take their address > >> space with them when they change ISPs (because there are too many > >> devices and applications that insist on having hard-coded IP addresses > >> instead of using DNS, and because DNS tends to get cached more often > >> than you'd sometimes like. > > > > That's why we have Unique Local Addresses. > > This is the opposite problem - ULAs are for internal devices, and what > businesses often want is globally routable non-provider-owned public > addresses. If you've got a VPN tunnel device, too often the remote > end will want to contact you at some numerical IPv4 address and isn't > smart enough to query DNS to get it. Which just means we should be fixing the VPN box. > And even though most enterprises these days only use registered > addresses outside the firewall and not inside the firewall, it's still > a pain to have to renumber everything and wait for everybody's DNS > caches to expire, so if you're using Provider-independent IP > addresses, it's much easier to tell your ISP "Sorry, ISP A, I've got a > better price from ISP B and I'll move all my stuff if you don't beat > their price." (Of course, customers like that are often telling ISP B > "You'll have to be X% cheaper/faster/somethinger than ISP A or I'll > just stay where I am" and telling ISP C "My main choices are ISP A and > ISP B but I'd take a lowball quote very seriously...") Renumbering in IPv6 is not the same as renumbering in IPv4. IPv6 is designed to support multiple prefixes on the one interface. There is actually enough address space to support doing this and allow renumber events to take weeks or months if needed. There is no need to say at XX:XX on DD/MM/YYYY we will be switching prefixes. One can be much smarter about how you do it. You can just introduce the new prefix. Add second address to the DNS. Do your manual fixes. Remove the old addresses from the DNS. Stop using the old prefix when you are satisfied that there is no traffic over them. > -- > ---- > Thanks; Bill > > Note that this isn't my regular email account - It's still experimental so far. > And Google probably logs and indexes everything you send it. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kauer at biplane.com.au Tue Oct 20 19:41:38 2009 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 21 Oct 2009 11:41:38 +1100 Subject: ISP customer assignments In-Reply-To: <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> Message-ID: <1256085698.30246.109.camel@karl> > There is no need to say at XX:XX on DD/MM/YYYY we will be switching > prefixes. One can be much smarter about how you do it. > > You can just introduce the new prefix. Add second address to the > DNS. Do your manual fixes. Remove the old addresses from the DNS. > Stop using the old prefix when you are satisfied that there is no > traffic over them. True in principle. In practice, changing stuff, especially globally, is not as simple as that. Many (most?) enterprises still have pretty primitive DNS/DHCP management. While there are good management systems out there, many of the largest are custom made for the enterprise concerned, and are not yet up to speed with IPv6. The practical experience is not yet there to drive the development of the right features - especially ones as rare as a complete renumbering. DHCPv6 server software is still pretty early days, too. The addressing on infrastructure kit like routers and switches, firewalls and IDS boxes and so on is also typically hard coded and difficult to change, as are the addresses used in ACLs and firewall rules. Renumbering means: - adding a new AAAA record to the DNS for every existing AAAA record, but using a different prefix (plus any other DNS changes needed - like giving the servers themselves addresses in the new prefix, and making sure they reply from the right address...) Reverse lookups may be an issue during the changeover, too. - updating DHCP configurations to issue addresses from the new prefixes, automatically divided along the same numbering plan - setting up reserved DHCP addresses with the same host parts as the old reserved addresses but using the new prefix etc - adding new addresses to every location where an address is hardcoded - such as in router and switch configurations - updating ACLs to account for the new addresses (without discarding the old rules yet) - updating firewall rules and what-have-you to account for the new prefix, without discarding the old ones yet - waiting the weeks or months until the old prefix may be safely discarded. During this time you have a prefix-schizo network. - updating firewall rules and what-have-you to remove the old prefix - updating ACLs to remove the old addresses - removing old addresses from every location where an address is hardcoded - such as in router and switch configurations - removing now-unused DHCP reservations - removing now-unwanted DHCP ranges - removing all AAAA records that reference the old prefix ... and this is by no means an exhaustive list. Many higher-level services will also need updating (twice) - your web server configurations, for example. And it gets more complicated if your prefix changes length as well. And what if the network was not set up with future renumbering in mind? DHCP servers issuing eternal leases, things like that. So once again the theory is good, but reality intrudes. Renumbering, even with the undeniably much better features of IPv6, is still going to be a royal pain. Of course, IPv6 may drive improvements in all these areas over time, but they're not there yet. Wouldn't it be cool to have a "renumber router" command that just took an old prefix, a new prefix and a number of seconds and did all the work? Regards, K. PS: If anyone knows of an IPAM that can do all the above, or even just some of the above, please let me know! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From marka at isc.org Tue Oct 20 21:01:56 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Oct 2009 13:01:56 +1100 Subject: ISP customer assignments In-Reply-To: Your message of "Wed, 21 Oct 2009 11:41:38 +1100." <1256085698.30246.109.camel@karl> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> <1256085698.30246.109.camel@karl> Message-ID: <200910210201.n9L21ud9036210@drugs.dv.isc.org> In message <1256085698.30246.109.camel at karl>, Karl Auer writes: > > There is no need to say at XX:XX on DD/MM/YYYY we will be switching > > prefixes. One can be much smarter about how you do it. > >=20 > > You can just introduce the new prefix. Add second address to the > > DNS. Do your manual fixes. Remove the old addresses from the DNS. > > Stop using the old prefix when you are satisfied that there is no > > traffic over them. > > True in principle. In practice, changing stuff, especially globally, is > not as simple as that. > > Many (most?) enterprises still have pretty primitive DNS/DHCP > management. While there are good management systems out there, many of > the largest are custom made for the enterprise concerned, and are not > yet up to speed with IPv6. The practical experience is not yet there to > drive the development of the right features - especially ones as rare as > a complete renumbering. > > DHCPv6 server software is still pretty early days, too. > > The addressing on infrastructure kit like routers and switches, > firewalls and IDS boxes and so on is also typically hard coded and > difficult to change, as are the addresses used in ACLs and firewall > rules. > > Renumbering means: > > - adding a new AAAA record to the DNS for every existing AAAA record, > but using a different prefix (plus any other DNS changes needed - like > giving the servers themselves addresses in the new prefix, and making > sure they reply from the right address...) Reverse lookups may be an > issue during the changeover, too. > > - updating DHCP configurations to issue addresses from the new prefixes, > automatically divided along the same numbering plan > > - setting up reserved DHCP addresses with the same host parts as the old > reserved addresses but using the new prefix etc > > - adding new addresses to every location where an address is hardcoded - > such as in router and switch configurations > > - updating ACLs to account for the new addresses (without discarding the > old rules yet) > > - updating firewall rules and what-have-you to account for the new > prefix, without discarding the old ones yet > > - waiting the weeks or months until the old prefix may be safely > discarded. During this time you have a prefix-schizo network. > > - updating firewall rules and what-have-you to remove the old prefix > > - updating ACLs to remove the old addresses > > - removing old addresses from every location where an address is > hardcoded - such as in router and switch configurations > > - removing now-unused DHCP reservations > > - removing now-unwanted DHCP ranges > > - removing all AAAA records that reference the old prefix > > ... and this is by no means an exhaustive list. Many higher-level > services will also need updating (twice) - your web server > configurations, for example. And it gets more complicated if your prefix > changes length as well. And what if the network was not set up with > future renumbering in mind? DHCP servers issuing eternal leases, things > like that. > > So once again the theory is good, but reality intrudes. Renumbering, > even with the undeniably much better features of IPv6, is still going to > be a royal pain. Of course, IPv6 may drive improvements in all these > areas over time, but they're not there yet. > > Wouldn't it be cool to have a "renumber router" command that just took > an old prefix, a new prefix and a number of seconds and did all the > work? Well request it from you favorite router vendors. Router/vpn/firewall vendors should be forced to renumber annually. That way they would have some incentive to make their products usable when a renumber event occurs. The same applies to other vendors. > Regards, K. > > PS: If anyone knows of an IPAM that can do all the above, or even just > some of the above, please let me know! > > --=20 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) > > GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF > > > --=-lq/A/spfwZ9P7pLx73k/ > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEABECAAYFAkreWLgACgkQSkRqA/Q6fe//UACfcPMTlaufxR4sk8pfJ9d7Uk/W > rW4AmgNnotHOzM4DnvcT90ow+0kDxMVF > =aZzD > -----END PGP SIGNATURE----- > > --=-lq/A/spfwZ9P7pLx73k/-- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rdobbins at arbor.net Tue Oct 20 21:15:39 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 20 Oct 2009 22:15:39 -0400 Subject: ISP customer assignments In-Reply-To: <1256085698.30246.109.camel@karl> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> <1256085698.30246.109.camel@karl> Message-ID: <1069DFD4-87A3-4E38-AEBC-43C05C16DECA@arbor.net> On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: > In practice, changing stuff, especially globally, is not as simple > as that. From : 'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.' ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From marka at isc.org Tue Oct 20 21:29:48 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 21 Oct 2009 13:29:48 +1100 Subject: ISP customer assignments In-Reply-To: Your message of "Tue, 20 Oct 2009 22:15:39 EDT." <1069DFD4-87A3-4E38-AEBC-43C05C16DECA@arbor.net> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> <1256085698.30246.109.camel@karl> <1069DFD4-87A3-4E38-AEBC-43C05C16DECA@arbor.net> Message-ID: <200910210229.n9L2TmHC057055@drugs.dv.isc.org> In message <1069DFD4-87A3-4E38-AEBC-43C05C16DECA at arbor.net>, Roland Dobbins wri tes: > On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: > > > In practice, changing stuff, especially globally, is not as simple > > as that. > > From : > > 'Some took it on themselves to convince the authors that the concept > of network renumbering as a normal or frequent procedure is daft.' There is a difference between renumbering every minute and renumber when required to optimise something else. We shouldn't be afraid to renumber. It should be something all vendors support. It should be as automated as possible. If there is a manual step you should be asking yourself "does this need to be done by hand". Remember there are lots of machines that renumber themselves several times a day as they move between work and home. All machines should be in a position to renumber themselves as easily as we renumber a laptop. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rdobbins at arbor.net Tue Oct 20 23:13:46 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 21 Oct 2009 00:13:46 -0400 Subject: ISP customer assignments In-Reply-To: <200910210229.n9L2TmHC057055@drugs.dv.isc.org> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> <1256085698.30246.109.camel@karl> <1069DFD4-87A3-4E38-AEBC-43C05C16DECA@arbor.net> <200910210229.n9L2TmHC057055@drugs.dv.isc.org> Message-ID: <3FBF685D-3FDF-442B-BCFC-2EFDFB65A673@arbor.net> On Oct 20, 2009, at 10:29 PM, Mark Andrews wrote: > Remember there are lots of machines that renumber themselves several > times a day as they move between work and home The problem isn't largely with the endpoints - it's with all the other devices/policies/etc. which overload the EID with inappropriate significance which tend to cause most of the problems. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From mpetach at netflight.com Wed Oct 21 00:53:17 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 20 Oct 2009 22:53:17 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <4AD3865B.8010908@he.net> References: <4AD3865B.8010908@he.net> Message-ID: <63ac96a50910202253v2948298raab6e5029878f65a@mail.gmail.com> On Mon, Oct 12, 2009 at 12:41 PM, Mike Leber wrote: ... > We don't ignore comments about connectivity, in fact quite the opposite. > We study each AS and which ASes are behind them. We work on getting > peering with the specific AS, in the case that they are unresponsive, > getting the ASes behind them. > > Among the things we do to discuss peering: send email to any relevant > contacts, call them, contact them on IRC, send people to the relevant > conferences to seek them out specifically, send people to their offices, > etc. > > So far we stop short of baking cakes, but hey... > And tonight we saw in public that even that path is being attempted: http://www.flickr.com/photos/77519640 at N00/4031434206/ (and yes, it was yummy and enjoyed by all at the peering BoF!) So Cogent...won't you please make nice with HE.net and get back together again? ^_^ Matt (speaking for neither party, but very happy to eat cake nonetheless) From ras at e-gerbil.net Wed Oct 21 02:13:20 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 21 Oct 2009 02:13:20 -0500 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <63ac96a50910202253v2948298raab6e5029878f65a@mail.gmail.com> References: <4AD3865B.8010908@he.net> <63ac96a50910202253v2948298raab6e5029878f65a@mail.gmail.com> Message-ID: <20091021071320.GS51443@gerbil.cluepon.net> On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote: > And tonight we saw in public that even that path is being attempted: > > http://www.flickr.com/photos/77519640 at N00/4031434206/ > > (and yes, it was yummy and enjoyed by all at the peering BoF!) > > So Cogent...won't you please make nice with HE.net and get back > together again? ^_^ > > Matt > (speaking for neither party, but very happy to eat cake nonetheless) "Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier than the correct version. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From tjc at ecs.soton.ac.uk Wed Oct 21 04:27:15 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 21 Oct 2009 10:27:15 +0100 Subject: ISP customer assignments In-Reply-To: <1069DFD4-87A3-4E38-AEBC-43C05C16DECA@arbor.net> References: <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> <200910202351.n9KNpqUQ052857@drugs.dv.isc.org> <1256085698.30246.109.camel@karl> <1069DFD4-87A3-4E38-AEBC-43C05C16DECA@arbor.net> <20091021092715.GB26933@login.ecs.soton.ac.uk> Message-ID: On Tue, Oct 20, 2009 at 10:15:39PM -0400, Roland Dobbins wrote: > > On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: > > >In practice, changing stuff, especially globally, is not as simple > >as that. > > From : > > 'Some took it on themselves to convince the authors that the concept > of network renumbering as a normal or frequent procedure is daft.' We tried Fred's procedure some 4 years ago within 6NET: http://www.6net.org/publications/deliverables/D3.6.2.pdf The 'prefix schizo' actually worked out quite well. The routing changes and multi-refix links generally behaved as expected. Address selection did its thing. The basics worked as advertised. The complexity is of course not in the routing and hosts, it's as pointed out in the firewalls and similar devices (yours and more importantly other people's) for which new capabilities of IPv6 can't help. We captured some of these thoughts at the time in http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout-05 and since then Brian Carpenter has produced a much more up to date and rounded set of thoughts in http://tools.ietf.org/html/draft-carpenter-renum-needs-work-03 We're far from a magic button press. In smaller networks RFC4192 is workable, but the larger and more complex the network/site, there's still so many open issues that it's completely understandable the people will want PI. -- Tim From mpetach at netflight.com Wed Oct 21 07:00:02 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 21 Oct 2009 05:00:02 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <20091021071320.GS51443@gerbil.cluepon.net> References: <4AD3865B.8010908@he.net> <63ac96a50910202253v2948298raab6e5029878f65a@mail.gmail.com> <20091021071320.GS51443@gerbil.cluepon.net> Message-ID: <63ac96a50910210500p12ba9da9lc56ff667b15ba085@mail.gmail.com> On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen wrote: > On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote: > > And tonight we saw in public that even that path is being attempted: > > > > http://www.flickr.com/photos/77519640 at N00/4031434206/ > > > > (and yes, it was yummy and enjoyed by all at the peering BoF!) > > > > So Cogent...won't you please make nice with HE.net and get back > > together again? ^_^ > > > > Matt > > (speaking for neither party, but very happy to eat cake nonetheless) > > "Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier > than the correct version. :) > > And now even better shots of the cake have been forthcoming from people. :) http://www.flickr.com/photos/77519640 at N00/4031195041/ (I was all the way at the far other end of the room taking notes on the laptop, so I never got to see the cake intact at all--all the photos are from others who were closer to the cake, and got to see it in its pristine glory). Fortunately, I did get to partake in the eating of it. ^_^ Matt (This cake is great, it's so delicious and moist...* ;) *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html From jzp-sc at rsuc.gweep.net Wed Oct 21 07:50:22 2009 From: jzp-sc at rsuc.gweep.net (Joe Provo) Date: Wed, 21 Oct 2009 08:50:22 -0400 Subject: [NANOG-announce] Elections - polls close within the hour! Message-ID: <20091021125021.GA41846@gweep.net> Hey folks, Just a reminder that the NANOG Election polls will be closing at 09.15 EDT. If you are listed here http://www.nanog.org/governance/elections/2009elections/2009_voters.php you can vote, no matter where in the world you are. Ballot is here: https://nanog.merit.edu/election/ MLC nominations will remain open until 29 Octobe: http://www.nanog.org/governance/elections/2009elections/2009mlc_candidates.php For thos at the meeting *or* watching the streams, take the survey! http://tinyurl.com/nanog47/ Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mpetach at netflight.com Wed Oct 21 09:54:40 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 21 Oct 2009 07:54:40 -0700 Subject: 2009.10.21 NANOG47 day 3 notes Message-ID: <63ac96a50910210754p664ac67eifb8ca9546b01ca9@mail.gmail.com> And last, but not least, here's the notes from the morning part of the NANOG meeting. I strongly, STRONLY suggest people read Aaron's IPv6 deployment in a nutshell slides; while I differ from him on some of the thoughts around address allocation schemes for very large networks, for small to midsized networks, it's a very, very good cookbook to follow for getting IPv6 rolled out: http://nanog.org/meetings/nanog47/presentations/Wednesday/Hughes_Kosters_fundamentals_N47_Wed.pdf Thanks to everyone for participating, both locally and remotely! subsequent ARIN notes will be posted to ppml list. Matt 2009.10.21 NANOG47 Wednesday morning notes Don't forget to fill out your survey!! http://tinyurl.com/nanog47 Dave Meyer welcomes everyone back from their hangovers at 0904 hours Eastern Time. John Curran isn't here, so he misses his 13 minutes of fame, and we go straight over to Mark Kosters. Mark Kosters, IPv6: Emerging stories of success. A stellar panel of people to talk about transitioning to v6. IPv4 is running out; in 2 years or so, we'll no longer have a flow of addresses from IANA to the RIRs. But why isn't more traffic moving onto IPv6, given the imminent runout? Still less than 1% of the overall traffic. What do you need to do to make the move to v6, from the enterprise and ISP viewpoint? John B, comcast Matt R, ARIN Owen DeLong, HE.net Aaron Hughes, 6connect John B from comcast is up first Native, dual stack core and access networks started as means to leverage device management; then moved to subscriber access service. Backoffice, where applicable, also dual stack Cable modems (DOCSIS) single stack v4 or v6 eMTAs remain v4 eSTBs targeted to support v4 or v6 only Native dual-stack subscriber services Leverage well known transition technologies to enable enterprise desktop IPv6 connectivity. Some of the backoffice pieces, like DHCP, are still evolving. This is a team organizational effort, so it takes many pieces working together. Core concept--intial key piece was device management. Core network, access network, and back office systems all have to work together, or the program fails. So, the iteratively extend those three elements to offer services over IPv6 Native is preferred whenever possible over tunnels and other techniques; but sometimes it's just not possible. There's still much learning to happen in the area to figure out how best to make the deployment happen. Lessons Learned IPv6 must become business as usual for staff from every area of business lack of attention here be be problematic for v6 deployment deferring or avoiding IPv6 will be problematic. it's really, REALLY important to do large scale testing of interoperability, especially when you have millions of devices. You test the key interconnect points where devices interact, especially with high levels of diversity in your gear. Also leverages technologies that newer releases, like DOCSIS3.0 provide. Find opportunties like that in your own environment. Challenges Need to manage the deployment of v6 relative to other business needs. channel bonding vs v6, which gets business priority, for example Security on v6 is still a challenge vendors often say "but you're the only one who has asked for that" backoffice and tool upgrades to support IPv6 are non-trivial best approach is to divide these efforts into smaller activities. Very substantial chunk of work; don't underestimate the challenges of this! IPv6 data services for subscribers. preferred approach is to offer native dual-stack v6 service to customers; v4 continues unchanged, just adds v6. Directly connected device that supports v6, or home gateway device that supports v6. all the support systems must support both models for the rollout to work. Most people in the room use a gateway device at home. most home gateway devices don't support v6 yet, so pushing the retail type devices to support v6 natively, off the shelf is a challenge. Challenges associated with routing for delegated v6 prefixes should be uniformly addressed. Support for v6 in many products is still considered 'new' and isn't as mature as v4. testing and interoperability are critical for successful deployment bugs and issues will arise scale makes a difference! deploying IPv6 must not impact existing services (this is pretty much true for everyone--can't break existing customers!) Content and Services availability of content and services over IPv6 to date appears to be lacking simply having v6 connectivity isn't sufficient John_Brzowoski at cable.comcast.com Matt Ryanczak, network ops manager at ARIN History of IPv6 @ARIN They're a small, 50 person multihomed customer network. Their network has been running IPv6 since 2003, with a beta Sprint circuit. it was a T1 line, appeared native, but was tunneled inside Sprint. v6 internet wasn't well connected. 2004 Worldcom circuit, similar issue. Started connecting to exchange points, got transit there, and is now starting to be able to serve large volumes of traffic. In 2003, T1 line from Sprint--very adhoc and beta, used Linux Router, and OpenBSD firewall. Completely segregated network. Not dual stack, too many security issues at the time; was a bit afraid of it at the time. Path MTU discovery issues, packets just dying; server MTU issues, upstream issues, great learning process. Sprint circuit finally being decomm'd. Sprint support was always really good. 2004, Worldcom circuit, part of Vint Cerf's test v6 network; real router this time, but OpenBSD firewall still used. T1 into 2800 router. Duplicated the services that were on Sprint link, provided a second path to verify issues, see if the problem could be duplicated or not. Similar issues, PMTU discovery issues due to tunnels, problems reaching chunks of Europe (problem for serving DNS, for example)--good learning exercise. 2006, joined Equi6IX--beta at time, completely free, 100Mb ethernet, transit via OCCAID, things started to look like production network; still had firewall, same services, but the service level got a lot better, still segregated network, but many routing issues went away, PMTU issues started to disappear. started to dual stack. 2008: NTT/TiNet IPv6; built two networks, one west coast, one east coast, would host all public services out there, separate provisioning side from public side. 1000Mb links to NTT/TiNet using ASR 1000 routers Foundry LBs, IPv6 support was Beta. They're very responsive, been issuing patches for them. Now it's a full dual-stack network end to end, and Foundry is still working with them to figure out how to best support the traffic. Whois is out there, DNS out there, figuring out how to expand the services. Traffic: Whois, about 0.12% DNS about 0.55% WWW IPv6 about 8% traffic in 2009 Most of that is internal ARIN traffic, since they're dual stacked internally. :D Lessons learned Tunnels are not desirable. he.net tunnel at home is fine for home use, but using them for production services, PathMTU discovery problems are just a pain. Not all transit is equal! Routing is not as reliable as v4; people are still learning, backbones aren't as good. Dual stack isn't so bad, no security issues they're aware of, stacks have gotten a lot better. Proxies are good; use 6to4 proxies for current rwhois servers, older routing registry (moving to v6 someday) People fear 4byte ASN. They have people who can't peer with them due to 4byte ASN. More people need to get 4byte ASN code. Native support is better. DHCPv6 is not well supported. This really needs fixing. Reverse DNS is a pain. No wildcards. Can't use same tricks as v4, and is very error-prone. Windows XP is broken but usable; can't do v6 DNS, but mostly usable. Bugging vendors does actually work. Helps if they recognize your name (being ARIN doesn't hurt!) Today and the Future standardizing dual stack, ipv6 enabled by default, including push scripts, back office, etc. v6 support a requirement for vendors All RFPs list IPv6 as a requirement Be prepared to do a lot of work tweaking your back office scripts! Patrick, Akamai, -- do you do Google whitelist or do you just break people who don't have v6 connectivity to you who ask for AAAA records. A: It probably happens, but they don't get too many complaints. It does happen sometimes, but often they can work with people to get them connected. Kevin Oberman, ESnet Recently, he had that issue, AAAA couldn't get there, but he didn't open a ticket, he just went back to IPv4 address. A: yeah, there's been some issues like that; they don't make much money from website, so it's not as critical for them as for some others, but they do work with people to try to fix those cases. Shift focus--what does it take to move enterprises into v6? Owen DeLong, what does it take to port systems from v4 to v6? Porting to Dual Stack -- not that hard Why important? We've all seen the exhaustion point graph. code examples there http://owend.corp.he.net/ipv6/ change variable names when changing types, to make it easier to spot old variables. compile-repair-recompile-test-debug-retest AF_INET to AF_INET6 sockaddr_in to sockaddr_in6 sockaddr_storage (generic storage type) check address scoping (link local vs global, and interface scope for link locals) Some gotchas not in sample code IP addresses in log files IP addresses stored in databases Parsing routines for external data PERL porting example refer to source code examples v4_* are v4 only code Add socket6 as well as socket module to code replace get*byname calls change protocol and address families in socket and bind calls get*byname to getaddinfo If you pass in in6addr_any to getaddrinfo returns localhost, not what you were looking for! Example of actual old way getservbyname becomes getaddrinfo socket and bind calls, AF_INET6, not too bad PERL client migrations, similar tactics inet_ntoa to inet_ntop now getaddrinfo simplifies DNS on client side You can't cycle socket calls anymore for reads; you have to explicitly create it each time right now, as you don't know which family the previous call was. Handy function replacement slide from the website, with structure replacement slide owend at he dot net Bill Fenner some kernels have changed to only bind to v6 sockets when available; has he found that to be the case? A: if your kernel does that, it's unfortunate; what Owen has found is that on his boxes, it binds to both. Q: yes, some kernels behaved that way, which is very unfortunate; there might be knobs that can change the default behaviour. A: Recent Linux stacks seem to behave just fine with dual stack socket calls; get with him if you have examples of bad kernels so he can post warnings. Aaron Hughes, deploying dual stack on a network succesful implementation requires good supporting policies! We need to participate in decisionmaking at the company level, to determine when and how to deploy v6. Timing will be different for different companies. Dispel the myths obtaining v6 addresses is hard transit providers don't support it no BGP multihoming Obtaining IPv6 address space is not really hard. My provider doesn't support v6! right now, talk to others, you can get free transit. he.net, wvfiber, probably others out there you can talk to. This is really valuable to people right now! Starting with IX locations--get IPv6 addresses from your exchange point providers Make a list of all relevant peering information update peeringDB--let the rest of the world know you have v6 addresses! Follow your own company change processes for the deployments! configure IPv6 locate existing v4 peering interfaces enable v6 (cisco) configure v6 address ping some peers (look their IPs up in peeringDB) within a minute, you can pass some ICMPv6 packets. Cisco ipv6 unicast-routing Juniper enabled by default v4 and v6 are configured almost identically. At this point, your IX interfaces are dual stacked. :) Next up, the backbone. Keeping track of peering interfaces in peeringDB is great. For your backbone, you really want a database to track them. Spreadsheets don't scale terribly well. ^_^; At least use a reverse DNS zone file Come up with a good numbering plan for IPv6!! If you take first /48 for infrastructure, take first /64 for loopbacks, You can take the opportunity to change your architecture for v6 if you want, but it's easier to keep is same as v4 so you don't have to keep track of two topologies. Architecture choices: simple one: loopbacks and connected infrastructure only in IGP rest of stuff in BGP Configure your backbone Numbering plan? IPv4 4th octet/32 -> IPv6 ::X/128 enable OSPFv3 if you're running OSPF: ipv6 router ospf 12456 enable v6 on interface configure OSPF for interface do same thing on next router, verify the link is up, reachable, and routed. Managing assignments with DNS zone you can just increment /48s in your zone file don't forget that after 9 comes a! It shouldn't take very long to do this, even for a midsized network. It's tedious, but not hard. To reach the outside world, need some BGP configure a new v6 peer group, you can mirror your v4 peer group, but with route-maps and lists that match v6 elements. Naming them -V6 makes it easier to spot them later. iBGP will be loopback to loopback, next-hop-self, like with v4. You can build a common config to be pushed out. iBGP will handle connected interfaces (except loopbacks) route-maps use slightly different syntax for v6 matching: match ipv6 address matchall Don't panic when you do address-family ipv6 it will reformat your config, your next Rancid run will look scary, but it really didn't break your whole router. You can build a common config chunk for all the IBGP configs, and push it out. Still doesn't let you reach outside world. Next up, configure your external peers. New peer group for v6 peers; you'll need new sanity lists, there's not as many well-defined bogon filters; but at least set filters on sizes seq 5 permit ::/0 ge 16 le 48 Create a list of your ASNs IPv6 prefix(es) to allow out. create route maps, use same communities and localprefs to match what you use in v4 Next, send email to peering at he.net to get BGP up; send the peering info file you collected early on. Next up, turn up a peer with he.net, you'll see the neighbor come up, and you can reach the world now. :D show bgp ipv6 unicast summary show bgp ipv6 unicast neighbor X::Y adv make sure you're sending and receiving the expected routes; do some traceroutes and pings, make sure it looks good. Go ahead and continue turning up more peers. Attaching a host to the v6 network. use a *nonproduction* host to test with first! Find a lab box, look at v4 routing and config; allocate a /64 from your DNS zone file (figure out your regional aggregation at some point) Configure interface facing host, and depending on the OS version, it may autoconfigure itself. No more ARP, you can try to ping, you can look at the neighbor table to see if your host is there. Check your iBGP, see if you see the subnet in your table now (first connected non-IGP subnet) look at http://ripe.net/ to see if you get there via v6 or not. Note about SLAAC--the moment you configure the interface on your router, *every* host on the subnet can get a v6 address! Make SURE you have your security concerns squared away before you do this! Time to add nameservice Add DNS reverse...is ugly. Look at the slide. forward: ns0 IN AAAA blech reload nameserver Note that your machine is now on the global v6 internet with every port open; in fact, every host on that subnet is now on the global v6 internet. you MUST make sure your security policy is ready to handle IPv6 security similar to IPv4! Peering--just about everyone out there will peer via v6 at the moment; it's the right time to dive in and make it happen. Start working with a good beta customer to start developing customer route maps, customer neighbor configs (most of which will be mirrors of your v4 configs and route maps, but with different address families and different filters) Most networks are allowing multihoming of /48s at this point, so you can let your downstream customer know it's OK for them to announce the /48 to their other upstream as well. Step 1 is pretty easy; the network side isn't that scary. Step 2, getting hosts and content up and running with security policy in place, operations staff comfortable on IPv6, etc is the harder part. So, on the network side, getting IPv6 up and running isn't hard; it's very, very similar to v4. Leo Bicknell--thanks for a great presentation, good summary. Few small items. BGP change on IOS, it does reformat things; there is a command "bgp upgrade-cli" will change your config to new format ahead of time to let you check the delta ahead of time. Presentation is heavy on IOS classic configs. IOS-xr and JunOS allows for common policies for both, with different lines and different terms for v4 and v6; makes configs even simpler. Lastly, with IPv6 reverse, people forget that $ORIGIN exists, so you can make the zone files look considerably easier to read. Humans seem to work better when v6 host address and v4 address map to each other statically, rather than using SLAAC and having hosts change when NICs change. A: Very true, that's more of step 2, but this is very very good information to know. Arjin, AMS-IX, since autoconfig is on by default, might want to turn them off on exchange point interfaces. Cathy says this looks like the beginnings of a WONDERFUL best current practices document; let's turn it into one! Next up is Betty with some results for us from the elections. 196 people voted Candidates: Steve Feldman, Sylvie LaPierre, and Duane Wessels are new SC members. Austin, Texas, NANOG 48, see you Feb 21-24 2010. Thanks to ARIN, Arbor, and Merit for this meeting! There's new SC members; we're at the first point since the restructuring where people have hit term limits. Josh, Joel, Ren, Todd, have been serving since the revolution, and are aging out--a big round of applause for them as well. AND FILL OUT YOUR SURVEY!!! http://tinyurl.com/nanog47 John Curran notes there is a break, and ARIN will start at 11am. :) BREAK TIME. From nanog at shreddedmail.com Wed Oct 21 10:07:25 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Wed, 21 Oct 2009 08:07:25 -0700 Subject: Consistent asymetric latency on monitoring? Message-ID: Although the implementation is Cisco-specific, this feels more appropriate for NANOG. We've started rolling out a state-wide monitoring system based on Cisco's "IP SLA" feature set. Out of 5 sites deployed so far (different locations, different providers), we are consistently seeing one-way latency mirror the opposite direction. As source-destination latency goes up, destination-source latency goes down and vice versa. Myself and the monitoring team have ripped apart the OIDs, IP SLA configuration, and monitoring system. We've also built an ad-hoc system to compare the results. It's still consistent behavior. It's not a true mirror; there is definitely variation between the data collection, but at the 10,000 foot level, there is an obvious and consistent mirror to the data. The network topology is independant service providers all providing backhaul to a local ethernet exchange. Has anybody seen this type of behavior? We are solidly convinced that we are using the proper OIDs and making the proper transformations of the data. The two remaining causes appear to be either "natural behavior of the links" and/or "artifact in the IP SLA mechanism". Any ideas? Thanks! From rps at maine.edu Wed Oct 21 10:37:42 2009 From: rps at maine.edu (Ray Soucy) Date: Wed, 21 Oct 2009 11:37:42 -0400 Subject: 2009.10.21 NANOG47 day 3 notes Message-ID: <7a6830090910210837r780d2c3ao2fab45d305db39a1@mail.gmail.com> Regarding: http://nanog.org/meetings/nanog47/presentations/Wednesday/Hughes_Kosters_fundamentals_N47_Wed.pdf Very common misconception for the "ipv6 enable" interface config statement for IOS on slides 19, 21, etc. The "ipv6 enable" statement is only necessary to enable IPv6 on an interface if you are not assigning it an IPv6 address (e.g. this will simply enable IPv6 with a LL address). Otherwise it is useless. Would be a good idea to stop spreading the false assumption that "ipv6 enable" determines whether or not IPv6 is active on an interface. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From jabley at hopcount.ca Wed Oct 21 10:43:01 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 21 Oct 2009 11:43:01 -0400 Subject: 2009.10.21 NANOG47 day 3 notes In-Reply-To: <63ac96a50910210754p664ac67eifb8ca9546b01ca9@mail.gmail.com> References: <63ac96a50910210754p664ac67eifb8ca9546b01ca9@mail.gmail.com> Message-ID: <7224BB43-36BE-471F-94C8-88F10308A2CC@hopcount.ca> Matt, On 2009-10-21, at 10:54, Matthew Petach wrote: > And last, but not least, here's the notes from the morning > part of the NANOG meeting. As someone who had to disappear early from the meeting for various reasons, your notes are fabulously useful (much better than video archives, for me, in fact). Many thanks once again for taking the time to make them. (followups set) Joe From jeff.gallagher at bellaliant.ca Wed Oct 21 10:54:28 2009 From: jeff.gallagher at bellaliant.ca (Jeff Gallagher) Date: Wed, 21 Oct 2009 13:24:28 -0230 Subject: CRTC rules on Traffic Management Practices Message-ID: For those following the regulatory / net neutrality debate, the Canadian Radio and Telecommunications Commission released this morning a decision requiring additional transparency with respect to the traffic management practices of Canadian service providers. News Release: http://www.crtc.gc.ca/eng/NEWS/RELEASES/2009/r091021.htm Policy Details: http://www.crtc.gc.ca/eng/archive/2009/2009-657.htm Jeff Gallagher? ? Network Engineering jeff.gallagher at bellaliant.ca From michael at linuxmagic.com Wed Oct 21 11:03:21 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Wed, 21 Oct 2009 09:03:21 -0700 Subject: CRTC rules on Traffic Management Practices In-Reply-To: References: Message-ID: <200910210903.21863.michael@linuxmagic.com> Holy Hannah! ISP actions affecting content According to the Telecommunications Act, a telecommunications company must obtain the Commission?s prior approval to ?control the content or influence the meaning or purpose of telecommunications? carried over its network. The Commission does not consider such disruptive actions to be proper Internet traffic management practices, and they will always require prior approval. An ISP would therefore need to seek the Commission?s approval before it implemented a practice that would: block the delivery of content to an end-user, or slow down time-sensitive traffic, such as videoconferencing or Internet telephone (Voice over Internet Protocol) services, to the extent that the content is degraded. When faced with these requests, the Commission will only grant its approval in the most exceptional cases. The email marketing lobby already got the legislation watered down on the spam front, but does this in essence say that ISP's are no longer allowed to block email content, viruses et al? On October 21, 2009, Jeff Gallagher wrote: > For those following the regulatory / net neutrality debate, the Canadian > Radio and Telecommunications Commission released this morning a decision > requiring additional transparency with respect to the traffic management > practices of Canadian service providers. > > News Release: > http://www.crtc.gc.ca/eng/NEWS/RELEASES/2009/r091021.htm > > Policy Details: > http://www.crtc.gc.ca/eng/archive/2009/2009-657.htm > > > Jeff Gallagher > Network Engineering > jeff.gallagher at bellaliant.ca > -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From jabley at hopcount.ca Wed Oct 21 11:14:53 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 21 Oct 2009 12:14:53 -0400 Subject: CRTC rules on Traffic Management Practices In-Reply-To: <200910210903.21863.michael@linuxmagic.com> References: <200910210903.21863.michael@linuxmagic.com> Message-ID: On 2009-10-21, at 12:03, Michael Peddemors wrote: > The email marketing lobby already got the legislation watered down > on the spam > front, but does this in essence say that ISP's are no longer allowed > to block > email content, viruses et al? No more null-routing targets in your own network as a DDoS mitigation technique? Joe From tim at broadlinenetworks.com Wed Oct 21 11:59:42 2009 From: tim at broadlinenetworks.com (Tim Lampman) Date: Wed, 21 Oct 2009 12:59:42 -0400 Subject: CRTC rules on Traffic Management Practices In-Reply-To: <200910210903.21863.michael@linuxmagic.com> References: <200910210903.21863.michael@linuxmagic.com> Message-ID: <4ADF3DFE.3070801@broadlinenetworks.com> Realistically this has to do with one main thing, traffic throttling (Mainly of bittorrent and other p2p applications). In previous decisions and hearings they discussed at length the management of networks in regards to spam and viruses. These have nothing to do with what this ruling is about and they stated that there is a clear distinction between managing spam and viruses and management of traffic for specific applications. This ruling really doesn't amount to much at this point as bell, rogers, shaw, cogeco etc will all still throttle whatever they want, whenever they want without much regard for the rulings of the CRTC. They ignore many other rulings every day, why would this one be any different. Michael Peddemors wrote: > Holy Hannah! > > ISP actions affecting content > According to the Telecommunications Act, a telecommunications company must > obtain the Commission?s prior approval to ?control the content or influence > the meaning or purpose of telecommunications? carried over its network. The > Commission does not consider such disruptive actions to be proper Internet > traffic management practices, and they will always require prior approval. > An ISP would therefore need to seek the Commission?s approval before it > implemented a practice that would: > block the delivery of content to an end-user, or > slow down time-sensitive traffic, such as videoconferencing or Internet > telephone (Voice over Internet Protocol) services, to the extent that the > content is degraded. > When faced with these requests, the Commission will only grant its approval in > the most exceptional cases. > > The email marketing lobby already got the legislation watered down on the spam > front, but does this in essence say that ISP's are no longer allowed to block > email content, viruses et al? > > > > On October 21, 2009, Jeff Gallagher wrote: > >> For those following the regulatory / net neutrality debate, the Canadian >> Radio and Telecommunications Commission released this morning a decision >> requiring additional transparency with respect to the traffic management >> practices of Canadian service providers. >> >> News Release: >> http://www.crtc.gc.ca/eng/NEWS/RELEASES/2009/r091021.htm >> >> Policy Details: >> http://www.crtc.gc.ca/eng/archive/2009/2009-657.htm >> >> >> Jeff Gallagher >> Network Engineering >> jeff.gallagher at bellaliant.ca >> >> > > > -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *c.* 905-746-3114 www.broadlinenetworks.com | tim at broadlinenetworks.com From jabley at hopcount.ca Wed Oct 21 12:09:16 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 21 Oct 2009 13:09:16 -0400 Subject: CRTC rules on Traffic Management Practices In-Reply-To: References: <200910210903.21863.michael@linuxmagic.com> Message-ID: On 2009-10-21, at 12:14, Joe Abley wrote: > On 2009-10-21, at 12:03, Michael Peddemors wrote: > >> The email marketing lobby already got the legislation watered down >> on the spam >> front, but does this in essence say that ISP's are no longer >> allowed to block >> email content, viruses et al? > > No more null-routing targets in your own network as a DDoS > mitigation technique? Some better-informed person dropped me a note off-list, pointing me to the following. On the face of it it seems like consideration for this aspect has already been incorporated into the ruling. >> ITMPs used for network security or employed temporarily to protect >> network integrity >> >> 44. >> The Commission notes that Canadian ISPs have used certain ITMPs >> for the purposes of network security and integrity. Specifically, >> these >> ITMPs have been employed to protect users from network threats such >> as >> malicious software, spam, and distribution of illicit materials. In >> the >> Commission's view, such activities are unlikely to trigger >> complaints or >> concerns under the Act and are a necessary part of an ISP's network >> operations. >> >> 45. >> The Commission is therefore not addressing, in this decision, >> ITMPs used only for the purpose of network security, nor those >> employed >> temporarily9 to address unpredictable traffic events (e.g. traffic >> surges due to global events and failures on part of an ISP's >> network) in >> order to protect network integrity. From jmaimon at ttec.com Wed Oct 21 12:16:10 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 21 Oct 2009 13:16:10 -0400 Subject: CRTC rules on Traffic Management Practices In-Reply-To: <4ADF3DFE.3070801@broadlinenetworks.com> References: <200910210903.21863.michael@linuxmagic.com> <4ADF3DFE.3070801@broadlinenetworks.com> Message-ID: <4ADF41DA.6040709@ttec.com> Tim Lampman wrote: > Realistically this has to do with one main thing, traffic throttling > (Mainly of bittorrent and other p2p applications). > In previous decisions and hearings they discussed at length the > management of networks in regards to spam and viruses. > These have nothing to do with what this ruling is about and they stated > that there is a clear distinction > between managing spam and viruses and management of traffic for specific > applications. > > This ruling really doesn't amount to much at this point as bell, rogers, > shaw, cogeco etc will all still throttle whatever they > want, whenever they want without much regard for the rulings of the > CRTC. They ignore many other rulings every day, > why would this one be any different. > The issue that interests me most is the reputed filtering and throttling performed by these companies for broadband L2 connections backhauled to ISP's doing the L3 on them, such as with ATM or L2TP. In that scenario, a broadband user who is a customer of Mom'N'Pop ISP is getting throttled by a third party providing a L2 backhaul. From what you have posted, this would now require prior approval. As I feel strongly that this behavior is quite wrong and should not happen, I am encouraged by these rules. Joe From tim at broadlinenetworks.com Wed Oct 21 12:22:33 2009 From: tim at broadlinenetworks.com (Tim Lampman) Date: Wed, 21 Oct 2009 13:22:33 -0400 Subject: CRTC rules on Traffic Management Practices In-Reply-To: <4ADF41DA.6040709@ttec.com> References: <200910210903.21863.michael@linuxmagic.com> <4ADF3DFE.3070801@broadlinenetworks.com> <4ADF41DA.6040709@ttec.com> Message-ID: <4ADF4359.4090003@broadlinenetworks.com> Joe Maimon wrote: > > > Tim Lampman wrote: >> Realistically this has to do with one main thing, traffic throttling >> (Mainly of bittorrent and other p2p applications). >> In previous decisions and hearings they discussed at length the >> management of networks in regards to spam and viruses. >> These have nothing to do with what this ruling is about and they >> stated that there is a clear distinction >> between managing spam and viruses and management of traffic for >> specific applications. >> >> This ruling really doesn't amount to much at this point as bell, >> rogers, shaw, cogeco etc will all still throttle whatever they >> want, whenever they want without much regard for the rulings of the >> CRTC. They ignore many other rulings every day, >> why would this one be any different. >> > > The issue that interests me most is the reputed filtering and > throttling performed by these companies for broadband L2 connections > backhauled to ISP's doing the L3 on them, such as with ATM or L2TP. > > In that scenario, a broadband user who is a customer of Mom'N'Pop ISP > is getting throttled by a third party providing a L2 backhaul. > > From what you have posted, this would now require prior approval. As I > feel strongly that this behavior is quite wrong and should not happen, > I am encouraged by these rules. > > Joe > It would appear this is how it should be, however the track record of Bell heeding the CRTC's rulings has not been good. Last year Bell was ordered to offer matching speeds to their wholesale GAS customers to that of their retail offerings, they simply never complied. This ruling only applies to time sensitive traffic, most of which Bell does not currently throttle. While I think most people would agree that its completely wrong to throttle the traffic of a third party wholesale customer, the reality is that Bell does this every day and will continue to do so regardless of what the CRTC tells them. -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *c.* 905-746-3114 www.broadlinenetworks.com | tim at broadlinenetworks.com From chris at chrisserafin.com Wed Oct 21 12:56:35 2009 From: chris at chrisserafin.com (ChrisSerafin) Date: Wed, 21 Oct 2009 12:56:35 -0500 Subject: ISP/VPN's to China? Message-ID: <4ADF4B53.7020001@chrisserafin.com> I have a client in the US looking to connect up an office in China and I'm wondering what type of connections are avilable and wether IPSEC VPNs can be established through the 'Great firewall of China'. I talked to a China Telcom rep in the US that says that the network congestion even in China makes VPN's difficult. From their website, I see that the majority of the country is using xDSL, or 2MB dedicated lines. Can anyone shed any light on this topic? Thanks! chris at chrisserafin.com From fred at cisco.com Wed Oct 21 13:16:28 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 21 Oct 2009 11:16:28 -0700 Subject: ISP/VPN's to China? In-Reply-To: <4ADF4B53.7020001@chrisserafin.com> References: <4ADF4B53.7020001@chrisserafin.com> Message-ID: I travel to China at least once a year, often several times. I generally visit major cities like Shanghai and Beijing, but have been to a number of other cities. I generally use Cisco VPN (an IPsec VPN) to Cisco DMZs in Tokyo or Hong Kong for business purposes. As with hotels in other parts of the world, congestive interference depends a lot on the hotel and what the person you're competing with is doing. I can tell you a few horror stories if you're amused by them, but in recent years things have been improving. On Oct 21, 2009, at 10:56 AM, ChrisSerafin wrote: > I have a client in the US looking to connect up an office in China > and I'm wondering what type of connections are avilable and wether > IPSEC VPNs can be established through the 'Great firewall of China'. > > I talked to a China Telcom rep in the US that says that the network > congestion even in China makes VPN's difficult. From their website, > I see that the majority of the country is using xDSL, or 2MB > dedicated lines. > > Can anyone shed any light on this topic? Thanks! > > chris at chrisserafin.com > From jmaimon at ttec.com Wed Oct 21 13:42:52 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 21 Oct 2009 14:42:52 -0400 Subject: CRTC rules on Traffic Management Practices In-Reply-To: <4ADF4359.4090003@broadlinenetworks.com> References: <200910210903.21863.michael@linuxmagic.com> <4ADF3DFE.3070801@broadlinenetworks.com> <4ADF41DA.6040709@ttec.com> <4ADF4359.4090003@broadlinenetworks.com> Message-ID: <4ADF562C.9040902@ttec.com> Tim Lampman wrote: > Joe Maimon wrote: >> In that scenario, a broadband user who is a customer of Mom'N'Pop ISP >> is getting throttled by a third party providing a L2 backhaul. >> >> From what you have posted, this would now require prior approval. As I >> feel strongly that this behavior is quite wrong and should not happen, >> I am encouraged by these rules. >> >> Joe >> > It would appear this is how it should be, however the track record of > Bell heeding the CRTC's rulings has not been good. Last year Bell was > ordered to offer matching speeds to their wholesale GAS customers to > that of their retail offerings, they simply never complied. This ruling > only applies to time sensitive traffic, most of which Bell does not > currently throttle. While I think most people would agree that its > completely wrong to throttle the traffic of a third party wholesale > customer, the reality is that Bell does this every day and will continue > to do so regardless of what the CRTC tells them. > Disappointing, but at least it is not a step in the wrong direction. From bbillon-ml at splio.fr Wed Oct 21 14:14:56 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Wed, 21 Oct 2009 21:14:56 +0200 Subject: ISP/VPN's to China? In-Reply-To: <4ADF4B53.7020001@chrisserafin.com> References: <4ADF4B53.7020001@chrisserafin.com> Message-ID: <4ADF5DB0.5030909@splio.fr> Hi, if you're talking about Mainland China in general (not Hong Kong specifically), indeed IPSEC VPN may not provide desired level of service. During the time I spent there, we opted for: - CNC MPLS for 4 sites in China - Equant MPLS between Beijing and other worldwide sites - Then replaced at high price Equant by Verizon MPLS in order to connect worldwide sites through Pacific links instead of Suez Canal - Then replaced Verizon by higher bandwidth Equant MPLS because Verizon's service was seriously bad. Not the link, but the service around it. At that time, Verizon used China Telecom as contractor, and I think Equant used CNC. Not sure about that, though. Between each site (Beijing to three others in China, and Beijing to others worldwide), there was backup IPSEC VPN set up "just in case". Hopefully we didn't had to use them, because they was down from time to time and bandwidth was inconsistent. "Great Firewall buddy" is not to charge this time. ChrisSerafin a ?crit : > I have a client in the US looking to connect up an office in China and > I'm wondering what type of connections are avilable and wether IPSEC > VPNs can be established through the 'Great firewall of China'. > > I talked to a China Telcom rep in the US that says that the network > congestion even in China makes VPN's difficult. From their website, I > see that the majority of the country is using xDSL, or 2MB dedicated > lines. > > Can anyone shed any light on this topic? Thanks! > > chris at chrisserafin.com > From iljitsch at muada.com Wed Oct 21 14:42:43 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 21 Oct 2009 21:42:43 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <1255837860.18603.1008.camel@karl> References: <1255837860.18603.1008.camel@karl> Message-ID: On 18 okt 2009, at 5:51, Karl Auer wrote: > Do the advertisements "right", advise sysadmins that hosts should > not do > SLAAC, Doesn't it tell you something that you're fighting this hard to avoid hosts from doing what comes naturally? It occurs to me that I haven't met anyone who uses the term "SLAAC" who uses IPv6 in a way that I would consider normal. (Or at all.) From iljitsch at muada.com Wed Oct 21 14:46:08 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 21 Oct 2009 21:46:08 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: On 18 okt 2009, at 10:03, Andy Davidson wrote: > Support default-routing options for DHCPv6 ! This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. And DHCPv6 is just a case of very bad design, don't expect it to work well without bending over backwards even farther than you're used to with DHCPv4. It's time for this DHC stuff to reach its final resting place. From drc at virtualized.org Wed Oct 21 14:50:56 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 21 Oct 2009 12:50:56 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> Iljitsch, On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: > On 18 okt 2009, at 10:03, Andy Davidson wrote: >> Support default-routing options for DHCPv6 ! > This would be a big mistake. [...] It's time for this DHC stuff to reach its final resting place. I'm curious: are you anticipating IPv4 network operators are willing/interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? Regards, -drc From tvest at eyeconomics.com Wed Oct 21 14:56:29 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Wed, 21 Oct 2009 15:56:29 -0400 Subject: ISP/VPN's to China? In-Reply-To: <4ADF5DB0.5030909@splio.fr> References: <4ADF4B53.7020001@chrisserafin.com> <4ADF5DB0.5030909@splio.fr> Message-ID: <4B30B1E8-31FF-4F46-AFB2-0BD42CB135D8@eyeconomics.com> Very interesting rundown of current infrastructure option -- thanks! On Oct 21, 2009, at 3:14 PM, Benjamin Billon wrote: > Hi, > > if you're talking about Mainland China in general (not Hong Kong > specifically), indeed IPSEC VPN may not provide desired level of > service. > During the time I spent there, we opted for: > - CNC MPLS for 4 sites in China > - Equant MPLS between Beijing and other worldwide sites > - Then replaced at high price Equant by Verizon MPLS in order to > connect worldwide sites through Pacific links instead of Suez Canal > - Then replaced Verizon by higher bandwidth Equant MPLS because > Verizon's service was seriously bad. Not the link, but the service > around it. > > At that time, Verizon used China Telecom as contractor, and I think > Equant used CNC. Not sure about that, though. Verizon = CT: also consistent with my memory (and an easy guess since there is no alternative) Equant = CNC: Perhaps you mean China Unicom =) TV > Between each site (Beijing to three others in China, and Beijing to > others worldwide), there was backup IPSEC VPN set up "just in case". > Hopefully we didn't had to use them, because they was down from time > to time and bandwidth was inconsistent. > > "Great Firewall buddy" is not to charge this time. > > ChrisSerafin a ?crit : >> I have a client in the US looking to connect up an office in China >> and I'm wondering what type of connections are avilable and wether >> IPSEC VPNs can be established through the 'Great firewall of China'. >> >> I talked to a China Telcom rep in the US that says that the network >> congestion even in China makes VPN's difficult. From their website, >> I see that the majority of the country is using xDSL, or 2MB >> dedicated lines. >> >> Can anyone shed any light on this topic? Thanks! >> >> chris at chrisserafin.com >> > From jbates at brightok.net Wed Oct 21 14:56:31 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 21 Oct 2009 14:56:31 -0500 Subject: 2009.10.21 NANOG47 day 3 notes In-Reply-To: <7a6830090910210837r780d2c3ao2fab45d305db39a1@mail.gmail.com> References: <7a6830090910210837r780d2c3ao2fab45d305db39a1@mail.gmail.com> Message-ID: <4ADF676F.6090705@brightok.net> Ray Soucy wrote: > Would be a good idea to stop spreading the false assumption that "ipv6 > enable" determines whether or not IPv6 is active on an interface. > Play with IPv6 and is-is enough on a Cisco router, and you'll enable it as a matter of practice too. It's the definitive way to say "yes, this interface needs IPv6 active and I don't care if there's an address bound or not". I forget the exact circumstances, but I ran into several cases where I had undesired results and needed to manually enable IPv6 on an interface. Oh, and different versions of IOS behave differently towards IPv6. Imagine that. Jack From owen at delong.com Wed Oct 21 14:55:29 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Oct 2009 12:55:29 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: > On 18 okt 2009, at 10:03, Andy Davidson wrote: > >> Support default-routing options for DHCPv6 ! > > This would be a big mistake. Fate sharing between the device that > advertises the presence of a router and the device that forwards > packets makes RAs much more robust than DHCPv4. And DHCPv6 is just a > case of very bad design, don't expect it to work well without > bending over backwards even farther than you're used to with DHCPv4. > It's time for this DHC stuff to reach its final resting place. You keep arguing this and you're still wrong. There are very good reasons that some people need this in their real world networks. I'm happy for you that you don't need or want to run DHCPv6 in your environment. I'm somewhat happy for me that I almost don't need it in mine. However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent this choice at the operator level. Owen From iljitsch at muada.com Wed Oct 21 15:05:44 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 21 Oct 2009 22:05:44 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> Message-ID: On 21 okt 2009, at 21:50, David Conrad wrote: > On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: >> On 18 okt 2009, at 10:03, Andy Davidson wrote: >>> Support default-routing options for DHCPv6 ! >> This would be a big mistake. [...] It's time for this DHC stuff to >> reach its final resting place. > I'm curious: are you anticipating IPv4 network operators are willing/ > interested/planning on redesigning/rebuilding their entire > provisioning and backend systems in order to support IPv6? No. Hence the low IPv6 utilization. Then again, if we remove all the improvements from IPv6 what's the point of adopting it? The problem with DHCP is that it is an old answer to an even older question. Strangely, DHCPv6 is even worse in this regard than DCHPv4. Some protocol designers were clearly sleeping on the job there, or they were to busy getting in the way of those of us who wanted a non- DHCP way to configure DNS resolvers. Whathever the reason, DHCPv6 is riddled with a badly specified way to interact with manual configuration and stateless autoconfig, it lacks a prefix length option and it has two modes, where the server knows which mode should be used but the client has to guess the right one. In this day and age it doesn't make an iota worth of sense to update binary protocols on two sides whenever there is something new to discover. What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration. Of course that's not going to happen but taking stuff away from IPv6 that actually works (RA fate sharing) isn't going to solve the DHCPv6 problems. From rps at maine.edu Wed Oct 21 15:08:10 2009 From: rps at maine.edu (Ray Soucy) Date: Wed, 21 Oct 2009 16:08:10 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <1255837860.18603.1008.camel@karl> Message-ID: <7a6830090910211308l15142f47u833cc1b383ec55cf@mail.gmail.com> I respectfully disagree. In my opinion there is no future for IPv6 that doesn't involve DHCPv6. DHCPv6 is part of the design of IPv6 as is clear by the existence of M, O, and A flags in RA. Without DHCPv6, SLAAC has no way to provide DNS (or other) configuration information, the fact that IPv6 was designed in a way where SLAAC could be used for addressing and DHCPv6 for "other" configuration is an example of how DHCPv6 is an integral component of IPv6. SLAAC was designed to make IPv6 work out of the box for ad-hoc networks (link local scope for example). It's increasingly clear that the designers never intended for SLAAC to "replace" DHCPv6 or that DHCPv6 wasn't a necessary part of IPv6, especially once you deploy it in an enterprise environment. What we've seen is a community of early adopters who are so eager to deploy IPv6 that they're willing to make compromises that most would question. I think we need to get into the mindset that any implementation of IPv6 that doesn't include a DHCPv6 client is as incomplete as one that doesn't support ICMPv6. Support from vendors will eventually fall into place. If more of the so-called advocates of IPv6 would stop talking about how DHCPv6 isn't necessary it would likely happen more quickly. Both SLAAC and DHCPv6 have their roles to fill; both are required. As for the use of the term SLAAC... it's usage is pretty widespread. On Wed, Oct 21, 2009 at 3:42 PM, Iljitsch van Beijnum wrote: > On 18 okt 2009, at 5:51, Karl Auer wrote: > >> Do the advertisements "right", advise sysadmins that hosts should not do >> SLAAC, > > Doesn't it tell you something that you're fighting this hard to avoid hosts > from doing what comes naturally? > > It occurs to me that I haven't met anyone who uses the term "SLAAC" who uses > IPv6 in a way that I would consider normal. (Or at all.) > > -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From iljitsch at muada.com Wed Oct 21 15:08:13 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 21 Oct 2009 22:08:13 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: <82B547ED-9637-4435-9F53-253551299555@muada.com> On 21 okt 2009, at 21:55, Owen DeLong wrote: > However, making it available as an option in DHCPv6 allows the end- > user/operator > to choose the technology that fits their needs best. I do not know > why you are so > determined to prevent this choice at the operator level. For the same reason that we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears. If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA. From cordmacleod at gmail.com Wed Oct 21 15:21:13 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Wed, 21 Oct 2009 13:21:13 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910211308l15142f47u833cc1b383ec55cf@mail.gmail.com> References: <1255837860.18603.1008.camel@karl> <7a6830090910211308l15142f47u833cc1b383ec55cf@mail.gmail.com> Message-ID: On Oct 21, 2009, at 1:08 PM, Ray Soucy wrote: > > Without DHCPv6, SLAAC has no way to provide DNS (or other) > configuration information, the fact that IPv6 was designed in a way > where SLAAC could be used for addressing and DHCPv6 for "other" > configuration is an example of how DHCPv6 is an integral component of > IPv6. Didn't RFC 4339 cover most of this? http://tools.ietf.org/html/rfc4339 From cmadams at hiwaay.net Wed Oct 21 15:23:04 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 Oct 2009 15:23:04 -0500 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> Message-ID: <20091021202304.GH1561963@hiwaay.net> Once upon a time, Iljitsch van Beijnum said: > What we need is a thing that gives us what we need to > connect to the network (addresses, DNS servers) and then a pointer in > the form of an HTTP or HTTPS URL for all other configuration. You want to invent yet _another_ form of configuration management? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From iljitsch at muada.com Wed Oct 21 15:33:15 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 21 Oct 2009 22:33:15 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091021202304.GH1561963@hiwaay.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> <20091021202304.GH1561963@hiwaay.net> Message-ID: <6889FCD2-F103-4EC7-B2CE-41909DD15E82@muada.com> On 21 okt 2009, at 22:23, Chris Adams wrote: >> What we need is a thing that gives us what we need to >> connect to the network (addresses, DNS servers) and then a pointer in >> the form of an HTTP or HTTPS URL for all other configuration. > You want to invent yet _another_ form of configuration management? Short answer: no, life is too short and I have other problems that need solving. Long answer: what we have now is a mess, if we want to clean up the mess we have to get it right, and putting new options in binary protocols is not right in any way, shape or form. From james.cutler at consultant.com Wed Oct 21 15:37:40 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Wed, 21 Oct 2009 16:37:40 -0400 Subject: [DHCPv6] was Re: IPv6 Deployment for the LAN Message-ID: We have networks and businesses to run. Why are we rehashing this yet again? For example, in December 200l http://www.merit.edu/mail.archives/nanog/2007-12/msg00280.html shows messages regarding exactly this issue. for emphasis I redundantly requote, "You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box!" Just in case the URL is faulty, here is the primary content of the referenced page of NANOG list history: And, besides the list forwarded below, Designated printers, Preferred DNS Servers, and, maybe, more. Even in a large enterprise, the ratio of "routers" to DHCP servers makes control of many end system parameters via DHCP a management win compared to configuration of "routers" with this "non-network core" data. (In case I was to abstruse, It is cheaper to maintain end system parameters in a smaller number of DHCP servers than in a larger number of "routers".) This is completely separate from the fact that many experienced router engineers are smart enough configure routers with NTP server addresses in preference to DNS names, and likewise for many other parameters. The end system population has requirements which respond much more dynamically to business requirements than do router configurations, which respond mostly to wiring configurations which are, by comparison, static. The statement that DHCP is not needed for IPv6 packet routing may well be exactly accurate. The absence of good DHCP support in IPv6 has costly consequences for enterprise management, of which IP routing is a small part. You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Cutler Begin forwarded message: From: Leo Bicknell Date: December 27, 2007 7:33:08 PM EST To: North American Network Operators Group Subject: Re: v6 subnet size for DSL & leased line customers In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - bicknell at xxxxxxx - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at xxxxxxxx, www.tmbg.org James R. Cutler james.cutler at consultant.com From cordmacleod at gmail.com Wed Oct 21 15:42:36 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Wed, 21 Oct 2009 13:42:36 -0700 Subject: equinix is acquiring switch & data Message-ID: <1A49012C-8099-4DD0-AC24-AABB5A5DAD1D@gmail.com> http://www.equinix.com/news/press/na/2009/news-5109/ Thought this was relevant. From rps at maine.edu Wed Oct 21 15:45:21 2009 From: rps at maine.edu (Ray Soucy) Date: Wed, 21 Oct 2009 16:45:21 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <6889FCD2-F103-4EC7-B2CE-41909DD15E82@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> <20091021202304.GH1561963@hiwaay.net> <6889FCD2-F103-4EC7-B2CE-41909DD15E82@muada.com> Message-ID: <7a6830090910211345m4243beabo8272e83589a2a95f@mail.gmail.com> What we have now is not a mess. What we have is a solid base to build on. The problem is in education, the fact that both stateless and stateful configuration are valid components to IPv6 for example, and proper implementation by vendors. There are a few challenges with IPv6 that need to be worked out, like RA-gaurd and DHCPv6 snooping, for example, but the core of IPv6 was generally done right. Reading this thread can get rather frustrating, what I've gotten out of the most recent exchange is that the combined suggestion is to add DNS to RA, and to add gateway information to DHCPv6. Well, DHCPv6 already handles DNS quite nicely (and DHCPv6 is about more than just DNS mind you), and RA does a perfect job handling gateway selection. I would love to understand how you feel that the roles of RA and DHCPv6 should be swapped. On Wed, Oct 21, 2009 at 4:33 PM, Iljitsch van Beijnum wrote: > On 21 okt 2009, at 22:23, Chris Adams wrote: > >>> What we need is a thing that gives us what we need to >>> connect to the network (addresses, DNS servers) and then a pointer in >>> the form of an HTTP or HTTPS URL for all other configuration. > >> You want to invent yet _another_ form of configuration management? > > Short answer: no, life is too short and I have other problems that need > solving. > > Long answer: what we have now is a mess, if we want to clean up the mess we > have to get it right, and putting new options in binary protocols is not > right in any way, shape or form. > > -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From owen at delong.com Wed Oct 21 15:48:42 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Oct 2009 13:48:42 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <82B547ED-9637-4435-9F53-253551299555@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> Message-ID: <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> On Oct 21, 2009, at 1:08 PM, Iljitsch van Beijnum wrote: > On 21 okt 2009, at 21:55, Owen DeLong wrote: > >> However, making it available as an option in DHCPv6 allows the end- >> user/operator >> to choose the technology that fits their needs best. I do not know >> why you are so >> determined to prevent this choice at the operator level. > > For the same reason that we don't let the kids play with the > powertools: giving them what they want here just makes everything > end in tears. > > If people want to run DHCPv6, fine, we're all adults. If they want > to go to the IETF and fix what's wrong with DHCPv6, so much the > better. But taking the information from the place where we can make > sure it's correct and putting it in a place where we can only guess > so we break the network regularly is A VERY BAD IDEA. You're incorporating a lot of assertions into your statement there. The assumption that the router "knows" it is correct for every host on a given LAN simply does not map to reality deployed today. DHCPv4 router assignments don't end in tears for the most part today, and, I don't think that DHCPv6 router assignment would be any more broken than the RA system. In many cases, it will be less broken. The assumption that all routers of a given priority are equal for all hosts on a given LAN also doesn't quite work out. DHCPv4 allows me to have multiple sets of VRRP addresses and balance my outbound routing from large LAN segments (imagine a /22 full of 10-g servers pushing ~6G each into a set of routers... Because they're a rendering farm, and the software is somewhat brain-dead, they need to be in the same broadcast domain.) (Yes, I know that broadcast goes away in IPv6, but, this can just as easily be a link-local multicast). With DHCPv4, I can assign different VRRP groups to the systems (with different IPv4 unicast addresses) based either on mac-addresses, or whatever other criteria I choose. Please explain to me how I can achieve this functionality in RA/SLAAC or stop pushing to prevent it from being available in DHCPv6. Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Owen From owen at delong.com Wed Oct 21 15:56:39 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Oct 2009 13:56:39 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> Message-ID: On Oct 21, 2009, at 1:05 PM, Iljitsch van Beijnum wrote: > On 21 okt 2009, at 21:50, David Conrad wrote: > >> On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: >>> On 18 okt 2009, at 10:03, Andy Davidson wrote: >>>> Support default-routing options for DHCPv6 ! >>> This would be a big mistake. [...] It's time for this DHC stuff to >>> reach its final resting place. > >> I'm curious: are you anticipating IPv4 network operators are >> willing/interested/planning on redesigning/rebuilding their entire >> provisioning and backend systems in order to support IPv6? > > No. Hence the low IPv6 utilization. > > Then again, if we remove all the improvements from IPv6 what's the > point of adopting it? > Bigger address space -- The only real improvement in IPv6. > The problem with DHCP is that it is an old answer to an even older > question. Strangely, DHCPv6 is even worse in this regard than > DCHPv4. Some protocol designers were clearly sleeping on the job > there, or they were to busy getting in the way of those of us who > wanted a non-DHCP way to configure DNS resolvers. Whathever the > reason, DHCPv6 is riddled with a badly specified way to interact > with manual configuration and stateless autoconfig, it lacks a > prefix length option and it has two modes, where the server knows > which mode should be used but the client has to guess the right one. > I agree that DHCPv6 should be fixed, but, fixing it should include adding the ability to assign routing information. > In this day and age it doesn't make an iota worth of sense to update > binary protocols on two sides whenever there is something new to > discover. What we need is a thing that gives us what we need to > connect to the network (addresses, DNS servers) and then a pointer > in the form of an HTTP or HTTPS URL for all other configuration. > Yes and no. RA giving out DNS information and a pointer might help, but, it doesn't solve everything. There is functionality provided by DHCPv4 today that is not available in DHCPv6, RA, or SLAAC or any combination. This must get resolved. It is an impediment to IPv6 adoption in the real world. The other features and improvements are all well and good if they work and they don't prevent the protocol from being accepted and/or deployed in the real world. With less than two years of remaining IANA IPv4 free pool, I think it is far more important that we get a deployable protocol with bigger addresses than one which contains a bunch of other features that aren't universally regarded as an improvement at the cost of existing functionality that has demand from real network operators. > Of course that's not going to happen but taking stuff away from IPv6 > that actually works (RA fate sharing) isn't going to solve the > DHCPv6 problems. Nobody is proposing taking RA away from networks that want to use it. We're proposing making it an option to assign router information in DHCPv6. So, given that the question isnt' taking away what you want, can we please now add capabilities that many people actually need? Owen From thegameiam at yahoo.com Wed Oct 21 16:00:39 2009 From: thegameiam at yahoo.com (David Barak) Date: Wed, 21 Oct 2009 14:00:39 -0700 (PDT) Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4801EC82-5E29-4CCE-A18A-A7A53D09C8FC@virtualized.org> Message-ID: <386861.57410.qm@web31802.mail.mud.yahoo.com> ----- Original Message ---- >From: Iljitsch van Beijnum iljitsch at muada.com >Then again, if we remove all the improvements from IPv6 what's the point of adopting it? How about?"IPv4 address depletion?" I'm perfectly happy with how my network works.? I do, however, want it to keep growing, and this requires more addresses.?? The requirement for organizations with thousands (or in some cases millions)?of deployed customers to dramatically change how they can associate an IP address with customer ports (or provide remote configuration of said customers' devices) is not an attractive feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From kloch at kl.net Wed Oct 21 16:20:05 2009 From: kloch at kl.net (Kevin Loch) Date: Wed, 21 Oct 2009 17:20:05 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: <4ADF7B05.5030209@kl.net> Iljitsch van Beijnum wrote: > On 18 okt 2009, at 10:03, Andy Davidson wrote: > >> Support default-routing options for DHCPv6 ! > > This would be a big mistake. Fate sharing between the device that > advertises the presence of a router and the device that forwards packets > makes RAs much more robust than DHCPv4. And DHCPv6 is just a case of > very bad design, don't expect it to work well without bending over > backwards even farther than you're used to with DHCPv4. It's time for > this DHC stuff to reach its final resting place. Then don't use it. That's why it's called an Option :) However some of us actually need to use this stuff and sometimes in ways not imagined by the IETF. - Kevin From David_Hankins at isc.org Wed Oct 21 16:34:26 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Wed, 21 Oct 2009 14:34:26 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> Message-ID: <20091021213426.GA6981@isc.org> I am replying to several people here in one message. I think most issues were covered fairly well, but I obviously like to hear myself talk, and I think there are a few things that need to be said more plainly (I hope). On Sat, Oct 17, 2009 at 08:55:28PM -0400, Ray Soucy wrote: > Looking for general feedback on IPv6 deployment to the edge. Having read the entire thread, I am surprised at how few answers and feedback there are to the actual questions you have posed. It seems people are much more interested in an opportunity to redesign your network for you or grind old hatchets... > Given that historically we have relied on DHCP for a means of NAC and > host registration, like many academic institutions, the idea of > sweeping changes to accommodate IPv6 was just not going to happen in > the near future. Unfortunately, it's a tiny bit worse than that. The IETF adopted the DUID for client identification; it promises to be able to identify a client uniquely across interfaces and NIC swap-outs (the MAC address changes, the DUID does not). This means you can't use the MAC address portion of a DUID reliably. Unfortunately, this completely circumvents all existing typical work flows for user registration or inventory accounting. There is still some work going on to try and reintroduce MAC based accounting to DHCPv6, and there are some proofs of concept available in source form today (but nothing standardized yet). Of course there is no way RA could reliably provide this, and the folks on this mailing list who have proposed you can predict SLAAC addresses based on prefix and MAC are confused; they are not taking into account the many clients that use temporary addresses by default when the A flag is set (these are intentionally not cryptographically predictable), or that clients may need to re-iterate their SLAAC algorithm if interfered with by a peer (not even RA-Guard can save you from that, it is a DAD exploit) and you can't necessarily reliably detect iterations of the algorithm... > Our current IPv6 allocation schema provides for a 64-bit prefix for > each network. Unfortunately, this enables SLAAC; yes, you can > suppress the prefix advertisement, and set the M and O flags, but that > only prevents hosts that have proper implementations of IPv6 from > making use of SLAAC. The concern here is that older hosts with less > than OK implementations will still enable IPv6 without regard for the > stability and security concerns associated with IPv6. > > Needless to say, the thought of being able to enable IPv6 on a > per-host basis is met with far less resistance than opening up the > floodgates and letting SLAAC take control. Ostensibly the solution to this problem is "per host RA", which has seen many drafts at recent IETF's. That is to implement RA in your switches rather than your routers such that router advertisements may be crafted in response to router solicitations on a per-switch-port basis (which might track to per-user). This is of course a completely scalable and well thought out plan showing an obvious foresight to the structure of network configuration management. Any initial assessment that this is some kind of "kludge" or "hack" is completely unfounded, and if managing RA configuration across your entire switch fabric isn't scalable for you, then you just need to rethink your network architecture and buy more tools. After all, your switches are in a better position to know more about prefix and router information than your routers are anyway, so there's no reason to force us all into top-down configuration management models. Things really have become that desperate. On the other hand, as you say, you could "just use DHCPv6." > Ultimately, the best solution that I've been able to come up with is > to preserve the IPv6 allocation schema and reserve a 64-bit prefix for > each network, but for the initial deployment use an 80-bit one in its > place with the extra 16 bits given a value of 1. The advantages of > this: Guarantee that SLAAC will not be initiated for the prefix; > Allow for a migration path to 64-bit prefixes in the future; and, Make > it easy to identify a network that us making use of an 80-bit prefix > by setting the extra bits to a value of 1. I can think of something you may like to know beforehand; There is a problem with the "Both RA and DHCPv6 Model" currently proposed by IETF iconoclasts. Should RA fail, for any reason from router, system, software, network path, security, or user error, then the simplest networks imaginable (where hosts and mail/Intranet/ work servers are all co-located on the same broadcast domain) will not be able to talk to one another, despite having valid IPv6 addresses. The problem is that they no longer know that the prefix for their address is locally connected. To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means. This does neatly work around the problem; the hosts may now speak to one another. But it may complicate your designs if you are assigning /80's. IPv6 does not have 'broadcast addresses' like IPv4 does, it uses a separate multicast address space instead, so there should not be similar non-interoperability issues with mixed prefix lengths as we have had in IPv4. I don't actually know if these circumstances will directly change your current plans, but it could have future ramifications if anyone believed they could segregate clients in separate prefixes under the covering /64. Anyway, I thought that this was the sort of thing you'd like to know. I doubt that many people try to use /80 prefixes or smaller prefixes with anything other than routers (and there, manual address assignment) for point to point links, so you are probably forging new territory here. > Windows XP has a poor implementation of IPv6 but has the option of > using Dibbler or some other 3rd party DHCPv6 client. Dibbler is a solid software package. > Mac OS X is a > challenge; it currently has no option for DHCPv6, though newer > releases provide for manual configuration of IPv6 addressing. According to the release notes of ISC DHCP 4.1.0, ISC 'dhclient -6' compiles and runs on Mac OSX. I don't actually own a Mac, so I have never used it myself, and our release notes even go into detail about the limitations of the current 'dhclient-script' for the Darwin platform (apparently their configuration system is somewhat opaque). But if there are ways our dhclient-script can be improved (perhaps by including other C-based tools to interface with OSX's configuration schemas?), we absolutely accept patches. (any followup to dhcp-users at isc.org and dhcp-bugs at isc.org please, no need to bore NANOG) > Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? No...but I have heard plans of the exact opposite. At one of the last IETF's I attended, there was an experiment during the Plenary session; IPv6 single-stack was provided. At the same time, an escape was provided for those who were unable to use IPv6 single-stack (for whatever reason). This was provided via two competing implementations of "4-6-4 NAT", an experimental technology at the time. According to statistics (DHCPv4 PRL fingerprinting), the most popular client on the 4-6-4 NAT network was OSX. It is supposed that Macs could not get name servers (without manually configuring them), and so could not even start to get net on IPv6 single-stack. When people at the microphone asked why Apple did not include a DHCPv6 client implementation, even a stateless one, I believe Bernard Aboba addressed the concern at the microphone saying, and I am paraphrasing from memory here, "We were told by the IETF that RA was all we would ever need, implementing DHCPv6 is optional, so RA is all we are doing." So, no, I wouldn't say there's been any indication they have plans for a DHCPv6 implementation. It seems they are steadfastly against it, which is disappointing. I don't want to say that queries to Apple's support infrastructure to ask that DHCPv6 be implemented is misplaced, but I think those trying may be "paddling upstream." If there is some change in the direction the water is flowing, I'd be more than happy to lend Apple any assistance I can offer, especially with testing a new DHCPv6 software package; there has not been a DHCPv6 vendor bake-off in years now, Apple has missed the time of opportunity when there was interest in testing implementations against each other, so that sort of thing has to be synthesized anew. If there isn't, then I'm more than happy to provide a locus for coordinating the development of DHCPv6 client services for Macs. > default behavior. Is this likely to happen or am I being too > optimistic? There will be one of three outcomes, with complete certainty. The first is that DHCPv6 becomes feature-complete and widely adopted to finally fulfill the global requirements of host configuration, and not merely those of the IETF iconoclasts' homes and laptops while visiting IETF meetings (where DHCPv4+RA is sufficient). The second is that RA is extended, with new messages as well as new options for host configuration, until it finally becomes DHCP. The third is that some new protocol will be designed, by people who are unapologetic about fulfilling specifically the global requirements of host configuration, which supplants both RA and DHCPv6. On Sun, Oct 18, 2009 at 02:17:58PM -0400, TJ wrote: > Um, DHCPv6 does configure the client - perhaps not until the +M or +O option > is recieved. This, the 'M and O bits', is a very pernicious mistake that I can't resist commenting on (I think TJ you might not have meant it, so this is not necessarily directed at you, but it's a theme I've seen in this thread that "A, M, and O bits are completely reliable"). To summarize, RA+DHCPv6 implementers are posed with problems: 1) Can I trust that RA will be there independently of DHCPv6? 2) Provided it is there, can I trust that the M and O bits will be consistent across all routers on the segment? 3) Provided it is not consistent, which one should I believe? Should DHCPv6 services be turned on and off as the M and O bits toggle? Should it stay on so long as any M or O bit is set in any router (so M and O states must be kept on a per-router basis, leading to yet another problem in that an attacker can attempt to create an infinite number of M-and-O states in the client)? 4) What do you do if both M and O are set? What if O is set but A isn't? 5) It takes time for RS->RA to complete, and then time again for DHCPv6's Solicit->Advertise->Request->Reply to complete. If I run these two in parallel, I get on the net faster and my user is happy about that. Why wouldn't I do that? There are possibly some others I've forgotten. There is for example the entire set of corner cases; e.g. a DHCPv6 client returning to a network segment will "Confirm" to determine if their old binding is still valid for the network they're attached to (laptop returning from hibernate for example) - it'll certainly do this before it receives any RA's. If the DHCPv6 configuration is valid and the Confirm succeeds, are you still supposed to wait (possibly forever) for an RA before installing configuration? This is why the RA RFC's are extremely waffle-mouthed on the subject of what a client should do when it encounters M and O bits. SHOULD and MAY and all that. That waffle-mouthedness is the reason why there are all kinds of bad behaviour in clients receiving RA's; some will start a DHCPv6 client every time M or O toggles 1->0->1->0...and ultimately crash. A RA and DHCPv6 software implementor from Beijing (I think) wrote a draft awhile ago asking for clarity (and from which I'm cribbing his problems list from memory): "I am a software implementor. Tell me clearly what to do here." The official IETF consensus was, in my observation of it, "we can't, we don't even know ourselves, just go make something up. It will work out. Don't write an RFC, no one will ever agree." So we don't have an RFC. But the answer is that a DHCPv6 software implementor's best bet is to simply run DHCPv6 statefully all the time, and run DHCPv6 stateless whenever that fails and SLAAC addresses are successfully configured. That is simply the most reliable thing to do. The RA RFC's are completely permissive of this most liberal interpretation. So as it turns out, whether or not a router is on link has nothing to do with whether or not a DHCPv6 server is on link. So although you may find some implementations that still try and guess something from M and O bits, I suspect these will slowly become fewer and fewer in number. > And RA Guard will fix it for IPv6. Did we have DHCP Guard @ day 1? DHCPv4 you mean? Basically yes, it's just that at the time there wasn't as much need for that sort of thing. It was a simpler time. Also, in my opinion RFC 3118 is more more believable than SEND, and DHCPv* snooping is a more reliable way to enforce switch fabric RPF than anything RA/ND based. There is another issue in the shadows I want to speak to here however. When I worked as an operator, all those years ago, we had a vendor. I don't think their name matters, so I won't share it. They sold server hardware. The details of what would go wrong with their hardware and the ways we would have preferred to work with failing systems aren't important; what's important is their approach to our every complaint that the device they sold us wasn't meeting our expectations, or didn't fit in our network architecture. Every answer to every question was to buy more hardware, or to take a hammer to our network. So we stopped coming to them for solutions, we used folks who answered the question on the first try. It is easier to patronize someone who genuinely wants to solve your problems than to fight them for everything you need. Similarly, with RA, every answer to every question is to buy more software add-ons that just need one more RFC, or to re-architect your network. Twiddle the bits just the right way, set your frob to zero and your woznit to 1 and it's all good, right? I am extremely skeptical that we'll ever reach where we're going if we get there one millimeter at a time all the while redrafting our plans over and over. Someone has forgotten that the reason IPv4 deployed so pervasively is because it was so very trivially simple. You didn't have to know the names of single-bit fields in the headers of ICMPv4 Router Discovery (which really is not very different from IPv6 RA). > > egos from tripping over other egos, each camp kept on their own turf: > > dhcp6 was hobbled to the extent that it couldn't feasibly be called a > > host > > configuration protocol (no default route, no address assignment and no > > Incorrect, DHCPv6 can assign addresses. I think in the spirit he is speaking at the time, he is speaking to the intention of the IETF iconoclasts that, realistically, SLAAC would be the only addressing mechanism used because it is the only universal addressing mechanism, and DHCPv6 would only be used statelessly, if at all. Stateful DHCPv6 service would be relegated to the outlier "unusual" networks. I think perhaps people are starting to learn that networks that use the network management features of DHCPv4 are not quite as unusual as had first been imagined, and that IPv4 will not reach these networks until one can reliably expect the same management features from DHCPv6. > > - there were two protocols required for stateless network management > > instead of one > > - we already had a really good working model in ipv4 > > Perhaps, But I submit that "good" and "working" do not mean "ideal". SLAAC set out to solve a problem that no one had. It chose to complicate the host implementation (SLAAC address generation and the subsequent DAD and SLAAC-iterating is much more complicated than copying a field from DHCP into another field) as the expense for simplifying the router implementation (which now had to just send flat RA messages). Was that really a problem we had before? Looking at just one network (broadcast domain) at a time... How many routers do you have? How many software implementations and versions? How many clients do you have? How many software implementations and versions? Only one of these two things is "ideal" to simplify at the expense of the other. It actually turns out that having a simplistic DHCPv6 server implementation that dumbly creates SLAAC-like addresses and spits them at the client with no state-keeping at all fulfills a superset of the requirements SLAAC solves...and keeps clients simple. SLAAC then becomes a proper subset of network operations requirements, obviated by the existence of a DHCP-like analogue. Eventually we'll get there. > With the addition of RFC5006, you can actually choose just one (once hosts > implement it). > Just not the one you seem to favor. DNS servers and search paths are not the alpha and omega of host configuration. > And I am OK with all that as well, although THAT also complicates scenarios > for implementers. > (Now hosts will need to support two discrete host-configuration protocols > that actively step on each others' capabilities). When we migrated from walking around the office setting our users' computers' IP addresses and configurations manually to BOOTP or RARP, we bled for awhile; we still had to do the dirty work while we waited for implementation support. When we migrated from BOOTP to DHCP, we also had to bleed for awhile, reserving addresses for BOOTP-only clients while migrating systems to DHCP service...and those systems had to cope with the problem where DHCP may not have been available initially, and fall back to BOOTP (of all the devices on the Internet today, the only one I've seen that actually still does this that you can buy new are APC UPS's management interfaces...kind of astounding really). When migrating from RA to DHCPv6, there will be pain, but the difference is that there is a light at the end of a tunnel; we do not run BOOTP anymore. There will come a day when we can turn off RA at the routers, and hosts won't need to carry SLAAC implementations. It seems the thing history teaches us is how to repeat it. > Well, obviously not _fully_ standardized as we are still adding stuff ... > but I would argue the sanity part is OK. > And again, it still (esthetically and architecturally) seems to make a lot > of sense for the router to send out information about the router. > With the added bonus of "it can and does work today", regardless of the > arguments for/against it. Unfortunately this "IETF horse sense" doesn't track into actual networks. It is not a question of "what device knows more", but rather a question of what person knows more about what the configuration for a given host should be (even its specific IP address and other network related configuration). That person is not typically your router operator. It is typically a systems operator shackled to a short desk in the basement. These two people are commonly two discrete entities, serving different masters in the umbrella of a bureaucracy that hates itself. For the "RA+DHCPv6" model to succeed, you will first have to force those people to come into good enough terms with one another to design, build, and debug services together in peace and harmony. When you're done with that, I think they can use your help in the middle east. Should be easy. On Sun, Oct 18, 2009 at 12:15:47AM -0500, Clue Store wrote: > >Since the goal for this initial wave is to make IPv6 available to > >those who request it or have a need for it, we feel its acceptable > >that there will need to be some user participation in enabling IPv6 > >for a host. > > To me, from a small ISP perspective, this is where the largest delima is.... > what 'vendor' is already depolying end user equipment that is ipv6 ready?? > Then there's the 'delivering the customer' their ipv6 block (hopefully > alongside their ipv4 block). Dual stack seems the way to go... For even a small ISP, dual stack is not incredibly obvious to me as a selectable solution. As the IPv4 shortfall comes, realistically most content on the Internet will continue to be on the IPv4 network. Any IPv6 content will also be available on the IPv4 network; being IPv4-single stack will not deprive the customers of content. What it does deprive them of, with increasing layers of NAT or proxy service, is "dial-in" access. Many do not require this feature. The cost of providing it is increased support costs; debugging two networks and three or four protocols. Today, even debugging IPv4 problems with customers is problematic and costly enough. That doesn't seem like a winning combination to me; more cost for no real benefit. A few NANOG's ago, Alain Durand from Comcast spoke about their plans to use IPv6 as a new L2, so their infrastructure can all be IPv6 addressed, and their customers traffic will be carried (by tunnel and NAT) and delivered by IPv4 riding on top of it. Having converted the infrastructure to IPv6, this puts them in a very good position to start deploying IPv6 in a limited capacity to the customer premise (for their own equipment, or for customers who elect to be IPv6 addressed, possibly as haven from being NAT'd). So far this is the best story I've heard for incremental IPv6 deployment. If you can make the charge straight out to dual stack, that's great, but I'm happy to see even large networks with more realistic, incremental goals. > To me, there's still a lot of wiggle room on how this should be deployed to > the absolute edge. > > What's folks experience in rolling this out the the customer ... be it DHCP > or SLAAC?? Also from a BBA perspective?? I have only worked with IPv6 directly in "office" networks, not in traditional service provider networks, but there my experience with SLAAC has been extremely poor; back to the days of manually configuring your clients kind of poor. DHCPv6 and in particular dynamic DNS is really the only solution in the office. I can suppose however that giving your customers IPv6 prefixes, and as a result gibberish IPv6 addresses, is going to give rise to a greater need for dynamic DNS services; they don't pass the phone test, for one thing. However it is perfectly acceptable in this "absolute edge" (and in fact every IETF meeting network does it this way) to use SLAAC to give IPv6 lip-service addresses while still using DHCPv4 to assign domain name servers, domain-search paths, NETBIOS configuration, so on, so forth. In this sense, IPv6 right now needs DHCPv4 as a crutch in order to bootstrap. And there's nothing wrong with that; DNS can resolve AAAA addresses using IPv4 addresses for your name servers just as easily as if you had supplied IPv6 addresses for them. Your DNS bits are not tastier if delivered by IPv6. When you move closer to the core... DOCSIS3 cable modems typically are assigned addresses (and configuration) by DHCPv6 rather than being left to their own default or customer configuration. PPP is not going to be extended to assign IPv6 addresses; over the PPP channel one will use either RA or DHCPv6 again. Because like any other network, an operator must ensure the client on this link is not sending from bogus (neighbor) source addresses, they will need a way to assign an IPv6 address to match filter rules, so then that means DHCPv6. Finally, I have something very abstract to say on the general subject of the underlying SLAAC-vs-Stateful-DHCPv6 debate; I submit the remainder of the debate over RA or DHCPv6 for address assignment is not technical. It is not religious or political. It is philosophical. With RA, you have a very Marxist-turned-Communist philosophy of design. All hosts are equal, everyone gets the same thing. From each according to their ability, to each according to their need. You want to be a router? Go ahead! Send an RA. The hosts are all allowed to freely roam and operate within their own limited capacity; but not really, eventually you need papers (along comes SEND and all the future development), and a bureaucracy of enforcement. DHCPv6 on the other hand embodies the philosophies of fascist dictators. Everything within the state, nothing outside the state. The will of the network over all. Hosts do what they are told, if they don't then results can't be guaranteed. You might just get hung out to dry unless you step in line. Although you might fail at building a social structure around both Communist and Fascist ideology, or perhaps some of you might debate that, I submit that when applying a philosophy of design to building a network for money - not as some social service, experiment or hobby - then the only philosophy worth applying is absolutely Fascism. Anything less, despite the nobilities espoused by their protractors, and you will bleed hidden costs. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jfbeam at gmail.com Wed Oct 21 16:37:02 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 21 Oct 2009 17:37:02 -0400 Subject: ISP customer assignments In-Reply-To: <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> Message-ID: On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart wrote: > ... If you've got a VPN tunnel device, too often the remote > end will want to contact you at some numerical IPv4 address and isn't > smart enough to query DNS to get it. As I was told by Cisco, that's a security "feature". Fixed VPN endpoints are supposed to be *fixed* endpoints. Yes, it is a pain when an address changes, for whatever reason. But relying on DNS to eventually get the endpoint(s) right is an even bigger mess... how often is the name<->IP updated? how often do the various DNS servers revalidate those records? how often do the VPN devices revalidate the names? what happens when the dns changes while the vpn is still up? I'll stick with entering IP addresses. --Ricky From kauer at biplane.com.au Wed Oct 21 17:40:49 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Oct 2009 09:40:49 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <1255837860.18603.1008.camel@karl> Message-ID: <1256164849.30246.410.camel@karl> On Wed, 2009-10-21 at 21:42 +0200, Iljitsch van Beijnum wrote: > On 18 okt 2009, at 5:51, Karl Auer wrote: > > Do the advertisements "right", advise sysadmins that hosts should > > not do SLAAC, > > Doesn't it tell you something that you're fighting this hard to avoid > hosts from doing what comes naturally? Well, I would not personally disable SLAAc except perhaps on specific machines for specific reasons. If I was using exclusively DHCPv6 I might disable the appropriate RA flags, and I would then expect my hosts to not do SLAAC. Any host that did would be broken, IMHO. > It occurs to me that I haven't met anyone who uses the term "SLAAC" > who uses IPv6 in a way that I would consider normal. (Or at all.) Ah well, it's always the exception that proves the rule. Sadly the term "stateless autoconfiguration" got overloaded, so now we have it meaning very different things - a) generating your own address from RA information; and b) getting only ancillary information from a DHCPv6 server. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From robert at tellurian.com Wed Oct 21 18:27:39 2009 From: robert at tellurian.com (Robert Boyle) Date: Wed, 21 Oct 2009 19:27:39 -0400 Subject: ISP/VPN's to China? In-Reply-To: References: <4ADF4B53.7020001@chrisserafin.com> Message-ID: <1256167734_1961523@mail1.tellurian.net> At 02:16 PM 10/21/2009, Fred Baker wrote: >I travel to China at least once a year, often several times. I >generally visit major cities like Shanghai and Beijing, but have been >to a number of other cities. I generally use Cisco VPN (an IPsec VPN) >to Cisco DMZs in Tokyo or Hong Kong for business purposes. As with >hotels in other parts of the world, congestive interference depends a >lot on the hotel and what the person you're competing with is doing. I >can tell you a few horror stories if you're amused by them, but in >recent years things have been improving. I use the Cisco WebVPN (AnyConnect) client and I have yet to find a place in China where it doesn't work perfectly - even in rural areas, but not so rural that they don't have Internet access. However, if you try to do many "normal" things outside of the VPN connection - check certain news sites, logon to facebook or watch a video on YouTube, you won't be able to do so. -Robert Tellurian Networks - A Perot Systems Company http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin From abalashov at evaristesys.com Wed Oct 21 18:36:40 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Wed, 21 Oct 2009 19:36:40 -0400 Subject: ISP/VPN's to China? In-Reply-To: <1256167734_1961523@mail1.tellurian.net> References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> Message-ID: <4ADF9B08.4040906@evaristesys.com> OpenVPN is ideal. It functions purely over application-level UDP transport (IP-IP) instead of using GRE/IPSec/other encapsulation protocols that could potentially be blocked by a protocol filter on a router. Route that traffic to a server outside of China and NAT it out to the rest of the Internet. The default port is UDP 1194, but can easily be changed. Anyone who wants to block it risks blocking any applications that use UDP in general, such as online games, Skype, etc. It is precisely because the traffic has no signature distinguishable from normal application traffic - aside from the fact that the payload is encrypted - that it makes a good fit. It's also open-source and free. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From jeffrey.lyon at blacklotus.net Wed Oct 21 18:44:56 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 21 Oct 2009 19:44:56 -0400 Subject: equinix is acquiring switch & data In-Reply-To: <1A49012C-8099-4DD0-AC24-AABB5A5DAD1D@gmail.com> References: <1A49012C-8099-4DD0-AC24-AABB5A5DAD1D@gmail.com> Message-ID: <16720fe00910211644s3295b05j16edf19e40b4d68e@mail.gmail.com> I had a S&D rep at a convention recently tell me that their prices were much more competitive than Equinix. I guess that's about to be out the window. Jeff On Wed, Oct 21, 2009 at 4:42 PM, Cord MacLeod wrote: > http://www.equinix.com/news/press/na/2009/news-5109/ > > Thought this was relevant. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From jabley at hopcount.ca Wed Oct 21 18:48:18 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 21 Oct 2009 19:48:18 -0400 Subject: equinix is acquiring switch & data In-Reply-To: <16720fe00910211644s3295b05j16edf19e40b4d68e@mail.gmail.com> References: <1A49012C-8099-4DD0-AC24-AABB5A5DAD1D@gmail.com> <16720fe00910211644s3295b05j16edf19e40b4d68e@mail.gmail.com> Message-ID: <5F0B0448-1A1A-4239-9EDB-0528B6B36EE5@hopcount.ca> On 2009-10-21, at 19:44, Jeffrey Lyon wrote: > I had a S&D rep at a convention recently tell me that their prices > were much > more competitive than Equinix. I guess that's about to be out the > window. I imagine the general practice of ${vendor1} reps telling potential customers that their prices are much better than ${vendor2}'s will persist, however. Joe From bmanning at vacation.karoshi.com Wed Oct 21 18:55:32 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Oct 2009 23:55:32 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <82B547ED-9637-4435-9F53-253551299555@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> Message-ID: <20091021235532.GB25829@vacation.karoshi.com.> On Wed, Oct 21, 2009 at 10:08:13PM +0200, Iljitsch van Beijnum wrote: > On 21 okt 2009, at 21:55, Owen DeLong wrote: > > >However, making it available as an option in DHCPv6 allows the end- > >user/operator > >to choose the technology that fits their needs best. I do not know > >why you are so > >determined to prevent this choice at the operator level. > > For the same reason that we don't let the kids play with the > powertools: giving them what they want here just makes everything end > in tears. > > If people want to run DHCPv6, fine, we're all adults. If they want to > go to the IETF and fix what's wrong with DHCPv6, so much the better. > But taking the information from the place where we can make sure it's > correct and putting it in a place where we can only guess so we break > the network regularly is A VERY BAD IDEA. so your not a fan of the smart edge and the stupid network. --bill From fred at cisco.com Wed Oct 21 18:59:42 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 21 Oct 2009 16:59:42 -0700 Subject: ISP/VPN's to China? In-Reply-To: <4ADF9B08.4040906@evaristesys.com> References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> Message-ID: <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> On Oct 21, 2009, at 4:36 PM, Alex Balashov wrote: > It is precisely because the traffic has no signature distinguishable > from normal application traffic oh my goodness. You're behind on your reading... From abalashov at evaristesys.com Wed Oct 21 19:00:56 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Wed, 21 Oct 2009 20:00:56 -0400 Subject: ISP/VPN's to China? In-Reply-To: <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> Message-ID: <4ADFA0B8.1030708@evaristesys.com> Fred Baker wrote: > > On Oct 21, 2009, at 4:36 PM, Alex Balashov wrote: > >> It is precisely because the traffic has no signature distinguishable >> from normal application traffic > > oh my goodness. You're behind on your reading... I didn't mean DPI. I meant in a way that can be inferred from the headers themselves, and aside from the port number. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From kauer at biplane.com.au Wed Oct 21 19:12:14 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Oct 2009 11:12:14 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091021213426.GA6981@isc.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021213426.GA6981@isc.org> Message-ID: <1256170334.30246.448.camel@karl> On Wed, 2009-10-21 at 14:34 -0700, David W. Hankins wrote: > folks on this mailing list who have proposed you can predict SLAAC > addresses based on prefix and MAC are confused; they are not taking > into account the many clients that use temporary addresses by default > when the A flag is set (these are intentionally not cryptographically > predictable), or that clients may need to re-iterate their SLAAC > algorithm if interfered with by a peer[...] That was me. My suggestion was to use MAC information from switches to build candidate addresses and ping6 them; rogue SLAAC-using hosts would respond, allowing them to be located and fixed. The OP I was replying to was concerned about clients that would do SLAAC even when the RA told them not to. It seems to me that hosts advanced enough to be able to do CGA or use temporary addresses (not necessarily the same thing) are unlikely to be hosts that would fail to interpret an RA correctly. This approach would probably not be 100% successful - maybe the pings don't get through, maybe the rogue doesn't answer pings, whatever. But it would at least be a start. A host that doesn't answer *may* still be a problem, but a host that does answer is *definitely* a problem. IMHO, automatically locating even some of your dud hosts is better than having to locate all of them the hard way. > Ostensibly the solution to this problem is "per host RA", which has > [...] > This is of course a completely scalable and well thought out plan Er - tap, tap - is this thing working? (Just testing my sarcasm detector :-) > To work around this problem, some DHCPv6 software implementers have > elected to temporarily apply a fixed /64 bit prefix to all applied > addresses until a prefix length can be made available in-band through > some means. This does neatly work around the problem; the hosts may > now speak to one another. I don't understand this. Could you elaborate? It seems to me that the "simplest network imaginable" should still operate on link local addresses. > Dibbler is a solid software package. Yes - and your note above tickles some vague memory that Dibbler has implemented something along those lines... > I am extremely skeptical that we'll ever reach where we're going if > we get there one millimeter at a time all the while redrafting our > plans over and over. True - but that *is* pretty much how we got to where we are with IPv4 :-) > Someone has forgotten that the reason IPv4 deployed so pervasively is > because it was so very trivially simple. And some of its biggest disadvantages are there for the same reason. As Einstein said, things should be made a simple as possible - but no simpler. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From perry at coders.net Wed Oct 21 19:20:04 2009 From: perry at coders.net (Perry Lorier) Date: Thu, 22 Oct 2009 13:20:04 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091021213426.GA6981@isc.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021213426.GA6981@isc.org> Message-ID: <4ADFA534.4010401@coders.net> > What it does deprive them of, with increasing layers of NAT or proxy > service, is "dial-in" access. Many do not require this feature. The > cost of providing it is increased support costs; debugging two > networks and three or four protocols. Today, even debugging IPv4 > problems with customers is problematic and costly enough. > The WAND Networking Research group did some measurements on the number of clients that accepted at least one incoming TCP connection from external to their network and presented their results at NZNOG 2009 ( http://www.wand.net.nz/~salcock/nznog09/spnat-nznog.pdf ). The number of people that successfully accepted at least one incoming TCP connection was somewhere from 30% to 44%. Most of it seemed to be from people using bittorrent, but about half was from other protocols. I'm not so sure it's entirely obvious that people aren't accepting incoming TCP connections. From adrian at creative.net.au Wed Oct 21 20:27:38 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 22 Oct 2009 09:27:38 +0800 Subject: ISP/VPN's to China? In-Reply-To: <4ADFA0B8.1030708@evaristesys.com> References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> Message-ID: <20091022012738.GB25573@skywalker.creative.net.au> On Wed, Oct 21, 2009, Alex Balashov wrote: > >oh my goodness. You're behind on your reading... > > I didn't mean DPI. I meant in a way that can be inferred from the > headers themselves, and aside from the port number. You don't think that statistical analysis of traffic patterns of your UDP traffic wouldn't identify it as a likely tunnel? :) Adrian From perry at coders.net Wed Oct 21 20:31:00 2009 From: perry at coders.net (Perry Lorier) Date: Thu, 22 Oct 2009 14:31:00 +1300 Subject: Consistent asymetric latency on monitoring? In-Reply-To: References: Message-ID: <4ADFB5D4.7050408@coders.net> Rick Ernst wrote: > Although the implementation is Cisco-specific, this feels more appropriate > for NANOG. > > We've started rolling out a state-wide monitoring system based on Cisco's > "IP SLA" feature set. Out of 5 sites deployed so far (different locations, > different providers), we are consistently seeing one-way latency mirror the > opposite direction. As source-destination latency goes up, > destination-source latency goes down and vice versa. > > Myself and the monitoring team have ripped apart the OIDs, IP SLA > configuration, and monitoring system. We've also built an ad-hoc system to > compare the results. It's still consistent behavior. It's not a true > mirror; there is definitely variation between the data collection, but at > the 10,000 foot level, there is an obvious and consistent mirror to the > data. > > The network topology is independant service providers all providing backhaul > to a local ethernet exchange. > > Has anybody seen this type of behavior? We are solidly convinced that we are > using the proper OIDs and making the proper transformations of the data. > The two remaining causes appear to be either "natural behavior of the links" > and/or "artifact in the IP SLA mechanism". > > Any ideas? > Having never used cisco's IP SLA (or even read about it), take this with a sack of salt. I assume this product works by having a packet with a timestamp sent from the source to the destination where it is timestamped again and either sent back, or another packet is sent in the other direction. The difference between the two timestamps gives you the latency in that direction. Now, how are your clocks syncronised? are they synchronised using NTP? or something better (GPS?) If one of your clocks is drifting with respect to the other then you'll see this effect. Does your clock drift because NTP is failing to keep the clock well syncronised when it's connection to it's parent NTP server is saturated? From nanog at daork.net Wed Oct 21 20:40:00 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 22 Oct 2009 14:40:00 +1300 Subject: Consistent asymetric latency on monitoring? In-Reply-To: <4ADFB5D4.7050408@coders.net> References: <4ADFB5D4.7050408@coders.net> Message-ID: <62A565AD-8254-457A-AE8B-E9156ACD650A@daork.net> On 22/10/2009, at 2:31 PM, Perry Lorier wrote: > I assume this product works by having a packet with a timestamp sent > from the source to the destination where it is timestamped again and > either sent back, or another packet is sent in the other direction. > The difference between the two timestamps gives you the latency in > that direction. I believe a packet is sent, and the target router responds with a timestamp. But yeah, timestamps are being compared. I'm with Perry though - sounds like your clocks are drifting. -- Nathan Ward From abalashov at evaristesys.com Wed Oct 21 20:47:34 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Wed, 21 Oct 2009 21:47:34 -0400 Subject: ISP/VPN's to China? In-Reply-To: <20091022012738.GB25573@skywalker.creative.net.au> References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> Message-ID: I was not aware that tools or techniques to do this are widespread or highly functional in a way that would get them adopted in an Internet access control application of a national scope. Tell me more? -- Sent from mobile device On Oct 21, 2009, at 9:27 PM, Adrian Chadd wrote: > On Wed, Oct 21, 2009, Alex Balashov wrote: > >>> oh my goodness. You're behind on your reading... >> >> I didn't mean DPI. I meant in a way that can be inferred from the >> headers themselves, and aside from the port number. > > You don't think that statistical analysis of traffic patterns > of your UDP traffic wouldn't identify it as a likely tunnel? :) > > > > Adrian > From adrian at creative.net.au Wed Oct 21 20:56:04 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 22 Oct 2009 09:56:04 +0800 Subject: ISP/VPN's to China? In-Reply-To: References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> Message-ID: <20091022015604.GC25573@skywalker.creative.net.au> On Wed, Oct 21, 2009, Alex Balashov wrote: > I was not aware that tools or techniques to do this are widespread or > highly functional in a way that would get them adopted in an Internet > access control application of a national scope. > > Tell me more? It's been a while since I tinkered with this for fun, but a quick abuse of google gives one relatively useful starting paper: http://ccr.sigcomm.org/online/files/p7-v37n1b-crotti.pdf Now, if you were getting multiple overlapping fingerprints inside a UDP packet stream you may conclude that it is a VPN tunnel of some sort. Just randomly padding the tunnel with a few bytes either side will probably just fuzz the classifier somewhat. Aggregating the packets up into larger packets may fuzz the classification methods but it certainly won't make the traffic look like "something else". It'll likely still stick out as being "different". :) Adrian From marka at isc.org Wed Oct 21 21:38:39 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 22 Oct 2009 13:38:39 +1100 Subject: ISP customer assignments In-Reply-To: Your message of "Wed, 21 Oct 2009 17:37:02 EDT." References: <200910060014.n960E1AP095142@aurora.sol.net> <29A54911243620478FF59F00EBB12F4701A60B48@ex01.drtel.lan> <877585b00910080346k7c96b4b6pc28bf5c468647674@mail.gmail.com> <20091008164818.GB4984@dan.olp.net> <4AD3E726.80400@justinshore.com> <7F8FDA9F-5CC0-46E9-BE51-D8B7593DE3C6@apnic.net> <4AD4A3F9.6010904@justinshore.com> <18a5e7cb0910191902q79b1f42eybcb10d0a3c7eb883@mail.gmail.com> <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com> Message-ID: <200910220238.n9M2cdVg082792@drugs.dv.isc.org> In message , "Ricky Beam" writes: > On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart > wrote: > > ... If you've got a VPN tunnel device, too often the remote > > end will want to contact you at some numerical IPv4 address and isn't > > smart enough to query DNS to get it. > > As I was told by Cisco, that's a security "feature". Fixed VPN endpoints > are supposed to be *fixed* endpoints. Yes, it is a pain when an address > changes, for whatever reason. But relying on DNS to eventually get the > endpoint(s) right is an even bigger mess... how often is the name<->IP > updated? It should be automatically updated by the end point. We do have the technology to do that. > how often do the various DNS servers revalidate those records? If you are talking about caching servers then they will honour the TTL in the records. > how often do the VPN devices revalidate the names? At startup. A well designed VPN protocol will support end point address mobility. > what happens when the dns changes while the vpn is still up? This should be transparent to everything other than the vpn end points. > I'll stick with entering IP addresses. > > --Ricky > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at shreddedmail.com Wed Oct 21 22:03:16 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Wed, 21 Oct 2009 20:03:16 -0700 Subject: Consistent asymetric latency on monitoring? In-Reply-To: References: <4ADFB5D4.7050408@coders.net> <62A565AD-8254-457A-AE8B-E9156ACD650A@daork.net> Message-ID: Resent, since I responded from the wrong address: --- The basic operation of IP SLA is as surmised; payload with timestamps and other telemetry data is sent to a 'responder' which manipulates the payload, including adding its own timestamps, and returns the altered payload. I had to do a mental walk-through, but I think I see how drift can cause this. I'm going to generate some artificial data, graph it, and see if it matches the general waveshape I'm seeing. I purposefully have the traffic generators ntp syncing against the responders. I thought that would keep the clocks more closely in sync. I don't necessarily care if the time is 'right', just that it's the same. What kind of difference should I expect if I sync both generators and responders against the same source, or not sync the responder? I'm thinking that having one source with constant drift may be better than both devices trying to walk/correct the time. Thanks for the input! On Wed, Oct 21, 2009 at 8:01 PM, Rick Ernst wrote: > Resent, since I responded from the wrong address: > --- > The basic operation of IP SLA is as surmised; payload with timestamps > and other telemetry data is sent to a 'responder' which manipulates > the payload, including adding its own timestamps, and returns the > altered payload. > > I had to do a mental walk-through, but I think I see how drift can > cause this. I'm going to generate some artificial data, graph it, and > see if it matches the general waveshape I'm seeing. > > I purposefully have the traffic generators ntp syncing against the > responders. I thought that would keep the clocks more closely in sync. > I don't necessarily care if the time is 'right', just that it's the > same. What kind of difference should I expect if I sync both > generators and responders against the same source, or not sync the > responder? I'm thinking that having one source with constant drift may > be better than both devices trying to walk/correct the time. > > Thanks for the input! > > > On Wed, Oct 21, 2009 at 7:55 PM, Rick Ernst wrote: > >> The basic operation of IP SLA is as surmised; payload with timestamps >> and other telemetry data is sent to a 'responder' which manipulates >> the payload, including adding its own timestamps, and returns the >> altered payload. >> >> I had to do a mental walk-through, but I think I see how drift can >> cause this. I'm going to generate some artificial data, graph it, and >> see if it matches the general waveshape I'm seeing. >> >> I purposefully have the traffic generators ntp syncing against the >> responders. I thought that would keep the clocks more closely in sync. >> I don't necessarily care if the time is 'right', just that it's the >> same. What kind of difference should I expect if I sync both >> generators and responders against the same source, or not sync the >> responder? I'm thinking that having one source with constant drift may >> be better than both devices trying to walk/correct the time. >> >> Thanks for the input! >> >> >> On Wednesday, October 21, 2009, Nathan Ward wrote: >> > On 22/10/2009, at 2:31 PM, Perry Lorier wrote: >> > >> > >> > I assume this product works by having a packet with a timestamp sent >> from the source to the destination where it is timestamped again and either >> sent back, or another packet is sent in the other direction. The difference >> between the two timestamps gives you the latency in that direction. >> > >> > >> > I believe a packet is sent, and the target router responds with a >> timestamp. >> > >> > But yeah, timestamps are being compared. >> > >> > I'm with Perry though - sounds like your clocks are drifting. >> > >> > -- >> > Nathan Ward >> > >> > >> > > From mnagel at willingminds.com Thu Oct 22 00:36:07 2009 From: mnagel at willingminds.com (Mark D. Nagel) Date: Wed, 21 Oct 2009 22:36:07 -0700 Subject: NetFlow analyzer software In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B903F65284@LOGAN.billtrust.local> References: <120987315-1255977397-cardhu_decombobulator_blackberry.rim.net-439977971-@bda543.bisx.prod.on.blackberry> <6bb5f5b10910191337x46f52447q6c43eabe5d4f49b@mail.gmail.com> <3C5B084431653D4A9C469A22AFCDB5B903F65284@LOGAN.billtrust.local> Message-ID: <4ADFEF47.5050503@willingminds.com> Jeffrey Negro wrote: > Yes my experience was the same on with Manage Engine. Although, they do have an article buried in their archives that shows how to tweak the mysql and java memory settings on start of the app. We found that helped a bit. We were successfully using it for netflows from more than 100Mbps, so I would say it can handle a bit more than typical SMB traffic. > > I don't know if anyone mentioned it, but a good commercial product a former customer of mine used to use was Solarwinds Orion. > A bout of research a few years back turned up IBM Aurora (http://www.zurich.ibm.com/aurora/), now sold as Tivoli/Netcool (http://www-01.ibm.com/software/tivoli/products/netcool-performance-flow/) as a potential solution for high performance analysis, but IIRC, a fairly hefty price tag applied based on traffic volume. Looking at the second URL, it is not clear, but looks like $10K + $200 per "resource unit", whatever that maps out to be. Definitely not on the same level as the typical solutions. Mark -- Mark D. Nagel, CCIE #3177 Principal Consultant, Willing Minds LLC (http://www.willingminds.com) cell: 949-279-5817, desk: 714-630-4772, fax: 949-623-9854 *** Please send support requests to support at willingminds.com! *** From swmike at swm.pp.se Thu Oct 22 00:51:00 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 22 Oct 2009 07:51:00 +0200 (CEST) Subject: Consistent asymetric latency on monitoring? In-Reply-To: References: Message-ID: On Wed, 21 Oct 2009, Rick Ernst wrote: > Has anybody seen this type of behavior? We are solidly convinced that we > are using the proper OIDs and making the proper transformations of the > data. The two remaining causes appear to be either "natural behavior of > the links" and/or "artifact in the IP SLA mechanism". I've been using IP SLA for years (right now under 12.4) and I have not seen behaviour that mirrors what you see. I often see one-way latency go up without the other way doing so. You should start by looking in "show ip sla (monitor) op" and see what values you see in the router, that might give you more information regarding where the problem might be (your polling system or if the IP SLA agent is actually reporting what you see). -- Mikael Abrahamsson email: swmike at swm.pp.se From fred at cisco.com Thu Oct 22 01:09:40 2009 From: fred at cisco.com (Fred Baker) Date: Wed, 21 Oct 2009 23:09:40 -0700 Subject: ISP/VPN's to China? In-Reply-To: References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> Message-ID: They exist and for certain applications are pretty effective. On Oct 21, 2009, at 6:47 PM, Alex Balashov wrote: > I was not aware that tools or techniques to do this are widespread > or highly functional in a way that would get them adopted in an > Internet access control application of a national scope. > > Tell me more? > > -- > Sent from mobile device > > On Oct 21, 2009, at 9:27 PM, Adrian Chadd > wrote: > >> On Wed, Oct 21, 2009, Alex Balashov wrote: >> >>>> oh my goodness. You're behind on your reading... >>> >>> I didn't mean DPI. I meant in a way that can be inferred from the >>> headers themselves, and aside from the port number. >> >> You don't think that statistical analysis of traffic patterns >> of your UDP traffic wouldn't identify it as a likely tunnel? :) >> >> >> >> Adrian >> From perry at coders.net Thu Oct 22 01:10:29 2009 From: perry at coders.net (Perry Lorier) Date: Thu, 22 Oct 2009 19:10:29 +1300 Subject: Consistent asymetric latency on monitoring? In-Reply-To: References: <4ADFB5D4.7050408@coders.net> <62A565AD-8254-457A-AE8B-E9156ACD650A@daork.net> Message-ID: <4ADFF755.8090806@coders.net> Rick Ernst wrote: > Resent, since I responded from the wrong address: > --- > The basic operation of IP SLA is as surmised; payload with timestamps > and other telemetry data is sent to a 'responder' which manipulates > the payload, including adding its own timestamps, and returns the > altered payload. > Yup :) It's the obvious way to do it :) > I had to do a mental walk-through, but I think I see how drift can > cause this. I'm going to generate some artificial data, graph it, and > see if it matches the general waveshape I'm seeing. > > I purposefully have the traffic generators ntp syncing against the > responders. I thought that would keep the clocks more closely in sync. > I don't necessarily care if the time is 'right', just that it's the > same. This causes major problems. What you're actually measuring here is how well ntp can keep the clock sync'd under assymetric latency. ntp is trying to do it's own measurements of one way delay, without the help of clocks to measure clock drift as well. As you can see from your graphs ntp is not coping[1]. You are far better to have each end sync to a local stratum 1 or stratum 2 ntp source, preferably one over a different link to the one under test. If you don't have a local stratum 1/2 time source at each end, you might be able find one over a local exchange or other less congested link. If this is very important to you then you should consider looking at running your own stratum 1 clocks at each end syncronised off something like GPS, CDMA or a T1 clock. > What kind of difference should I expect if I sync both > generators and responders against the same source, or not sync the > responder? I'm thinking that having one source with constant drift may > be better than both devices trying to walk/correct the time. > Most hardware clocks in PC's/routers/switches etc have pretty atrocious amounts of drift if left to free run[2], sometimes in the order of seconds or occasionally minutes per week. To get useful numbers you really do need to syncronise them to /something/. Synchronising them to each other causes problems as ntp I think (I could be wrong) assumes mostly symmetrical latency, and if the latency isn't symmetric assumes it's because one clock is running fast/slow and will alter the clock's speed to account for it. The great thing about ntp stratum 1 servers is that by definition they have more or less the same time no matter where they are, so synchronising each against a local ntp server will be a much much better solution. If possible you should consider peering with at least 3 upstreams, preferably 4(!)[3] other ntp servers. [1]: To be fair it's a hard problem. Anything that involves time just gets more and more complicated the more you look at it, ntp is extremely clever and probably knows more about time than I'd ever want to know, but you're making it's job hard. [2]: http://vancouver-webpages.com/time/ / http://vancouver-webpages.com/time/ltmhist.png [3]: http://twiki.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3. From schoen at loyalty.org Thu Oct 22 01:59:35 2009 From: schoen at loyalty.org (Seth David Schoen) Date: Wed, 21 Oct 2009 23:59:35 -0700 Subject: ISP/VPN's to China? In-Reply-To: <20091022015604.GC25573@skywalker.creative.net.au> References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> <20091022015604.GC25573@skywalker.creative.net.au> Message-ID: <20091022065935.GS9766@frotz.zork.net> Adrian Chadd writes: > On Wed, Oct 21, 2009, Alex Balashov wrote: > > I was not aware that tools or techniques to do this are widespread or > > highly functional in a way that would get them adopted in an Internet > > access control application of a national scope. > > > > Tell me more? > > It's been a while since I tinkered with this for fun, but a quick abuse > of google gives one relatively useful starting paper: > > http://ccr.sigcomm.org/online/files/p7-v37n1b-crotti.pdf A lot of research papers on what is or isn't possible in traffic analysis are linked from http://freehaven.net/anonbib/topic.html#Traffic_20analysis This bibliography is updated periodically. It's a pretty big, complex topic, and the open literature could use lots more publications. -- Seth David Schoen | Qu? empresa f?cil no pensar en http://www.loyalty.org/~schoen/ | un tigre, reflexion?. http://vitanuova.loyalty.org/ | -- Borges, El Zahir From chris at eng.gla.ac.uk Thu Oct 22 04:19:35 2009 From: chris at eng.gla.ac.uk (Chris Edwards) Date: Thu, 22 Oct 2009 10:19:35 +0100 (BST) Subject: ISP/VPN's to China? In-Reply-To: References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> Message-ID: On Wed, 21 Oct 2009, Alex Balashov wrote: | I was not aware that tools or techniques to do this are widespread or highly | functional in a way that would get them adopted in an Internet access control | application of a national scope. Doesn't necessarily have to be hugely accurate. The authorities could simply identify a few likely suspect tunnels, then knock-on-doors and ask you to explain what the traffic in question is... From abalashov at evaristesys.com Thu Oct 22 04:38:00 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Thu, 22 Oct 2009 05:38:00 -0400 Subject: ISP/VPN's to China? In-Reply-To: References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> Message-ID: <4AE027F8.3040809@evaristesys.com> Chris Edwards wrote: > Doesn't necessarily have to be hugely accurate. The authorities could > simply identify a few likely suspect tunnels, then knock-on-doors and ask > you to explain what the traffic in question is... Understood. I guess the angle I was going more for was: Is this actually practical to do in a country with almost as many Internet users as the US has people? I had always assumed that broad policies and ACLs work in China, but most forms of DPI and traffic pattern analysis aren't practical simply for computational feasibility reasons. Not unless the system were highly distributed. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From iljitsch at muada.com Thu Oct 22 04:40:50 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 22 Oct 2009 11:40:50 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> Message-ID: <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> On 21 okt 2009, at 22:48, Owen DeLong wrote: > The assumption that the router "knows" it is correct for every host > on a given > LAN simply does not map to reality deployed today. What I'm saying is that a router knows whether it's a router or not. A DHCP server does not, so it has to make a leap of faith and then sometimes the hosts fall flat on their face if there's no router on the address indicated by the DHCP server. The counter-argument is "it works today" but my counter-counter-argument is "it doesn't work today". I get burned by broken DHCP setups _all_ _the_ _time_ at work, at IETF meetings, at RIPE meetings, etc. Anyone claiming that having a DHCP server direct hosts to a router address in the blind is simply incompetetent, so there is no point in listening to them. If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. > Please explain to me how I can achieve this functionality in RA/SLAAC > or stop pushing to prevent it from being available in DHCPv6. There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways. > Seriously, we're all adults. So treating us like children and > taking away > the power tools is not appreciated. Stop trying to break the internet and I'll treat you like an adult. From iljitsch at muada.com Thu Oct 22 04:59:54 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 22 Oct 2009 11:59:54 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091021213426.GA6981@isc.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021213426.GA6981@isc.org> Message-ID: On 21 okt 2009, at 23:34, David W. Hankins wrote: > There is a problem with the "Both RA and DHCPv6 Model" currently > proposed by IETF iconoclasts. Should RA fail, for any reason from > router, system, software, network path, security, or user error, > then the simplest networks imaginable (where hosts and mail/Intranet/ > work servers are all co-located on the same broadcast domain) will > not be able to talk to one another, Or the rest of the world. Note however that it is very hard to get false negatives for RAs and even harder to get false positives. The only way I've had RAs fail in the real world was with multilayer switches that wouldn't let IPv6 multicasts through because they couldn't do IGMP snooping for those. This affected RAs but also all other neighbor discovery, and would have affected DHCPv6, too. So in this situation IPv6 is completely dead in the water. The good thing is that you don't get any false positives, where a host thinks there's a router somewhere but there's not actually a router there. This is because when a router stops being a router it will also stop sending RAs. All of this works extremely well, I can't think of any instance where there is any trouble with RAs, except of course the problem of rogue routers advertising themselves. However, this is not really any different from the situation in IPv4 where rogue DHCP servers advertise stuff they shouldn't advertise. > To work around this problem, some DHCPv6 software implementers have > elected to temporarily apply a fixed /64 bit prefix to all applied > addresses until a prefix length can be made available in-band through > some means. Why not simply fix the DHCPv6 protocol so it has a prefix length attribute? DHCP'ers can complain about stateless autoconfig and RAs, but the simple truth is that DHCPv6 has problems that are unrelated to anything outside DHCPv6 that haven't been fixed in the half a decade that I've been paying attention to it. > But it may complicate your designs if you > are assigning /80's. RFC 3513 says that all interface identifiers for addresses outside ::/ 3 must be 64 bits in size. That doesn't work with a /80. So I'm not sure if using DHCPv6 with /80s will work on all systems. > According to the release notes of ISC DHCP 4.1.0, ISC 'dhclient -6' > compiles and runs on Mac OSX. I don't actually own a Mac, so I have > never used it myself, and our release notes even go into detail about > the limitations of the current 'dhclient-script' for the Darwin > platform (apparently their configuration system is somewhat opaque). MacOS detects when interface go online and offline and does all kinds of stuff when that happens. For instance, you can't globally enable/ disable stateless autoconfig on MacOS, either. Manually running a script when the interface status changes is a rather blunt way to interact with the system. >> Does anyone know if Apple has plans to release a DHCPv6 client for >> Mac OS X? > No...but I have heard plans of the exact opposite. [...] > When people at > the microphone asked why Apple did not include a DHCPv6 client > implementation, even a stateless one, I believe Bernard Aboba > addressed the concern at the microphone saying, and I am paraphrasing > from memory here, "We were told by the IETF that RA was all we would > ever need, implementing DHCPv6 is optional, so RA is all we are > doing." I don't remember that. What I do remember is that Stuart Cheshire of Apple explained how he was unhappy that it was necessary to run a rather involved protocol (DHCPv6) for the relatively simple task of obtaining DNS resolver addresses. > To summarize, RA+DHCPv6 implementers are posed with problems: ...which apparently some DHCPv6 people want to solve by ALWAYS running their chatty protocol that wastes a lot of bandwidth on wireless LANs until people give in and just run a DHCPv6 server just to get rid of the constant DHCP retransmissions that can't be stopped any other way because actually looking at the O/M bits is of course way too simple. I hate this crap so much. From iljitsch at muada.com Thu Oct 22 05:02:14 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 22 Oct 2009 12:02:14 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091021235532.GB25829@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> Message-ID: <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> On 22 okt 2009, at 01:55, bmanning at vacation.karoshi.com wrote: > so your not a fan of the smart edge and the stupid network. I'm a fan of getting things right. A server somewhere 5 subnets away doesn't really know what routers are working on my subnet. It can take a guess and then wait for people to complain and then an admin to fix stuff if the guess is wrong, but I wouldn't call that a "smart edge". Always learn information from the place where it's actually known. From kauer at biplane.com.au Thu Oct 22 05:20:11 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Oct 2009 21:20:11 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> Message-ID: <1256206811.30246.646.camel@karl> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: > If, on the other hand, the REAL desire is to have a DHCP server break > the tie in the selection between several routers that advertise their > presence, that wouldn't be unreasonable. The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. In any case, anywhere this is actually of vital importance, a routing protocol would be in use. Using the DHCP protocol to deliver information - about anything really - is what it's *for*. That said, making clients depend utterly on the presence of a working DHCP server for basic connectivity seems like a backward step. Of course, different people have different ideas about what constitutes "basic" connectivity. > Stop trying to break the internet and I'll treat you like an adult. Whoa! Tell you what, how about if I break it, and you get to choose which piece you keep? [Bash, bash, thud. Ugh. Hm. It's tougher than it looks!] :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bmanning at vacation.karoshi.com Thu Oct 22 05:27:48 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Oct 2009 10:27:48 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> Message-ID: <20091022102748.GA32008@vacation.karoshi.com.> On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote: > On 22 okt 2009, at 01:55, bmanning at vacation.karoshi.com wrote: > > > so your not a fan of the smart edge and the stupid network. > > I'm a fan of getting things right. A server somewhere 5 subnets away > doesn't really know what routers are working on my subnet. It can take > a guess and then wait for people to complain and then an admin to fix > stuff if the guess is wrong, but I wouldn't call that a "smart edge". > > Always learn information from the place where it's actually known. i'm ok w// that mindset. one should learn routing from the router(s), time from the time servers, DNS from the DNS servers, etc... now -normally- I would expect the router to focus on forwarding packets ... not be the time keeper, DNS server, handing out IP addresses, hosting content for the HTTP protocol etc. sounds to me like your reacting to a particular style of implementation (DHCP servers being multi-hops away) and want to move the function(s) closer to the edge, e.g. in the routers. and if we can get RA/ND -fixed- to accomodate all the functions that folks have grown to depend on over the years from a configuration service like DHCP - then we should be able to converge. I am not a fan of the way DHCPv6 has developed/emerged. And yes, I've re-written both client and server to fix the egergious problems found in the current spec... (it now works just fine for doing things like handing out DNS servers for resolvers, picking mapped addresses for my IVI service, etc.) so my DHCP is non-interoperable w/ anyone elses. Thing is, its easier to fix DHCP code than to fix the router code. And the edge is not the LAN, its the device. --bill From bmanning at vacation.karoshi.com Thu Oct 22 05:30:41 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Oct 2009 10:30:41 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256206811.30246.646.camel@karl> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> Message-ID: <20091022103041.GB32008@vacation.karoshi.com.> On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: > On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: > > If, on the other hand, the REAL desire is to have a DHCP server break > > the tie in the selection between several routers that advertise their > > presence, that wouldn't be unreasonable. > > The RA contains a preference level... maybe that doesn't cut it if > multiple routers are sending the same preference level, but presumably > that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. > > Regards, K. > --bill From kauer at biplane.com.au Thu Oct 22 05:44:38 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Oct 2009 21:44:38 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022103041.GB32008@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> Message-ID: <1256208278.30246.683.camel@karl> On Thu, 2009-10-22 at 10:30 +0000, bmanning at vacation.karoshi.com wrote: > > The RA contains a preference level... maybe that doesn't cut it if > > multiple routers are sending the same preference level, but presumably > > that would not happen in a well-tended network. > > I point you to a fairly common Internet architecture artifact, > the exchange point... dozens of routers sharing a common > media for peering exchange. And how do they discriminate now, with IPv4? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rdobbins at arbor.net Thu Oct 22 05:59:02 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 22 Oct 2009 06:59:02 -0400 Subject: Consistent asymetric latency on monitoring? In-Reply-To: References: <4ADFB5D4.7050408@coders.net> <62A565AD-8254-457A-AE8B-E9156ACD650A@daork.net> Message-ID: On Oct 21, 2009, at 11:03 PM, Rick Ernst wrote: > I thought that would keep the clocks more closely in sync. I don't > necessarily care if the time is 'right', just that it's the same. ntp is a pretty basic operational requirement for any network, irrespective of the use of IP SLA, is it not? ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From bmanning at vacation.karoshi.com Thu Oct 22 06:08:16 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Oct 2009 11:08:16 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256208278.30246.683.camel@karl> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> <1256208278.30246.683.camel@karl> Message-ID: <20091022110816.GD32008@vacation.karoshi.com.> On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote: > On Thu, 2009-10-22 at 10:30 +0000, bmanning at vacation.karoshi.com wrote: > > > The RA contains a preference level... maybe that doesn't cut it if > > > multiple routers are sending the same preference level, but presumably > > > that would not happen in a well-tended network. > > > > I point you to a fairly common Internet architecture artifact, > > the exchange point... dozens of routers sharing a common > > media for peering exchange. > > And how do they discriminate now, with IPv4? > > Regards, K. > IPv4 has no concept of RA/ND. to make this construct work at all in IPv6, all participants have to turn -off- RA/ND to prevent one or more routers trying to impose their views of addressing on their neighbours. --bill From kauer at biplane.com.au Thu Oct 22 06:18:48 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Oct 2009 22:18:48 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022110816.GD32008@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> <1256208278.30246.683.camel@karl> <20091022110816.GD32008@vacation.karoshi.com.> Message-ID: <1256210328.30246.740.camel@karl> On Thu, 2009-10-22 at 11:08 +0000, bmanning at vacation.karoshi.com wrote: > On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote: > > On Thu, 2009-10-22 at 10:30 +0000, bmanning at vacation.karoshi.com wrote: > > > > The RA contains a preference level... maybe that doesn't cut it if > > > > > > I point you to a fairly common Internet architecture artifact, > > > the exchange point... dozens of routers sharing a common > > > media for peering exchange. > > > > And how do they discriminate now, with IPv4? > > IPv4 has no concept of RA/ND. to make this construct work at > all in IPv6, all participants have to turn -off- RA/ND to prevent > one or more routers trying to impose their views of addressing > on their neighbours. But my question was not about IPv6. How do IPv4 routers operate in such a situation? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From perry at coders.net Thu Oct 22 06:22:52 2009 From: perry at coders.net (Perry Lorier) Date: Fri, 23 Oct 2009 00:22:52 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022102748.GA32008@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> Message-ID: <4AE0408C.9080303@coders.net> bmanning at vacation.karoshi.com wrote: > On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote: > >> On 22 okt 2009, at 01:55, bmanning at vacation.karoshi.com wrote: >> >> >>> so your not a fan of the smart edge and the stupid network. >>> >> I'm a fan of getting things right. A server somewhere 5 subnets away >> doesn't really know what routers are working on my subnet. It can take >> a guess and then wait for people to complain and then an admin to fix >> stuff if the guess is wrong, but I wouldn't call that a "smart edge". >> >> Always learn information from the place where it's actually known. >> > > i'm ok w// that mindset. > > one should learn routing from the router(s), > time from the time servers, > DNS from the DNS servers, > etc... > > I quite liked the old http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea. (tl;dr version: Have a set of well known site local anycast address for recursive name servers). It has a number of nice features such as: * since it's not in globally routable space people can't (ab)use your recursive name servers from outside your network. * you don't have to change recursive name servers when going to a different network -- they're the same everywhere. * the addresses can be set as the default addresses by the OS manufacturer, and then don't need to be configured ever again. * If your recursive name server becomes unreachable, broken or otherwise out of contact, it withdraws the address from your IGP, then since you can any cast these addresses, another node takes over. Similar to the shared fate idea of RA's. * You don't tie your recursive nameservers addresses to any point in the network, since they have their own special range, moving them, reshuffling them, or anything doesn't impact anything. They don't need to cohabit a router sending RA's or anything odd like that. However it has a number of obvious drawbacks, primarily amongst them being that it uses deprecated site local addresses. You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers. Another obvious approach might be to have a service discovery protocol where you send to a "service discovery" multicast group a message asking "wheres the nearest nameserver(s)?" then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a "ServiceDiscovery-Guard" feature for switches.... Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :) From nanog at shreddedmail.com Thu Oct 22 06:25:54 2009 From: nanog at shreddedmail.com (Rick Ernst) Date: Thu, 22 Oct 2009 04:25:54 -0700 Subject: Consistent asymetric latency on monitoring? In-Reply-To: <4ADFF755.8090806@coders.net> References: <4ADFB5D4.7050408@coders.net> <62A565AD-8254-457A-AE8B-E9156ACD650A@daork.net> <4ADFF755.8090806@coders.net> Message-ID: Lots of good info, and a nice mind-dump that gives me a whole host of other things that need to be looked at... Umm. "thanks" :) On Wed, Oct 21, 2009 at 11:10 PM, Perry Lorier wrote: > Rick Ernst wrote: > >> Resent, since I responded from the wrong address: >> --- >> The basic operation of IP SLA is as surmised; payload with timestamps >> and other telemetry data is sent to a 'responder' which manipulates >> the payload, including adding its own timestamps, and returns the >> altered payload. >> >> > > Yup :) It's the obvious way to do it :) > > I had to do a mental walk-through, but I think I see how drift can >> cause this. I'm going to generate some artificial data, graph it, and >> see if it matches the general waveshape I'm seeing. >> >> I purposefully have the traffic generators ntp syncing against the >> responders. I thought that would keep the clocks more closely in sync. >> I don't necessarily care if the time is 'right', just that it's the >> same. >> > > This causes major problems. What you're actually measuring here is how > well ntp can keep the clock sync'd under assymetric latency. ntp is trying > to do it's own measurements of one way delay, without the help of clocks to > measure clock drift as well. As you can see from your graphs ntp is not > coping[1]. > > You are far better to have each end sync to a local stratum 1 or stratum 2 > ntp source, preferably one over a different link to the one under test. If > you don't have a local stratum 1/2 time source at each end, you might be > able find one over a local exchange or other less congested link. If this > is very important to you then you should consider looking at running your > own stratum 1 clocks at each end syncronised off something like GPS, CDMA or > a T1 clock. > > What kind of difference should I expect if I sync both >> generators and responders against the same source, or not sync the >> responder? I'm thinking that having one source with constant drift may >> be better than both devices trying to walk/correct the time. >> >> > > Most hardware clocks in PC's/routers/switches etc have pretty atrocious > amounts of drift if left to free run[2], sometimes in the order of seconds > or occasionally minutes per week. To get useful numbers you really do need > to syncronise them to /something/. Synchronising them to each other causes > problems as ntp I think (I could be wrong) assumes mostly symmetrical > latency, and if the latency isn't symmetric assumes it's because one clock > is running fast/slow and will alter the clock's speed to account for it. > The great thing about ntp stratum 1 servers is that by definition they have > more or less the same time no matter where they are, so synchronising each > against a local ntp server will be a much much better solution. If possible > you should consider peering with at least 3 upstreams, preferably 4(!)[3] > other ntp servers. > > [1]: To be fair it's a hard problem. Anything that involves time just gets > more and more complicated the more you look at it, ntp is extremely clever > and probably knows more about time than I'd ever want to know, but you're > making it's job hard. > > [2]: http://vancouver-webpages.com/time/ / > http://vancouver-webpages.com/time/ltmhist.png > > [3]: > http://twiki.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3 > . > From bmanning at vacation.karoshi.com Thu Oct 22 06:30:19 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Oct 2009 11:30:19 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256210328.30246.740.camel@karl> References: <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> <1256208278.30246.683.camel@karl> <20091022110816.GD32008@vacation.karoshi.com.> <1256210328.30246.740.camel@karl> Message-ID: <20091022113019.GG32008@vacation.karoshi.com.> On Thu, Oct 22, 2009 at 10:18:48PM +1100, Karl Auer wrote: > On Thu, 2009-10-22 at 11:08 +0000, bmanning at vacation.karoshi.com wrote: > > On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote: > > > On Thu, 2009-10-22 at 10:30 +0000, bmanning at vacation.karoshi.com wrote: > > > > > The RA contains a preference level... maybe that doesn't cut it if > > > > > > > > I point you to a fairly common Internet architecture artifact, > > > > the exchange point... dozens of routers sharing a common > > > > media for peering exchange. > > > > > > And how do they discriminate now, with IPv4? > > > > IPv4 has no concept of RA/ND. to make this construct work at > > all in IPv6, all participants have to turn -off- RA/ND to prevent > > one or more routers trying to impose their views of addressing > > on their neighbours. > > But my question was not about IPv6. How do IPv4 routers operate in such > a situation? > > Regards, K. > exchange design 101. each connecting router interface is manually configured with an address of the exchange fabrics IP space. to establish peering, a router needs to know, at a minimum, the targets IP address and ASN - and while arp (if enabled) can get the target IP address, the ASN has to come via another channel - usually manually aquired. this is how the exchanges generally work, regardless of IP address family. more generally, where there are two or more egress routers from a broadcast domain, there will be problems -if- the routers know about each other -and- have the ability to try and set the exit rules for all other participants sharing the broadcast domain. Hence, with IPv6 and RA/ND, the idea of "preference" levels ... although in most cases I've experienced where there are multiple exit routers - that doesn't work either, since only subsets of the nodes on the shared media can use one or the other egress router. e.g. all the nodes don't fate-share. RA/ND was only an 80% solution anyway. --bill From nick at foobar.org Thu Oct 22 06:35:18 2009 From: nick at foobar.org (Nick Hilliard) Date: Thu, 22 Oct 2009 12:35:18 +0100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022103041.GB32008@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> Message-ID: <4AE04376.5010001@foobar.org> On 22/10/2009 11:30, bmanning at vacation.karoshi.com wrote: > On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: >> The RA contains a preference level... maybe that doesn't cut it if >> multiple routers are sending the same preference level, but presumably >> that would not happen in a well-tended network. > > I point you to a fairly common Internet architecture artifact, > the exchange point... dozens of routers sharing a common > media for peering exchange. Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance to an IXP? Being one of these "artefact" operators - and clearly stuck with a very small dinosaur brain - I am having some trouble understanding the point you're attempting to make here. Nick From chris at eng.gla.ac.uk Thu Oct 22 06:38:11 2009 From: chris at eng.gla.ac.uk (Chris Edwards) Date: Thu, 22 Oct 2009 12:38:11 +0100 (BST) Subject: ISP/VPN's to China? In-Reply-To: <4AE027F8.3040809@evaristesys.com> References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> <4AE027F8.3040809@evaristesys.com> Message-ID: On Thu, 22 Oct 2009, Alex Balashov wrote: | Understood. I guess the angle I was going more for was: Is this actually | practical to do in a country with almost as many Internet users as the US has | people? | | I had always assumed that broad policies and ACLs work in China, but most | forms of DPI and traffic pattern analysis aren't practical simply for | computational feasibility reasons. Not unless the system were highly | distributed. Perhaps they only need make an example of a few, and thus introduce an element of fear for everyone else. From bmanning at vacation.karoshi.com Thu Oct 22 06:39:38 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Oct 2009 11:39:38 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE0408C.9080303@coders.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> Message-ID: <20091022113938.GH32008@vacation.karoshi.com.> On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote: > > You could imagine extending this to other services such as NTP, but I'm > not sure that you really would want to go that far, perhaps using DNS to > lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers. > > Another obvious approach might be to have a service discovery protocol > where you send to a "service discovery" multicast group a message asking > "wheres the nearest nameserver(s)?" then nameserver implementations > could listen on this multicast group and reply. Again shared fate. > This does have the downside of people running rogue nameservers and > needing a "ServiceDiscovery-Guard" feature for switches.... ah... well - if your a router centric person, then you want to put everything into the tools you know and love. if your a dns centric person, then you put everything in the DNS. I point you to the "DISCOVER' opcode (experimental) in the DNS and the use of DNS over multicast for doing service discovery (e.g. Apples Bonjour)... Most of that is already designed/deployed and in pretty widespread use... over IPv4 or IPv6. And yes, its not RA/ND, or DHCP... its another configuration protocol and its not quite vendor specific. The best thing is, it pushes the smarts closer to the edge (the end device) and this makes me happy. > Personally I like the first option (anycast addresses) better, you can > control who has access to your IGP and if your IGP is down, then for all > intents and purposes your recursive nameservers are offline too :) > everyone to their own taste. --bill From bmanning at vacation.karoshi.com Thu Oct 22 06:49:16 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 22 Oct 2009 11:49:16 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE04376.5010001@foobar.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> <4AE04376.5010001@foobar.org> Message-ID: <20091022114916.GJ32008@vacation.karoshi.com.> On Thu, Oct 22, 2009 at 12:35:18PM +0100, Nick Hilliard wrote: > On 22/10/2009 11:30, bmanning at vacation.karoshi.com wrote: > >On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: > >>The RA contains a preference level... maybe that doesn't cut it if > >>multiple routers are sending the same preference level, but presumably > >>that would not happen in a well-tended network. > > > > I point you to a fairly common Internet architecture artifact, > > the exchange point... dozens of routers sharing a common > > media for peering exchange. > > Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance > to an IXP? Being one of these "artefact" operators - and clearly stuck > with a very small dinosaur brain - I am having some trouble understanding > the point you're attempting to make here. > > Nick its been a few weeks/years/minutes since I ran an exchange fabric, but when we first turned up IPv6 - the first thing they did was try to hand all the other routers IPv6 addresses. that pesky RA/ND thing... had to turn it off ... RA preference would not work, since there was no -pecking- order - all the routers were peers. we did the manual configuration - no DHCP - it was the only way to ensure things would be deterministic. Hence my comments to Karl re his statement about "not happen in a well-tended network". the point. RA/ND was designed to solve what some of its designers thought would be 80% of the problems. It might just be able to do that - for the limited scope that it has. There are other, more robust, decomposable, resilient configuration tools out there that have capabilities people need that are not currently in RA/ND. and even then, not all architectures are ammenable to automated configuration tools. RA/ND is not a panecea. --bill From owen at delong.com Thu Oct 22 06:52:10 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 04:52:10 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> Message-ID: <3F7C9B8E-6E3F-4536-A285-7FE24CE8762A@delong.com> On Oct 22, 2009, at 2:40 AM, Iljitsch van Beijnum wrote: > On 21 okt 2009, at 22:48, Owen DeLong wrote: > >> The assumption that the router "knows" it is correct for every host >> on a given >> LAN simply does not map to reality deployed today. > > What I'm saying is that a router knows whether it's a router or not. > A DHCP server does not, so it has to make a leap of faith and then > sometimes the hosts fall flat on their face if there's no router on > the address indicated by the DHCP server. The counter-argument is > "it works today" but my counter-counter-argument is "it doesn't work > today". I get burned by broken DHCP setups _all_ _the_ _time_ at > work, at IETF meetings, at RIPE meetings, etc. > And what I'm saying is that knowing you are a router is not sufficient. A badly configured router will mess things up just as bad as a badly configured DHCP server. > Anyone claiming that having a DHCP server direct hosts to a router > address in the blind is simply incompetetent, so there is no point > in listening to them. > The arrogance is just astounding. > If, on the other hand, the REAL desire is to have a DHCP server > break the tie in the selection between several routers that > advertise their presence, that wouldn't be unreasonable. > The real desire is to have the ability for the group that administers hosts to retain authority over host configuration. Often, in the real world, this is not the same group as the group that manages the routers. There are many different reasons that some organizations consider this important. Strangely, despite your claim that all of these people are incompetent, their IPv4 networks continue to operate just fine. >> Please explain to me how I can achieve this functionality in RA/SLAAC >> or stop pushing to prevent it from being available in DHCPv6. > > There is no requirement that the IETF provides all functionality > that someone can think up. The list of desired functionality is > infinite, and much on that list is a bad idea and/or can be achieved > in different ways. > Sure, but, if we want people to accept IPv6, then, it needs to, at a bare minimum, provide feature parity with IPv4 in addition to at least the advantage of a larger address space. If it contains additional features, that's great. So far, it falls short at least in this area. Hoping not to open an additional can of worms, but, I do limit this to FEATURE parity, so, for example, bugs like NAT do not need to be replicated. Stateful inspection and stateful inspection firewalls that fail closed are needed, but, the protocol gives us everything we need to make that work, it's a software development issue at this point. NAT is strictly a kludge on top of stateful inspection which automatically fails closed and thus has gained the illusion of being a security tool in IPv4 because many people cannot distinguish the two. >> Seriously, we're all adults. So treating us like children and >> taking away >> the power tools is not appreciated. > > Stop trying to break the internet and I'll treat you like an adult. And now, even more astounding arrogance. No one is trying to break the internet. People are, on the other hand, insisting that they retain certain capabilities to administer their own networks in the way THEY consider best, regardless of your arrogant idea of how they SHOULD administer their networks. Since their networks are working today in the manner they describe in IPv4, I can not accept your argument that their networks are broken. Further, the idea that it is possible to "break the internet" by giving administrators the option to assign router information from a DHCP server is simply absurd. Owen From sthaug at nethelp.no Thu Oct 22 06:59:52 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 22 Oct 2009 13:59:52 +0200 (CEST) Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE04376.5010001@foobar.org> References: <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> <4AE04376.5010001@foobar.org> Message-ID: <20091022.135952.71104044.sthaug@nethelp.no> > > I point you to a fairly common Internet architecture artifact, > > the exchange point... dozens of routers sharing a common > > media for peering exchange. > > Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance > to an IXP? Being one of these "artefact" operators - and clearly stuck > with a very small dinosaur brain - I am having some trouble understanding > the point you're attempting to make here. IPv6 ND is relevant, obviously. RA, DHCP or DHCPv6 are not relevant here. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From tvest at eyeconomics.com Thu Oct 22 07:04:03 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 22 Oct 2009 08:04:03 -0400 Subject: Fwd: [IP] [warning: layer 8/9] "Strange bedfellows, " aka a joint statement from Verizon Wireless and Google References: <2CF76151-5CF3-4C45-8020-F0A5C6190D62@farber.net> Message-ID: <9B4B9260-0D79-4D0F-9827-296D584FC359@eyeconomics.com> Interesting, curious... but meaningful? To my mind Google's language seems to be focused on wireline issues, which I guess are probably quite a bit easier for Verizon Wireless to accommodate. Conversely, VW's emphasis on continuing self-regulation of wireless access would seem to be of secondary importance, at best, to Google. Does this mean that a future of combat over "my (TCP) ports" is somewhat less likely? Does this mean that Google won't be offering me FTTH within the next 2-3 years? Inquiring minds take note! TV Begin forwarded message: > From: David Farber > Date: October 22, 2009 7:27:48 AM EDT > To: "ip" > Subject: [IP] Finding Common Ground on an Open Internet - a joint > statement from Lowell McAdam, CEO Verizon Wireless and Eric Schmidt, > CEO Google. > Reply-To: dave at farber.net > > A Technology and Telecommunications Policy Blog > Thursday, October 22, 2009 > > Finding Common Ground on an Open Internet > > The following is a joint statement from Lowell McAdam, CEO Verizon > Wireless and Eric Schmidt, CEO Google. > > > Verizon and Google might seem unlikely bedfellows in the current > debate > around network neutrality, or an open Internet. And while it's true we > do disagree quite strongly about certain aspects of government > policy in > this area--such as whether mobile networks should even be part of the > discussion--there are many issues on which we agree. For starters we > both think it's essential that the Internet remains an unrestricted > and > open platform--where people can access any content (so long as it's > legal), as well as the services and applications of their choice. > > > > There are two key factors driving innovation on the web today. First > is > the programming language of the Internet, which was designed over > forty > years ago by engineers who wanted the freedom to communicate from any > computer, anywhere in the world. It enables Macs to talk to PCs, > Blackberry Storms to iPhones, the newest computers to the oldest > hardware on the planet across any kind of network--cable, DSL, fiber, > mobile, WiFi or even dial up. > > > > Second, private investment is dramatically increasing broadband > capacity > and the intelligence of networks, creating the infrastructure to > support > ever more sophisticated applications. > > > > As a result, however or wherever you access the Internet the people > you > want to connect with can receive your message. There is no central > authority that can step in and prevent you from talking to someone > else, > or that imposes rules prescribing what services should be available. > > > > Transformative is an over-used word, especially in the tech sector. > But > the Internet has genuinely changed the world. Consumers of all stripes > can decide which services they want to use and the companies they > trust > to provide them. In addition, if you're an entrepreneur with a big > idea, > you can launch your service online and instantly connect to an > audience > of billions. You don't need advance permission to use the network. At > the same time, network providers are free to develop new applications, > either on their own or in collaboration with others. > > > > This kind of "innovation without permission" has changed the way we do > business forever, fueling unprecedented collaboration, creativity and > opportunity. And because America has been at the forefront of most of > these changes, we have disproportionately benefited in terms of > economic > growth and job creation. > > > > So, in conjunction with the Federal Communications Commission's > national > plan to bring broadband to all Americans, we understand its decision > to > start a debate about how best to protect and promote the openness of > the > Internet. FCC Chairman Julius Genachowski has promised a thoughtful, > transparent decision-making process, and we look forward to taking > part > in the analysis and discussion that is to follow. We believe this kind > of process can work, because as the two of us have debated these > issues > we have found a number of basic concepts to agree on. > > > > First, it's obvious that users should continue to have the final say > about their web experience, from the networks and software they use, > to > the hardware they plug in to the Internet and the services they access > online. The Internet revolution has been people powered from the very > beginning, and should remain so. The minute that anyone, whether from > government or the private sector, starts to control how people use the > Internet, it is the beginning of the end of the Net as we know it. > > > > Second, advanced and open networks are essential to the future > development of the Web. Policies that continue to provide incentives > for > investment and innovation are a vital part of the debate we are now > beginning. > > > > Third, the FCC's existing wireline broadband principles make clear > that > users are in charge of all aspects of their Internet experience--from > access to apps and content. So we think it makes sense for the > Commission to establish that these existing principles are > enforceable, > and implement them on a case-by-case basis. > > > > Fourth, we're in wild agreement that in this rapidly changing Internet > ecosystem, flexibility in government policy is key. Policymakers > sometimes fall prey to the temptation to write overly detailed rules, > attempting to predict every possible scenario and address every > possible > concern. This can have unintended consequences. > > > > Fifth, broadband network providers should have the flexibility to > manage > their networks to deal with issues like traffic congestion, spam, > "malware" and denial of service attacks, as well as other threats that > may emerge in the future--so long as they do it reasonably, consistent > with their customers' preferences, and don't unreasonably discriminate > in ways that either harm users or are anti-competitive. They should > also > be free to offer managed network services, such as IP television. > > > > Finally, transparency is a must. Chairman Genachowski has proposed > adding this principle to the FCC's guidelines, and we both support > this > step. All providers of broadband access, services and applications > should provide their customers with clear information about their > offerings. > > > > Doubtless, there will be disagreements along the way. While Verizon > supports openness across its networks, it believes that there is no > evidence of a problem today -- especially for wireless -- and no basis > for new rules and that regulation in the US could have a detrimental > effect globally. While Google supports light touch regulation, it > believes that safeguards are needed to combat the incentives for > carriers to pick winners and losers online. > > > > Both of our businesses rely on each other. So we believe it's > appropriate to discuss how we ensure that consumers can get the > information, products, and services they want online, encourage > investment in advanced networks and ensure the openness of the web > around the world. We're ready to engage in this important policy > discussion. From kauer at biplane.com.au Thu Oct 22 07:09:25 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Oct 2009 23:09:25 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022113019.GG32008@vacation.karoshi.com.> References: <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> <1256208278.30246.683.camel@karl> <20091022110816.GD32008@vacation.karoshi.com.> <1256210328.30246.740.camel@karl> <20091022113019.GG32008@vacation.karoshi.com.> Message-ID: <1256213365.30246.759.camel@karl> On Thu, 2009-10-22 at 11:30 +0000, bmanning at vacation.karoshi.com wrote: > > But my question was not about IPv6. How do IPv4 routers operate in such > > a situation? > exchange design 101. Thanks :-) I was being a bit Socratic. In the IPv4 world, routers in such complex environments are generally manually configured. In other situations they might use a routing protocol. Turning off RA in a similar environment with IPv6 is no loss over IPv6. My point (several messages ago,now) was in regard to DHCP information being used to send preferred route information; seems to me that in a situation where RA preference levels are not cutting it, a DHCP server sending discrimination information is probably not going to cut it either. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From frederic at placenet.org Thu Oct 22 07:08:44 2009 From: frederic at placenet.org (=?ISO-8859-1?Q?Fr=E9d=E9ric?=) Date: Thu, 22 Oct 2009 14:08:44 +0200 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <63ac96a50910210500p12ba9da9lc56ff667b15ba085@mail.gmail.com> References: <4AD3865B.8010908@he.net> <63ac96a50910202253v2948298raab6e5029878f65a@mail.gmail.com> <20091021071320.GS51443@gerbil.cluepon.net> <63ac96a50910210500p12ba9da9lc56ff667b15ba085@mail.gmail.com> Message-ID: <1256213324.8059.1.camel@home> please full support huricane ! De-peer your ipv6 peering cogent/telia or max prepend it. ! Le mercredi 21 octobre 2009 ? 05:00 -0700, Matthew Petach a ?crit : > On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen wrote: > > > On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote: > > > And tonight we saw in public that even that path is being attempted: > > > > > > http://www.flickr.com/photos/77519640 at N00/4031434206/ > > > > > > (and yes, it was yummy and enjoyed by all at the peering BoF!) > > > > > > So Cogent...won't you please make nice with HE.net and get back > > > together again? ^_^ > > > > > > Matt > > > (speaking for neither party, but very happy to eat cake nonetheless) > > > > "Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier > > than the correct version. :) > > > > > And now even better shots of the cake have been forthcoming from > people. :) > > http://www.flickr.com/photos/77519640 at N00/4031195041/ > > (I was all the way at the far other end of the room taking notes on the > laptop, > so I never got to see the cake intact at all--all the photos are from others > who > were closer to the cake, and got to see it in its pristine glory). > > Fortunately, I did get to partake in the eating of it. ^_^ > > Matt > (This cake is great, it's so delicious and moist...* ;) > > > > *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html > From rps at maine.edu Thu Oct 22 07:11:39 2009 From: rps at maine.edu (Ray Soucy) Date: Thu, 22 Oct 2009 08:11:39 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021213426.GA6981@isc.org> Message-ID: <7a6830090910220511i5562c0e0p26f2d0eb7a3fa108@mail.gmail.com> Just to clear things up, I'm not advocating the use of 80-bit prefixes. I was asking if they were a legitimate way to prevent SLAAC in environments with hardware that don't support disabling the autonomous flag for a prefix, or hosts that don't respect the autonomous flag. I've since done some testing in the lab, and have found that the majority of operating systems that are still in use respect the autonomous flag when deciding whether or not to run SLAAC if IPv6 is implemented, so this becomes a non-issue. I agree, sticking with a 64-bit prefix for every network is a good thing. SLAAC itself is also a good thing and I'm not advocating that it go away. I think its rather elegant and provides a lot of flexibility. That said, DHCPv6 is also a key part of IPv6. The fact that we have M and O flags in RA, and the A flag in advertised prefixes is a pretty strong signal that both stateless and stateful configuration are valid choices for IPv6 deployment. Adding DNS information to RA would generally be a bad idea. There is more to host configuration than just DNS, though DNS is the most common. I think that RA knows its role and archives it rather nicely. When you want to provide hosts with other configuration, like DNS, you can do so making use of a lightweight implementation of DHCPv6. In fact, most routers already support this. The argument that implementing DHCPv6 in the client is somehow too much work is ridiculous. DHCPv6 is as essential to IPv6 as ICMPv6 and MLD. You really shouldn't consider an implementation of IPv6 without a functional DHCPv6 client complete. At the same time, adding gateway information to DHCPv6 is also a bad idea. This is already accomplished by RA in an elegant and thoughtful way. This whole line of thinking is a result of the mindset that SLAAC and DHCPv6 are mutually exclusive; they're not. RA, SLAAC, and DHCPv6 compliment one another. They are all important components of the IPv6 addressing architecture. What we have now generally works well. Getting vendors to work together and actually implement things the same way is sometimes a challenge. Perhaps we need to update the language on RFCs from MAY and SHOULD to MUST and eliminate the ambiguity of what needs to be implemented with IPv6. In an enterprise environment, SLAAC has no place. It makes perfect sense to not run SLAAC on prefixes you advertised in this case. Just because SLAAC is the default doesn't mean it's the only method of deployment. There are still some challenges to work out with DHCPv6 implementations, and it may help dual-stack environments if DHCPv6 is amended to include a MAC address in requests when running on a dual-stack network so associations can be made between IP and IPv6 addresses on a host, but the use of DUID is generally a good thing. Once we start seeing more IPAM solutions include support for IPv6 and DHCPv6 I think a lot of the hostility towards DHCPv6 will go away. We've been implementing DHCPv6 support in our home-grown IPAM solution and have found that it all works rather nicely. Mac OS X is a challenge since it doesn't provide a DHCPv6 client, but our position has become that of saying we don't roll out IPv6 to clients with incomplete implementations and to leave it at that. IPv6 isn't quite necessary for all clients just yet. There is very little that is reachable by IPv6 only. Until that changes, we're willing to ignore certain groups of clients in an effort to pressure vendors to come into the fold and support DHCPv6 by default. If we have a case where there is a legitimate need for IPv6, we still have the ability to manually assign an IPv6 address on the host, but this would be on a very limited basis. If you're an ISP and deploying IPv6 for your residential customers, by all means run SLAAC. It's easy and it works. If you manage an enterprise IT environment and need control over your network, disable SLAAC and run DHCPv6. This will allow you to roll out IPv6 at your own pace, giving you time to make sure that hosts and users are prepared for it, all while maintaining the benefits of DHCPv6 in your architecture. That's all I'm trying to say. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From a.harrowell at gmail.com Thu Oct 22 07:14:19 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 22 Oct 2009 13:14:19 +0100 Subject: ISP/VPN's to China? In-Reply-To: References: <4ADF4B53.7020001@chrisserafin.com> <4AE027F8.3040809@evaristesys.com> Message-ID: <200910221314.27024.alexander.harrowell@stlpartners.com> On Thursday 22 October 2009 12:38:11 Chris Edwards wrote: > On Thu, 22 Oct 2009, Alex Balashov wrote: > | Understood. I guess the angle I was going more for was: Is this > | actually practical to do in a country with almost as many Internet users > | as the US has people? > | > | I had always assumed that broad policies and ACLs work in China, but most > | forms of DPI and traffic pattern analysis aren't practical simply for > | computational feasibility reasons. Not unless the system were highly > | distributed. > > Perhaps they only need make an example of a few, and thus introduce an > element of fear for everyone else. I had always assumed that the Gt. Firewall, and especially the fake RST element of it, existed precisely to let the geeks and weirdos stand out of the naive traffic so they could be subjected to special treatment. Similarly, this is the approach the Iranians seem to have taken after their disputed election - although there isn't a telco monopoly, there's a wholesale transit monopoly, and they just had the transit provider rate-limit everyone. My understanding of this was that "normal" users would give up and do something else, and only people who really wanted to reach the outside world or each other - i.e. potential subversives - would keep trying. Therefore, not only would the volume of traffic to DPI, proxy etc be lower, but the concentration of suspect traffic in it would be higher. From this point of view, I suppose there's some value in using an IPSec or SSL VPN, because that's what corporate traveller applications tend to use and they'll therefore never cut it off. I mean, are you suggesting that the assistant party secretary of Wuhan won't be able to log into CommunistSpace (Iike Facebook with Chinese characteristics) while he's on the road? Unthinkable! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From owen at delong.com Thu Oct 22 07:19:39 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 05:19:39 -0700 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <1256213324.8059.1.camel@home> References: <4AD3865B.8010908@he.net> <63ac96a50910202253v2948298raab6e5029878f65a@mail.gmail.com> <20091021071320.GS51443@gerbil.cluepon.net> <63ac96a50910210500p12ba9da9lc56ff667b15ba085@mail.gmail.com> <1256213324.8059.1.camel@home> Message-ID: <2FDB432B-03D4-4788-AD37-98A7E67F14DA@delong.com> Please don't break existing connectivity in an effort to show support for Hurricane. That's going in the wrong direction and it doesn't help the users of the internet, your customers, or ours. Please do continue to, or start peering with Hurricane. The internet works best when people peer. Breaking or damaging that in any way is not helping any of our customers and it is contrary to Hurricane's desire. We appreciate the intended message of support, but, it's most important to preserve functionality for all of our customers. Thanks, Owen DeLong IPv6 Evangelist Hurricane Electric On Oct 22, 2009, at 5:08 AM, Fr?d?ric wrote: > > please full support huricane ! > > De-peer your ipv6 peering cogent/telia or max prepend it. > > ! > > > > > > Le mercredi 21 octobre 2009 ? 05:00 -0700, Matthew Petach a ?crit : >> On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen > >wrote: >> >>> On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote: >>>> And tonight we saw in public that even that path is being >>>> attempted: >>>> >>>> http://www.flickr.com/photos/77519640 at N00/4031434206/ >>>> >>>> (and yes, it was yummy and enjoyed by all at the peering BoF!) >>>> >>>> So Cogent...won't you please make nice with HE.net and get back >>>> together again? ^_^ >>>> >>>> Matt >>>> (speaking for neither party, but very happy to eat cake >>>> nonetheless) >>> >>> "Cogent Pleas IPv6"... for some reason that "cake typo" is even >>> funnier >>> than the correct version. :) >>> >>> >> And now even better shots of the cake have been forthcoming from >> people. :) >> >> http://www.flickr.com/photos/77519640 at N00/4031195041/ >> >> (I was all the way at the far other end of the room taking notes on >> the >> laptop, >> so I never got to see the cake intact at all--all the photos are >> from others >> who >> were closer to the cake, and got to see it in its pristine glory). >> >> Fortunately, I did get to partake in the eating of it. ^_^ >> >> Matt >> (This cake is great, it's so delicious and moist...* ;) >> >> >> >> *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html >> > From mohacsi at niif.hu Thu Oct 22 07:25:52 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 22 Oct 2009 14:25:52 +0200 (CEST) Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022103041.GB32008@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> Message-ID: On Thu, 22 Oct 2009, bmanning at vacation.karoshi.com wrote: > On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: >> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: >>> If, on the other hand, the REAL desire is to have a DHCP server break >>> the tie in the selection between several routers that advertise their >>> presence, that wouldn't be unreasonable. >> >> The RA contains a preference level... maybe that doesn't cut it if >> multiple routers are sending the same preference level, but presumably >> that would not happen in a well-tended network. > > I point you to a fairly common Internet architecture artifact, > the exchange point... dozens of routers sharing a common > media for peering exchange. And you want to use router advertisments for assigning addresses for them? Huh! Regards, Janos From trejrco at gmail.com Thu Oct 22 07:32:55 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Thu, 22 Oct 2009 12:32:55 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE0408C.9080303@coders.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com><20091022102748.GA32008@vacation.karoshi.com.><4AE0408C.9080303@coders.net> Message-ID: <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? ... Just thinking 'out loud' ... /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Perry Lorier Date: Fri, 23 Oct 2009 00:22:52 To: Cc: Subject: Re: IPv6 Deployment for the LAN bmanning at vacation.karoshi.com wrote: > On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote: > >> On 22 okt 2009, at 01:55, bmanning at vacation.karoshi.com wrote: >> >> >>> so your not a fan of the smart edge and the stupid network. >>> >> I'm a fan of getting things right. A server somewhere 5 subnets away >> doesn't really know what routers are working on my subnet. It can take >> a guess and then wait for people to complain and then an admin to fix >> stuff if the guess is wrong, but I wouldn't call that a "smart edge". >> >> Always learn information from the place where it's actually known. >> > > i'm ok w// that mindset. > > one should learn routing from the router(s), > time from the time servers, > DNS from the DNS servers, > etc... > > I quite liked the old http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea. (tl;dr version: Have a set of well known site local anycast address for recursive name servers). It has a number of nice features such as: * since it's not in globally routable space people can't (ab)use your recursive name servers from outside your network. * you don't have to change recursive name servers when going to a different network -- they're the same everywhere. * the addresses can be set as the default addresses by the OS manufacturer, and then don't need to be configured ever again. * If your recursive name server becomes unreachable, broken or otherwise out of contact, it withdraws the address from your IGP, then since you can any cast these addresses, another node takes over. Similar to the shared fate idea of RA's. * You don't tie your recursive nameservers addresses to any point in the network, since they have their own special range, moving them, reshuffling them, or anything doesn't impact anything. They don't need to cohabit a router sending RA's or anything odd like that. However it has a number of obvious drawbacks, primarily amongst them being that it uses deprecated site local addresses. You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers. Another obvious approach might be to have a service discovery protocol where you send to a "service discovery" multicast group a message asking "wheres the nearest nameserver(s)?" then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a "ServiceDiscovery-Guard" feature for switches.... Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :) From tvest at eyeconomics.com Thu Oct 22 07:33:09 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 22 Oct 2009 08:33:09 -0400 Subject: ISP/VPN's to China? In-Reply-To: References: <4ADF4B53.7020001@chrisserafin.com> <1256167734_1961523@mail1.tellurian.net> <4ADF9B08.4040906@evaristesys.com> <8BBEA259-840A-4503-AB8D-6A269A39DD56@cisco.com> <4ADFA0B8.1030708@evaristesys.com> <20091022012738.GB25573@skywalker.creative.net.au> <4AE027F8.3040809@evaristesys.com> Message-ID: <3792834B-582E-4B54-BB08-81600B9198F4@eyeconomics.com> On Oct 22, 2009, at 7:38 AM, Chris Edwards wrote: > On Thu, 22 Oct 2009, Alex Balashov wrote: > > | Understood. I guess the angle I was going more for was: Is this > actually > | practical to do in a country with almost as many Internet users as > the US has > | people? > | > | I had always assumed that broad policies and ACLs work in China, > but most > | forms of DPI and traffic pattern analysis aren't practical simply > for > | computational feasibility reasons. Not unless the system were > highly > | distributed. > > Perhaps they only need make an example of a few, and thus introduce an > element of fear for everyone else. Not "a few," but rather quite a lot, albeit only infrequently, and at unpredictable intervals, with a very high inclusion/exclusion error rate -- an artifact of the absence clear and easily demonstrable line between compliance/non-compliance (which is itself an artifact of the ?? [internally published only] nature of many of the related rules). http://www.usc.cuhk.edu.hk/wk_wzdetails.asp?id=2791 www.usc.cuhk.edu.hk/webmanager/wkfiles/2791_1_paper.pdf TV From frederic at placenet.org Thu Oct 22 07:33:00 2009 From: frederic at placenet.org (=?ISO-8859-1?Q?Fr=E9d=E9ric?=) Date: Thu, 22 Oct 2009 14:33:00 +0200 Subject: IPv6 internet broken, cogent/telia/hurricane not peering In-Reply-To: <2FDB432B-03D4-4788-AD37-98A7E67F14DA@delong.com> References: <4AD3865B.8010908@he.net> <63ac96a50910202253v2948298raab6e5029878f65a@mail.gmail.com> <20091021071320.GS51443@gerbil.cluepon.net> <63ac96a50910210500p12ba9da9lc56ff667b15ba085@mail.gmail.com> <1256213324.8059.1.camel@home> <2FDB432B-03D4-4788-AD37-98A7E67F14DA@delong.com> Message-ID: <1256214780.9114.0.camel@home> yes of course, sorry my wrong use of english. Le jeudi 22 octobre 2009 ? 05:19 -0700, Owen DeLong a ?crit : > Please don't break existing connectivity in an effort to show support > for Hurricane. > > That's going in the wrong direction and it doesn't help the users of > the internet, your customers, > or ours. > > Please do continue to, or start peering with Hurricane. > > The internet works best when people peer. Breaking or damaging that in > any way is not > helping any of our customers and it is contrary to Hurricane's desire. > > We appreciate the intended message of support, but, it's most > important to preserve > functionality for all of our customers. > > Thanks, > > Owen DeLong > IPv6 Evangelist > Hurricane Electric > > On Oct 22, 2009, at 5:08 AM, Fr?d?ric wrote: > > > > > please full support huricane ! > > > > De-peer your ipv6 peering cogent/telia or max prepend it. > > > > ! > > > > > > > > > > > > Le mercredi 21 octobre 2009 ? 05:00 -0700, Matthew Petach a ?crit : > >> On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen >> >wrote: > >> > >>> On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote: > >>>> And tonight we saw in public that even that path is being > >>>> attempted: > >>>> > >>>> http://www.flickr.com/photos/77519640 at N00/4031434206/ > >>>> > >>>> (and yes, it was yummy and enjoyed by all at the peering BoF!) > >>>> > >>>> So Cogent...won't you please make nice with HE.net and get back > >>>> together again? ^_^ > >>>> > >>>> Matt > >>>> (speaking for neither party, but very happy to eat cake > >>>> nonetheless) > >>> > >>> "Cogent Pleas IPv6"... for some reason that "cake typo" is even > >>> funnier > >>> than the correct version. :) > >>> > >>> > >> And now even better shots of the cake have been forthcoming from > >> people. :) > >> > >> http://www.flickr.com/photos/77519640 at N00/4031195041/ > >> > >> (I was all the way at the far other end of the room taking notes on > >> the > >> laptop, > >> so I never got to see the cake intact at all--all the photos are > >> from others > >> who > >> were closer to the cake, and got to see it in its pristine glory). > >> > >> Fortunately, I did get to partake in the eating of it. ^_^ > >> > >> Matt > >> (This cake is great, it's so delicious and moist...* ;) > >> > >> > >> > >> *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html > >> > > > > From kauer at biplane.com.au Thu Oct 22 07:36:47 2009 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Oct 2009 23:36:47 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> Message-ID: <1256215007.30246.772.camel@karl> On Thu, 2009-10-22 at 14:25 +0200, Mohacsi Janos wrote: > On Thu, 22 Oct 2009, bmanning at vacation.karoshi.com wrote: > > I point you to a fairly common Internet architecture artifact, > > the exchange point... dozens of routers sharing a common > > media for peering exchange. > > And you want to use router advertisments for assigning addresses for them? > Huh! You've got the wrong end of the stick. The point of this exchange was that RA was not going to do the job. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nick at foobar.org Thu Oct 22 07:45:29 2009 From: nick at foobar.org (Nick Hilliard) Date: Thu, 22 Oct 2009 13:45:29 +0100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022114916.GJ32008@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> <20091022103041.GB32008@vacation.karoshi.com.> <4AE04376.5010001@foobar.org> <20091022114916.GJ32008@vacation.karoshi.com.> Message-ID: <4AE053E9.8040502@foobar.org> On 22/10/2009 12:49, bmanning at vacation.karoshi.com wrote: > its been a few weeks/years/minutes since I ran an exchange fabric, > but when we first turned up IPv6 - the first thing they did was try > to hand all the other routers IPv6 addresses. that pesky RA/ND > thing... had to turn it off ... RA preference would not work, since > there was no -pecking- order - all the routers were peers. Bill, I am not able to look at this paragraph without being reminded of Charles Babbage's take on the GIGO principal: "On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." Nick From tvest at eyeconomics.com Thu Oct 22 07:54:29 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 22 Oct 2009 08:54:29 -0400 Subject: ISP/VPN's to China? In-Reply-To: <200910221314.27024.alexander.harrowell@stlpartners.com> References: <4ADF4B53.7020001@chrisserafin.com> <4AE027F8.3040809@evaristesys.com> <200910221314.27024.alexander.harrowell@stlpartners.com> Message-ID: <8264F26E-B826-466B-8CB7-787747D90C03@eyeconomics.com> On Oct 22, 2009, at 8:14 AM, Alexander Harrowell wrote: > On Thursday 22 October 2009 12:38:11 Chris Edwards wrote: >> On Thu, 22 Oct 2009, Alex Balashov wrote: >> | Understood. I guess the angle I was going more for was: Is this >> | actually practical to do in a country with almost as many >> Internet users >> | as the US has people? >> | >> | I had always assumed that broad policies and ACLs work in China, >> but most >> | forms of DPI and traffic pattern analysis aren't practical simply >> for >> | computational feasibility reasons. Not unless the system were >> highly >> | distributed. >> >> Perhaps they only need make an example of a few, and thus introduce >> an >> element of fear for everyone else. > > I had always assumed that the Gt. Firewall, and especially the fake > RST > element of it, existed precisely to let the geeks and weirdos stand > out of the > naive traffic so they could be subjected to special treatment. > > Similarly, this is the approach the Iranians seem to have taken > after their > disputed election - although there isn't a telco monopoly, there's a > wholesale > transit monopoly, and they just had the transit provider rate-limit > everyone. > My understanding of this was that "normal" users would give up and do > something else, and only people who really wanted to reach the > outside world > or each other - i.e. potential subversives - would keep trying. > Therefore, > not only would the volume of traffic to DPI, proxy etc be lower, but > the > concentration of suspect traffic in it would be higher. > > From this point of view, I suppose there's some value in using an > IPSec or SSL > VPN, because that's what corporate traveller applications tend to > use and > they'll therefore never cut it off. I mean, are you suggesting that > the > assistant party secretary of Wuhan won't be able to log into > CommunistSpace > (Iike Facebook with Chinese characteristics) while he's on the road? > Unthinkable! Generally speaking, the definition of "corporate traveller applications" in such cases == "Whatever anyone tries to do from the following specific address ranges, which are known to be accessible exclusively inside certain international hotels, exclusively to users who are willing to pay the equivalent of 1-2 weeks of avg. local income for the privilege). TV From kloch at kl.net Thu Oct 22 10:03:32 2009 From: kloch at kl.net (Kevin Loch) Date: Thu, 22 Oct 2009 11:03:32 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> Message-ID: <4AE07444.2000905@kl.net> Iljitsch van Beijnum wrote: > If, on the other hand, the REAL desire is to have a DHCP server break > the tie in the selection between several routers that advertise their > presence, that wouldn't be unreasonable. In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see. > There is no requirement that the IETF provides all functionality that > someone can think up. The list of desired functionality is infinite, and > much on that list is a bad idea and/or can be achieved in different ways. Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap. >> Seriously, we're all adults. So treating us like children and taking >> away >> the power tools is not appreciated. > > Stop trying to break the internet and I'll treat you like an adult. At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? - Kevin From drc at virtualized.org Thu Oct 22 10:22:50 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 22 Oct 2009 08:22:50 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE07444.2000905@kl.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> Message-ID: <9F365689-1896-41D6-A047-F3151DF2FD1D@virtualized.org> > Ok, lets start with not breaking the functionality we have today > in IPv4. Once you get that working again we can look at new > ideas (like RA) that might have utility. Let the new stuff live/die on > it's own merits. The Internet is very good at sorting out the useful > technology from the crap. Right. I'll admit some confusion here. If the IETF, due to religion or aesthetics, is blocking attempts at making DHCPv6 do what network operators _need_ (as opposed to want), why haven't network operators routed around the problem and gone and funded folks like ISC, NLNetLabs, Cisco, Juniper, et al., to implement what they need? > At conferences I keep hearing "It would be great if the IETF had > more operator input." Yet whenever we try to provide operationally > useful advice we are ridiculed for not being smart enough to know > how things should work. > > How do we fix that? You seem to be asking "how do we make people not stupid". Folks tend to simplify reality so that it fits their world view. Stupid people attempt to force that simplified reality onto others. You can either play their game, attempting to get them to understand reality is often more complicated than we'd like, or route around them. Or you can post to NANOG... :-) Regards, -drc From iljitsch at muada.com Thu Oct 22 10:44:48 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 22 Oct 2009 17:44:48 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE07444.2000905@kl.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> Message-ID: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> On 22 okt 2009, at 17:03, Kevin Loch wrote: >> If, on the other hand, the REAL desire is to have a DHCP server >> break the tie in the selection between several routers that >> advertise their presence, that wouldn't be unreasonable. > In some configurations not all hosts are supposed to use the same > router. We need the _option_ to specify a default gateway and > have the override any RA's a host may see. Lots of people "need" a gun. If I were living in a place where bears walk around loose I might "need" one, too. But most guns are used to shoot the owner in the foot most of the time. The world would be a better place without them. Like I said, if there's a bunch of routers announcing their presence and you want a DHCP option to provide guidance to a host as to which one to choose, that would be fine. But pointing to a potentially non- existing address in the hopes that there will magically be a router residing at that address would a serious regression in robustness. >> There is no requirement that the IETF provides all functionality >> that someone can think up. The list of desired functionality is >> infinite, and much on that list is a bad idea and/or can be >> achieved in different ways. > Ok, lets start with not breaking the functionality we have today > in IPv4. Once you get that working again we can look at new > ideas (like RA) that might have utility. What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4. > Let the new stuff live/die on > it's own merits. The Internet is very good at sorting out the useful > technology from the crap. Absolutely not. Give users the choice between something good that suits their needs 83% and a piece of crap tht suits their needs 84% and they'll choose the latter each and every time. Users get to say what they need. They don't get to design the solution by committee any more than they get to design bridges or airplanes by committee, although of course they do get to choose which ones to use. > At conferences I keep hearing "It would be great if the IETF had > more operator input." Yet whenever we try to provide operationally > useful advice we are ridiculed for not being smart enough to know > how things should work. > How do we fix that? Tell the IETF your real requirements, don't try to do back seat protocol design. Protocol design is hard, the IETF gets it wrong most of the time (and they do better than some of their colleagues, still). Suggesting specific changes to a protocol as a solution to an unstated real requirement wastes everyone's time. With writing, they tell you "listen when people say there is a problem, but ignore them when they tell you what the problem is". Same thing here. Users know their needs, but generally they don't know the best way to meet those needs. From adrian at creative.net.au Thu Oct 22 10:55:21 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 22 Oct 2009 23:55:21 +0800 Subject: IPv6 Deployment for the LAN In-Reply-To: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> Message-ID: <20091022155521.GA23181@skywalker.creative.net.au> On Thu, Oct 22, 2009, Iljitsch van Beijnum wrote: > What does that have to with anything? IPv6 stateless autoconfig > predates the widespread use of DHCPv4. So does IPX and IPX/RIP. Why does this thread seem to rehash some big disconnect between academics, IETF and actual deployment-oriented people who have a job to do? Silly architecture groups.. Adrian (Glad I'm not involved. I'd lose patience and punch people.) From zhiyunq at umich.edu Thu Oct 22 12:22:17 2009 From: zhiyunq at umich.edu (Zhiyun Qian) Date: Thu, 22 Oct 2009 13:22:17 -0400 Subject: ISP port blocking practice Message-ID: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> Hi all, What is the common practice for enforcing port blocking policy (or what is the common practice for you and your ISP)? More specifically, when ISPs try to block certain outgoing port (port 25 for instance), they could do two rules: 1). For any outgoing traffic, if the destination port is 25, then drop the packets. 2). For any incoming traffic, if the source port is 25, then drop the packets. Note that either of the rule would be able to block outgoing port 25 traffic since each rule essentially represent one direction in a TCP flow. Of course, they could apply both rules. However, based on our measurement study, it looks like most of the ISPs are only using rule 1). Is there any particular reason why rule 1) instead of rule 2)? Or maybe both? Also, is it common that the rules are based on tcp flags (e.g. SYN, SYN-ACK)? One would think block SYN packet is good enough. Regards. -Zhiyun From tony at lava.net Thu Oct 22 12:32:42 2009 From: tony at lava.net (Antonio Querubin) Date: Thu, 22 Oct 2009 07:32:42 -1000 (HST) Subject: ISP port blocking practice In-Reply-To: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> Message-ID: On Thu, 22 Oct 2009, Zhiyun Qian wrote: > the common practice for you and your ISP)? More specifically, when ISPs try > to block certain outgoing port (port 25 for instance), they could do two > rules: > 1). For any outgoing traffic, if the destination port is 25, then drop the > packets. > 2). For any incoming traffic, if the source port is 25, then drop the > packets. > > Note that either of the rule would be able to block outgoing port 25 traffic > since each rule essentially represent one direction in a TCP flow. Of course, > they could apply both rules. However, based on our measurement study, it > looks like most of the ISPs are only using rule 1). Is there any particular > reason why rule 1) instead of rule 2)? Or maybe both? Because rule 1 prevents the target server from having to respond to the initial connection request in the first place thereby reducing load on the server and reducing network traffic. Ie. both rules prevent the connection but 1 stops it earlier. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From Valdis.Kletnieks at vt.edu Thu Oct 22 12:33:17 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 22 Oct 2009 13:33:17 -0400 Subject: ISP port blocking practice In-Reply-To: Your message of "Thu, 22 Oct 2009 13:22:17 EDT." <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> Message-ID: <13222.1256232797@turing-police.cc.vt.edu> On Thu, 22 Oct 2009 13:22:17 EDT, Zhiyun Qian said: > Hi all, > > What is the common practice for enforcing port blocking policy (or > what is the common practice for you and your ISP)? More specifically, > when ISPs try to block certain outgoing port (port 25 for instance), > they could do two rules: > 1). For any outgoing traffic, if the destination port is 25, then drop > the packets. > 2). For any incoming traffic, if the source port is 25, then drop the > packets. > > Note that either of the rule would be able to block outgoing port 25 > traffic since each rule essentially represent one direction in a TCP > flow. Of course, they could apply both rules. However, based on our > measurement study, it looks like most of the ISPs are only using rule > 1). Is there any particular reason why rule 1) instead of rule 2)? Or > maybe both? Note that some spammers use assymetric routing with forged packets - they spew out a stream of crafted packets from a compromised machine, showing a different source IP. The claimed source IP is also under the spammer's control, and just basically has to catch the inbound SYN/ACK and forward it to the spam-sender (and, if wanted, sink the other ACKs and forward the SMTP replies from the server to the real sender). So you can have a big sending pipe that doesn't get ingress-filtered(*) sending the spam, and do the control from a throwaway that may have a small pipe. (*) Of course it's not ingress-filtered - if somebody is selling a spammer a big pipe for this, they can arrange to fail to filter. ;) The upshot is, of course, that you want to do (1) because you never actually see the (2) packets, they're going someplace else... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Thu Oct 22 13:10:10 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 11:10:10 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> Message-ID: On Oct 22, 2009, at 8:44 AM, Iljitsch van Beijnum wrote: > On 22 okt 2009, at 17:03, Kevin Loch wrote: > >>> If, on the other hand, the REAL desire is to have a DHCP server >>> break the tie in the selection between several routers that >>> advertise their presence, that wouldn't be unreasonable. > >> In some configurations not all hosts are supposed to use the same >> router. We need the _option_ to specify a default gateway and >> have the override any RA's a host may see. > > Lots of people "need" a gun. If I were living in a place where bears > walk around loose I might "need" one, too. But most guns are used to > shoot the owner in the foot most of the time. The world would be a > better place without them. > As a strong proponent of the second amendment, it is now clear to me that we have a fundamental disagreement on how society should interoperate which is unlikely to ever be resolved between us. > Like I said, if there's a bunch of routers announcing their presence > and you want a DHCP option to provide guidance to a host as to which > one to choose, that would be fine. But pointing to a potentially non- > existing address in the hopes that there will magically be a router > residing at that address would a serious regression in robustness. > It really isn't a serious regression in robustness in the real world. It really is functioning today. Most DHCP servers are not used to shoot users in the head, despite your claims to the contrary. >>> There is no requirement that the IETF provides all functionality >>> that someone can think up. The list of desired functionality is >>> infinite, and much on that list is a bad idea and/or can be >>> achieved in different ways. > >> Ok, lets start with not breaking the functionality we have today >> in IPv4. Once you get that working again we can look at new >> ideas (like RA) that might have utility. > > What does that have to with anything? IPv6 stateless autoconfig > predates the widespread use of DHCPv4. > Hmmm... Perhaps you should be asking yourself why IPv6 SLAAC was not used as the model for address assignment in IPv4 instead of DHCPv4 in that case? >> Let the new stuff live/die on >> it's own merits. The Internet is very good at sorting out the useful >> technology from the crap. > > Absolutely not. Give users the choice between something good that > suits their needs 83% and a piece of crap tht suits their needs 84% > and they'll choose the latter each and every time. > Yes... As well they should. Meeting their needs 84% of the time is actually vastly superior. > Users get to say what they need. They don't get to design the > solution by committee any more than they get to design bridges or > airplanes by committee, although of course they do get to choose > which ones to use. > Depends on how you define users. If you don't think that airlines have a substantial amount of technical input into how airliners are designed, you are vastly mistaken. >> At conferences I keep hearing "It would be great if the IETF had >> more operator input." Yet whenever we try to provide operationally >> useful advice we are ridiculed for not being smart enough to know >> how things should work. > >> How do we fix that? > > Tell the IETF your real requirements, don't try to do back seat > protocol design. Protocol design is hard, the IETF gets it wrong > most of the time (and they do better than some of their colleagues, > still). Suggesting specific changes to a protocol as a solution to > an unstated real requirement wastes everyone's time. > > With writing, they tell you "listen when people say there is a > problem, but ignore them when they tell you what the problem is". > Same thing here. Users know their needs, but generally they don't > know the best way to meet those needs. OK... Here's the real requirement: Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: 1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options) These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. Owen From sthaug at nethelp.no Thu Oct 22 13:51:35 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 22 Oct 2009 20:51:35 +0200 (CEST) Subject: IPv6 Deployment for the LAN In-Reply-To: References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> Message-ID: <20091022.205135.74697009.sthaug@nethelp.no> > > Like I said, if there's a bunch of routers announcing their presence > > and you want a DHCP option to provide guidance to a host as to which > > one to choose, that would be fine. But pointing to a potentially non- > > existing address in the hopes that there will magically be a router > > residing at that address would a serious regression in robustness. > > > It really isn't a serious regression in robustness in the real world. > It really is functioning today. Most DHCP servers are not used to > shoot users in the head, despite your claims to the contrary. This to me is one of the least credible claims of the RA/SLAAC crowd. On the one hand we have carriers around the world with millions and millions of customers getting default routes and other config through DHCPv4 every day. And most of the time it actually works very well! On the other hand we have RA/SLAAC with a vastly smaller customer base, vastly less real life testing - but which is still claimed to be so much better that DHCPv6 is not *allowed* to get a default route option. The mind boggles. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From vasil at ludost.net Thu Oct 22 14:03:31 2009 From: vasil at ludost.net (Vasil Kolev) Date: Thu, 22 Oct 2009 22:03:31 +0300 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> Message-ID: <1256238211.4101.13.camel@shrike.home.ludost.net> ? 11:10 -0700 ?? 22.10.2009 (??), Owen DeLong ??????: > OK... Here's the real requirement: > > Systems administrators who do not control routers need the ability in > a dynamic host configuration mechanism to > assign a number of parameters to the hosts they administer through > that dynamic configuration mechanism. These > parameters include, but, are not limited to: > > 1. Default Router > 2. DNS Resolver information > 3. Host can provide name to server so server can supply dynamic DNS > update > 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things > like Shim6, etc.) > 5. NTP servers > 6. Boot server > 7. Site specific attribute/value pairs (ala DHCPv4 Options) > > These assignments MUST be controlled by a server and not by the router > because the router is outside of the > administrative control of the Systems Administrator responsible for > the hosts being configured. > And to add a real-world case for this - two months ago at HAR (hacking at random, a convention in the Netherlands) I was in the network team, handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at some point we asked the question around - ok, how should we provide DNS and other useful information for the V6 only people? After a while with all the brains around, the decision was to write it on the datenklos through the field, where people can read it and configure it in their browsers. This would've been funny if it wasn't so sad. OTOH, for V4 everything with the DHCP worked fine (as it has always done, even at an event of this size), as is my experience with all the networks I've administered. Saying that DHCP doesn't work for me is extremely weird, as to me this means someone made specific effort to fuck it up. Finally - we have something that works, that's called DHCP. It might not be perfect, it might have some weird issues and implementations, but it's actually making our lives easier, is tested and works. I'd love anything that would be better, but as an option, not as the only choice I have. And it's not just the protocol that I care about. I care about that it's implemented in a HOST, where I can play with the software as much as possible, instead on a ROUTER, which is a vastly different device with rarely-updated OS, and even in the case where they're both the same machine(as in small office environments), they're again handled at different layers (kernel vs userspace). There are reasons that we're using what we're using, and not all of them are "because we're masochistic idiots". -- Regards, Vasil Kolev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: ???? ? ??????? ????????? ???? ?? ??????? URL: From james.cutler at consultant.com Thu Oct 22 14:22:11 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Thu, 22 Oct 2009 15:22:11 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256238211.4101.13.camel@shrike.home.ludost.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <1256238211.4101.13.camel@shrike.home.ludost.net> Message-ID: <1C027389-C888-4362-B950-4EDAEC547481@consultant.com> On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote: > ? 11:10 -0700 ?? 22.10.2009 (??), Owen DeLong ??????: > >> OK... Here's the real requirement: >> >> Systems administrators who do not control routers need the ability in >> a dynamic host configuration mechanism to >> assign a number of parameters to the hosts they administer through >> that dynamic configuration mechanism. These >> parameters include, but, are not limited to: >> >> 1. Default Router >> 2. DNS Resolver information >> 3. Host can provide name to server so server can supply dynamic DNS >> update >> 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of >> things >> like Shim6, etc.) >> 5. NTP servers >> 6. Boot server >> 7. Site specific attribute/value pairs (ala DHCPv4 Options) >> >> These assignments MUST be controlled by a server and not by the >> router >> because the router is outside of the >> administrative control of the Systems Administrator responsible for >> the hosts being configured. >> > > > And to add a real-world case for this - two months ago at HAR (hacking > at random, a convention in the Netherlands) I was in the network team, > handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 > connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and > at > some point we asked the question around - ok, how should we provide > DNS > and other useful information for the V6 only people? > > After a while with all the brains around, the decision was to write it > on the datenklos through the field, where people can read it and > configure it in their browsers. This would've been funny if it > wasn't so > sad. > > OTOH, for V4 everything with the DHCP worked fine (as it has always > done, even at an event of this size), as is my experience with all the > networks I've administered. Saying that DHCP doesn't work for me is > extremely weird, as to me this means someone made specific effort to > fuck it up. > > Finally - we have something that works, that's called DHCP. It might > not > be perfect, it might have some weird issues and implementations, but > it's actually making our lives easier, is tested and works. I'd love > anything that would be better, but as an option, not as the only > choice > I have. > And it's not just the protocol that I care about. I care about that > it's > implemented in a HOST, where I can play with the software as much as > possible, instead on a ROUTER, which is a vastly different device with > rarely-updated OS, and even in the case where they're both the same > machine(as in small office environments), they're again handled at > different layers (kernel vs userspace). > There are reasons that we're using what we're using, and not all of > them > are "because we're masochistic idiots". > > > -- > Regards, > Vasil Kolev Following on the comments above: The security domain for HOST should not overlap the security domain for ROUTER. That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social- engineering distributed malware began to affect BGP! Give the router managers the NTP server addresses and their DHCP forwarding list and leave them alone to produce a robust and reliable transport facility! James R. Cutler james.cutler at consultant.com From rps at maine.edu Thu Oct 22 14:23:13 2009 From: rps at maine.edu (Ray Soucy) Date: Thu, 22 Oct 2009 15:23:13 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091022.205135.74697009.sthaug@nethelp.no> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> Message-ID: <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> > This to me is one of the least credible claims of the RA/SLAAC crowd. > On the one hand we have carriers around the world with millions and > millions of customers getting default routes and other config through > DHCPv4 every day. And most of the time it actually works very well! > > On the other hand we have RA/SLAAC with a vastly smaller customer > base, vastly less real life testing - but which is still claimed to > be so much better that DHCPv6 is not *allowed* to get a default route > option. If the argument against RA being used to provide gateway information is "rogue RA," then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? I guess I'm not really seeing the case here. Are people really making use of DHCP to provide hosts on the same network with different default gateway information? If so, why? Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From bicknell at ufp.org Thu Oct 22 14:29:30 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 22 Oct 2009 12:29:30 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> Message-ID: <20091022192930.GA16755@ussenterprise.ufp.org> In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote: > If the argument against RA being used to provide gateway information > is "rogue RA," then announcing gateway information though the use of > DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but > you'll still have to deal with rogue DHCPv6. So what is gained? It's a huge difference, and any conference network shows it. Let's assume 400 people come into a room, get up and working (with DHCPv4, and IPv6 RA's). Someone now introduces a rogue IPv4 server. Who breaks? Anyone who requests a new lease. That is 400 people keep working just fine. Now, someone introduces a roge RA. Who breaks? All 400 users are instantly down. More importantly, there is another class of misconfigured device. I plugged in a Cisco router to download new code to it on our office network. It had a DHCP forward statement, and IPv6. It was from another site. The DHCP forward didn't work, it pointed to something non-existant that also was never configured for the local subnet. There was zero chance of IPv4 interfearance. The IPv6 network picked up the RA to a router with no routes though, and so simply plugging in the old router took down the entire office network. The operational threats of a DHCP based network and a RA based network are quite different. Try it on your own network. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rps at maine.edu Thu Oct 22 14:42:19 2009 From: rps at maine.edu (Ray Soucy) Date: Thu, 22 Oct 2009 15:42:19 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091022192930.GA16755@ussenterprise.ufp.org> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> Message-ID: <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> Sorry, not buying it. The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. What your proposing as a solution isn't much of a solution at all but just a (seemingly) lesser problem. On Thu, Oct 22, 2009 at 3:29 PM, Leo Bicknell wrote: > In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote: >> If the argument against RA being used to provide gateway information >> is "rogue RA," then announcing gateway information though the use of >> DHCPv6 doesn't solve anything. ?Sure you'll get around rogue RA, but >> you'll still have to deal with rogue DHCPv6. ?So what is gained? > > It's a huge difference, and any conference network shows it. > > Let's assume 400 people come into a room, get up and working (with > DHCPv4, and IPv6 RA's). > > Someone now introduces a rogue IPv4 server. ?Who breaks? ?Anyone who > requests a new lease. ?That is 400 people keep working just fine. > > Now, someone introduces a roge RA. ?Who breaks? ?All 400 users are > instantly down. > > More importantly, there is another class of misconfigured device. ?I > plugged in a Cisco router to download new code to it on our office > network. ?It had a DHCP forward statement, and IPv6. ?It was from > another site. > > The DHCP forward didn't work, it pointed to something non-existant that > also was never configured for the local subnet. ?There was zero chance > of IPv4 interfearance. > > The IPv6 network picked up the RA to a router with no routes though, and > so simply plugging in the old router took down the entire office > network. > > The operational threats of a DHCP based network and a RA based network > are quite different. ?Try it on your own network. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From alh-ietf at tndh.net Thu Oct 22 14:41:20 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 22 Oct 2009 12:41:20 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <9F365689-1896-41D6-A047-F3151DF2FD1D@virtualized.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <9F365689-1896-41D6-A047-F3151DF2FD1D@virtualized.org> Message-ID: <023701ca534f$a1110750$e33315f0$@net> David Conrad wrote: > > Ok, lets start with not breaking the functionality we have today > > in IPv4. Once you get that working again we can look at new > > ideas (like RA) that might have utility. Let the new stuff live/die > on > > it's own merits. The Internet is very good at sorting out the useful > > technology from the crap. > > Right. I'll admit some confusion here. If the IETF, due to religion > or aesthetics, is blocking attempts at making DHCPv6 do what network > operators _need_ (as opposed to want), why haven't network operators > routed around the problem and gone and funded folks like ISC, > NLNetLabs, Cisco, Juniper, et al., to implement what they need? > > > At conferences I keep hearing "It would be great if the IETF had > > more operator input." Yet whenever we try to provide operationally > > useful advice we are ridiculed for not being smart enough to know > > how things should work. > > > > How do we fix that? > > You seem to be asking "how do we make people not stupid". Folks tend > to simplify reality so that it fits their world view. Stupid people > attempt to force that simplified reality onto others. You can either > play their game, attempting to get them to understand reality is often > more complicated than we'd like, or route around them. Or you can post > to NANOG... :-) The root of the argument I see in this entire thread is the assumption that 'what we have for IPv4 has *always* been there'. There is lots of finger pointing at the IETF for failure to define 15 years ago, what we have evolved as the every-day assumptions about the IPv4 network of today. SLAAC was presented specifically to deal with the DHCP failure modes of the time, and the very real possibility that DHCP might not make it as a technology that operators would want to deploy. While lots of evolution happened in the DHCP space to deal with changing operational requirements, it is still a complex approach (which may be why it is favored by those that like to maintain a high salary). To be fair, there were failures in the IETF, as the SLAAC and DCHP sides couldn't get out of each other's way; so now instead of having 2 independent models for provisioning, we have 2 interdependent models. RFC 5006 is one step at breaking that interdependence, and more are needed on the DHCPv6 side, yet these steps can't happen if people sit in the corner and do the 'they won't listen to me' routine. For those that insist that DHCP is 'the only way to know who is using an address', have you considered dDNS? Oh wait, that moves the trust point to a different service that in the enterprise is typically run by the host admin, not the network admin, or in the SP case crosses the trust boundary in the wrong direction ... my bad. Seriously, there are ways to figure this out, as Ron Broersma pointed out on Monday. I am not arguing for one model over the other, as they each have their benefits and trade-offs. The real issue here is that some people are so locked into one approach that they refuse to even consider that there might be an alternative way to achieve the same goal, or that the actual goal will change over time in the face of external requirements. IPv4 continues to be a work-in-progress 30 years later, and IPv6 will be no different. The fact that there is not functional parity between the operational aspects is due to operators insisting until very recently that 'the only thing that matters is IPv4'. It should not be a surprise that IPv4 is where the majority of the work in the IETF happened. Despite my attempts to get the IETF to stop wasting effort on what is clearly a dead-end, this is still true today. As drc points out, you can continue to post complaints on the nanog list, or if you want real change make sure your vendors get a clear message about IPv6 being the priority, then make your point on the appropriate IETF WG list. At the end of the day, the way networks are operated today is not the way they will be operated in 5 years, just as it is not the same as they way they were operated 5 year ago. Asserting a snap-shot perspective about 'requirements' has its place, but everyone needs to recognize that this is an evolving environment. Changing the base protocol version is just one more step on that evolutionary path. Tony From bicknell at ufp.org Thu Oct 22 14:50:14 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 22 Oct 2009 12:50:14 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> Message-ID: <20091022195014.GA18237@ussenterprise.ufp.org> In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote: > The solution here, and one that is already being worked on by vendors, > is RA gaurd, not changing DHCPv6 in an effort to bypass RA. Port based solutions don't work well on wireless networks and other mediums. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rps at maine.edu Thu Oct 22 14:57:40 2009 From: rps at maine.edu (Ray Soucy) Date: Thu, 22 Oct 2009 15:57:40 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091022195014.GA18237@ussenterprise.ufp.org> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> Message-ID: <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. On Thu, Oct 22, 2009 at 3:50 PM, Leo Bicknell wrote: > In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote: >> The solution here, and one that is already being worked on by vendors, >> is RA gaurd, not changing DHCPv6 in an effort to bypass RA. > > Port based solutions don't work well on wireless networks and other > mediums. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From cra at WPI.EDU Thu Oct 22 15:06:48 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 22 Oct 2009 16:06:48 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> Message-ID: <20091022200648.GS5070@angus.ind.WPI.EDU> On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: > Really. How do we deal with rouge DHCP on the wireless LAN, obviously > this is such a complex issue that we couldn't possibly have a solution > that could be applied to RA. Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases. It generally only affects new machines trying to get a lease, or RENEWing machines. The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use. Regardless, modern wireless deployments use central controllers or smart APs that can filter DHCP. They could be extended to filter RA as well. And this whole point is rather moot because we have RAs and must deal with them. It is too late to get rid of the RA behavior of clients. Even if you don't want to use RAs, your hosts are going to still listen to them which means a Rogue RA is going to take down your network. We have this problem even on IPv4-only subnets, where a Rogue RA (usually a Windows box with routing turned on) breaks connectivity to dual-stack servers for machines on that subnet. Since the hosts prefer native IPv6 connectivity over IPv4, the hosts end up preferring the Rogue RA as the route towards the dual-stack server. We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6. From jeffrey.lyon at blacklotus.net Thu Oct 22 15:19:53 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 22 Oct 2009 16:19:53 -0400 Subject: Need a clueful Telia AS1299 engineer Message-ID: <16720fe00910221319q137762fcyd8803addd3ea6323@mail.gmail.com> Could a clueful AS1299 engineer please drop me a line? Dealing with the Level 0 technicians that are offered to IC clients is completely useless in diagnosing a rather serious issue. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From drc at virtualized.org Thu Oct 22 15:24:03 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 22 Oct 2009 13:24:03 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <023701ca534f$a1110750$e33315f0$@net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <9F365689-1896-41D6-A047-F3151DF2FD1D@virtualized.org> <023701ca534f$a1110750$e33315f0$@net> Message-ID: <19D169A9-EE5A-4038-93B5-2ABDBD8B82F0@virtualized.org> Tony, On Oct 22, 2009, at 12:41 PM, Tony Hain wrote: > The root of the argument I see in this entire thread is the assumption that > 'what we have for IPv4 has *always* been there'. Well, no. My reading is "what we have for IPv4 works, scales well, we're accustomed to it, and our provisioning systems are all built around it'. > There is lots of finger > pointing at the IETF for failure to define 15 years ago, what we have > evolved as the every-day assumptions about the IPv4 network of today. Well, no. My reading is that there is finger pointing at the IETF for ignoring and/or denying what network operators are specifying. > The real issue here > is that some people are so locked into one approach that they refuse to even > consider that there might be an alternative way to achieve the same goal, or > that the actual goal will change over time in the face of external > requirements. Actually, I think the issue is that there are folks who are running real, live businesses who don't really have the time (or interest) to experiment with alternative ways of doing things. They're getting pressure to deploy new stuff and are looking for technologies that are the quickest, easiest, requires the least retraining, retooling, redeployment, etc. They then get folks (most of which do not run real, live non-trivial networks) who say "use this new shiny toy!" and block efforts to hack the existing tools. It's that last bit that's the problem. But then again, I'm just guessing since I don't run a real, live non-trivial network... Regards, -drc From rps at maine.edu Thu Oct 22 15:32:17 2009 From: rps at maine.edu (Ray Soucy) Date: Thu, 22 Oct 2009 16:32:17 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091022200648.GS5070@angus.ind.WPI.EDU> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022200648.GS5070@angus.ind.WPI.EDU> Message-ID: <7a6830090910221332g2c881174x7ad3f71b5c7e97ee@mail.gmail.com> Correct. Not sure if you got the sarcasm in that last reply... As far as I'm concerned, a rogue is a rogue. Knowing about it the instant it happens might even be better than slowly coming to the realization that you're dealing with one. The point is that we need to address rogues regardless of their type, not move from RA to DHCPv6 because the impact of a rogue is slower to disrupt service. On Thu, Oct 22, 2009 at 4:06 PM, Chuck Anderson wrote: > On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: >> Really. ?How do we deal with rouge DHCP on the wireless LAN, obviously >> this is such a complex issue that we couldn't possibly have a solution >> that could be applied to RA. > > Rogue DHCP doesn't immedately take down the entire subnet of machines > with existing DHCP leases. ?It generally only affects new machines > trying to get a lease, or RENEWing machines. ?The impact of a rogue RA > is to immediately break connectivity for every machine on the subnet. > Differing impacts leads to different risk assessments of which > protocol to use. > > Regardless, modern wireless deployments use central controllers or > smart APs that can filter DHCP. ?They could be extended to filter RA > as well. > > And this whole point is rather moot because we have RAs and must deal > with them. ?It is too late to get rid of the RA behavior of clients. > Even if you don't want to use RAs, your hosts are going to still > listen to them which means a Rogue RA is going to take down your > network. ?We have this problem even on IPv4-only subnets, where a > Rogue RA (usually a Windows box with routing turned on) breaks > connectivity to dual-stack servers for machines on that subnet. ?Since > the hosts prefer native IPv6 connectivity over IPv4, the hosts end up > preferring the Rogue RA as the route towards the dual-stack server. > > We really just need to bug our vendors to implement Rogue RA > protection for wired and wireless ASAP, wherever we are in our > deployment of IPv6. > > -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From dwhite at olp.net Thu Oct 22 15:33:26 2009 From: dwhite at olp.net (Dan White) Date: Thu, 22 Oct 2009 15:33:26 -0500 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022200648.GS5070@angus.ind.WPI.EDU> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022200648.GS5070@angus.ind.WPI.EDU> Message-ID: <20091022203325.GB17421@dan.olp.net> On 22/10/09?16:06?-0400, Chuck Anderson wrote: >On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: >> Really. How do we deal with rouge DHCP on the wireless LAN, obviously >> this is such a complex issue that we couldn't possibly have a solution >> that could be applied to RA. > >Rogue DHCP doesn't immedately take down the entire subnet of machines >with existing DHCP leases. It generally only affects new machines >trying to get a lease, or RENEWing machines. The impact of a rogue RA >is to immediately break connectivity for every machine on the subnet. >Differing impacts leads to different risk assessments of which >protocol to use. That breaks both ways. You could do maintenance in the middle of the night and break DHCP in unexpected ways (which I've seen happen) and then you have the problem of manually rebooting (or renewing) all those devices the next morning when you notice they're not working. >We really just need to bug our vendors to implement Rogue RA >protection for wired and wireless ASAP, wherever we are in our >deployment of IPv6. VLAN per subscriber fixes this. It's not really appropriate everywhere, but it's a nice solution for wireless and ISP scenarios. -- Dan White From owen at delong.com Thu Oct 22 15:29:10 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 13:29:10 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> Message-ID: On Oct 22, 2009, at 12:23 PM, Ray Soucy wrote: >> This to me is one of the least credible claims of the RA/SLAAC crowd. >> On the one hand we have carriers around the world with millions and >> millions of customers getting default routes and other config through >> DHCPv4 every day. And most of the time it actually works very well! >> >> On the other hand we have RA/SLAAC with a vastly smaller customer >> base, vastly less real life testing - but which is still claimed to >> be so much better that DHCPv6 is not *allowed* to get a default route >> option. > > If the argument against RA being used to provide gateway information > is "rogue RA," then announcing gateway information though the use of > DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but > you'll still have to deal with rogue DHCPv6. So what is gained? > Apparently you missed the entire message he responded to about the number of things specified by DHCP and the differences between the groups in control of the routers vs control of the hosts/servers and the actual administrative groups in charge of each? > I guess I'm not really seeing the case here. Are people really making > use of DHCP to provide hosts on the same network with different > default gateway information? If so, why? > Yes. A number of different application and business requirements. Some I can go into easily (load balancing among different routers, routers owned by different departments, etc.), some are proprietary to my clients and I can't give enough details without violating NDA. > Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a > good idea and it works. You can add options to DHCPv6, but I don't > see many vendors implementing default gateway support unless you can > make a real case for it. > The assignment of gateway information to the host belongs in the hands of the systems administrators and not in the hands of the people running the switches and routers in many organizations. With router information assigned through DHCP, this is preserved. With it being assigned by the router, it is not, and, in fact, the case. With DHCPv6 unable to assign router information you lose that administrative boundary and take away a systems administrators control over their hosts and hand it to the networking group. > My fear is that your goal is to do away with RA completely and turn to > DHCPv6 for all configuration. RA is actually quite nice. You really > need to stop fighting it, because it's not going away. > Not at all. People are not saying RA has to go away. They are saying we need the option of DHCPv6 doing the job where we do not feel that RA is the correct tool. More tools are good. Replacing one tool that works today with a new tool that is arguably inferior in many real world cases, on the other hand, is not so good. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Oct 22 15:42:24 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 23 Oct 2009 07:12:24 +1030 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256206811.30246.646.camel@karl> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <1256206811.30246.646.camel@karl> Message-ID: <20091023071224.14bdd177@opy.nosense.org> On Thu, 22 Oct 2009 21:20:11 +1100 Karl Auer wrote: > On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: > > If, on the other hand, the REAL desire is to have a DHCP server break > > the tie in the selection between several routers that advertise their > > presence, that wouldn't be unreasonable. > > The RA contains a preference level... maybe that doesn't cut it if > multiple routers are sending the same preference level, but presumably > that would not happen in a well-tended network. > IPv6 Subnets/VLANs are pretty cheap, maybe if people are having this issue, that's a sign they need to divide their hosts into more subnets/VLANs. More broadly, it seems the argument is where to put networking operational policy - in the network (via e.g. engineered topology), or on the hosts. I think there is value in putting it in the network, because it avoids having to change host located policy when the network policy changes. > In any case, anywhere this is actually of vital importance, a routing > protocol would be in use. > > Using the DHCP protocol to deliver information - about anything really - > is what it's *for*. That said, making clients depend utterly on the > presence of a working DHCP server for basic connectivity seems like a > backward step. Of course, different people have different ideas about > what constitutes "basic" connectivity. > > > Stop trying to break the internet and I'll treat you like an adult. > > Whoa! Tell you what, how about if I break it, and you get to choose > which piece you keep? [Bash, bash, thud. Ugh. Hm. It's tougher than it > looks!] > > :-) > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) > > GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF > From thegameiam at yahoo.com Thu Oct 22 15:49:26 2009 From: thegameiam at yahoo.com (David Barak) Date: Thu, 22 Oct 2009 13:49:26 -0700 (PDT) Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> Message-ID: <496401.93622.qm@web31803.mail.mud.yahoo.com> ---- Original Message ---- From: Ray Soucy >Or is it that you want IPv6 to be a 128-bit version of IPv4?? Yes, this is in fact exactly what the network operators keep saying.? >RA is a >good idea and it works.? You can add options to DHCPv6, but I don't >see many vendors implementing default gateway support unless you can >make a real case for it. >My fear is that your goal is to do away with RA completely and turn to >DHCPv6 for all configuration.? RA is actually quite nice.? You really >need to stop fighting it, because it's not going away. RA may be quite nice for some cases.? However, several examples over this thread alone have been provided about some other cases where it is something other than nice.? DHCPv4 is not a perfect protocol, but it's widely deployed and understood.? It also is a one-stop-shop for centralized host configuration.? IPv6 does not currently have a similar one-stop-shop protocol, and this is a major gap in functionality.??There are a bunch of very large providers and enterprises which number their DHCP-managed end-sites in the hundreds of thousands or millions.? The inability to provide the same centralized configuration management should not be considered a feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Oct 22 15:52:40 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 23 Oct 2009 07:22:40 +1030 Subject: IPv6 Deployment for the LAN In-Reply-To: <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> Message-ID: <20091023072240.092e69a9@opy.nosense.org> On Thu, 22 Oct 2009 11:40:50 +0200 Iljitsch van Beijnum wrote: > On 21 okt 2009, at 22:48, Owen DeLong wrote: > > > The assumption that the router "knows" it is correct for every host > > on a given > > LAN simply does not map to reality deployed today. > > What I'm saying is that a router knows whether it's a router or not. A > DHCP server does not, so it has to make a leap of faith and then > sometimes the hosts fall flat on their face if there's no router on > the address indicated by the DHCP server. The counter-argument is "it > works today" but my counter-counter-argument is "it doesn't work > today". I get burned by broken DHCP setups _all_ _the_ _time_ at work, > at IETF meetings, at RIPE meetings, etc. > > Anyone claiming that having a DHCP server direct hosts to a router > address in the blind is simply incompetetent, so there is no point in > listening to them. > > If, on the other hand, the REAL desire is to have a DHCP server break > the tie in the selection between several routers that advertise their > presence, that wouldn't be unreasonable. > > > Please explain to me how I can achieve this functionality in RA/SLAAC > > or stop pushing to prevent it from being available in DHCPv6. > > There is no requirement that the IETF provides all functionality that > someone can think up. The list of desired functionality is infinite, > and much on that list is a bad idea and/or can be achieved in > different ways. > > > Seriously, we're all adults. So treating us like children and > > taking away > > the power tools is not appreciated. > > Stop trying to break the internet and I'll treat you like an adult. > Great way to shoot down your own credibility. Just because you don't have or don't understand problems other people have doesn't mean they don't have them or they're invalid. You'd be far better off proposing alternative solutions that use methods that you believe in, or looking to understand better why your methods aren't appropriate. (I don't believe in your agenda to add a prefix length option to DHCPv6 (you probably haven't run an IPX or Appletalk network, and therefore haven't experienced the convenience of fixed length subnets/node addresses), but I don't think it's appropriate to call you a child because of you naivety in this area ...) From jmaimon at ttec.com Thu Oct 22 15:55:50 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 Oct 2009 16:55:50 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> Message-ID: <4AE0C6D6.5090606@ttec.com> Owen DeLong wrote: >> > Not at all. People are not saying RA has to go away. They are saying we > need the option of DHCPv6 doing the job where we do not feel that RA is > the correct tool. Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. DHCPv4 works everywhere and meets every networks needs, from the $50 linksys to the million dollar network. RA already does not. The answer to RA shortcomings is not to turn it into a clone of DHCP, only stateless and chained to the router. > > More tools are good. Replacing one tool that works today with a new tool > that is arguably inferior in many real world cases, on the other hand, is > not so good. > > Owen > Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. Joe From trejrco at gmail.com Thu Oct 22 16:20:12 2009 From: trejrco at gmail.com (TJ) Date: Thu, 22 Oct 2009 17:20:12 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091022195014.GA18237@ussenterprise.ufp.org> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> Message-ID: <71bfd60c0910221420p1f4b5157y7f7ba96a15765ab4@mail.gmail.com> > > > Port based solutions don't work well on wireless networks and other > mediums. > > Something like PSPF then? (assuming it works properly on IPv6 multicast ... ) /TJ From trejrco at gmail.com Thu Oct 22 16:31:39 2009 From: trejrco at gmail.com (TJ) Date: Thu, 22 Oct 2009 17:31:39 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <4AE0C6D6.5090606@ttec.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <4AE0C6D6.5090606@ttec.com> Message-ID: <71bfd60c0910221431p14b49563q26b09fa1bf2fc3bc@mail.gmail.com> > > >>> Then let me say it. RA needs to be able to be completely turned off. > DHCPv6 needs to be able to completely configure all requesting hosts. Those two statements are not synonymous ... Sure, leave RA in the IPv6 stack. The market will decide, and we will see if > it is still on by default on soho routers and in IOS 15.4T in 2015. > > That is a more sensible statement. And were I to be a gambling man I would say it will indeed be on by default ... we'll talk more about it then :). Also, I would like to add - there is a difference between the default gateway information and other things, such as NTP|DNS|SIP server information. The default gateway, by definition, is an on-link thing. IMHO, this makes the router a good source for information about the router. I am not saying use cases for "fully spec'ed DHCPv6" don't exist or should be ignored. Making the router capable of sharing the "missing piece" that covers ~95% of use cases is also a Good Thing. Thinking out loud, we could also re-create the idea of an auto-magic DNS by creating a special use case within ULA-space - say FD00::/96, saving the last 32 bits for something like ::53 and using anycast. *(Could abstract same idea to any stateless and/or light-session-based service ... FD00::123 for Automagic ULA-based anycast NTP, etc. Need 32 bits if we don't want to hex convert the >9999 things, just in case ...)* /TJ From rps at maine.edu Thu Oct 22 16:34:07 2009 From: rps at maine.edu (Ray Soucy) Date: Thu, 22 Oct 2009 17:34:07 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910171743r77f155f5ia48a167c4d57b00b@mail.gmail.com> References: <7a6830090910171743r77f155f5ia48a167c4d57b00b@mail.gmail.com> Message-ID: <7a6830090910221434ta5d1091gc8c34cf1bba4664c@mail.gmail.com> It's certainly encouraging to see how there is such consensus among NANOG on IPv6 deployment. :-) Recent exchanges seem to be getting a little personal, so we might want to take a step back and breath. I don't think adding default gateway support to DHCPv6 will have much of an impact, but I'm OK with people trying to get it implemented. Another tool in the box. I just wouldn't hold your breath waiting for it. I think the better approach is to take a firm stand on security and make RA gaurd and DHCPv6 snooping expected for network devices. These problems will still exist if default gateway options for DHCPv6 get implemented. As for RA taking down a network quickly, well, it can be restored quickly too. The fact that RA is actually responsive can be a benefit in some situations. Hopefully if anything has come out of this thread its that both stateless and stateful configuration have a place in IPv6, and that there is still work to be done before IPv6 is really ready for the enterprise LAN. Others may have their specific requests from vendors, but here are mine: 1. Include DHCPv6 client functionality as part of any IPv6 implementation. 2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure. A lot of the frustration seems to come from Windows ICS acting as an IPv6 router. I think everyone here has been after Microsoft to either remove ICS or make it more difficult to enable at one point or another. While a rogue RA can come from anywhere, Windows is usually the guilty party. I would argue that since NAT is not a component of IPv6, no host should be implementing ICS-like functionality for IPv6. It's unlikely that there would be a situation on an IPv6 network that a host needed to share it's IPv6 address to get others online. Just my thoughts. Maybe someone from Microsoft who can do something about it lurks on this list. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From jfbeam at gmail.com Thu Oct 22 16:37:03 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 22 Oct 2009 17:37:03 -0400 Subject: ISP port blocking practice In-Reply-To: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> Message-ID: On Thu, 22 Oct 2009 13:22:17 -0400, Zhiyun Qian wrote: > 1). For any outgoing traffic, if the destination port is 25, then drop > the packets. > 2). For any incoming traffic, if the source port is 25, then drop the > packets. Inspecting outgoing traffic is generally easier to do as there's less of it. (in a consumer context, which is the only place such filtering makes any sense.) --Ricky From iljitsch at muada.com Thu Oct 22 16:37:14 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 22 Oct 2009 23:37:14 +0200 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091023072240.092e69a9@opy.nosense.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <20091023072240.092e69a9@opy.nosense.org> Message-ID: <23BA3F46-88BC-4FE3-9377-79FF8940AA99@muada.com> On 22 okt 2009, at 22:52, Mark Smith wrote: >>> Seriously, we're all adults. So treating us like children and >>> taking away the power tools is not appreciated. >> Stop trying to break the internet and I'll treat you like an adult. > Great way to shoot down your own credibility. Just because you don't > have or don't understand problems other people have doesn't mean they > don't have them or they're invalid. When people want something which is clearly a bad idea (doing default gateways in DHCPv6 the same way as in DHCPv4) and they ignore it when a better solution is suggested (having a DHCP option that allows a DHCPv6 server to tell hosts which of the available routers to use) then the discussion tends to take a turn for the worse. > You'd be far better off proposing > alternative solutions that use methods that you believe in, or looking > to understand better why your methods aren't appropriate. I often do that. Unfortunately, in many cases, people not only insist on bad ideas, but they won't even take suggestions on how to achieve what they want in less harmful ways. That annoys me a great deal. > (I don't believe in your agenda to add a prefix length option to > DHCPv6 (you probably haven't run an IPX or Appletalk network, and > therefore haven't experienced the convenience of fixed length > subnets/node addresses), but I don't think it's appropriate to call > you > a child because of you naivety in this area ...) But wouldn't hardcoding a prefix length also be a bad idea? We now pretty much always have /64 but there are just enough exceptions to make it dangerous to just assume /64. However, I firmly believe that whether is done with DHCPv6 it will continue to have problems. Even if DHCPv6 itself would operate well and consistently in all cases, then there are still the permuations between hosts that support stateless autoconfig and not DHCP, those that support both, those that are configured to only do DHCP, those that listen for the M/O bits and those that don't... There's simply no way to get consistent behavior out of a set of hosts unless those hosts all run the same version of the same OS. Now for anything else than a configuration protocol that wouldn't be a disaster but for a configuration protocol this is fairly inconvenient. From john at sackheads.org Thu Oct 22 16:54:30 2009 From: john at sackheads.org (John Payne) Date: Thu, 22 Oct 2009 17:54:30 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221332g2c881174x7ad3f71b5c7e97ee@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022200648.GS5070@angus.ind.WPI.EDU> <7a6830090910221332g2c881174x7ad3f71b5c7e97ee@mail.gmail.com> Message-ID: <3AAF8205-7EC9-4B50-A67A-DC3B5BF2BFF3@sackheads.org> On Oct 22, 2009, at 4:32 PM, Ray Soucy wrote: > Knowing about it the > instant it happens might even be better than slowly coming to the > realization that you're dealing with one. Might just be me, but I'm more worried about the rogue RA (or DHCPv4) server that does not disrupt communication at all... From asr+nanog at latency.net Thu Oct 22 16:58:32 2009 From: asr+nanog at latency.net (Adam Rothschild) Date: Thu, 22 Oct 2009 17:58:32 -0400 Subject: Need a clueful Telia AS1299 engineer In-Reply-To: <16720fe00910221319q137762fcyd8803addd3ea6323@mail.gmail.com> References: <16720fe00910221319q137762fcyd8803addd3ea6323@mail.gmail.com> Message-ID: <20091022215830.GA22137@latency.net> On 2009-10-22-16:19:53, Jeffrey Lyon wrote: > Could a clueful AS1299 engineer please drop me a line? Dealing with > the Level 0 technicians that are offered to IC clients is completely > useless in diagnosing a rather serious issue. rr at telia.net is a good place for routing/policy-related inquiries, or carrier-csc at teliasonera.com for more time-sensitive issues. Both can provide a quick escalation path to clue and enable. I've amassed some individual contacts from being a customer, which I'd be happy to share off-list... -a From justin at justinshore.com Thu Oct 22 17:39:46 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 22 Oct 2009 17:39:46 -0500 Subject: ISP port blocking practice In-Reply-To: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> Message-ID: <4AE0DF32.1040903@justinshore.com> Zhiyun Qian wrote: > Hi all, > > What is the common practice for enforcing port blocking policy (or what > is the common practice for you and your ISP)? More specifically, when > ISPs try to block certain outgoing port (port 25 for instance), they > could do two rules: > 1). For any outgoing traffic, if the destination port is 25, then drop > the packets. > 2). For any incoming traffic, if the source port is 25, then drop the > packets. I block on both generally. I block inbound and outbound for residential customers in dynamic pools. I block inbound only for residential with statically-assigned IPs. That way a customer can request (and pay for) a static IP and be able to get around out outbound SMTP block. Few companies use the MSP port (tcp/587). I'm not sure why more don't make the effort but most don't. To make up for that we allow static residential customers to evade that filter with a static IP. We still block inbound though. We also allow them to use our SMTP servers and SmartHosts if they want with no requirements on source domains (like some providers require, essentially requiring the customer to advertise for you). The inbound block isn't really all that useful as you elude to. However I use it more often than not to look for people scanning out ranges for open relays. I use that data for feed my RTBH trigger router and drop the spammer's traffic on the floor (or the poor, unfortunate owner of the compromised PC that's been 0wned. We block several other things too. Netbios traffic gets dropped both ways. MS-SQL traffic gets dropped both ways (a few users have complained about this but very few stick to their guns when you point out that their traffic is traversing the web completely unencrypted). I block default and common proxy ports such as 3128, 7212, and 6588 in both directions. Squid is too easy to misconfigure (done it myself). GhostSurf and WinGate have both been abusable as open proxies in various releases. I also block 8000, 8080 and 8081 towards the customers. These are some of our most commonly scanned ports (usually all 3 at once plus some or all of the 80xx ones). I've encountered many compromised residential CPEs that the users either enabled themselves or were enabled by default. I don't block those 3 ports on outbound flows though; too many false positives. And finally we also block several different types of ICMPs. First off we block ICMP fragments. Then we permit echo, echo-reply, packet-too-big, and time-exceeded. The rest get explicitly dropped. IPv6 will change this list dramatically. I haven't had time to research ICMPv6 thoroughly enough to say any more than that. Basically I just pick out some of the really bad ports and block them. This gives me a wealth of data with which to null-route compromised PCs scanning my networks. > Also, is it common that the rules are based on tcp flags (e.g. SYN, > SYN-ACK)? One would think block SYN packet is good enough. I don't get that deep into it. Forged packets of types other than SYN can still reek havoc on existing flows. I think it's better to block all and move on. Justin From perry at coders.net Thu Oct 22 18:04:33 2009 From: perry at coders.net (Perry Lorier) Date: Fri, 23 Oct 2009 12:04:33 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022113938.GH32008@vacation.karoshi.com.> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> <20091022113938.GH32008@vacation.karoshi.com.> Message-ID: <4AE0E501.80606@coders.net> bmanning at vacation.karoshi.com wrote: > On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote: > >> You could imagine extending this to other services such as NTP, but I'm >> not sure that you really would want to go that far, perhaps using DNS to >> lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers. >> >> Another obvious approach might be to have a service discovery protocol >> where you send to a "service discovery" multicast group a message asking >> "wheres the nearest nameserver(s)?" then nameserver implementations >> could listen on this multicast group and reply. Again shared fate. >> This does have the downside of people running rogue nameservers and >> needing a "ServiceDiscovery-Guard" feature for switches.... >> > > ah... well - if your a router centric person, then you want > to put everything into the tools you know and love. > > Generally I don't think of myself as a router centric person ;) > if your a dns centric person, then you put everything in the > DNS. > > This has always sounded like a nice solution to me, however, DNS is starting to look a little long in the tooth, overloading it with more and more semantics seems to be pushing it well beyond it's design envelope. (EDNS0?) > I point you to the "DISCOVER' opcode (experimental) in the DNS > and the use of DNS over multicast for doing service discovery > (e.g. Apples Bonjour)... Most of that is already designed/deployed > and in pretty widespread use... over IPv4 or IPv6. > Yup, they're good ways to discover some local resources. To my understanding mDNS works over the local subnet, unless you're going to start having your routers run as mDNS relays (is there any standards for this? How do you stop mDNS relays from creating loops and broadcast storms?). mDNS works over a a single multicast group with a single port 5353 which makes it hard to filter different types of services (People on this switch can announce their iTunes sharing, but they're not allowed to announce a local DNS server) without DPI, you're more likely to find network engineers just filter the entire multicast group breaking it for other purposes If you're not going to have mDNS forwarders on your routers, then you're going to need to reconfigure your entire configuration on every segment as well. (IMHO) there are different types of configuration: * Network related (routes, addressing). RA's seem to do a fairly good job at at least 80% of this. * Network provided services, such as DNS, NTP. Well known anycast addresses seems to be (IMHO) the best way to advertise these. Currently you need DHCPv6 to get this information. * Application settings (web proxy, local outgoing SMTP relay, default printer location, local SIP/RTP proxy, local home/intranet page, what the current local timezone rules are). This seems to be currently done by a variety of adhoc protocols, usually bundled over well known DNS names with HTTP, often replicating the same information in a wide range of different places in different formats. This seems an ugly solution, but I have no other suggestions. I'm sure there are several RFCs/Drafts around somewhere that tries to solve this. * Ephemeral end user provided services, which is already provided today by the well documented, and deployed mDNS. in theory you can kinda pick and choose between those, for instance you can run just mDNS on a network without RA's or DHCPv6 and things will work (for the limited value of work that involves only whatever the ephemeral services are being announced). You can run RA's by themselves, and your bittorrent will work fine. > And yes, its not RA/ND, or DHCP... its another configuration protocol > and its not quite vendor specific. The best thing is, it pushes > the smarts closer to the edge (the end device) and this makes me happy. > > Theres a general issue of access control. While I like a very smart edge, you don't want some ""misinformed"" user turning on a feature and suddenly having the rest of your network ending up using it. >> Personally I like the first option (anycast addresses) better, you can >> control who has access to your IGP and if your IGP is down, then for all >> intents and purposes your recursive nameservers are offline too :) >> >> > > everyone to their own taste. > > Yup. There are different systems, they have different tradeoffs. Pick the one that trades off things you don't care about for things you do care about. :) From kauer at biplane.com.au Thu Oct 22 18:12:48 2009 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 23 Oct 2009 10:12:48 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE07444.2000905@kl.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> Message-ID: <1256253168.13611.40.camel@karl> On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote: > > If, on the other hand, the REAL desire is to have a DHCP server break > > the tie in the selection between several routers that advertise their > > presence, that wouldn't be unreasonable. > > In some configurations not all hosts are supposed to use the same > router. We need the _option_ to specify a default gateway and > have the override any RA's a host may see. It would be a tool, and if someone wants to use a tool, they can. It won't be my thumb they hit :-) But I can't see how a DHCP server can know enough about the routers to be able to send out useful discrimination information. So it will have to be manually entered, or come from an IPAM, or... Nor can I see how the DHCP server can identify the routers to the host except by their addresses, and these can change or be removed without the DHCP server finding out. The only way I can see it working is if the host were smart enough to compare the DHCP router discrimination info with the information it has received via RA and delete mismatches, or possibly just revert to using RA information if any mismatches at all are detected. That would be an item the DHCP server could specify as well - what to do in case of a mismatch. It could even be specified on a per-router basis, though the whole thing seems to be getting a bit unwieldy now. The DHCP servers will not be on the same subnets as all the routers involved, so they can't sniff the RAs themselves - unless we set up an RA relay... hmm. I don't see DHCP-delivered router preferences as being something that will "break the Internet". In the vast majority of cases they will be unnecessary. For those that do need it though, and if it can be done, why not? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lyndon at orthanc.ca Thu Oct 22 18:14:11 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Thu, 22 Oct 2009 17:14:11 -0600 Subject: ISP port blocking practice In-Reply-To: <4AE0DF32.1040903@justinshore.com> Message-ID: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> > Few > companies use the MSP port (tcp/587). Can you elaborate. Is this based on analysis you've conducted on your own network? And if so, is the data (anonymized) available for the rest of us to look at? My experience is that port 587 isn't used because ISPs block it out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack it with a proxy that filters out the AUTH parts of the EHLO response, making the whole point of using the submission service ... pointless. --lyndon From David_Hankins at isc.org Thu Oct 22 18:16:41 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 22 Oct 2009 16:16:41 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256170334.30246.448.camel@karl> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021213426.GA6981@isc.org> <1256170334.30246.448.camel@karl> Message-ID: <20091022231641.GB3418@isc.org> On Thu, Oct 22, 2009 at 11:12:14AM +1100, Karl Auer wrote: > > To work around this problem, some DHCPv6 software implementers have > > elected to temporarily apply a fixed /64 bit prefix to all applied > > addresses until a prefix length can be made available in-band through > > some means. This does neatly work around the problem; the hosts may > > now speak to one another. > > I don't understand this. Could you elaborate? It seems to me that the > "simplest network imaginable" should still operate on link local > addresses. To use a link local address, you also have to supply the application with the interface name for it to be used upon. The application has to pass this as an extra argument when opening a socket; it isn't part of the regular gethostbyname/socket/connect. Provided you have applications that have a separate dialog field for the interface name so LL's can be used, you're probably going to be entering in the IPv6 LL address in all its glory. First, you are not going to have LL addresses in /etc/resolv.conf because you can't list interface names there (I think it is the same for other OS's analogues of their nameservers list), and second people are not going to be very well motivated to put LL addresses in DNS because those addresses are not globally applicable; they would have to use DNS views. So it is not really very realistic to expect LL to actually be used except to bootstrap. Maybe it's possible for some proprietary printer or fileshare network stuff to continue working on LL's (or, ironically, routing protocols or DHCPv6 itself), but anywhere else ("mail.example.com", "contacts.example.com"), anywhere real, and the network goes dark. Unless of course it can fall back on native IPv4, or has entered a bogus covering /64. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jmaimon at ttec.com Thu Oct 22 18:18:56 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 Oct 2009 19:18:56 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <23BA3F46-88BC-4FE3-9377-79FF8940AA99@muada.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <20091023072240.092e69a9@opy.nosense.org> <23BA3F46-88BC-4FE3-9377-79FF8940AA99@muada.com> Message-ID: <4AE0E860.2040406@ttec.com> Iljitsch van Beijnum wrote: > On 22 okt 2009, at 22:52, Mark Smith wrote: > >>>> Seriously, we're all adults. So treating us like children and >>>> taking away the power tools is not appreciated. > >>> Stop trying to break the internet and I'll treat you like an adult. > > >> Great way to shoot down your own credibility. Just because you don't >> have or don't understand problems other people have doesn't mean they >> don't have them or they're invalid. > > When people want something which is clearly a bad idea (doing default > gateways in DHCPv6 the same way as in DHCPv4) and they ignore it when a > better solution is suggested (having a DHCP option that allows a DHCPv6 > server to tell hosts which of the available routers to use) then the > discussion tends to take a turn for the worse. Thats your opinion. However ICMP router advertisment and before that RIP have always been available to provide default router in IPv4 and the userbase has already decided which they prefer. History is not on your side on this one. That doesnt mean that DHCPv6 could not do a better job, such as being able to configure hosts with multiple specific routes, including a default one, or being able to tell hosts to use RA or which potential RA learnt gateways should be used and in which preference order. But requiring default gateway information be learnt from RA and that RA be operational for DHCPv6 operation is as clearly to me a bad idea as is allowing people to use DHCP with ipv6 in a manner they have come to rely on it for IPv4 is to you. A DHCP server that requires a working router RA is like having a 3 legged race. > > But wouldn't hardcoding a prefix length also be a bad idea? We now > pretty much always have /64 but there are just enough exceptions to make > it dangerous to just assume /64. There is no reason to assume we will be stuck with /64. Once upon a time nobody thought subnet masks would ever be anything longer than /24 /16 or /8 depending on the first few bits in the address. I dont think that lasted very long and was completely erased by CIDR adoption. The one lesson we should be taking from that is not to assign magic and sacred powers to bit boundaries. > > However, I firmly believe that whether is done with DHCPv6 it will > continue to have problems. Even if DHCPv6 itself would operate well and > consistently in all cases, then there are still the permuations between > hosts that support stateless autoconfig and not DHCP, those that support > both, those that are configured to only do DHCP, those that listen for > the M/O bits and those that don't... So in effect, you are saying that now that this mess has been created over peoples strenuous objections that they are forced to live with it? Thats not going to win any arguments. And in any effect, you are probably making the point that using non /64 subnet lengths with a properly operational DHCPv6 is actually a good idea for those who wish to completely skip all RA. Joe From kauer at biplane.com.au Thu Oct 22 18:25:10 2009 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 23 Oct 2009 10:25:10 +1100 Subject: IPv6 Deployment for the LAN In-Reply-To: <20091022231641.GB3418@isc.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021213426.GA6981@isc.org> <1256170334.30246.448.camel@karl> <20091022231641.GB3418@isc.org> Message-ID: <1256253910.13611.45.camel@karl> On Thu, 2009-10-22 at 16:16 -0700, David W. Hankins wrote: > Unless of course it can fall back on native IPv4, or has entered a > bogus covering /64. I think it was really this that I was wanting more info on. "Entered" where? Sorry to be obtuse, clearly I am missing something obvious. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jmaimon at ttec.com Thu Oct 22 18:27:27 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 Oct 2009 19:27:27 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221434ta5d1091gc8c34cf1bba4664c@mail.gmail.com> References: <7a6830090910171743r77f155f5ia48a167c4d57b00b@mail.gmail.com> <7a6830090910221434ta5d1091gc8c34cf1bba4664c@mail.gmail.com> Message-ID: <4AE0EA5F.0@ttec.com> Ray Soucy wrote: > > Others may have their specific requests from vendors, but here are mine: > > 1. Include DHCPv6 client functionality as part of any IPv6 implementation. > 2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure. I can agree with that. I would also add that there is plenty of work that can be done to DHCP, such as adding full route support, multiple gateways with preference and even transitioning from a binary only protocol. > > A lot of the frustration seems to come from Windows ICS acting as an > IPv6 router. I think everyone here has been after Microsoft to either > remove ICS or make it more difficult to enable at one point or > another. While a rogue RA can come from anywhere, Windows is usually > the guilty party. I would argue that since NAT is not a component of > IPv6, NAT wasnt a component of IPv4 until it was already had widespread adoption. I remain completely unconvinced that people will not continue to perceive value in PAT6 between their private and their public subnets. And of course, different forms of NAT are almost certainly required to try to make ipv4 and ipv6 interoperate for as long as people need it to. > no host should be implementing ICS-like functionality for IPv6. > It's unlikely that there would be a situation on an IPv6 network that > a host needed to share it's IPv6 address to get others online. > > Just my thoughts. Maybe someone from Microsoft who can do something > about it lurks on this list. Good luck. Joe From justin at justinshore.com Thu Oct 22 18:27:14 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 22 Oct 2009 18:27:14 -0500 Subject: ISP port blocking practice In-Reply-To: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> Message-ID: <4AE0EA52.9000405@justinshore.com> Zhiyun Qian wrote: > 1). For any outgoing traffic, if the destination port is 25, then drop > the packets. > 2). For any incoming traffic, if the source port is 25, then drop the > packets. It's been pointed that I glossed over the wording of #2, specifically missing the "source port" part of it, thus giving the right answer to the wrong question. :-) To answer your question, all our tcp/25 filters are based on destination port. I could use source port but really I'm more concerned with my customers not running SMTP servers in one direction and them not being able to send spam in the other. Using source port needlessly complicates those goals IMHO. Someone might have a specific reason to use it but I don't in my case at least. Justin From David_Hankins at isc.org Thu Oct 22 18:46:16 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 22 Oct 2009 16:46:16 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> Message-ID: <20091022234616.GC3418@isc.org> On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: > Really. How do we deal with rouge DHCP on the wireless LAN, obviously > this is such a complex issue that we couldn't possibly have a solution > that could be applied to RA. There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation... In both cases there may still be some wireless adapters that receive bogus packets directly from attackers. And then you bring ND into the question and wonder why you bothered with either RA or DHCP filtering. DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic authentication. The problem however has been the key distribution model. Here it all falls down, and leads to poor deployment. But with DHCPv*, we have a hope that we can secure it if we can solve that last problem (and at least I think we can). So if you accept that as an outcome, one must ponder the question: How long will people accept that a secured DHCPv6 session must rely, in order to function to expectations, upon the unsecurable RA and/or questionably secure SEND? -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From David_Hankins at isc.org Thu Oct 22 18:50:33 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 22 Oct 2009 16:50:33 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256253910.13611.45.camel@karl> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021213426.GA6981@isc.org> <1256170334.30246.448.camel@karl> <20091022231641.GB3418@isc.org> <1256253910.13611.45.camel@karl> Message-ID: <20091022235033.GD3418@isc.org> On Fri, Oct 23, 2009 at 10:25:10AM +1100, Karl Auer wrote: > I think it was really this that I was wanting more info on. "Entered" > where? On the address configured on the interface typically, or whatever other system specifical local means are used to enter a route for the prefix for the interface. Typically on Linux; ip=/sbin/ip ${ip} -f inet6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \ dev ${interface} scope global -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From perry at coders.net Thu Oct 22 18:50:47 2009 From: perry at coders.net (Perry Lorier) Date: Fri, 23 Oct 2009 12:50:47 +1300 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091022234616.GC3418@isc.org> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> Message-ID: <4AE0EFD7.9020907@coders.net> David W. Hankins wrote: > On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: > >> Really. How do we deal with rouge DHCP on the wireless LAN, obviously >> this is such a complex issue that we couldn't possibly have a solution >> that could be applied to RA. >> > > There are some wireless equipment that claim to have a setting that > forces all packets through the wireless bridge (where all traffic is > between clients and bridge, and never client to client), and so one > can filter DHCPv6 and maybe RA, but I am kind of skeptical about how > much of this is elective and dependent upon client implementation... > When you're associated to an AP, you're in a "managed" wireless network, where all traffic *must* go through the AP. I've implemented myself a system which firewalled all ARP within the AP and queried the DHCP server asking for the correct MAC for that lease then sent the ARP back (as well as firewalling DHCP servers and the like). It's quite easily doable, and quite reliable. If nodes were to send packets directly when associated to an AP then the 802.11 protocol would fall apart, I've never met an implementation that broke this requirement of the standard. > In both cases there may still be some wireless adapters that receive > bogus packets directly from attackers. > You can of course pretend you're the AP and send a packet if you're wanting to be vicious enough. From perry at coders.net Thu Oct 22 19:00:35 2009 From: perry at coders.net (Perry Lorier) Date: Fri, 23 Oct 2009 13:00:35 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com><20091022102748.GA32008@vacation.karoshi.com.><4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> Message-ID: <4AE0F223.3050000@coders.net> trejrco at gmail.com wrote: > WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? > > You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using :FFFF::1 I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use :::1 :::2 and :::3, where could be "0035" for DNS, and "007b" for NTP, and if you're feeling adventurous you could use "0019" for outgoing SMTP relay. > ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would only reach 9999 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) > > > Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? > > Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over. From sean at donelan.com Thu Oct 22 19:38:30 2009 From: sean at donelan.com (Sean Donelan) Date: Thu, 22 Oct 2009 20:38:30 -0400 (EDT) Subject: ISP port blocking practice In-Reply-To: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> Message-ID: <200910222031140.32BF5B92.18442@clifden.donelan.com> On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > My experience is that port 587 isn't used because ISPs block it > out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack > it with a proxy that filters out the AUTH parts of the EHLO response, > making the whole point of using the submission service ... pointless. You mentioned this last June. Can anyone else corroborate it? Rogers says they don't do that, and lots of other people seem to be able to use port 587 on Rogers (and other ISPs) without problems. All the cases I've looked at, where someone claimed an ISP was blocking port 587, it turned out to be some other problem. The most common reason was related to some security software/host based firewall running on the user's own computer. From jmaimon at ttec.com Thu Oct 22 19:45:56 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 Oct 2009 20:45:56 -0400 Subject: ISP port blocking practice In-Reply-To: <200910222031140.32BF5B92.18442@clifden.donelan.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <200910222031140.32BF5B92.18442@clifden.donelan.com> Message-ID: <4AE0FCC4.6070502@ttec.com> Sean Donelan wrote: > On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> My experience is that port 587 isn't used because ISPs block it >> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack >> it with a proxy that filters out the AUTH parts of the EHLO response, >> making the whole point of using the submission service ... pointless. > > You mentioned this last June. Can anyone else corroborate it? Rogers > says they don't do that, and lots of other people seem to be able to > use port 587 on Rogers (and other ISPs) without problems. > > All the cases I've looked at, where someone claimed an ISP was blocking > port 587, it turned out to be some other problem. The most common > reason was related to some security software/host based firewall running > on the user's own computer. First thing to check when "email is stuck in my outbox" Next is to check whether outlook is trying to do SMTPS on 587 instead of STARTTLS. Hence 465 SMTPS port workaround. From justin at justinshore.com Thu Oct 22 20:29:27 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 22 Oct 2009 20:29:27 -0500 Subject: ISP port blocking practice In-Reply-To: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> Message-ID: <4AE106F7.3090302@justinshore.com> Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> Few >> companies use the MSP port (tcp/587). > > Can you elaborate. Is this based on analysis you've conducted on > your own network? And if so, is the data (anonymized) available for > the rest of us to look at? > > My experience is that port 587 isn't used because ISPs block it > out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack > it with a proxy that filters out the AUTH parts of the EHLO response, > making the whole point of using the submission service ... pointless. I can't speak for Rogers but I have analyzed our netflow captures on a semi-regular basis for several things before flushing it, use of the MSP port being one of them. I've never seen any MSP port traffic on my SP network that didn't fall into 1 of 2 categories: 1) inbound scanning for MTAs listening on the MSP port, or 2) my own MSP traffic or that of family members traffic running across my SP network that happen to use one of my personal servers for their own email hosting. I can also speak from experience from the enterprise customers of the consulting side of my SP that I worked with before returning to the SP. Not a one of them made use of the MSP port. The vast majority, I'm sorry to say, used Microsoft Exchange which to the best of my knowledge doesn't support RFC2476. I did a little Googling just now and couldn't find any hits to say they did either. Some utilized RPC-over-HTTP. Most at the time didn't, requiring direct SMTP access or VPN. I wish more people would use it though. My users wouldn't have cause to get so upset when I tell them that they have to pay monthly for a static IP to use tcp/25. It would reduce my hassles a wee bit. Justin From jmaimon at ttec.com Thu Oct 22 20:41:25 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 Oct 2009 21:41:25 -0400 Subject: ISP port blocking practice In-Reply-To: <4AE106F7.3090302@justinshore.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <4AE106F7.3090302@justinshore.com> Message-ID: <4AE109C5.3040406@ttec.com> Justin Shore wrote: > The vast majority, I'm > sorry to say, used Microsoft Exchange which to the best of my knowledge > doesn't support RFC2476. You can configure exchange to use additional smtp virtual servers and bind them to specific ports. You can also require authentication to access the ports and you can restrict it to users. You can also enable it for STARTTLS. What I dont know is whether Exchange has or ever will support SMTPS which is strange considering many versions of outlook default to try that for any secured port other than 25. > I wish more people would use it though. My users wouldn't have cause to > get so upset when I tell them that they have to pay monthly for a static > IP to use tcp/25. It would reduce my hassles a wee bit. I have many a time recommended consulting customers to follow up with their mail provider to see if they has any plans to support the rfc standard, but I dont share much enthusiasm for complete adoption. I do believe it is getting better. > > Justin > > From scott at doc.net.au Thu Oct 22 20:46:52 2009 From: scott at doc.net.au (Scott Howard) Date: Thu, 22 Oct 2009 18:46:52 -0700 Subject: ISP port blocking practice In-Reply-To: <4AE106F7.3090302@justinshore.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <4AE106F7.3090302@justinshore.com> Message-ID: On Thu, Oct 22, 2009 at 6:29 PM, Justin Shore wrote: > I can also speak from experience from the enterprise customers of the > consulting side of my SP that I worked with before returning to the SP. Not > a one of them made use of the MSP port. The vast majority, I'm sorry to > say, used Microsoft Exchange which to the best of my knowledge doesn't > support RFC2476. I did a little Googling just now and couldn't find any > hits to say they did either. Some utilized RPC-over-HTTP. Most at the time > didn't, requiring direct SMTP access or VPN. > Depends what you mean by "support RFC2476". Exchange most definitely supports message submission on port 587. Whether it supports RFC2476 to the letter in terms of other requirements I don't know, but submission as a "client access" mechanism is fully supported, with all the usual defaults you'd expect (eg, auth required) Of course, that doesn't mean that it'll be enabled in a specific environment, or even if it is enabled, that it will be exposed from the firewall. Most larger corporates will be using Outlook with Exchange, and thus may only support RPC-over-HTTP as you've stated. Scott From Jon.Kibler at aset.com Thu Oct 22 21:36:13 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Thu, 22 Oct 2009 22:36:13 -0400 Subject: ISP port blocking practice In-Reply-To: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> Message-ID: <4AE1169D.2040409@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zhiyun Qian wrote: > Hi all, > > What is the common practice for enforcing port blocking policy (or what > is the common practice for you and your ISP)? More specifically, when > ISPs try to block certain outgoing port (port 25 for instance), they > could do two rules: > 1). For any outgoing traffic, if the destination port is 25, then drop > the packets. > 2). For any incoming traffic, if the source port is 25, then drop the > packets. > > Note that either of the rule would be able to block outgoing port 25 > traffic since each rule essentially represent one direction in a TCP > flow. Of course, they could apply both rules. However, based on our > measurement study, it looks like most of the ISPs are only using rule > 1). Is there any particular reason why rule 1) instead of rule 2)? Or > maybe both? > > Also, is it common that the rules are based on tcp flags (e.g. SYN, > SYN-ACK)? One would think block SYN packet is good enough. > > Regards. > -Zhiyun I understand your question, and I believe that you have been given a lot of good answers. However, I believe that, as an ISP, you are asking the wrong question; more precisely, you are only asking part of the real question you should be asking. The more appropriate question should be: "What should be our network filtering policies?" To answer that question, I would start with ingress and egress filtering by IP address, protocol, etc.: 1) Never allow traffic to egress any subnet unless its source IP address is within that subnet range. 2) Never allow traffic to egress any subnet, if that traffic claims to originate from the subnet's network number or broadcast address. 3) Never allow traffic to ingress any subnet, if that traffic is directed to the subnet's network number or broadcast address. 4) Never allow traffic to ingress any network if the source address is bogus. 5) Never allow traffic to ingress or egress any network if it has an protocol not "supported" by your network (e.g., allow only TCP, UDP, ICMP, ESP, AH, GRE, etc.). 6) Never allow traffic to ingress or egress any network if it has an invalid TCP flags configuration. These are the rules I can think of off the top of my head without looking at an actual hardened router. I am sure I am missing some, but these are a good start. My $0.02 worth. Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 s: 843-564-4224 s: JonRKibler e: Jon.Kibler at aset.com e: Jon.R.Kibler at gmail.com http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrhFp0ACgkQUVxQRc85QlOYlgCggttgagm2sb90Vg7ntEreFtLr ydAAnjG4zEmkTmLuZpWUey9nNRHZiTLs =VDEG -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From justin at justinshore.com Thu Oct 22 21:51:06 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 22 Oct 2009 21:51:06 -0500 Subject: ISP port blocking practice In-Reply-To: <4AE109C5.3040406@ttec.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <4AE106F7.3090302@justinshore.com> <4AE109C5.3040406@ttec.com> Message-ID: <4AE11A1A.10000@justinshore.com> Joe Maimon wrote: > You can configure exchange to use additional smtp virtual servers and > bind them to specific ports. You can also require authentication to > access the ports and you can restrict it to users. You can also enable > it for STARTTLS. That I did not know. Last time I'd looked there wasn't a decent work around unless you wanted to run a 2nd Exchange server in a cluster of sorts on a 2nd box and change it's default port to 587. Then let Exchange clustering move the mail around on the back end. This is good to know. > I have many a time recommended consulting customers to follow up with > their mail provider to see if they has any plans to support the rfc > standard, but I dont share much enthusiasm for complete adoption. I do > believe it is getting better. I'm sorry to say that the larger SP that we outsourced our customer mail service to doesn't support MSP. They don't support much of anything outside of the very basics. They require SMTP AUTH but until relatively recently they didn't support any AUTH options other than plaintext (I was actually shocked just now when I doublechecked because I have looked before). No, I'm not kidding. They do rDNS checks on every IP list in a Received line. The also do DNSBL DUL checks on all IPs on the Received lines (dumb because of course the first one will match if the SP has their customer dynamic pools listed in a DUL-type list). Things will change on their end and the way we find out is because of user complaints. The decision to switch to them wasn't a technical one I'm afraid. If you're an Internet *Service* Provider you should probably provide you own services. Justin From owen at delong.com Thu Oct 22 22:15:58 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 20:15:58 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <71bfd60c0910221431p14b49563q26b09fa1bf2fc3bc@mail.gmail.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <4AE0C6D6.5090606@ttec.com> <71bfd60c0910221431p14b49563q26b09fa1bf2fc3bc@mail.gmail.com> Message-ID: On Oct 22, 2009, at 2:31 PM, TJ wrote: >> >> >>>> Then let me say it. RA needs to be able to be completely turned >>>> off. >> DHCPv6 needs to be able to completely configure all requesting hosts. > > > Those two statements are not synonymous ... > They may not be synonymous, but, there is a set of operators for whom both are true. > > Sure, leave RA in the IPv6 stack. The market will decide, and we > will see if >> it is still on by default on soho routers and in IOS 15.4T in 2015. >> >> That is a more sensible statement. And were I to be a gambling man >> I would > say it will indeed be on by default ... we'll talk more about it > then :). > > > Also, I would like to add - there is a difference between the default > gateway information and other things, such as NTP|DNS|SIP server > information. Maybe. > The default gateway, by definition, is an on-link thing. IMHO, this > makes > the router a good source for information about the router. It does in some cases. In other cases, it does not. > I am not saying use cases for "fully spec'ed DHCPv6" don't exist or > should > be ignored. > Making the router capable of sharing the "missing piece" that covers > ~95% of > use cases is also a Good Thing. > I don't think most people are arguing that it should not be possible to configure a network for RA/SLAAC with the RA providing the gateway information. In fact, I think most of us would like to see RA/SLAAC capable of providing the other needed pieces of the puzzle. That said, there is a group of operators for whom RA is a bad thing, SLAAC is also a bad thing, and, their current usage of DHCPv4 does not map to any existing IPv6 technology, so, they are crying foul and want their needs addressed. I think that is 100% legitimate, regardless of whether Iljitsch thinks we are old enough to play with power tools or not. > Thinking out loud, we could also re-create the idea of an auto-magic > DNS by > creating a special use case within ULA-space - say FD00::/96, saving > the > last 32 bits for something like ::53 and using anycast. That's a fine solution for part of the problem space, but, moving the router assignment function for hosts to a device controlled by the host administrator is a necessary administrative boundary issue for a number of organizations. > *(Could abstract same idea to any stateless and/or light-session-based > service ... FD00::123 for Automagic ULA-based anycast NTP, etc. > Need 32 > bits if we don't want to hex convert the >9999 things, just in > case ...)* > NOOO... If you're going to do fd00:: for this, the 123 case really should be fd00::7b, not fd00::123 Owen From steve at ibctech.ca Thu Oct 22 22:26:36 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 22 Oct 2009 23:26:36 -0400 Subject: ISP port blocking practice In-Reply-To: <200910222031140.32BF5B92.18442@clifden.donelan.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <200910222031140.32BF5B92.18442@clifden.donelan.com> Message-ID: <4AE1226C.8090606@ibctech.ca> Sean Donelan wrote: > On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> My experience is that port 587 isn't used because ISPs block it >> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack >> it with a proxy that filters out the AUTH parts of the EHLO response, >> making the whole point of using the submission service ... pointless. > > You mentioned this last June. Can anyone else corroborate it? Rogers > says they don't do that, and lots of other people seem to be able to > use port 587 on Rogers (and other ISPs) without problems. > > All the cases I've looked at, where someone claimed an ISP was blocking > port 587, it turned out to be some other problem. The most common > reason was related to some security software/host based firewall running > on the user's own computer. Please pardon my ignorance here, especially if I've mistaken context... Although I'm not an email engineer, it was at *least* three-1/2 years ago that we switched our users from sending on port 25, to auth over 587 ('users' meaning the clients we have as an ISP/hosting company, which can establish on 587 from within OR without our network). Although I can recall a few edge cases that were brought to my attention for clients (users) not able to submit from a different network, the collateral damage has been ~1%. (ironically however, it seems as though recently those who have gone with a 'stick' have been reporting issues, and we've had to have them switch to port 25 on the SMTP server within the relevant network). I never even imagined that someone would do port 587 blocking as such. I'll have to light up on the network of the next client that complains, and if 587 doesn't get through, I'll start advising the helpdesk that they should redirect the former-client to call the 'ISP'. Someone please tell me that I'm misunderstanding something, so that I don't feel that two years of client notices, research and implementation, and another two years of dealing with manual support calls because they didn't 'see' the 400 warnings of email changes wasn't all a waste. fwiw to keep on topic, I block all 25-in with a small exception list for a few colo boxes, and our incoming MTA collection/filtering cluster. This 'in' ACL is placed on all PE hardware. The incoming mail cluster is attached to it's own PE, which ensures that everything from anywhere on the network eventually filters through this ACL, and that the core is always essentially clean. I then pretty much do the same out-25 on all PE hardware. Because my network is small, I manually/strictly manage the ACLs on any PE that is Internet/Peer facing. colo servers that require SMTP services is either connected to a PE designed to allow it, or is put into a VLAN designed for such. afair, I have only two clients remaining that I haven't forced into a /29 corner where I can SWIP their space, thereby using the 'you're responsible' hammer. Either way, even without the swip, I've made them well aware of the repercussions of failing to at least be attentive. Steve From owen at delong.com Thu Oct 22 22:38:01 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 20:38:01 -0700 Subject: ISP port blocking practice In-Reply-To: <4AE0DF32.1040903@justinshore.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> Message-ID: <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> On Oct 22, 2009, at 3:39 PM, Justin Shore wrote: > Zhiyun Qian wrote: >> Hi all, >> What is the common practice for enforcing port blocking policy (or >> what is the common practice for you and your ISP)? More >> specifically, when ISPs try to block certain outgoing port (port 25 >> for instance), they could do two rules: >> 1). For any outgoing traffic, if the destination port is 25, then >> drop the packets. >> 2). For any incoming traffic, if the source port is 25, then drop >> the packets. > > I block on both generally. I block inbound and outbound for > residential customers in dynamic pools. I block inbound only for > residential with statically-assigned IPs. That way a customer can > request (and pay for) a static IP and be able to get around out > outbound SMTP block. Few companies use the MSP port (tcp/587). I'm > not sure why more don't make the effort but most don't. To make up > for that we allow static residential customers to evade that filter > with a static IP. We still block inbound though. We also allow > them to use our SMTP servers and SmartHosts if they want with no > requirements on source domains (like some providers require, > essentially requiring the customer to advertise for you). The > inbound block isn't really all that useful as you elude to. However > I use it more often than not to look for people scanning out ranges > for open relays. I use that data for feed my RTBH trigger router > and drop the spammer's traffic on the floor (or the poor, > unfortunate owner of the compromised PC that's been 0wned. > Blocking ports that the end user has not asked for is bad. Doing it and refusing to unblock is worse. Some ISPs have the even worse practice of blocking 587 and a few even go to the horrible length to block 465. A few hotel gateways I have encountered are dumb enough to think they can block TCP/53 which is always fun. > We block several other things too. Netbios traffic gets dropped > both ways. MS-SQL traffic gets dropped both ways (a few users have > complained about this but very few stick to their guns when you > point out that their traffic is traversing the web completely > unencrypted). I block default and common proxy ports such as 3128, > 7212, and 6588 in both directions. Squid is too easy to > misconfigure (done it myself). GhostSurf and WinGate have both been > abusable as open proxies in various releases. I also block 8000, > 8080 and 8081 towards the customers. These are some of our most > commonly scanned ports (usually all 3 at once plus some or all of > the 80xx ones). I've encountered many compromised residential CPEs > that the users either enabled themselves or were enabled by > default. I don't block those 3 ports on outbound flows though; too > many false positives. > > And finally we also block several different types of ICMPs. First > off we block ICMP fragments. Then we permit echo, echo-reply, > packet-too-big, and time-exceeded. The rest get explicitly dropped. > IPv6 will change this list dramatically. I haven't had time to > research ICMPv6 thoroughly enough to say any more than that. > > Basically I just pick out some of the really bad ports and block > them. This gives me a wealth of data with which to null-route > compromised PCs scanning my networks. > Lovely for you, but, not particularly helpful to your customers who may actually want to use some of those services. Owen From owen at delong.com Thu Oct 22 22:50:04 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 20:50:04 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <1256253168.13611.40.camel@karl> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <1256253168.13611.40.camel@karl> Message-ID: <681C5CC9-FAEB-45D2-B767-88CB1182DBB4@delong.com> On Oct 22, 2009, at 4:12 PM, Karl Auer wrote: > On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote: >>> If, on the other hand, the REAL desire is to have a DHCP server >>> break >>> the tie in the selection between several routers that advertise >>> their >>> presence, that wouldn't be unreasonable. >> >> In some configurations not all hosts are supposed to use the same >> router. We need the _option_ to specify a default gateway and >> have the override any RA's a host may see. > > It would be a tool, and if someone wants to use a tool, they can. It > won't be my thumb they hit :-) > > But I can't see how a DHCP server can know enough about the routers to > be able to send out useful discrimination information. So it will have > to be manually entered, or come from an IPAM, or... > Current practice in the environments I know that are doing this is that groups of hosts are maintained in a database (including MAC addresses) and this database is used to build the DHCP configuration. The host group is assigned a default router address which is actually a VRRP group address. The routers then elect an appropriate VRRP active/standby configuration and the hosts route via the Active router for their VRRP group. If the host administrators find that a host needs to be part of a different VRRP group for whatever reason, there are tools at their disposal to address that issue. DHCP lease times can be short since the addresses are actually static anyway (yes, lots of people use DHCP to assign static addresses in production environments because it allows table-driven central management of host assignment). > Nor can I see how the DHCP server can identify the routers to the host > except by their addresses, and these can change or be removed without > the DHCP server finding out. > In most environments I know, there are addresses reserved for the VRRP groups that the routers participate in and the router administrators are well aware of the damage they will bring if they change them without extensive planning and notice. > The only way I can see it working is if the host were smart enough to > compare the DHCP router discrimination info with the information it > has > received via RA and delete mismatches, or possibly just revert to > using > RA information if any mismatches at all are detected. That would be an > item the DHCP server could specify as well - what to do in case of a > mismatch. It could even be specified on a per-router basis, though the > whole thing seems to be getting a bit unwieldy now. > That would be a terrible choice because you have eliminated one of the key reasons that some installations need DHCP to assign router information instead of RA. While what you propose is probably technically cleaner from a pure protocol design perspective, the reality is that pure protocol design is not how the real world thinks or operates. In the real world, one must make the protocol adapt to the business rules and other odd parameters that don't always make logical sense from a protocol design perspective. This is one such example when you have different administrative groups responsible for hosts and routers. I know it is rare to find an enterprise where the network infrastructure is not run by the same group that does the systems administration. But in many of these organizations, this means that having the router specify the default gateway to the host is not going to work well for the systems administrators. In today's world, they don't have to worry about this and, the network group, surprisingly, is pretty good at keeping the VRRP groups numbered as they are supposed to be (usually .1, .2, etc. or .254, .253, .252, etc., or whatever the first/last addresses of a segment happen to be). > The DHCP servers will not be on the same subnets as all the routers > involved, so they can't sniff the RAs themselves - unless we set up an > RA relay... hmm. > They don't need to. > I don't see DHCP-delivered router preferences as being something that > will "break the Internet". In the vast majority of cases they will be > unnecessary. For those that do need it though, and if it can be done, > why not? > Why do router preferences instead of just routers? Sure, the DHCP server doesn't know which router should be doing the routing, but, VRRP can take care of that as it does today. The DHCP server just needs to assign the VRRP group. Owen \ From owen at delong.com Thu Oct 22 22:51:09 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 20:51:09 -0700 Subject: ISP port blocking practice In-Reply-To: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> Message-ID: <07EB4BE7-2E92-42F0-A8DF-7B1DAFF2D018@delong.com> On Oct 22, 2009, at 4:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> Few >> companies use the MSP port (tcp/587). > > Can you elaborate. Is this based on analysis you've conducted on > your own network? And if so, is the data (anonymized) available for > the rest of us to look at? > > My experience is that port 587 isn't used because ISPs block it > out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack > it with a proxy that filters out the AUTH parts of the EHLO response, > making the whole point of using the submission service ... pointless. > > --lyndon > Wow... That's evil. Most ISPs I've dealt with don't have that problem, but, if I encountered one that did, I'd vote with my feet in short order. Owen From owen at delong.com Thu Oct 22 22:55:21 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 20:55:21 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE0EA5F.0@ttec.com> References: <7a6830090910171743r77f155f5ia48a167c4d57b00b@mail.gmail.com> <7a6830090910221434ta5d1091gc8c34cf1bba4664c@mail.gmail.com> <4AE0EA5F.0@ttec.com> Message-ID: <96566BD9-EC95-4C4F-8694-47EDD272426E@delong.com> On Oct 22, 2009, at 4:27 PM, Joe Maimon wrote: > > > Ray Soucy wrote: > > >> Others may have their specific requests from vendors, but here are >> mine: >> 1. Include DHCPv6 client functionality as part of any IPv6 >> implementation. >> 2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure. > > I can agree with that. > > I would also add that there is plenty of work that can be done to > DHCP, such as adding full route support, multiple gateways with > preference and even transitioning from a binary only protocol. > >> A lot of the frustration seems to come from Windows ICS acting as an >> IPv6 router. I think everyone here has been after Microsoft to >> either >> remove ICS or make it more difficult to enable at one point or >> another. While a rogue RA can come from anywhere, Windows is usually >> the guilty party. I would argue that since NAT is not a component of >> IPv6, > > NAT wasnt a component of IPv4 until it was already had widespread > adoption. I remain completely unconvinced that people will not > continue to perceive value in PAT6 between their private and their > public subnets. > People may perceive value, but, I truly hope that they won't be able to obtain the "functionality". It's just a very bad idea that does terrible things to the network. NAT/PAT was a necessary evil in IPv4 to extend the lifetime of the addressing until IPv6 could be almost ready. It should be allowed to die with IPv4. > And of course, different forms of NAT are almost certainly required > to try to make ipv4 and ipv6 interoperate for as long as people need > it to. > Sort of, but, yeah. That's OK. Unfortunate, but, OK. I actually think that now that we have a transfer market policy, IPv4 will probably die much faster than it would have otherwise. Owen From owen at delong.com Thu Oct 22 23:00:11 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Oct 2009 21:00:11 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE0F223.3050000@coders.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com><20091022102748.GA32008@vacation.karoshi.com.><4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> Message-ID: <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> On Oct 22, 2009, at 5:00 PM, Perry Lorier wrote: > trejrco at gmail.com wrote: >> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? >> > You want to allow for more than one for obvious fault isolation and > load balancing reasons. The draft suggested using :FFFF::1 > I personally would suggest getting a well known ULA-C allocation > assigned to IANA, then use :::1 > :::2 and :: assignment>:3, where could be "0035" for DNS, > and "007b" for NTP, and if you're feeling adventurous you could use > "0019" for outgoing SMTP relay. > I thought ULA-C was dead... Did someone resurrect this unfortunate bad idea? > > >> ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... >> Maybe reserve FD00::/96 for this type of "ULA port-based anycast >> allocation". (16bits would only reach 9999 w/o hex-conversion (if >> hex-converted could reserve FD00::/112 ... But would be less >> obvious)) >> >> >> Easily identified, not globally routable, can be pre-programmed in >> implementations/applications ... ? >> >> > > Exactly, seems easy, straight forward, robust, reliable and allows > for things like fate sharing and fail over. Why pull this out of ULA? Why not pull it out of 0000/16 or one of the other reserved prefixes? Owen From trejrco at gmail.com Thu Oct 22 23:38:31 2009 From: trejrco at gmail.com (TJ) Date: Fri, 23 Oct 2009 00:38:31 -0400 Subject: IPv6 Deployment for the LAN ... anycast In-Reply-To: <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com><20091022102748.GA32008@vacation.karoshi.com.><4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> Message-ID: <007a01ca539a$ad1935e0$074ba1a0$@com> > >> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? > > You want to allow for more than one for obvious fault isolation and > > load balancing reasons. The draft suggested using :FFFF::1 FWIW - I think simple anycast fits that bill. > > I personally would suggest getting a well known ULA-C allocation > > assigned to IANA, then use :::1 > > :::2 and :: > assignment>:3, where could be "0035" for DNS, > > and "007b" for NTP, and if you're feeling adventurous you could use > > "0019" for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? > I thought ULA-C was dead... Did someone resurrect this unfortunate bad > idea? Anything is dead until someone uses it. I was thinking FD00 just to have symmetry with anyone using ULAs today, so FC00::/8 could be outright blocked ... ? FC may make sense as they are, de facto, registered ... > >> ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... > >> Maybe reserve FD00::/96 for this type of "ULA port-based anycast > >> allocation". (16bits would only reach 9999 w/o hex-conversion (if > >> hex-converted could reserve FD00::/112 ... But would be less > >> obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful. > >> Easily identified, not globally routable, can be pre-programmed in > >> implementations/applications ... ? > > Exactly, seems easy, straight forward, robust, reliable and allows > > for things like fate sharing and fail over. > Why pull this out of ULA? Why not pull it out of 0000/16 or one of > the other reserved prefixes? ULAs are already defined as "internally routable, but not globally routable" - which is exactly how I would envision these being used. IOW, seemed to make sense to me! /TJ From steve at ibctech.ca Thu Oct 22 23:40:12 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Oct 2009 00:40:12 -0400 Subject: ISP port blocking practice In-Reply-To: <4AE1169D.2040409@aset.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE1169D.2040409@aset.com> Message-ID: <4AE133AC.8020202@ibctech.ca> Jon Kibler wrote: > Zhiyun Qian wrote: >> Hi all, > >> What is the common practice for enforcing port blocking policy (or what >> is the common practice for you and your ISP)? More specifically, when >> ISPs try to block certain outgoing port (port 25 for instance), they >> could do two rules: >> 1). For any outgoing traffic, if the destination port is 25, then drop >> the packets. >> 2). For any incoming traffic, if the source port is 25, then drop the >> packets. > >> Note that either of the rule would be able to block outgoing port 25 >> traffic since each rule essentially represent one direction in a TCP >> flow. Of course, they could apply both rules. However, based on our >> measurement study, it looks like most of the ISPs are only using rule >> 1). Is there any particular reason why rule 1) instead of rule 2)? Or >> maybe both? > >> Also, is it common that the rules are based on tcp flags (e.g. SYN, >> SYN-ACK)? One would think block SYN packet is good enough. > >> Regards. >> -Zhiyun > > I understand your question, and I believe that you have been given a lot of good > answers. However, I believe that, as an ISP, you are asking the wrong question; > more precisely, you are only asking part of the real question you should be > asking. The more appropriate question should be: "What should be our network > filtering policies?" > > To answer that question, I would start with ingress and egress filtering by IP > address, protocol, etc.: > 1) Never allow traffic to egress any subnet unless its source IP address is > within that subnet range. Sorry to nit, but shouldn't your uRPF setup take care of this (and many other of your list items), long before ACL? It's absolutely great if you have your list implemented, but imho, all ISP's, no matter how small should investigate and implement urpf. It's especially fun to play with RTBH. To be honest, the smaller you are, the easier it is to implement (ie. urpf strict everywhere! :) Steve From Valdis.Kletnieks at vt.edu Fri Oct 23 00:29:01 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Oct 2009 01:29:01 -0400 Subject: ISP port blocking practice In-Reply-To: Your message of "Thu, 22 Oct 2009 22:36:13 EDT." <4AE1169D.2040409@aset.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE1169D.2040409@aset.com> Message-ID: <44292.1256275741@turing-police.cc.vt.edu> On Thu, 22 Oct 2009 22:36:13 EDT, Jon Kibler said: > 4) Never allow traffic to ingress any network if the source address is bogus. 4a) Never flag a source address as bogus unless you can verify it is bogus *today*, not when you installed the filter. Out of date bogon filters are evil. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Jon.Kibler at aset.com Fri Oct 23 04:14:17 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 23 Oct 2009 05:14:17 -0400 Subject: ISP port blocking practice In-Reply-To: <4AE133AC.8020202@ibctech.ca> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE1169D.2040409@aset.com> <4AE133AC.8020202@ibctech.ca> Message-ID: <4AE173E9.4010209@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve Bertrand wrote: > Jon Kibler wrote: >> To answer that question, I would start with ingress and egress filtering by IP >> address, protocol, etc.: >> 1) Never allow traffic to egress any subnet unless its source IP address is >> within that subnet range. > > Sorry to nit, but shouldn't your uRPF setup take care of this (and many > other of your list items), long before ACL? > > It's absolutely great if you have your list implemented, but imho, all > ISP's, no matter how small should investigate and implement urpf. It's > especially fun to play with RTBH. > > To be honest, the smaller you are, the easier it is to implement (ie. > urpf strict everywhere! :) > > Steve > Agree for the most part. However: 1) The overwhelming majority of routers I have audited do not have uRPF implemented and most admins do not comprehend it, but they do comprehend (usually) ACLs. 2) L3 switching does not always support it, leaving potential for abuse if the network has any donut holes. 3) uRPF works best on egress but does little on outside ingress (e.g., bogons). 4) Defense in depth dictates using more than one way to detect an attack, so use both ACLs and uRPF. Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 s: 843-564-4224 s: JonRKibler e: Jon.Kibler at aset.com e: Jon.R.Kibler at gmail.com http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrhc+gACgkQUVxQRc85QlNAgACfZgrSuZ7dC1A38oIXB3lInUOc FnIAniWiQcVpJzp/ooh4LOHwEzPXUWo3 =dKbZ -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From perry at coders.net Fri Oct 23 07:08:09 2009 From: perry at coders.net (Perry Lorier) Date: Sat, 24 Oct 2009 01:08:09 +1300 Subject: IPv6 Deployment for the LAN In-Reply-To: <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com><20091022102748.GA32008@vacation.karoshi.com.><4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> Message-ID: <4AE19CA9.5030404@coders.net> >>> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? >>> >> You want to allow for more than one for obvious fault isolation and >> load balancing reasons. The draft suggested using :FFFF::1 I >> personally would suggest getting a well known ULA-C allocation >> assigned to IANA, then use :::1 >> :::2 and ::> assignment>:3, where could be "0035" for DNS, >> and "007b" for NTP, and if you're feeling adventurous you could use >> "0019" for outgoing SMTP relay. >> > I thought ULA-C was dead... Did someone resurrect this unfortunate bad > idea? > I'm not sure, I've not checked for a pulse recently. Last I looked it seemed that there was ULA-L and ULA-C, and most people were saying use ULA-L unless you needed ULA-C, ULA-C seemed like a good fit for this, if it's been buried then sure ULA-L would fit the bill just as well. >>> >>> Easily identified, not globally routable, can be pre-programmed in >>> implementations/applications ... ? >>> >>> >> >> Exactly, seems easy, straight forward, robust, reliable and allows >> for things like fate sharing and fail over. > > Why pull this out of ULA? Why not pull it out of 0000/16 or one of > the other reserved prefixes? With my proposal above it only requires a /96, seems silly to use up an entire /16 on a /96 worth of bits. It shouldn't come out of 2000::/3 because that's globally routable and this is defined to sit within locally scoped addressing. I have no major thoughts either way as to exactly where the range comes from other than it should be an easy to spot, and easy to type range which suggests plenty of 0's :) From perry at coders.net Fri Oct 23 07:25:33 2009 From: perry at coders.net (Perry Lorier) Date: Sat, 24 Oct 2009 01:25:33 +1300 Subject: IPv6 Deployment for the LAN ... anycast In-Reply-To: <007a01ca539a$ad1935e0$074ba1a0$@com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com><20091022102748.GA32008@vacation.karoshi.com.><4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <007a01ca539a$ad1935e0$074ba1a0$@com> Message-ID: <4AE1A0BD.8020301@coders.net> TJ wrote: >>>> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? >>>> >>> You want to allow for more than one for obvious fault isolation and >>> load balancing reasons. The draft suggested using :FFFF::1 >>> > > FWIW - I think simple anycast fits that bill. > > I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. There are some protocols that anycasting doesn't work well for, they may require multiple instances. >>> I personally would suggest getting a well known ULA-C allocation >>> assigned to IANA, then use :::1 >>> :::2 and ::>> assignment>:3, where could be "0035" for DNS, >>> and "007b" for NTP, and if you're feeling adventurous you could use >>> "0019" for outgoing SMTP relay. >>> > > IMHO non-hex-converted port numbers works cleanly ... ? > > Up to 9999, if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have "well known" ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports >9999 and protocols that don't have "well known" ports could get an unused one assigned to them. >>>> ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... >>>> Maybe reserve FD00::/96 for this type of "ULA port-based anycast >>>> allocation". (16bits would only reach 9999 w/o hex-conversion (if >>>> hex-converted could reserve FD00::/112 ... But would be less >>>> obvious)) >>>> > > Thinking further, if simply based on port#s wouldn't even need a registry. > Unless it was decided to implement the multiple-addresses-per-function > mentioned above, then perhaps useful. > > In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above). From trejrco at gmail.com Fri Oct 23 07:27:14 2009 From: trejrco at gmail.com (TJ) Date: Fri, 23 Oct 2009 08:27:14 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE19CA9.5030404@coders.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <4AE19CA9.5030404@coders.net> Message-ID: <71bfd60c0910230527p7079bae3x4f0d8aac37a81779@mail.gmail.com> > WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? >>>> >>>> Needs an acronym ... off the top of my head, something like ASPEN - Anycast Service Provisioning for Enterprise Networks ... ? (Although it could be appropriate for an ISP-HomeUser as well ... hmmm, SPATULA - Service Provisioning - Anycast, Transparent, Unique Local, Anycast ... ) <> > Exactly, seems easy, straight forward, robust, reliable and allows for >>> things like fate sharing and fail over. >>> >> >> I have no major thoughts either way as to exactly where the range comes > from other than it should be an easy to spot, and easy to type range which > suggests plenty of 0's :) > > I don't have any "major thoughts" on this either, still thinking out lout / rambling. :) /TJ From steve at ibctech.ca Fri Oct 23 07:36:57 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Oct 2009 08:36:57 -0400 Subject: ISP port blocking practice In-Reply-To: <4AE173E9.4010209@aset.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE1169D.2040409@aset.com> <4AE133AC.8020202@ibctech.ca> <4AE173E9.4010209@aset.com> Message-ID: <4AE1A369.1060907@ibctech.ca> Jon Kibler wrote: > Steve Bertrand wrote: >> Jon Kibler wrote: >>> To answer that question, I would start with ingress and egress filtering by IP >>> address, protocol, etc.: >>> 1) Never allow traffic to egress any subnet unless its source IP address is >>> within that subnet range. >> Sorry to nit, but shouldn't your uRPF setup take care of this (and many >> other of your list items), long before ACL? > >> It's absolutely great if you have your list implemented, but imho, all >> ISP's, no matter how small should investigate and implement urpf. It's >> especially fun to play with RTBH. > >> To be honest, the smaller you are, the easier it is to implement (ie. >> urpf strict everywhere! :) > >> Steve > > > Agree for the most part. However: > > 1) The overwhelming majority of routers I have audited do not have uRPF > implemented and most admins do not comprehend it, but they do comprehend > (usually) ACLs. Fair enough. However, a considerable portion of my PE and CE gear consists of 2691's in which uRPF is enabled, so I'd have to wonder which hardware doesn't support it. Even my routers running FreeBSD/Quagga have it enabled. Aside from that, I truly did mean kudos for the poster for at least putting in the effort for configuring such an elaborate ACL setup :) As for the admins not comprehending it, imho, if someone is in a position of operating an Internet Provider network, particularly one that utilizes BGP, they need to comprehend it, if even just for the respect of the community. IIRC, it was about two weeks after I read Kumari's initial draft that I had it not only understood, but implemented. Even given the small scale that I am at, it really sucks when you see BOGON/your own prefixes ingress to your network. What's more upsetting, is when you have made more than one request to an upstream to stop it, and you get no response...at all. > 2) L3 switching does not always support it, leaving potential for abuse if the > network has any donut holes. I didn't think of that angle. My experience with L3 switching is very limited. My understanding is though that most ops use L3 switching closer to the core (as opposed to the edge), where uRPF isn't needed anyhow. > 3) uRPF works best on egress but does little on outside ingress (e.g., bogons). Unless you have implemented an automated s/RT(BH|sink). Cymru bogons (learnt via peering) on a trigger box, pushed in through a route-map tagged with the null-route community to the PE. Works magic. > 4) Defense in depth dictates using more than one way to detect an attack, so use > both ACLs and uRPF. I completely agree. Useful not only as depth, but to patch the holes where one can't implement strict uRPF due to a client having multiple peer-points within your network. Cheers, Steve From trejrco at gmail.com Fri Oct 23 07:45:21 2009 From: trejrco at gmail.com (TJ) Date: Fri, 23 Oct 2009 08:45:21 -0400 Subject: IPv6 Deployment for the LAN ... anycast In-Reply-To: <4AE1A0BD.8020301@coders.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <007a01ca539a$ad1935e0$074ba1a0$@com> <4AE1A0BD.8020301@coders.net> Message-ID: <71bfd60c0910230545s1818f270kf3e64890342b53db@mail.gmail.com> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? > >>>>> >>>> You want to allow for more than one for obvious fault isolation and >>>> load balancing reasons. The draft suggested using :FFFF::1 >>>> >>>> >>> >> FWIW - I think simple anycast fits that bill. >> >> >> > I think for very small/small networks anycast requires a lot of overhead > and understanding. If your big enough to do anycast and/or loadbalancing > it's not hard for you to put all three addresses onto one device. > Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ... > > There are some protocols that anycasting doesn't work well for, they may > require multiple instances. Fair enough; could also standardize something like FD00::, FD00::1:, and FD00::2: ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... ) I personally would suggest getting a well known ULA-C allocation >>> assigned to IANA, then use :::1 >>> :::2 and ::>> assignment>:3, where could be "0035" for DNS, >>> and "007b" for NTP, and if you're feeling adventurous you could use >>> "0019" for outgoing SMTP relay. >>> >>> >> > IMHO non-hex-converted port numbers works cleanly ... ? > > > Up to 9999, if you want to announce a service port 30,000 you're in trouble. > Also quite a few protocols don't have "well known" ports, so may want to > get things assigned. If you're doing assignment you could do nice things > like 0x53 for DNS and then ports >9999 and protocols that don't have "well > known" ports could get an unused one assigned to them. OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port 9999 based on automatically using port numbers (or using automatically registered port numbers, see below). Maybe FD00::FFFF:xxxx/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses. > ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... >>>> Maybe reserve FD00::/96 for this type of "ULA port-based anycast >>>> allocation". (16bits would only reach 9999 w/o hex-conversion (if >>>> hex-converted could reserve FD00::/112 ... But would be less >>>> obvious)) >>>> >>>> >>> > Thinking further, if simply based on port#s wouldn't even need a registry. > Unless it was decided to implement the multiple-addresses-per-function > mentioned above, then perhaps useful. > > > In my humble opinion I'd have them registered, linking them to port numbers > means that it's easier on the poor admins brain at 3am while diagnosing > faults, but may cause various hassles in the future (see above). > OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...) And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc. /TJ From jmaimon at ttec.com Fri Oct 23 08:08:00 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 23 Oct 2009 09:08:00 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <96566BD9-EC95-4C4F-8694-47EDD272426E@delong.com> References: <7a6830090910171743r77f155f5ia48a167c4d57b00b@mail.gmail.com> <7a6830090910221434ta5d1091gc8c34cf1bba4664c@mail.gmail.com> <4AE0EA5F.0@ttec.com> <96566BD9-EC95-4C4F-8694-47EDD272426E@delong.com> Message-ID: <4AE1AAB0.1020105@ttec.com> Owen DeLong wrote: > > On Oct 22, 2009, at 4:27 PM, Joe Maimon wrote: >> NAT wasnt a component of IPv4 until it was already had widespread >> adoption. I remain completely unconvinced that people will not >> continue to perceive value in PAT6 between their private and their >> public subnets. >> > People may perceive value, but, I truly hope that they won't be able to > obtain the "functionality". It's just a very bad idea that does > terrible things to the network. NAT/PAT was a necessary evil in IPv4 to > extend the lifetime of the addressing until IPv6 could be almost ready. > It should be allowed to die with IPv4. I have had the privilege of seeing quite a few different organizations networks up close and personal, from small to very large, networks and organizations. I can recall two, both in academia, that used global unique to the desktop, firewalled of course. I can think of another two who chose to use public ASN and BGP because of input I was part of. Neither obtained PI space. Neither used global unique addresses anywhere near an internal server or desktop. Most of the rest use private space exclusively internal and different chunks of public space from different providers, from /24 - /28. For redundancy and load balancing, the tool of choice is natting load balancers or just plain nat with ecmp. Some even used private ASN (or provider ASN) to get their internet service with some degree of redundancy, but still just some chunks of PA /25 or so. I dont think IPv6 has much to offer these companies. I dont think encouraging all of them to get an ASN and PI /48 is that great an idea for both network operators and these organizations and I highly doubt that PA ipv6 has any real attraction to them at all. Depletion wont have any real affect on them at all. Perhaps it means they wont be able to get /25 or /26, but they most likely will have no issues lighting up new connectivity with a /28 or /29. Should they need native access to IPv6 content/endpoints, they would probably choose to use another nat functionality at the external points in their network. Only if there was no other way to do it would they consider lighting up guIPv6 to the desktop. And they would be quite unhappy about it. Many of these companies have explicit security policies concerning this. Many of these network architects have explicit preferences concerning this. Naturally there are probably many other end user organizations who wont fit in these lines, but my experience suggests that there are large percentages who will. I truly think it is way too early to decide and predict that IPv6 will not ever have widespread use of IPv6 PAT to IPv6 > >> And of course, different forms of NAT are almost certainly required to >> try to make ipv4 and ipv6 interoperate for as long as people need it to. >> > Sort of, but, yeah. That's OK. Unfortunate, but, OK. > > I actually think that now that we have a transfer market policy, IPv4 > will probably die much faster than it would have otherwise. > > Owen > Depletion wont ring a death knell for any end user with existing connectivity. What it will do is cause providers to start harvesting the fat in their networks. Some providers who will choose to implement private ipv4 along with IPv6 rollouts are likely to have very large amounts of that fat. Other companies with large amounts of fat probably exist as well, from the companies who had the habit of assigning /26 to every leased line customer back in the day to the hosters who handed out /24 like candy. What is a residential cable or DSL company who replaced millions of subscribers guIPv4 address with dual stack (lite?) private ipv4 and guIPv6 going to do with the all that IPv4? Will they cutover to new models that arent guIPv4 centric by attrition or quicker? I believe there will be strong pressure to monetize IPv4 addresses, both for internal customer use and perhaps to transfer it to other organizations. This is not necessarily a bad thing. People who want it will pay for it and those who do not will not. This will likely result in the identification of more IPv4 fat to be harvested. The really nice side effect would hopefully be to provide economic incentive to IPv6 as an alternative to pricey IPv4, which could provide enough acceleration to ipv6 demands to reach a tipover point sooner, rather then later. So in that sense, you could be right. Joe From feldman at twincreeks.net Fri Oct 23 08:37:07 2009 From: feldman at twincreeks.net (Steve Feldman) Date: Fri, 23 Oct 2009 09:37:07 -0400 Subject: [NANOG-announce] NANOG committee announcements Message-ID: The NANOG Steering Committee is pleased to announce that these people have been chosen to fill the eight open seats on the Program Committee: - Cathy Aronson - Jim Cowie - Barry Greene - Mohit Lad - Chris Morrow - Kevin Oberman - Dani Roisman - Sonia Sakovich With eighteen candidates this year, the decisions were more difficult than usual. So we want to give special thanks those who weren't selected for their participation, and to encourage them to try again during the next selection cycle for the PC or other NANOG roles. For the Steering Committee, Steve Feldman (Chair) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From owen at delong.com Fri Oct 23 08:42:50 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Oct 2009 06:42:50 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE19CA9.5030404@coders.net> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com><20091022102748.GA32008@vacation.karoshi.com.><4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <4AE19CA9.5030404@coders.net> Message-ID: <0654D0B4-4732-4DAD-A95F-2A0B8B7F1580@delong.com> On Oct 23, 2009, at 5:08 AM, Perry Lorier wrote: > >>>> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? >>>> >>> You want to allow for more than one for obvious fault isolation >>> and load balancing reasons. The draft suggested using >>> :FFFF::1 I personally would suggest getting a well known >>> ULA-C allocation assigned to IANA, then use ::>> assignment>:1 :::2 and >>> :::3, where >>> could be "0035" for DNS, and "007b" for NTP, and if you're feeling >>> adventurous you could use "0019" for outgoing SMTP relay. >>> >> I thought ULA-C was dead... Did someone resurrect this unfortunate >> bad idea? >> > > I'm not sure, I've not checked for a pulse recently. Last I looked > it seemed that there was ULA-L and ULA-C, and most people were > saying use ULA-L unless you needed ULA-C, ULA-C seemed like a good > fit for this, if it's been buried then sure ULA-L would fit the bill > just as well. > >>>> >>>> Easily identified, not globally routable, can be pre-programmed >>>> in implementations/applications ... ? >>>> >>>> >>> >>> Exactly, seems easy, straight forward, robust, reliable and allows >>> for things like fate sharing and fail over. >> >> Why pull this out of ULA? Why not pull it out of 0000/16 or one of >> the other reserved prefixes? > > With my proposal above it only requires a /96, seems silly to use up > an entire /16 on a /96 worth of bits. It shouldn't come out of > 2000::/3 because that's globally routable and this is defined to sit > within locally scoped addressing. > No... You missed my point... I was suggesting that 0000::/16 already had some assignments for stuff somewhat like this, so, why not use more of that prefix to get a /96 for this... e.g. ::/0 == default, ::1/128 == Loopback, etc. Why not use 0000:ffff::/64 to assign these addresses as: 0000:ffff::: That is a 32 bit instance number and 32 bit port number, using up just a /64. I was not suggesting the entire /16 for this, the entire /16 there isn't available. > I have no major thoughts either way as to exactly where the range > comes from other than it should be an easy to spot, and easy to type > range which suggests plenty of 0's :) I figured 0000 was a good candidate since it's already partially in use for reserved special addresses. Owen From owen at delong.com Fri Oct 23 08:48:52 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Oct 2009 06:48:52 -0700 Subject: IPv6 Deployment for the LAN ... anycast In-Reply-To: <71bfd60c0910230545s1818f270kf3e64890342b53db@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <007a01ca539a$ad1935e0$074ba1a0$@com> <4AE1A0BD.8020301@coders.net> <71bfd60c0910230545s1818f270kf3e64890342b53db@mail.gmail.com> Message-ID: On Oct 23, 2009, at 5:45 AM, TJ wrote: > WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? > >> >>>>>> >>>>> You want to allow for more than one for obvious fault isolation >>>>> and >>>>> load balancing reasons. The draft suggested using >>>>> :FFFF::1 >>>>> >>>>> >>>> >>> FWIW - I think simple anycast fits that bill. >>> >>> >>> >> I think for very small/small networks anycast requires a lot of >> overhead >> and understanding. If your big enough to do anycast and/or >> loadbalancing >> it's not hard for you to put all three addresses onto one device. >> > > Anycast isn't really hard - same address, multiple places, routers > see what > appear to be multiple routes to same destination, they choose the > least > expensive. Only tricky part (for stateless things) is ensuring the > route > announcement is implicitly tied to service availability on that > device ... > Please remember that IPv6 DNS is OFTEN not stateless as the replies are commonly too large for UDP. > > >> >> There are some protocols that anycasting doesn't work well for, >> they may >> require multiple instances. > > > Fair enough; could also standardize something like FD00:: number>, > FD00::1:, and FD00::2: ... is three > addresses > enough? (IIRC, the Site-Local based automagic DNS used 2 or three > addresses > ... ) > That's what I meant by prefix::: would be a 32-bit instance value and would be a 32 bit service value (probably port number in the low order bits initially). > > I personally would suggest getting a well known ULA-C allocation >>>> assigned to IANA, then use :::1 >>>> :::2 and ::>>> assignment>:3, where could be "0035" for DNS, >>>> and "007b" for NTP, and if you're feeling adventurous you could use >>>> "0019" for outgoing SMTP relay. >>>> >>>> >>> >> IMHO non-hex-converted port numbers works cleanly ... ? >> >> >> > > Up to 9999, if you want to announce a service port 30,000 you're in > trouble. >> Also quite a few protocols don't have "well known" ports, so may >> want to >> get things assigned. If you're doing assignment you could do nice >> things >> like 0x53 for DNS and then ports >9999 and protocols that don't >> have "well >> known" ports could get an unused one assigned to them. > > > OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - > reserving FD00::/96) covers us to port 9999 based on automatically > using > port numbers (or using automatically registered port numbers, see > below). > Why use the non-hex converted? Is it really hard to realize that 0x35 = 53? > Maybe FD00::FFFF:xxxx/112 as a block within the above range to be > used for > manual assignment of automatic service (potentially anycast) > addresses. > > > >> ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... >>>>> Maybe reserve FD00::/96 for this type of "ULA port-based anycast >>>>> allocation". (16bits would only reach 9999 w/o hex-conversion (if >>>>> hex-converted could reserve FD00::/112 ... But would be less >>>>> obvious)) >>>>> >>>>> >>>> >> Thinking further, if simply based on port#s wouldn't even need a >> registry. >> Unless it was decided to implement the multiple-addresses-per- >> function >> mentioned above, then perhaps useful. >> >> >> > In my humble opinion I'd have them registered, linking them to port > numbers >> means that it's easier on the poor admins brain at 3am while >> diagnosing >> faults, but may cause various hassles in the future (see above). >> > > OK, so register them - but sign up some well-known ones at very > comfortable > addresses, like DNS at 53 :). > (Or 35 if you prefer hex-conversion ...) > > And I am sure some would be concerned about hosts performing any > sort of > automatic service discovery anything, but this atleast has the > advantage > over multicast in that it doesn't require multicast routing or group > membership / state maintenance, only delivers packets to the nearest > (not > all) instances, etc. Agreed, but, since this mostly doesn't get typed by humans, I think that using 0x35 is much better in this case than using 0x53 -> 53 stuff. Owen From feldman at twincreeks.net Fri Oct 23 08:55:42 2009 From: feldman at twincreeks.net (Steve Feldman) Date: Fri, 23 Oct 2009 09:55:42 -0400 Subject: [NANOG-announce] NANOG committee announcements (part 2) Message-ID: Nominations for the Communications Committee (formerly known as the Mailing List Committee) remain open until October 29. With the recent charter amendment, this committee has a unique opportunity to help shape the presence of NANOG on the web, collaboration and social media platforms, and other forms of electronic communications beyond the mailing list. If you are interested or know someone else who is, please make a nomination by sending a message to nominations at nanog.org. Also, this past Wednesday the new Steering Committee met for the first time to welcome our new members, Sylvie LaPerri?re and Duane Wessels and to thank our outgoing members, Chris Morrow and Jared Mauch. During this meeting, I was selected as chair for the coming year. Joe Provo, who has done a great job as chair for the past year, will be vice chair. For the Steering Committee, Steve Feldman (Chair) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cmadams at hiwaay.net Fri Oct 23 09:04:57 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 23 Oct 2009 09:04:57 -0500 Subject: IPv6 Deployment for the LAN ... anycast In-Reply-To: References: <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <007a01ca539a$ad1935e0$074ba1a0$@com> <4AE1A0BD.8020301@coders.net> <71bfd60c0910230545s1818f270kf3e64890342b53db@mail.gmail.com> Message-ID: <20091023140457.GE931198@hiwaay.net> Once upon a time, Owen DeLong said: > Please remember that IPv6 DNS is OFTEN not stateless as the replies > are commonly too large for UDP. Anything that supports IPv6 _should_ also support EDNS0. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From justin at justinshore.com Fri Oct 23 09:47:38 2009 From: justin at justinshore.com (Justin Shore) Date: Fri, 23 Oct 2009 09:47:38 -0500 Subject: ISP port blocking practice In-Reply-To: <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> Message-ID: <4AE1C20A.1020405@justinshore.com> Owen DeLong wrote: > Blocking ports that the end user has not asked for is bad. I was going to ask for a clarification to make sure I read your statement correctly but then again it's short enough I really don't see any room to misinterpret it. Do you seriously think that a typical residential user has the required level of knowledge to call their SP and ask for them to block tcp/25, tcp & udp/1433 and 1434, and a whole list of common open proxy ports? While they're at it they might ask the SP to block the C&C ports for Bobax and Kraken. I'm sure all residential users know that they use ports 447 and 13789. If so then send me some of your users. You must be serving users around the MIT campus. > Doing it and refusing to unblock is worse. How you you propose we pull a customer's dynamically-assigned IP out of a DHCP pool so we can treat it differently? Not all SPs use customer-facing AUTH. I can think of none that do for CATV though I'm sure someone will now point an oddball SP that I've never heard of before. > Some ISPs have the even worse practice of blocking 587 and a few even > go to the horrible length to block 465. I would call that a very bad practice. I haven't personally seen a mis-configured MTA listening on the MSP port so I don't think they can make he claim that the MSP port is a common security risk. I would call tcp/587 a very safe port to have traverse my network. I think those ISPs are either demonstrating willful ignorance or marketing malice. > A few hotel gateways I have encountered are dumb enough to think they > can block TCP/53 > which is always fun. The hotel I stayed in 2 weeks ago that housed a GK class I took had just such a proxy. It screwed up DNS but even worse it completely hosed anything trying to tunnel over HTTP. OCS was dead in the water. My RPC-over-HTTP Outlook client couldn't work either. Fortunately they didn't mess with IPSec VPN or SSH. Either way it didn't matter much since the network was unusable (12 visible APs from room, all on overlapping 802.11b/g channels). The average throughput was .02Mbps. > Lovely for you, but, not particularly helpful to your customers who may > actually want to use some of those services. I take a hard line on this. I will not let the technical ignorance of the average residential user harm my other customers. There is absolutely no excuse for using Netbios or MS-SQL over the Internet outside of an encrypted tunnel. Any user smart enough to use a proxy is smart enough to pick a non-default port. Any residential user running a proxy server locally is in violation of our AUP anyway and will get warned and then terminated. My filtering helps 99.99% of my userbase. The .001% that find this basic security filter intolerable can speak with their wallets. They can find themselves another provider if they want to use those ports or pay for a business circuit where we filter very little on the assumption they as a business have the technical competence to handle basic security on their own. (The actual percentage of users that have raised concerns in the past 3 years is .0008%. I spoke with each of them and none decided to leave our service.) We've been down the road of no customer-facing ingress ACLs. We've fought the battles of getting large swaths of IPs blacklisted because of a few users' technical incompetence. We've had large portions of our network null-routed in large SPs. Then we got our act together and stopped acting like those ISPs who we all love to bitch about, that do not manage their customer traffic, and are poor netizens of this shared resource we call the Internet. Our problems have all but gone away. Our residential and business users no longer call in on a daily basis to report blacklisting problems. We no longer have reachability issues with networks that got fed up with the abuse coming from our compromised users and null-routed us. I stand by our results as proof that what we're doing is right. Our customers seem to agree and that's what matters. Justin From cboyd at gizmopartners.com Fri Oct 23 10:25:56 2009 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 23 Oct 2009 10:25:56 -0500 Subject: ISP port blocking practice In-Reply-To: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> Message-ID: <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> On Oct 22, 2009, at 6:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > My experience is that port 587 isn't used because ISPs block it > out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack > it with a proxy that filters out the AUTH parts of the EHLO response, > making the whole point of using the submission service ... pointless. We use 587 quite a lot (with SMTP Auth and SSL/TLS), and have found _very_ few places block or proxy it. We don't have any/many customers in Rogers service areas though. The biggest reason people don't use it is that it requires some thought and tweaking settings in the "advanced" tab areas of many email clients. Newer email clients are actually starting to look for submission port and SSL support and configuring it autmatically if they find it. Once it's set up correctly we've found customers really like it since their email "just works" in most places. --Chris From jbates at brightok.net Fri Oct 23 10:27:48 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 23 Oct 2009 10:27:48 -0500 Subject: ISP port blocking practice In-Reply-To: <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> Message-ID: <4AE1CB74.9060007@brightok.net> Chris Boyd wrote: > Once it's set up correctly we've found customers really like it since > their email "just works" in most places. > We get the same response. The largest 587 usage we have currently, though, is cell/PDA. Jack From steve at ibctech.ca Fri Oct 23 10:35:10 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Oct 2009 11:35:10 -0400 Subject: ISP port blocking practice In-Reply-To: <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> Message-ID: <4AE1CD2E.1090205@ibctech.ca> Chris Boyd wrote: > > On Oct 22, 2009, at 6:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > >> My experience is that port 587 isn't used because ISPs block it >> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack >> it with a proxy that filters out the AUTH parts of the EHLO response, >> making the whole point of using the submission service ... pointless. > > We use 587 quite a lot (with SMTP Auth and SSL/TLS), and have found > _very_ few places block or proxy it. We don't have any/many customers > in Rogers service areas though. > > The biggest reason people don't use it is that it requires some thought > and tweaking settings in the "advanced" tab areas of many email > clients. Newer email clients are actually starting to look for > submission port and SSL support and configuring it autmatically if they > find it. > > Once it's set up correctly we've found customers really like it since > their email "just works" in most places. I completely agree, and after all was said and done, well worth the effort. Even today, if users use their age-old setup manual to set up an email application, they can receive, but not send. We know why immediately when they call in and state this, and we tell them to expect an email to fix it, and then send them something like this: http://eagle.ca/update/mail/Outlook_Express/index.html ...yes, believe it or not, even with the pictures, they will sometimes still get it wrong ;) Years in planning and implementation, but a good, large-scale learning exercise and the achievement of no port 25 that I'm very proud of. Steve From alex-lists-nanog at yuriev.com Fri Oct 23 09:18:38 2009 From: alex-lists-nanog at yuriev.com (alex-lists-nanog at yuriev.com) Date: Fri, 23 Oct 2009 10:18:38 -0400 Subject: Anyone connected to AR2.PHI1 of GlobalCrossing? Message-ID: <20091023141837.GA7690@s1.yuriev.com> If there's anyone getting transit of AR2.PHI1 of Global Crossing, could you kindly drop me an email off-list? Thanks, Alex From michael at linuxmagic.com Fri Oct 23 11:11:13 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Fri, 23 Oct 2009 09:11:13 -0700 Subject: ISP port blocking practice In-Reply-To: <4AE1CD2E.1090205@ibctech.ca> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> <4AE1CD2E.1090205@ibctech.ca> Message-ID: <200910230911.14043.michael@linuxmagic.com> On October 23, 2009, Steve Bertrand wrote: > http://eagle.ca/update/mail/Outlook_Express/index.html > > ...yes, believe it or not, even with the pictures, they will sometimes > still get it wrong ;) > > Years in planning and implementation, but a good, large-scale learning > exercise and the achievement of no port 25 that I'm very proud of. > > Steve > Congratulations, it would be nice if everyone got there, and we push all our clients to adopt such a strategy, but it is always surprising how many still fear.. change.. and the phone calls they fear may come from it. We should all work to educate that in the end run, call volumes, and other problems will be reduced. -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From trejrco at gmail.com Fri Oct 23 11:36:11 2009 From: trejrco at gmail.com (TJ) Date: Fri, 23 Oct 2009 12:36:11 -0400 Subject: IPv6 Deployment for the LAN In-Reply-To: <0654D0B4-4732-4DAD-A95F-2A0B8B7F1580@delong.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <4AE19CA9.5030404@coders.net> <0654D0B4-4732-4DAD-A95F-2A0B8B7F1580@delong.com> Message-ID: <71bfd60c0910230936s3c4471e4o890b2eff3c2a22a8@mail.gmail.com> > > I figured 0000 was a good candidate since it's already partially in use >> for >> reserved special addresses. > > But in a totally non-routable fashion, as it stands today. ULA's have the immediate benefit of being routable, but not globally so - and (hopefully) already being in filter lists to prevent accidental implementation. /TJ From steve at ibctech.ca Fri Oct 23 12:14:30 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 23 Oct 2009 13:14:30 -0400 Subject: ISP port blocking practice In-Reply-To: <200910230911.14043.michael@linuxmagic.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> <4AE1CD2E.1090205@ibctech.ca> <200910230911.14043.michael@linuxmagic.com> Message-ID: <4AE1E476.4020803@ibctech.ca> Michael Peddemors wrote: > On October 23, 2009, Steve Bertrand wrote: >> http://eagle.ca/update/mail/Outlook_Express/index.html >> >> ...yes, believe it or not, even with the pictures, they will sometimes >> still get it wrong ;) >> >> Years in planning and implementation, but a good, large-scale learning >> exercise and the achievement of no port 25 that I'm very proud of. >> >> Steve >> > > Congratulations, it would be nice if everyone got there, and we push all our > clients to adopt such a strategy, but it is always surprising how many still > fear.. change.. and the phone calls they fear may come from it. Thanks. The phone calls is what we 'feared' the most. For most things, I'm able to come up with hackery/workarounds to enable change with no client impact, but not in this case. What we did was go on a massive PR campaign via email and web for nearly two years while I ran both 587 and 25 in parallel. Also, (for the most part), we'd have the users make the changes pro-actively during unrelated calls. Getting closer to the 'due date', I set up a in-band, on-the-side network of sensors that monitored for port 25 traffic across the network segments. The sensors had access to RADIUS and other systems that automated the task of retrieving the username (or client ident of some sort) who was using the IP in question during that time period. The results would then be emailed to me. Sometimes the support staff would make a few cold-calls here or there to further knock down the list when things were slow. Most of the domain hosting and non-resi clients have their own 'techs', so they were pretty good. Slowly but surely, I started blocking 25 on segments of the network. At this point, I'd say that we had about 80% coverage. On and after doomsday, the call volume wasn't overly bad (I think we had 6 staff at that time). Because we were very prepared (with the handy-dandy pictorials), calls incoming were exceptionally short: "yep, you can't send. Read this email we're about to send and you'll be good to go". We of course impounded into their minds that "oh, you didn't follow the instructions we've been sending for the last two years" for good measure. Collateral damage was minimalistic, but was quickly spotted via the sensors. Adjustments were made, and here we are. I'd have no fear in doing it again, now that I know what to expect :) Although we have only ~10k access users and on top of that ~400 hosted domains, I do believe that the effort can scale up to any scope, so long as the proper preparations are made in advance. I believe renumbering my network twice prior to that helped with keeping me sensible and realistic in how I needed to prepare though. Cheers, Steve From lyndon at orthanc.ca Fri Oct 23 12:15:23 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Fri, 23 Oct 2009 11:15:23 -0600 Subject: ISP port blocking practice In-Reply-To: <200910222031140.32BF5B92.18442@clifden.donelan.com> Message-ID: <5fb2e8c20677ede59e8d6d355d63ea8c@yyc.orthanc.ca> > Rogers > says they don't do that, and lots of other people seem to be able to > use port 587 on Rogers (and other ISPs) without problems. I'm in Calgary right now so I can't check the current behaviour, but as of June 1st it was still broken. Broken in the sense that any connection to port 587 would go through, but the AUTH lines in the EHLO response get deleted. They're obviously hijacking the connections through a broken proxy. And port 587 without AUTH is useless. As for outright blockage of port 587, I get this complaint from many of my clients while they are on the road. It seems hotels love to block it. --lyndon From cscora at apnic.net Fri Oct 23 13:31:51 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Oct 2009 04:31:51 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200910231831.n9NIVplf018275@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 24 Oct, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 301090 Prefixes after maximum aggregation: 141242 Deaggregation factor: 2.13 Unique aggregates announced to Internet: 149275 Total ASes present in the Internet Routing Table: 32521 Prefixes per ASN: 9.26 Origin-only ASes present in the Internet Routing Table: 28255 Origin ASes announcing only one prefix: 13771 Transit ASes present in the Internet Routing Table: 4266 Transit-only ASes present in the Internet Routing Table: 105 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 30 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 604 Unregistered ASNs in the Routing Table: 123 Number of 32-bit ASNs allocated by the RIRs: 300 Prefixes from 32-bit ASNs in the Routing Table: 242 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 189 Number of addresses announced to Internet: 2116891488 Equivalent to 126 /8s, 45 /16s and 51 /24s Percentage of available address space announced: 57.1 Percentage of allocated address space announced: 64.7 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 79.4 Total number of prefixes smaller than registry allocations: 144872 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72260 Total APNIC prefixes after maximum aggregation: 25358 APNIC Deaggregation factor: 2.85 Prefixes being announced from the APNIC address blocks: 68831 Unique aggregates announced from the APNIC address blocks: 30562 APNIC Region origin ASes present in the Internet Routing Table: 3842 APNIC Prefixes per ASN: 17.92 APNIC Region origin ASes announcing only one prefix: 1047 APNIC Region transit ASes present in the Internet Routing Table: 589 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 462803232 Equivalent to 27 /8s, 149 /16s and 209 /24s Percentage of available APNIC address space announced: 78.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 127136 Total ARIN prefixes after maximum aggregation: 67099 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 101658 Unique aggregates announced from the ARIN address blocks: 38678 ARIN Region origin ASes present in the Internet Routing Table: 13315 ARIN Prefixes per ASN: 7.63 ARIN Region origin ASes announcing only one prefix: 5144 ARIN Region transit ASes present in the Internet Routing Table: 1313 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 708690432 Equivalent to 42 /8s, 61 /16s and 194 /24s Percentage of available ARIN address space announced: 62.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 69365 Total RIPE prefixes after maximum aggregation: 40565 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 62853 Unique aggregates announced from the RIPE address blocks: 42173 RIPE Region origin ASes present in the Internet Routing Table: 13646 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7107 RIPE Region transit ASes present in the Internet Routing Table: 2053 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 402504512 Equivalent to 23 /8s, 253 /16s and 187 /24s Percentage of available RIPE address space announced: 75.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 25911 Total LACNIC prefixes after maximum aggregation: 6365 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24217 Unique aggregates announced from the LACNIC address blocks: 13306 LACNIC Region origin ASes present in the Internet Routing Table: 1195 LACNIC Prefixes per ASN: 20.27 LACNIC Region origin ASes announcing only one prefix: 375 LACNIC Region transit ASes present in the Internet Routing Table: 196 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC addresses announced to Internet: 67503616 Equivalent to 4 /8s, 6 /16s and 6 /24s Percentage of available LACNIC address space announced: 67.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 5949 Total AfriNIC prefixes after maximum aggregation: 1574 AfriNIC Deaggregation factor: 3.78 Prefixes being announced from the AfriNIC address blocks: 4309 Unique aggregates announced from the AfriNIC address blocks: 1581 AfriNIC Region origin ASes present in the Internet Routing Table: 331 AfriNIC Prefixes per ASN: 13.02 AfriNIC Region origin ASes announcing only one prefix: 98 AfriNIC Region transit ASes present in the Internet Routing Table: 68 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12602112 Equivalent to 0 /8s, 192 /16s and 75 /24s Percentage of available AfriNIC address space announced: 37.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1763 6991 454 Korea Telecom (KIX) 17488 1470 138 142 Hathway IP Over Cable Interne 4755 1266 292 145 TATA Communications formerly 9583 1103 87 532 Sify Limited 4134 1005 18177 392 CHINANET-BACKBONE 18101 980 204 32 Reliance Infocom Ltd Internet 7545 901 199 101 TPG Internet Pty Ltd 9829 849 661 20 BSNL National Internet Backbo 17974 797 249 94 PT TELEKOMUNIKASI INDONESIA 24560 781 290 164 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4164 3882 312 bellsouth.net, inc. 4323 3711 1037 384 Time Warner Telecom 1785 1776 714 139 PaeTec Communications, Inc. 7018 1574 5844 1059 AT&T WorldNet Services 20115 1488 1481 670 Charter Communications 6478 1347 275 437 AT&T Worldnet Services 2386 1306 637 945 AT&T Data Communications Serv 3356 1224 10964 439 Level 3 Communications, LLC 11492 1134 206 13 Cable One 22773 1113 2604 67 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 514 94 208 Evolva Telecom 35805 465 40 5 United Telecom of Georgia 3292 451 1908 394 TDC Tele Danmark 702 415 1822 334 UUNET - Commercial IP service 9198 387 138 12 Kazakhtelecom Data Network Ad 8866 360 110 23 Bulgarian Telecommunication C 3320 356 7068 304 Deutsche Telekom AG 3301 350 1428 307 TeliaNet Sweden 3215 349 3144 111 France Telecom Transpac 8551 316 294 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1520 2899 237 UniNet S.A. de C.V. 10620 1020 227 100 TVCABLE BOGOTA 28573 779 652 90 NET Servicos de Comunicao S.A 7303 658 347 98 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 475 310 61 Instituto Costarricense de El 11172 443 99 71 Servicios Alestra S.A de C.V 14117 438 29 11 Telefonica del Sur S.A. 7738 428 858 29 Telecomunicacoes da Bahia S.A 6471 421 96 31 ENTEL CHILE S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 990 188 7 TEDATA 24863 874 96 73 LINKdotNET AS number 3741 272 856 233 The Internet Solution 2018 195 188 118 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 142 14 6 Ci Telecom Autonomous system 33776 124 7 11 Starcomms Nigeria Limited 5536 121 8 18 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 20858 109 34 6 EgyNet Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4164 3882 312 bellsouth.net, inc. 4323 3711 1037 384 Time Warner Telecom 1785 1776 714 139 PaeTec Communications, Inc. 4766 1763 6991 454 Korea Telecom (KIX) 7018 1574 5844 1059 AT&T WorldNet Services 8151 1520 2899 237 UniNet S.A. de C.V. 20115 1488 1481 670 Charter Communications 17488 1470 138 142 Hathway IP Over Cable Interne 6478 1347 275 437 AT&T Worldnet Services 2386 1306 637 945 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3711 3327 Time Warner Telecom 1785 1776 1637 PaeTec Communications, Inc. 17488 1470 1328 Hathway IP Over Cable Interne 4766 1763 1309 Korea Telecom (KIX) 8151 1520 1283 UniNet S.A. de C.V. 4755 1266 1121 TATA Communications formerly 11492 1134 1121 Cable One 18566 1062 1052 Covad Communications 22773 1113 1046 Cox Communications, Inc. 8452 990 983 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:24 /11:63 /12:177 /13:355 /14:629 /15:1210 /16:10692 /17:4886 /18:8472 /19:17517 /20:21113 /21:21075 /22:27386 /23:26945 /24:157743 /25:926 /26:1113 /27:557 /28:154 /29:8 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2691 4164 bellsouth.net, inc. 4323 2350 3711 Time Warner Telecom 4766 1436 1763 Korea Telecom (KIX) 1785 1241 1776 PaeTec Communications, Inc. 17488 1231 1470 Hathway IP Over Cable Interne 11492 1058 1134 Cable One 18566 1043 1062 Covad Communications 9583 955 1103 Sify Limited 7018 932 1574 AT&T WorldNet Services 10620 926 1020 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:225 12:2147 13:7 15:22 16:3 17:5 20:36 24:1199 32:52 34:2 38:605 40:97 41:1767 43:1 44:2 46:1 47:21 52:6 55:2 56:2 57:25 58:607 59:640 60:441 61:1088 62:973 63:2005 64:3661 65:2374 66:4090 67:1758 68:984 69:2761 70:572 71:154 72:1725 73:2 74:1989 75:183 76:357 77:866 78:566 79:390 80:913 81:814 82:479 83:436 84:533 85:1006 86:372 87:692 88:422 89:1517 90:53 91:2616 92:417 93:1279 94:1317 95:1145 96:190 97:271 98:371 99:30 109:86 110:246 111:456 112:142 113:155 114:274 115:446 116:1096 117:592 118:358 119:790 120:132 121:797 122:1293 123:778 124:1043 125:1373 128:219 129:220 130:130 131:421 132:76 133:10 134:186 135:42 136:224 137:171 138:174 139:82 140:440 141:123 142:385 143:348 144:365 145:49 146:391 147:170 148:551 149:202 150:151 151:176 152:212 153:158 154:2 155:273 156:168 157:310 158:91 159:358 160:292 161:171 162:279 163:171 164:278 165:467 166:478 167:391 168:754 169:163 170:466 171:42 172:2 173:386 174:382 175:1 178:1 180:96 182:1 186:148 187:167 188:1179 189:610 190:3168 192:5745 193:4270 194:3326 195:2736 196:1170 198:3551 199:3352 200:5202 201:1360 202:7891 203:8237 204:3915 205:2180 206:2400 207:2987 208:3972 209:3456 210:2570 211:1142 212:1603 213:1619 214:172 215:39 216:4425 217:1335 218:415 219:456 220:1135 221:449 222:304 End of report From cboyd at gizmopartners.com Fri Oct 23 15:49:20 2009 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 23 Oct 2009 15:49:20 -0500 Subject: ISP port blocking practice In-Reply-To: <5fb2e8c20677ede59e8d6d355d63ea8c@yyc.orthanc.ca> References: <5fb2e8c20677ede59e8d6d355d63ea8c@yyc.orthanc.ca> Message-ID: On Oct 23, 2009, at 12:15 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > As for outright blockage of port 587, I get this complaint from many > of > my clients while they are on the road. It seems hotels love to block > it. I travel a bit (used to a lot) and only found one place that proxied it. Never saw an outright block. A call to the support group actually got if fixed in about 45 minutes. Call and complain if it's broken. You are the customer at that point..... --Chris From David_Hankins at isc.org Fri Oct 23 16:11:37 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 23 Oct 2009 14:11:37 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <4AE0EFD7.9020907@coders.net> References: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <4AE0EFD7.9020907@coders.net> Message-ID: <20091023211137.GD4261@isc.org> On Fri, Oct 23, 2009 at 12:50:47PM +1300, Perry Lorier wrote: > I've implemented myself a system which firewalled all ARP within the AP and > queried the DHCP server asking for the correct MAC for that lease then sent > the ARP back (as well as firewalling DHCP servers and the like). It's > quite easily doable, and quite reliable. If nodes were to send packets > directly when associated to an AP then the 802.11 protocol would fall > apart, I've never met an implementation that broke this requirement of the > standard. It had not occurred to me to intercept ARP (or ND) as a transition mechanism, that is pretty clever, but the idea of using DHCPv* leasequery as a way to make IP->MAC resolution both secure and unicast is something I've heard many times. I don't know about my peers, but I would be very interested to see an RFC that describes and examines your results. > You can of course pretend you're the AP and send a packet if you're wanting > to be vicious enough. Yes, of course, that is much simpler. If the attacker can associate with the real wireless network, they can always bridge and provide a rogue AP to insert themselves in the middle. Sometimes in focusing on packet exchanges, we miss the forest for the trees. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From lriemer at bestline.net Fri Oct 23 16:19:23 2009 From: lriemer at bestline.net (Lee Riemer) Date: Fri, 23 Oct 2009 16:19:23 -0500 Subject: ISP port blocking practice In-Reply-To: <4AE1C20A.1020405@justinshore.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> Message-ID: <4AE21DDB.8050204@bestline.net> Isn't blocking any port against the idea of Net Neutrality? Justin Shore wrote: > Owen DeLong wrote: >> Blocking ports that the end user has not asked for is bad. > > I was going to ask for a clarification to make sure I read your > statement correctly but then again it's short enough I really don't > see any room to misinterpret it. Do you seriously think that a > typical residential user has the required level of knowledge to call > their SP and ask for them to block tcp/25, tcp & udp/1433 and 1434, > and a whole list of common open proxy ports? While they're at it they > might ask the SP to block the C&C ports for Bobax and Kraken. I'm > sure all residential users know that they use ports 447 and 13789. If > so then send me some of your users. You must be serving users around > the MIT campus. > >> Doing it and refusing to unblock is worse. > > How you you propose we pull a customer's dynamically-assigned IP out > of a DHCP pool so we can treat it differently? Not all SPs use > customer-facing AUTH. I can think of none that do for CATV though I'm > sure someone will now point an oddball SP that I've never heard of > before. > >> Some ISPs have the even worse practice of blocking 587 and a few even >> go to the horrible length to block 465. > > I would call that a very bad practice. I haven't personally seen a > mis-configured MTA listening on the MSP port so I don't think they can > make he claim that the MSP port is a common security risk. I would > call tcp/587 a very safe port to have traverse my network. I think > those ISPs are either demonstrating willful ignorance or marketing > malice. > >> A few hotel gateways I have encountered are dumb enough to think they >> can block TCP/53 >> which is always fun. > > The hotel I stayed in 2 weeks ago that housed a GK class I took had > just such a proxy. It screwed up DNS but even worse it completely > hosed anything trying to tunnel over HTTP. OCS was dead in the > water. My RPC-over-HTTP Outlook client couldn't work either. > Fortunately they didn't mess with IPSec VPN or SSH. Either way it > didn't matter much since the network was unusable (12 visible APs from > room, all on overlapping 802.11b/g channels). The average throughput > was .02Mbps. > >> Lovely for you, but, not particularly helpful to your customers who >> may actually want to use some of those services. > > I take a hard line on this. I will not let the technical ignorance of > the average residential user harm my other customers. There is > absolutely no excuse for using Netbios or MS-SQL over the Internet > outside of an encrypted tunnel. Any user smart enough to use a proxy > is smart enough to pick a non-default port. Any residential user > running a proxy server locally is in violation of our AUP anyway and > will get warned and then terminated. My filtering helps 99.99% of my > userbase. The .001% that find this basic security filter intolerable > can speak with their wallets. They can find themselves another > provider if they want to use those ports or pay for a business circuit > where we filter very little on the assumption they as a business have > the technical competence to handle basic security on their own. (The > actual percentage of users that have raised concerns in the past 3 > years is .0008%. I spoke with each of them and none decided to leave > our service.) > > We've been down the road of no customer-facing ingress ACLs. We've > fought the battles of getting large swaths of IPs blacklisted because > of a few users' technical incompetence. We've had large portions of > our network null-routed in large SPs. Then we got our act together > and stopped acting like those ISPs who we all love to bitch about, > that do not manage their customer traffic, and are poor netizens of > this shared resource we call the Internet. Our problems have all but > gone away. Our residential and business users no longer call in on a > daily basis to report blacklisting problems. We no longer have > reachability issues with networks that got fed up with the abuse > coming from our compromised users and null-routed us. I stand by our > results as proof that what we're doing is right. Our customers seem > to agree and that's what matters. > > Justin > > > From james.cutler at consultant.com Fri Oct 23 16:58:38 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Fri, 23 Oct 2009 17:58:38 -0400 Subject: ISP port blocking practice In-Reply-To: <4AE21DDB.8050204@bestline.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> Message-ID: <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> Blocking the well known port 25 does not block sending of mail. Or the message content. Blocking various well know M$ protocol ports does not block remote file access. Or control the type of files that can be accessed. I think the relevant neutrality principle is that traffic is not blocked by content. So, no, blocking any port is NOT against the idea of Net Neutrality. On Oct 23, 2009, at 5:19 PM, Lee Riemer wrote: > Isn't blocking any port against the idea of Net Neutrality? > James R. Cutler james.cutler at consultant.com From cidr-report at potaroo.net Fri Oct 23 17:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Oct 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200910232200.n9NM01Gb051552@wattle.apnic.net> BGP Update Report Interval: 15-Oct-09 -to- 22-Oct-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 129479 3.7% 38.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS17488 55469 1.6% 43.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 3 - AS9198 52840 1.5% 133.1 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - AS6478 52749 1.5% 38.7 -- ATT-INTERNET3 - AT&T WorldNet Services 5 - AS7018 45927 1.3% 37.8 -- ATT-INTERNET4 - AT&T WorldNet Services 6 - AS10176 43444 1.2% 3103.1 -- TENET-AS Taejon Institute of Education Science 7 - AS4755 39408 1.1% 36.8 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 8 - AS19262 39193 1.1% 40.5 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 9 - AS10620 36769 1.1% 39.9 -- TV Cable S.A. 10 - AS2386 32287 0.9% 32.0 -- INS-AS - AT&T Data Communications Services 11 - AS8151 32202 0.9% 27.7 -- Uninet S.A. de C.V. 12 - AS9829 30851 0.9% 44.1 -- BSNL-NIB National Internet Backbone 13 - AS701 27071 0.8% 40.5 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 14 - AS24560 26966 0.8% 38.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 15 - AS9498 23721 0.7% 39.0 -- BBIL-AP BHARTI Airtel Ltd. 16 - AS17908 21789 0.6% 39.5 -- TCISL Tata Communications 17 - AS9706 19919 0.6% 1532.2 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 18 - AS14117 19452 0.6% 45.8 -- Telefonica del Sur S.A. 19 - AS41661 18440 0.5% 512.2 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 20 - AS17974 17365 0.5% 26.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS11735 11238 0.3% 5619.0 -- ITRON-OAKLAND-HOSTING - ITRON 2 - AS10176 43444 1.2% 3103.1 -- TENET-AS Taejon Institute of Education Science 3 - AS9531 15485 0.5% 3097.0 -- GEDU-AS-KR Kwangju City Office Of Education 4 - AS45406 6154 0.2% 3077.0 -- AJU-AS-KR AJU Internet Technology 5 - AS36239 2774 0.1% 2774.0 -- EXIGEN-CANADA - Exigen Canada 6 - AS9706 19919 0.6% 1532.2 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 7 - AS38703 5759 0.2% 1439.8 -- KTB-AS-KR KTBnetwork Co., Ltd. 8 - AS27667 1209 0.0% 1209.0 -- Universidad Autonoma de la Laguna 9 - AS14490 765 0.0% 765.0 -- VIRTELA-CUST-VCASJC1-EXTREME Virtela Communications 10 - AS5963 8181 0.2% 681.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS22806 592 0.0% 592.0 -- TENCO-INC - TENCO, INC. 12 - AS12732 568 0.0% 568.0 -- bbTT GmbH 13 - AS41661 18440 0.5% 512.2 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 14 - AS2642 1732 0.1% 433.0 -- LEG-CA-GOV - State of California 15 - AS32243 393 0.0% 393.0 -- ALBL - Aluminum Blanking Company 16 - AS22917 1511 0.0% 377.8 -- INFOCHANNEL - InfoChannel Ltd. 17 - AS3 372 0.0% 143.0 -- BLETANET Bleta Sh.p.k 18 - AS18084 304 0.0% 304.0 -- ANC Asia Netcom Japan Corp. 19 - AS5691 2681 0.1% 297.9 -- MITRE-AS-5 - The MITRE Corporation 20 - AS45782 288 0.0% 288.0 -- PHILIPPINEAIRLINES-PH-AP Philippine Airlines Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 63.82.251.0/24 5620 0.2% AS11735 -- ITRON-OAKLAND-HOSTING - ITRON 2 - 63.80.163.0/24 5618 0.2% AS11735 -- ITRON-OAKLAND-HOSTING - ITRON 3 - 95.59.1.0/24 4715 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 88.204.221.0/24 4680 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.3.0/24 4529 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.8.0/23 4522 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.2.0/23 4522 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 95.59.4.0/22 4522 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 92.46.244.0/23 4488 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 89.218.220.0/23 4478 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 11 - 89.218.218.0/23 4476 0.1% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 12 - 214.15.28.0/24 4037 0.1% AS5963 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - 214.15.29.0/24 4037 0.1% AS5963 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - 210.111.224.0/19 3108 0.1% AS10176 -- TENET-AS Taejon Institute of Education Science 15 - 211.253.176.0/20 3106 0.1% AS10176 -- TENET-AS Taejon Institute of Education Science 16 - 210.100.212.0/23 3106 0.1% AS10176 -- TENET-AS Taejon Institute of Education Science 17 - 210.95.136.0/22 3106 0.1% AS10176 -- TENET-AS Taejon Institute of Education Science 18 - 211.185.225.0/24 3104 0.1% AS10176 -- TENET-AS Taejon Institute of Education Science 19 - 211.185.224.0/24 3104 0.1% AS10176 -- TENET-AS Taejon Institute of Education Science 20 - 211.248.68.0/22 3104 0.1% AS10176 -- TENET-AS Taejon Institute of Education Science Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 23 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Oct 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200910232200.n9NM00vJ051542@wattle.apnic.net> This report has been generated at Fri Oct 23 21:11:17 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-10-09 305625 188521 17-10-09 305777 188584 18-10-09 305721 188718 19-10-09 305781 188812 20-10-09 306184 188983 21-10-09 306022 189387 22-10-09 306388 189448 23-10-09 306361 189635 AS Summary 32685 Number of ASes in routing system 13880 Number of ASes announcing only one prefix 4323 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89686272 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 23Oct09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 306714 189740 116974 38.1% All ASes AS6389 4164 319 3845 92.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4323 1885 2438 56.4% TWTC - tw telecom holdings, inc. AS4766 1879 579 1300 69.2% KIXS-AS-KR Korea Telecom AS17488 1470 294 1176 80.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1113 77 1036 93.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1775 840 935 52.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1520 598 922 60.7% Uninet S.A. de C.V. AS4755 1266 398 868 68.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1024 233 791 77.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 297 765 72.0% COVAD - Covad Communications Co. AS8452 990 254 736 74.3% TEDATA TEDATA AS18101 979 245 734 75.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1347 681 666 49.4% ATT-INTERNET3 - AT&T WorldNet Services AS3356 1225 567 658 53.7% LEVEL3 Level 3 Communications AS4808 759 189 570 75.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS10620 1020 456 564 55.3% TV Cable S.A. AS7303 657 100 557 84.8% Telecom Argentina S.A. AS17908 638 92 546 85.6% TCISL Tata Communications AS24560 780 242 538 69.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9498 652 125 527 80.8% BBIL-AP BHARTI Airtel Ltd. AS22047 545 18 527 96.7% VTR BANDA ANCHA S.A. AS7018 1576 1063 513 32.6% ATT-INTERNET4 - AT&T WorldNet Services AS4804 621 114 507 81.6% MPX-AS Microplex PTY LTD AS11492 1134 646 488 43.0% CABLEONE - CABLE ONE, INC. AS9443 525 80 445 84.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 562 125 437 77.8% GIGAINFRA Softbank BB Corp. AS4780 562 143 419 74.6% SEEDNET Digital United Inc. AS7011 1029 620 409 39.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS855 628 223 405 64.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7738 428 29 399 93.2% Telecomunicacoes da Bahia S.A. Total 36253 11532 24721 68.2% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.248.67.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.68.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.69.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.70.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.71.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.74.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.76.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.77.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.78.0/24 AS11730 CIL-ASN - Circle Internet LTD 89.248.79.0/24 AS11730 CIL-ASN - Circle Internet LTD 91.198.127.0/24 AS8972 PLUSSERVER-AS PlusServer AG, Germany 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.77.128.0/24 AS4323 TWTC - tw telecom holdings, inc. 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.162.0/24 AS4841 202.140.168.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK Wind International Services SA 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From dwhite at olp.net Fri Oct 23 17:15:45 2009 From: dwhite at olp.net (Dan White) Date: Fri, 23 Oct 2009 17:15:45 -0500 Subject: ISP port blocking practice In-Reply-To: <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> Message-ID: <20091023221545.GH4947@dan.olp.net> On 23/10/09?17:58?-0400, James R. Cutler wrote: > Blocking the well known port 25 does not block sending of mail. Or the > message content. It does block incoming SMTP traffic on that well known port. > I think the relevant neutrality principle is that traffic is not blocked > by content. My personal definition doesn't quite gel with that. You're deciding for the customer how they can use their connection, before you have any evidence of nefarious activity. Would you consider restricting a customer's outgoing port 25 traffic to a specific mail server a step over the net neutrality line? -- Dan White From justin at justinshore.com Fri Oct 23 17:43:32 2009 From: justin at justinshore.com (Justin Shore) Date: Fri, 23 Oct 2009 17:43:32 -0500 Subject: ISP port blocking practice In-Reply-To: <20091023221545.GH4947@dan.olp.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> Message-ID: <4AE23194.3010501@justinshore.com> Dan White wrote: > On 23/10/09 17:58 -0400, James R. Cutler wrote: >> Blocking the well known port 25 does not block sending of mail. Or the >> message content. > > It does block incoming SMTP traffic on that well known port. Then the customer should have bought a class of service that permits servers. >> I think the relevant neutrality principle is that traffic is not blocked >> by content. > > My personal definition doesn't quite gel with that. You're deciding for the > customer how they can use their connection, before you have any evidence of > nefarious activity. They decided for themselves when they bought a residential connection instead of a business circuit. Just because someone bought themselves a Camry doesn't mean that Toyota is deciding for them that they can't haul 1000lbs of concrete with it. The customer did when they decided to buy a car and not a pickup. > Would you consider restricting a customer's outgoing port 25 traffic to a > specific mail server a step over the net neutrality line? I do this all the time. For example I don't let my customers send or receive mail (or any traffic for that matter) from prefixes originating from AS32311 (Colorado spammer Scott Richter). Now if I was blocking mail to dnc.org, gop.com, greenpeace.org, etc or restricting Vonage to .05% of my bandwidth then yeah that would violate net neutrality principles. The difference is one stifles speech and is anti-competitive. The other mitigates a network security and stability risk. I see this same argument on Slashdot all too often. It's usually bundled with an argument against providers doing any sort of traffic aggregation ("if I buy 1.5Mbps then it should be a dedicated pipe straight to the Internet!") Unfortunately that's simply not reality. You can either live with a small level of controls on your traffic for the sake of stability and security or you can have wide-open ISPs with no security prohibitions whatsoever. The support costs for the ISPs go through the roof and of course that gets passed onto the customer. Your 5 9s SLA gets replaced with "use it while you can before it goes down again". Everyone pays a penalty for having a digital Wild West. Not to start another thread on a completely OT topic but the same concept can be applied to other things like health care. Either everyone can pay a little bit for all to have good service or many average consumers can pay lots to make up the losses for those that can't pay at all. Justin From james.cutler at consultant.com Fri Oct 23 18:33:58 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Fri, 23 Oct 2009 19:33:58 -0400 Subject: ISP port blocking practice In-Reply-To: <20091023221545.GH4947@dan.olp.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> Message-ID: No, blocking a port does not restrict a customers use of the network any more than one way streets restrict access to downtown stores. It just forces certain traffic directions in a bicycle/motorcycle/car/van/ truck neutral manner. Carry anything you want. Others laws restrict incendiary content. On Oct 23, 2009, at 6:15 PM, Dan White wrote: > On 23/10/09 17:58 -0400, James R. Cutler wrote: >> Blocking the well known port 25 does not block sending of mail. Or >> the >> message content. > > It does block incoming SMTP traffic on that well known port. > >> I think the relevant neutrality principle is that traffic is not >> blocked >> by content. > > My personal definition doesn't quite gel with that. You're deciding > for the > customer how they can use their connection, before you have any > evidence of > nefarious activity. > > Would you consider restricting a customer's outgoing port 25 traffic > to a > specific mail server a step over the net neutrality line? > > -- > Dan White James R. Cutler james.cutler at consultant.com From patrick at ianai.net Fri Oct 23 19:12:22 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 23 Oct 2009 20:12:22 -0400 Subject: ISP port blocking practice In-Reply-To: References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> Message-ID: The original intent of Net Neutrality laws had nothing to do with blocking or not on random ports. It had to do with giving an unfair advantage to the provider in question to sell competing services. Much like anti-trust legislation doesn't stop a company from cornering a market, just stops them from using that Market Power to create artificial advantages in other market segments to the detriment of the public. Putting this into a hypothetical example: If your access to iTunes, NetFlix, Amazon, etc. is filtered / rate limited / whatever, but you can order On-Demand from the company who owns the same piece of which delivers the Internet, especially if that is the only broadband connection you can buy because of monopoly / duopoly protection, then this is deemed "unfair". Anti-net-neutrality people spin this into "but suppose I want to charge extra for premium access to YouTube?" A != B, their argument does not address the underlying point of the rule. Do not be fooled by such spin. Back to the original question, no provider is blocking port 25 to force you to buy their mail services - they usually give it out for free with a connection! Add in the "reasonable network management / preventing abuse / best common practices" argument, which are backed up with 3rd party documents, and I don't think anyone rational would call this a violation of Network Neutrality. The problem is, not everyone is rational, and no law is written perfectly. Some spammer _will_ file a lawsuit claiming their spam is CAN-SPAM compliant, therefore legal, and the provider cannot block them. This will use legal resource, and may even result in un- blocking while a judge who knows what the box on his secretary's desk where his "e-mail" (huh?) gets printed is found. And that could take a while. Would that life were perfect. But it is not, so we muddle through as best we can. And I think we can do better than allowing a gov't sponsored monopoly use that monopoly to decide what things we can and cannot do based on what will raise their profit margin. One other personal comment: I believe if you paid for a resource, you should be allowed to dictate its use, even to your customers (as long as it is clear when they paid what the rules are). That said, there are no cable or DSL providers in the US who "paid" 100% for their resources, no matter what the executives at these companies think. This is not opinion, this is fact. OTOH: Companies who set up WiMAX or satellite or other technologies which do not depend on gov't grants, tax relief, right-of-way, monopoly protection, etc. should be allowed to do as they please. Yes, this includes filtering iTunes so you buy their movie streaming service. Of course, I have no idea if such a company exists, but it certainly is not impossible to set one up. I just don't know if it can make any money against companies that are funded by, granted exclusive rights by, or are helped in other ways by the gov't. I fear the answer is "no way in hell". All of this is IMHO, of course. -- TTFN, patrick On Oct 23, 2009, at 7:33 PM, James R. Cutler wrote: > No, blocking a port does not restrict a customers use of the network > any more than one way streets restrict access to downtown stores. It > just forces certain traffic directions in a bicycle/motorcycle/car/ > van/truck neutral manner. Carry anything you want. Others laws > restrict incendiary content. > > > On Oct 23, 2009, at 6:15 PM, Dan White wrote: > >> On 23/10/09 17:58 -0400, James R. Cutler wrote: >>> Blocking the well known port 25 does not block sending of mail. Or >>> the >>> message content. >> >> It does block incoming SMTP traffic on that well known port. >> >>> I think the relevant neutrality principle is that traffic is not >>> blocked >>> by content. >> >> My personal definition doesn't quite gel with that. You're deciding >> for the >> customer how they can use their connection, before you have any >> evidence of >> nefarious activity. >> >> Would you consider restricting a customer's outgoing port 25 >> traffic to a >> specific mail server a step over the net neutrality line? >> >> -- >> Dan White > > James R. Cutler > james.cutler at consultant.com > > > > > From dwhite at olp.net Fri Oct 23 21:35:31 2009 From: dwhite at olp.net (Dan White) Date: Fri, 23 Oct 2009 21:35:31 -0500 Subject: ISP port blocking practice In-Reply-To: <4AE23194.3010501@justinshore.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> <4AE23194.3010501@justinshore.com> Message-ID: <20091024023530.GC5404@dan.olp.net> On 23/10/09?17:43?-0500, Justin Shore wrote: >> It does block incoming SMTP traffic on that well known port. > > Then the customer should have bought a class of service that permits > servers. That justification is a slippery slope. At what point do you draw the line on what constitutes business use? Is running a web server business use? A mail server? What about a server which participates in a peer to peer network? VPN? I certainly think you're within your right as a network operator to determine what is business use. I don't happen to feel that running a protocol server in and of itself meets that definition. >> Would you consider restricting a customer's outgoing port 25 traffic to a >> specific mail server a step over the net neutrality line? > > I do this all the time. For example I don't let my customers send or > receive mail (or any traffic for that matter) from prefixes originating > from AS32311 (Colorado spammer Scott Richter). Now if I was blocking > mail to dnc.org, gop.com, greenpeace.org, etc or restricting Vonage to > .05% of my bandwidth then yeah that would violate net neutrality > principles. The difference is one stifles speech and is > anti-competitive. The other mitigates a network security and stability > risk. I think I worded my question a bit wrong. I meant to hypothetically propose a common scenario: You only allow your customers to connect to your SMTP server, and if they attempt to connect to *any* other SMTP server, they are blocked or redirected to your SMTP server. -- Dan White From owen at delong.com Fri Oct 23 21:54:28 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Oct 2009 19:54:28 -0700 Subject: ISP port blocking practice In-Reply-To: <4AE23194.3010501@justinshore.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> <4AE23194.3010501@justinshore.com> Message-ID: <614BF03D-27BD-482B-A680-BFB1383EA44E@delong.com> On Oct 23, 2009, at 3:43 PM, Justin Shore wrote: > Dan White wrote: >> On 23/10/09 17:58 -0400, James R. Cutler wrote: >>> Blocking the well known port 25 does not block sending of mail. Or >>> the >>> message content. >> It does block incoming SMTP traffic on that well known port. > > Then the customer should have bought a class of service that permits > servers. > Then you shouldn't be marketing what the customer bought as "Internet Access". >>> I think the relevant neutrality principle is that traffic is not >>> blocked >>> by content. >> My personal definition doesn't quite gel with that. You're deciding >> for the >> customer how they can use their connection, before you have any >> evidence of >> nefarious activity. > > They decided for themselves when they bought a residential > connection instead of a business circuit. Just because someone > bought themselves a Camry doesn't mean that Toyota is deciding for > them that they can't haul 1000lbs of concrete with it. The customer > did when they decided to buy a car and not a pickup. > Toyota does not market the Camry as a load hauling truck. If you are marketing your service as "Residential access to the part of the internet that we think is appropriate for a residence", then, I suppose that's fine. If you're calling it "Internet Access", then, you're claiming to sell a truck when you are delivering a Camry. It's a very different comparison. >> Would you consider restricting a customer's outgoing port 25 >> traffic to a >> specific mail server a step over the net neutrality line? > > I do this all the time. For example I don't let my customers send > or receive mail (or any traffic for that matter) from prefixes > originating from AS32311 (Colorado spammer Scott Richter). Now if I > was blocking mail to dnc.org, gop.com, greenpeace.org, etc or > restricting Vonage to .05% of my bandwidth then yeah that would > violate net neutrality principles. The difference is one stifles > speech and is anti-competitive. The other mitigates a network > security and stability risk. > I actually admit that I don't have a problem with you blocking traffic entering your peering connections from a known SPAM-AS. That is, as you state, a network security issue. OTOH, filtering what I, as a customer, send/receive at my end without my consent is a different issue. > I see this same argument on Slashdot all too often. It's usually > bundled with an argument against providers doing any sort of traffic > aggregation ("if I buy 1.5Mbps then it should be a dedicated pipe > straight to the Internet!") Unfortunately that's simply not > reality. You can either live with a small level of controls on your > traffic for the sake of stability and security or you can have wide- > open ISPs with no security prohibitions whatsoever. The support > costs for the ISPs go through the roof and of course that gets > passed onto the customer. Your 5 9s SLA gets replaced with "use it > while you can before it goes down again". Everyone pays a penalty > for having a digital Wild West. Not to start another thread on a > completely OT topic but the same concept can be applied to other > things like health care. Either everyone can pay a little bit for > all to have good service or many average consumers can pay lots to > make up the losses for those that can't pay at all. > Yeah, I don't buy the aggregation issue. That's absurd (Of course you can stat mux the traffic, that's what makes packet switched networks cost effective and gives us that great residential pricing) I don't buy the argument that you have to filter your customers to keep your support costs down. I've worked for a number of ISPs that don't filter their customers' traffic and don't have astronomical support costs or even heavy support call volume. We're not dumb enough to push a 5 9s SLA at residential prices, but, I'd say we're probably closer to 4 9s than 3. Owen From scott at doc.net.au Fri Oct 23 21:56:28 2009 From: scott at doc.net.au (Scott Howard) Date: Fri, 23 Oct 2009 19:56:28 -0700 Subject: Slashdotted - Peering Disputes Migrate To IPv6 Message-ID: http://tech.slashdot.org/story/09/10/23/1715235/Peering-Disputes-Migrate-To-IPv6 I wouldn't bother with the comments unless you really need to know how the analogy between IP peering and two gay guys ends up... (hey, it's Slashdot, what did you expect?) Scott From owen at delong.com Fri Oct 23 21:46:34 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Oct 2009 19:46:34 -0700 Subject: ISP port blocking practice In-Reply-To: <4AE21DDB.8050204@bestline.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> Message-ID: Yes. Owen On Oct 23, 2009, at 2:19 PM, Lee Riemer wrote: > Isn't blocking any port against the idea of Net Neutrality? > > Justin Shore wrote: >> Owen DeLong wrote: >>> Blocking ports that the end user has not asked for is bad. >> >> I was going to ask for a clarification to make sure I read your >> statement correctly but then again it's short enough I really don't >> see any room to misinterpret it. Do you seriously think that a >> typical residential user has the required level of knowledge to >> call their SP and ask for them to block tcp/25, tcp & udp/1433 and >> 1434, and a whole list of common open proxy ports? While they're >> at it they might ask the SP to block the C&C ports for Bobax and >> Kraken. I'm sure all residential users know that they use ports >> 447 and 13789. If so then send me some of your users. You must be >> serving users around the MIT campus. >> >>> Doing it and refusing to unblock is worse. >> >> How you you propose we pull a customer's dynamically-assigned IP >> out of a DHCP pool so we can treat it differently? Not all SPs use >> customer-facing AUTH. I can think of none that do for CATV though >> I'm sure someone will now point an oddball SP that I've never heard >> of before. >> >>> Some ISPs have the even worse practice of blocking 587 and a few >>> even >>> go to the horrible length to block 465. >> >> I would call that a very bad practice. I haven't personally seen a >> mis-configured MTA listening on the MSP port so I don't think they >> can make he claim that the MSP port is a common security risk. I >> would call tcp/587 a very safe port to have traverse my network. I >> think those ISPs are either demonstrating willful ignorance or >> marketing malice. >> >>> A few hotel gateways I have encountered are dumb enough to think >>> they can block TCP/53 >>> which is always fun. >> >> The hotel I stayed in 2 weeks ago that housed a GK class I took had >> just such a proxy. It screwed up DNS but even worse it completely >> hosed anything trying to tunnel over HTTP. OCS was dead in the >> water. My RPC-over-HTTP Outlook client couldn't work either. >> Fortunately they didn't mess with IPSec VPN or SSH. Either way it >> didn't matter much since the network was unusable (12 visible APs >> from room, all on overlapping 802.11b/g channels). The average >> throughput was .02Mbps. >> >>> Lovely for you, but, not particularly helpful to your customers >>> who may actually want to use some of those services. >> >> I take a hard line on this. I will not let the technical ignorance >> of the average residential user harm my other customers. There is >> absolutely no excuse for using Netbios or MS-SQL over the Internet >> outside of an encrypted tunnel. Any user smart enough to use a >> proxy is smart enough to pick a non-default port. Any residential >> user running a proxy server locally is in violation of our AUP >> anyway and will get warned and then terminated. My filtering helps >> 99.99% of my userbase. The .001% that find this basic security >> filter intolerable can speak with their wallets. They can find >> themselves another provider if they want to use those ports or pay >> for a business circuit where we filter very little on the >> assumption they as a business have the technical competence to >> handle basic security on their own. (The actual percentage of >> users that have raised concerns in the past 3 years is .0008%. I >> spoke with each of them and none decided to leave our service.) >> >> We've been down the road of no customer-facing ingress ACLs. We've >> fought the battles of getting large swaths of IPs blacklisted >> because of a few users' technical incompetence. We've had large >> portions of our network null-routed in large SPs. Then we got our >> act together and stopped acting like those ISPs who we all love to >> bitch about, that do not manage their customer traffic, and are >> poor netizens of this shared resource we call the Internet. Our >> problems have all but gone away. Our residential and business users >> no longer call in on a daily basis to report blacklisting >> problems. We no longer have reachability issues with networks that >> got fed up with the abuse coming from our compromised users and >> null-routed us. I stand by our results as proof that what we're >> doing is right. Our customers seem to agree and that's what matters. >> >> Justin >> >> >> From perry at coders.net Fri Oct 23 22:05:13 2009 From: perry at coders.net (Perry Lorier) Date: Sat, 24 Oct 2009 16:05:13 +1300 Subject: IPv6 Deployment for the LAN ... anycast In-Reply-To: <71bfd60c0910230545s1818f270kf3e64890342b53db@mail.gmail.com> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <20091021235532.GB25829@vacation.karoshi.com.> <2203F7F4-1B9C-425A-BD38-1A2FCCC3501A@muada.com> <20091022102748.GA32008@vacation.karoshi.com.> <4AE0408C.9080303@coders.net> <992013212-1256214762-cardhu_decombobulator_blackberry.rim.net-1426959583-@bda575.bisx.prod.on.blackberry> <4AE0F223.3050000@coders.net> <3960DB5B-C59E-49D2-8276-04802B59D101@delong.com> <007a01ca539a$ad1935e0$074ba1a0$@com> <4AE1A0BD.8020301@coders.net> <71bfd60c0910230545s1818f270kf3e64890342b53db@mail.gmail.com> Message-ID: <4AE26EE9.9070507@coders.net> >> I think for very small/small networks anycast requires a lot of overhead >> and understanding. If your big enough to do anycast and/or loadbalancing >> it's not hard for you to put all three addresses onto one device. >> >> > > Anycast isn't really hard - same address, multiple places, routers see what > appear to be multiple routes to same destination, they choose the least > expensive. Only tricky part (for stateless things) is ensuring the route > announcement is implicitly tied to service availability on that device ... > > I'm thinking for places like home users and the like which don't really run an IGP, can't correctly identify a router, and when you say "anycast" think that you might be talking about a new form of fishing. >> There are some protocols that anycasting doesn't work well for, they may >> require multiple instances. >> > > > Fair enough; could also standardize something like FD00::, > FD00::1:, and FD00::2: ... is three addresses > enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses > ... ) > > 3 seems to me to be plenty for most cases. For some things like NTP you might want to have 4 or more. > OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - > reserving FD00::/96) covers us to port 9999 based on automatically using > port numbers (or using automatically registered port numbers, see below). > > Maybe FD00::FFFF:xxxx/112 as a block within the above range to be used for > manual assignment of automatic service (potentially anycast) addresses. > > Seems sane to me. > In my humble opinion I'd have them registered, linking them to port numbers > >> means that it's easier on the poor admins brain at 3am while diagnosing >> faults, but may cause various hassles in the future (see above). >> >> > > OK, so register them - but sign up some well-known ones at very comfortable > addresses, like DNS at 53 :). > (Or 35 if you prefer hex-conversion ...) > > And I am sure some would be concerned about hosts performing any sort of > automatic service discovery anything, but this atleast has the advantage > over multicast in that it doesn't require multicast routing or group > membership / state maintenance, only delivers packets to the nearest (not > all) instances, etc. > > Yup, and it makes a sane default, if you want to override with DHCP, or some funky RA option, or manual configuration or whatever, then this gets out of your way and you don't have to care. It doesn't involve any code changes on hosts *or* routers to work today. From mysidia at gmail.com Fri Oct 23 22:36:18 2009 From: mysidia at gmail.com (James Hess) Date: Fri, 23 Oct 2009 22:36:18 -0500 Subject: ISP port blocking practice In-Reply-To: <4AE23194.3010501@justinshore.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> <4AE23194.3010501@justinshore.com> Message-ID: <6eb799ab0910232036l1a93f794w197472bca4cb97a2@mail.gmail.com> On Fri, Oct 23, 2009 at 5:43 PM, Justin Shore wrote: >[...] ?Just because someone bought themselves a >Camry doesn't mean that Toyota is deciding for them that they can't haul > 1000lbs of concrete with it. [...] Server does not necessarily equal business. A server that handles a few personal mailboxes for a residential user is not 1000lbs of concrete. Offhand, I can think of a lot of uses for various types of servers at a residence that don't require special business features, and are generallly low-traffic. Some people might be a little upset if they brought their brand new leased Camry home, to find their particular dealer had made an ad-hoc decision to weld the trunk shut, and didn't tell them about it directly and immediately, when advertising the vehicle. You want to haul a few groceries home? Shoulda asked for a "business" camry. Nevermind that the manufacturer has no separate product for that, it was a dealer's arbitrary decision to block that particular "port", anticipating customers would otherwise try to do evil things with it (like try to haul concrete). Anyways... like it or not.. blocking of outbound/inbound 25 may be common. But how common was the original question.. not 'is it a good idea?' or not. I would suggest that blocking the destination port 25, outgoing traffic from the end-user's point of view is the more preferred choice, it is more efficient, in that the block is closer to the source, and there are fewer wasted bits of traffic. -- -J From ops.lists at gmail.com Sat Oct 24 02:00:39 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 24 Oct 2009 00:00:39 -0700 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN Message-ID: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 Some quotes from the article - Internet registry RIPE NCC turned a blind eye to cybercrime, and Russian police corruption helped the perpetrators get away with it, according to the UK Serious Organised Crime Agency [...] "RIPE was being paid by RBN for that service, for its IP allocation," he said. "Essentially what you have - and I make no apologies for saying this is - if you were going to interpret this very harshly RIPE as the IP allocation body was receiving criminal funds and therefore RIPE was involved in money laundering offences," said Auld. [...] "All we could get there was a disruption, we weren't able to get a prosecution in Russia," admitted Auld. "Our biggest concern is where did RBN go? Our information suggests that RBN is back in business but now pursuing a slightly different business model which is bad news." [...] "Where you have got LIRs (Local Internet Registries) set up to run a criminal business- that is criminal actvity being taken by the regional internet registries themselves. "So what we are trying to do is work with them to make internet governance a somewhat less permissive environment for criminals and make it more about protecting consumers and individuals," added Auld. RBN looked legitimate, says RIPE NCC In response to the comments that it could be accused of being involved in criminal activity, Paul Rendek, head of external relations and communications at RIPE NCC said that the organisation has very strict guidelines for dealing with LIRs. "The RBN was accepted as an LIR based on our checklists," he said." Our checklists include the provision of proof that a prospective LIR has the necessary legal documentation, which proves that a business is bona fide." etc From jeffrey.lyon at blacklotus.net Sat Oct 24 02:18:23 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 24 Oct 2009 03:18:23 -0400 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> Message-ID: <16720fe00910240018t428a432cw4780747e3aaeceb2@mail.gmail.com> Since we're on the subject, here is where RBN went: inetnum: 91.202.60.0 - 91.202.63.255 netname: AKRINO-NET descr: Akrino Inc country: VG org: ORG-AI38-RIPE admin-c: IVM27-RIPE tech-c: IVM27-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: MNT-AKRINO mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: MNT-AKRINO mnt-domains: MNT-AKRINO source: RIPE # Filtered organisation: ORG-AI38-RIPE org-name: Akrino Inc org-type: OTHER address: Akrino Inc. address: P.O.Box 146 Trident Chambers address: Road Town, Tortola address: BVI e-mail: noc.akrino at gmail.com mnt-ref: MNT-AKRINO mnt-by: MNT-AKRINO source: RIPE # Filtered person: Igoren V Murzak address: Akrino Inc address: P.O.Box 146 Trident Chambers address: Road Town, Tortola address: BVI phone: +1 914 5952753 e-mail: noc.akrino at gmail.com nic-hdl: IVM27-RIPE mnt-by: MNT-AKRINO source: RIPE # Filtered % Information related to '91.202.60.0/22AS44571' route: 91.202.60.0/22 descr: AKRINO BLOCK origin: AS44571 mnt-by: MNT-AKRINO source: RIPE # Filtered On Sat, Oct 24, 2009 at 3:00 AM, Suresh Ramasubramanian wrote: > http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 > > Some quotes from the article - > > Internet registry RIPE NCC turned a blind eye to cybercrime, and Russian police > corruption helped the perpetrators get away with it, according to the UK > Serious Organised Crime Agency > > [...] > > "RIPE was being paid by RBN for that service, for its IP allocation," he said. > "Essentially what you have - and I make no apologies for saying this is - if > you were going to interpret this very harshly RIPE as the IP allocation body > was receiving criminal funds and therefore RIPE was involved in money > laundering offences," said Auld. > > [...] > > "All we could get there was a disruption, we weren't able to get a prosecution > in Russia," admitted Auld. "Our biggest concern is where did RBN go? Our > information suggests that RBN is back in business but now pursuing a slightly > different business model which is bad news." > > [...] > > "Where you have got LIRs (Local Internet Registries) set up to run a criminal > business- that is criminal actvity being taken by the regional internet > registries themselves. "So what we are trying to do is work with them to make > internet governance a somewhat less permissive environment for criminals and > make it more about protecting consumers and individuals," added Auld. > RBN looked legitimate, says RIPE NCC > > In response to the comments that it could be accused of being involved in > criminal activity, Paul Rendek, head of external relations and communications > at RIPE NCC said that the organisation has very strict guidelines for dealing > with LIRs. > > "The RBN was accepted as an LIR based on our checklists," he said." Our > checklists include the provision of proof that a prospective LIR has the > necessary legal documentation, which proves that a business is bona fide." > > etc > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From bbillon-ml at splio.fr Sat Oct 24 02:20:35 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Sat, 24 Oct 2009 09:20:35 +0200 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> Message-ID: <4AE2AAC3.2050301@splio.fr> Accusing RIPE of complicity is in my opinion abusive. So when a RBN member buys a burger at MacDonald's, should we consider MacDo accepts money from RBN while helping them to run their "business" as they feed the criminal member? From jeffrey.lyon at blacklotus.net Sat Oct 24 02:24:32 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 24 Oct 2009 03:24:32 -0400 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <4AE2AAC3.2050301@splio.fr> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <4AE2AAC3.2050301@splio.fr> Message-ID: <16720fe00910240024m27c74a90h9c01ff0948213b24@mail.gmail.com> Indeed. If they bought fries and a drink that's two counts. Jeff On Sat, Oct 24, 2009 at 3:20 AM, Benjamin Billon wrote: > Accusing RIPE of complicity is in my opinion abusive. So when a RBN member > buys a burger at MacDonald's, should we consider MacDo accepts money from > RBN while helping them to run their "business" as they feed the criminal > member? > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From bbillon-ml at splio.fr Sat Oct 24 02:29:22 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Sat, 24 Oct 2009 09:29:22 +0200 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <16720fe00910240024m27c74a90h9c01ff0948213b24@mail.gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <4AE2AAC3.2050301@splio.fr> <16720fe00910240024m27c74a90h9c01ff0948213b24@mail.gmail.com> Message-ID: <4AE2ACD2.50405@splio.fr> That's what I thought. I still see the author's point =) From pbosworth at gmail.com Sat Oct 24 03:05:59 2009 From: pbosworth at gmail.com (Paul Bosworth) Date: Sat, 24 Oct 2009 03:05:59 -0500 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <25b132e90910240101xe2ddbe0g40a361b4ba191d06@mail.gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <25b132e90910240101xe2ddbe0g40a361b4ba191d06@mail.gmail.com> Message-ID: <25b132e90910240105k3641905fwfd234e4ab37e1b37@mail.gmail.com> I think the larger point is that ripe turned a blind eye to an internationally recognized criminal network. On Oct 24, 2009 2:01 AM, "Suresh Ramasubramanian" wrote: http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 Some quotes from the article - Internet registry RIPE NCC turned a blind eye to cybercrime, and Russian police corruption helped the perpetrators get away with it, according to the UK Serious Organised Crime Agency [...] "RIPE was being paid by RBN for that service, for its IP allocation," he said. "Essentially what you have - and I make no apologies for saying this is - if you were going to interpret this very harshly RIPE as the IP allocation body was receiving criminal funds and therefore RIPE was involved in money laundering offences," said Auld. [...] "All we could get there was a disruption, we weren't able to get a prosecution in Russia," admitted Auld. "Our biggest concern is where did RBN go? Our information suggests that RBN is back in business but now pursuing a slightly different business model which is bad news." [...] "Where you have got LIRs (Local Internet Registries) set up to run a criminal business- that is criminal actvity being taken by the regional internet registries themselves. "So what we are trying to do is work with them to make internet governance a somewhat less permissive environment for criminals and make it more about protecting consumers and individuals," added Auld. RBN looked legitimate, says RIPE NCC In response to the comments that it could be accused of being involved in criminal activity, Paul Rendek, head of external relations and communications at RIPE NCC said that the organisation has very strict guidelines for dealing with LIRs. "The RBN was accepted as an LIR based on our checklists," he said." Our checklists include the provision of proof that a prospective LIR has the necessary legal documentation, which proves that a business is bona fide." etc From Paul.Martin at viatel.com Sat Oct 24 03:23:16 2009 From: Paul.Martin at viatel.com (Martin, Paul) Date: Sat, 24 Oct 2009 09:23:16 +0100 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <16720fe00910240018t428a432cw4780747e3aaeceb2@mail.gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <16720fe00910240018t428a432cw4780747e3aaeceb2@mail.gmail.com> Message-ID: <6E91D15697439543A9636FCA11BDA1C511235195@eghexch01.viatel.local> So considering they're widely regarded as a criminal network hosting the more dodgy/dangerous stuff on the net, surely we could 'protect' our customers by blocking the 91.202.60.0/22 range? Consider that can of worms opened :o) Paul -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: 24 October 2009 08:18 To: Suresh Ramasubramanian Cc: nanog at nanog.org Subject: Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN Since we're on the subject, here is where RBN went: inetnum: 91.202.60.0 - 91.202.63.255 netname: AKRINO-NET descr: Akrino Inc country: VG org: ORG-AI38-RIPE admin-c: IVM27-RIPE tech-c: IVM27-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: MNT-AKRINO mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: MNT-AKRINO mnt-domains: MNT-AKRINO source: RIPE # Filtered organisation: ORG-AI38-RIPE org-name: Akrino Inc org-type: OTHER address: Akrino Inc. address: P.O.Box 146 Trident Chambers address: Road Town, Tortola address: BVI e-mail: noc.akrino at gmail.com mnt-ref: MNT-AKRINO mnt-by: MNT-AKRINO source: RIPE # Filtered person: Igoren V Murzak address: Akrino Inc address: P.O.Box 146 Trident Chambers address: Road Town, Tortola address: BVI phone: +1 914 5952753 e-mail: noc.akrino at gmail.com nic-hdl: IVM27-RIPE mnt-by: MNT-AKRINO source: RIPE # Filtered % Information related to '91.202.60.0/22AS44571' route: 91.202.60.0/22 descr: AKRINO BLOCK origin: AS44571 mnt-by: MNT-AKRINO source: RIPE # Filtered On Sat, Oct 24, 2009 at 3:00 AM, Suresh Ramasubramanian wrote: > http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-a ccused-of-aiding-cybercrime-2165 > > Some quotes from the article - > > Internet registry RIPE NCC turned a blind eye to cybercrime, and Russian police > corruption helped the perpetrators get away with it, according to the UK > Serious Organised Crime Agency > > [...] > > "RIPE was being paid by RBN for that service, for its IP allocation," he said. > "Essentially what you have - and I make no apologies for saying this is - if > you were going to interpret this very harshly RIPE as the IP allocation body > was receiving criminal funds and therefore RIPE was involved in money > laundering offences," said Auld. > > [...] > > "All we could get there was a disruption, we weren't able to get a prosecution > in Russia," admitted Auld. "Our biggest concern is where did RBN go? Our > information suggests that RBN is back in business but now pursuing a slightly > different business model which is bad news." > > [...] > > "Where you have got LIRs (Local Internet Registries) set up to run a criminal > business- that is criminal actvity being taken by the regional internet > registries themselves. "So what we are trying to do is work with them to make > internet governance a somewhat less permissive environment for criminals and > make it more about protecting consumers and individuals," added Auld. > RBN looked legitimate, says RIPE NCC > > In response to the comments that it could be accused of being involved in > criminal activity, Paul Rendek, head of external relations and communications > at RIPE NCC said that the organisation has very strict guidelines for dealing > with LIRs. > > "The RBN was accepted as an LIR based on our checklists," he said." Our > checklists include the provision of proof that a prospective LIR has the > necessary legal documentation, which proves that a business is bona fide." > > etc > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." For more information about the Viatel Group, please visit www.viatel.com VTL (UK) Limited Registered in England and Wales Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR Company Registration No: 04287100 VAT Registration Number: 781 4991 88 THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this e-mail is prohibited, and you should delete this e-mail from your system. This message has been scanned for viruses and spam by Viatel MailControl - www.viatel.com From a.harrowell at gmail.com Sat Oct 24 04:11:33 2009 From: a.harrowell at gmail.com (a.harrowell at gmail.com) Date: Sat, 24 Oct 2009 10:11:33 +0100 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN Message-ID: I'd like to apologise in advance for SOCA. Frankly, I am surprised that they are even aware of RIPE or its role in life. They have done so poorly since subsuming the old National Hi-Tech Crime Unit that the other police forces want NHTCU back. It ought to be superfluous to point out that the only effective action taken against RBN was by the Internet community in getting all their upstreams to null route them. As is blindingly obvious, SOCA would never have been granted a warrant by the Russians. Pathetic to take it out on RIPE. -original message- Subject: RE: Interesting Point of view - Russian police and RIPE accused of aiding RBN From: "Martin, Paul" Date: 24/10/2009 9:23 am So considering they're widely regarded as a criminal network hosting the more dodgy/dangerous stuff on the net, surely we could 'protect' our customers by blocking the 91.202.60.0/22 range? Consider that can of worms opened :o) Paul -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: 24 October 2009 08:18 To: Suresh Ramasubramanian Cc: nanog at nanog.org Subject: Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN Since we're on the subject, here is where RBN went: inetnum: 91.202.60.0 - 91.202.63.255 netname: AKRINO-NET descr: Akrino Inc country: VG org: ORG-AI38-RIPE admin-c: IVM27-RIPE tech-c: IVM27-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: MNT-AKRINO mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: MNT-AKRINO mnt-domains: MNT-AKRINO source: RIPE # Filtered organisation: ORG-AI38-RIPE org-name: Akrino Inc org-type: OTHER address: Akrino Inc. address: P.O.Box 146 Trident Chambers address: Road Town, Tortola address: BVI e-mail: noc.akrino at gmail.com mnt-ref: MNT-AKRINO mnt-by: MNT-AKRINO source: RIPE # Filtered person: Igoren V Murzak address: Akrino Inc address: P.O.Box 146 Trident Chambers address: Road Town, Tortola address: BVI phone: +1 914 5952753 e-mail: noc.akrino at gmail.com nic-hdl: IVM27-RIPE mnt-by: MNT-AKRINO source: RIPE # Filtered % Information related to '91.202.60.0/22AS44571' route: 91.202.60.0/22 descr: AKRINO BLOCK origin: AS44571 mnt-by: MNT-AKRINO source: RIPE # Filtered On Sat, Oct 24, 2009 at 3:00 AM, Suresh Ramasubramanian wrote: > http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-a ccused-of-aiding-cybercrime-2165 > > Some quotes from the article - > > Internet registry RIPE NCC turned a blind eye to cybercrime, and Russian police > corruption helped the perpetrators get away with it, according to the UK > Serious Organised Crime Agency > > [...] > > "RIPE was being paid by RBN for that service, for its IP allocation," he said. > "Essentially what you have - and I make no apologies for saying this is - if > you were going to interpret this very harshly RIPE as the IP allocation body > was receiving criminal funds and therefore RIPE was involved in money > laundering offences," said Auld. > > [...] > > "All we could get there was a disruption, we weren't able to get a prosecution > in Russia," admitted Auld. "Our biggest concern is where did RBN go? Our > information suggests that RBN is back in business but now pursuing a slightly > different business model which is bad news." > > [...] > > "Where you have got LIRs (Local Internet Registries) set up to run a criminal > business- that is criminal actvity being taken by the regional internet > registries themselves. "So what we are trying to do is work with them to make > internet governance a somewhat less permissive environment for criminals and > make it more about protecting consumers and individuals," added Auld. > RBN looked legitimate, says RIPE NCC > > In response to the comments that it could be accused of being involved in > criminal activity, Paul Rendek, head of external relations and communications > at RIPE NCC said that the organisation has very strict guidelines for dealing > with LIRs. > > "The RBN was accepted as an LIR based on our checklists," he said." Our > checklists include the provision of proof that a prospective LIR has the > necessary legal documentation, which proves that a business is bona fide." > > etc > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." For more information about the Viatel Group, please visit www.viatel.com VTL (UK) Limited Registered in England and Wales Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR Company Registration No: 04287100 VAT Registration Number: 781 4991 88 THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this e-mail is prohibited, and you should delete this e-mail from your system. This message has been scanned for viruses and spam by Viatel MailControl - www.viatel.com From marcoh at marcoh.net Sat Oct 24 04:18:27 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sat, 24 Oct 2009 11:18:27 +0200 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> Message-ID: <7543076B-1E20-4CDD-BD13-D871F5C3FF2D@marcoh.net> On Oct 24, 2009, at 9:00 AM, Suresh Ramasubramanian wrote: > http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 With more on that: http://www.ripe.net/news/rbn.html "Press coverage this week portrayed the RIPE NCC as being involved with the criminal network provider Russian Business Network (RBN). Any connection with criminal activity, or with RBN itself, is completely unfounded. The press coverage arose from a speech given by the Serious Organised Crime Agency (SOCA) in the UK. SOCA has since contacted the RIPE NCC with an apology. The RIPE NCC will continue to work with SOCA and other bodies to ensure criminal investigations can be carried out in an efficient manner within established laws and guidelines." MarcoH From a.harrowell at gmail.com Sat Oct 24 04:27:28 2009 From: a.harrowell at gmail.com (a.harrowell at gmail.com) Date: Sat, 24 Oct 2009 10:27:28 +0100 Subject: ISP port blocking practice Message-ID: <4FxLTmHsMKRd.TVRTrj86@smtp.gmail.com> -original message- Subject: Re: ISP port blocking practice From: Owen DeLong Date: 24/10/2009 4:00 am Yes. Owen On Oct 23, 2009, at 2:19 PM, Lee Riemer wrote: > Isn't blocking any port against the idea of Net Neutrality? > Only if you take a legalistic view of it. Too much of the NN debate is about the futile search for an infallible legal argument with no corner cases. This is silly. Take an empirical, practical view instead. Obviously there is no objection to blocking spam going out; after all, the spam comes from machines that are no longer under the control of their owners, so the only free speech that is affected is that of the spammer, and hasn't that already been litigated? Free speech doesn't include the freedom to shout fire in a crowded theatre. Neither does it include the freedom to carry out a DDOS on the fire brigade control room. You aren't allowed to levy a toll on the roads and except your mates - roads are neutral. But that doesn't invalidate the speed limit or the obligation to drive on the left. > Justin Shore wrote: >> Owen DeLong wrote: >>> Blocking ports that the end user has not asked for is bad. >> >> I was going to ask for a clarification to make sure I read your >> statement correctly but then again it's short enough I really don't >> see any room to misinterpret it. Do you seriously think that a >> typical residential user has the required level of knowledge to >> call their SP and ask for them to block tcp/25, tcp & udp/1433 and >> 1434, and a whole list of common open proxy ports? While they're >> at it they might ask the SP to block the C&C ports for Bobax and >> Kraken. I'm sure all residential users know that they use ports >> 447 and 13789. If so then send me some of your users. You must be >> serving users around the MIT campus. >> >>> Doing it and refusing to unblock is worse. >> >> How you you propose we pull a customer's dynamically-assigned IP >> out of a DHCP pool so we can treat it differently? Not all SPs use >> customer-facing AUTH. I can think of none that do for CATV though >> I'm sure someone will now point an oddball SP that I've never heard >> of before. >> >>> Some ISPs have the even worse practice of blocking 587 and a few >>> even >>> go to the horrible length to block 465. >> >> I would call that a very bad practice. I haven't personally seen a >> mis-configured MTA listening on the MSP port so I don't think they >> can make he claim that the MSP port is a common security risk. I >> would call tcp/587 a very safe port to have traverse my network. I >> think those ISPs are either demonstrating willful ignorance or >> marketing malice. >> >>> A few hotel gateways I have encountered are dumb enough to think >>> they can block TCP/53 >>> which is always fun. >> >> The hotel I stayed in 2 weeks ago that housed a GK class I took had >> just such a proxy. It screwed up DNS but even worse it completely >> hosed anything trying to tunnel over HTTP. OCS was dead in the >> water. My RPC-over-HTTP Outlook client couldn't work either. >> Fortunately they didn't mess with IPSec VPN or SSH. Either way it >> didn't matter much since the network was unusable (12 visible APs >> from room, all on overlapping 802.11b/g channels). The average >> throughput was .02Mbps. >> >>> Lovely for you, but, not particularly helpful to your customers >>> who may actually want to use some of those services. >> >> I take a hard line on this. I will not let the technical ignorance >> of the average residential user harm my other customers. There is >> absolutely no excuse for using Netbios or MS-SQL over the Internet >> outside of an encrypted tunnel. Any user smart enough to use a >> proxy is smart enough to pick a non-default port. Any residential >> user running a proxy server locally is in violation of our AUP >> anyway and will get warned and then terminated. My filtering helps >> 99.99% of my userbase. The .001% that find this basic security >> filter intolerable can speak with their wallets. They can find >> themselves another provider if they want to use those ports or pay >> for a business circuit where we filter very little on the >> assumption they as a business have the technical competence to >> handle basic security on their own. (The actual percentage of >> users that have raised concerns in the past 3 years is .0008%. I >> spoke with each of them and none decided to leave our service.) >> >> We've been down the road of no customer-facing ingress ACLs. We've >> fought the battles of getting large swaths of IPs blacklisted >> because of a few users' technical incompetence. We've had large >> portions of our network null-routed in large SPs. Then we got our >> act together and stopped acting like those ISPs who we all love to >> bitch about, that do not manage their customer traffic, and are >> poor netizens of this shared resource we call the Internet. Our >> problems have all but gone away. Our residential and business users >> no longer call in on a daily basis to report blacklisting >> problems. We no longer have reachability issues with networks that >> got fed up with the abuse coming from our compromised users and >> null-routed us. I stand by our results as proof that what we're >> doing is right. Our customers seem to agree and that's what matters. >> >> Justin >> >> >> From fw at deneb.enyo.de Sat Oct 24 04:38:31 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 24 Oct 2009 11:38:31 +0200 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: (a. harrowell's message of "Sat, 24 Oct 2009 10:11:33 +0100") References: Message-ID: <87y6n1dtd4.fsf@mid.deneb.enyo.de> * a. harrowell: > It ought to be superfluous to point out that the only effective > action taken against RBN was by the Internet community in getting > all their upstreams to null route them. As is blindingly obvious, > SOCA would never have been granted a warrant by the Russians. Ugh, in reality, they needed a warrant from the Metropolitan Police (which could have been equally problematic). From jeffrey.lyon at blacklotus.net Sat Oct 24 04:44:56 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 24 Oct 2009 05:44:56 -0400 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <16720fe00910240242g2672ddc5k622ca86c61aa62e2@mail.gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <16720fe00910240018t428a432cw4780747e3aaeceb2@mail.gmail.com> <6E91D15697439543A9636FCA11BDA1C511235195@eghexch01.viatel.local> <16720fe00910240242g2672ddc5k622ca86c61aa62e2@mail.gmail.com> Message-ID: <16720fe00910240244m78c8bb13j49089c7b522aaab1@mail.gmail.com> We already filter this network but the move is largely symbolic. This needs to be done by eyeball networks, not just hosting networks. In filtering 91.202.60.0/22 we primarily keep our reverse proxies from serving up their "content" and keep them from offering proxies on our network. Its pretty rare that we will filter any network as a whole but in this case the need is pretty blatent. Jeff On Oct 24, 2009 4:25 AM, "Martin, Paul" wrote: So considering they're widely regarded as a criminal network hosting the more dodgy/dangerous stuff on the net, surely we could 'protect' our customers by blocking the 91.202.60.0/22 range? Consider that can of worms opened :o) Paul -----Original Message----- From: Jeffrey Lyon [mailto: jeffrey.lyon at blacklotus.net] Sent: 24 Octobe... For more information about the Viatel Group, please visit www.viatel.com VTL (UK) Limited Registered in England and Wales Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR Company Registration No: 04287100 VAT Registration Number: 781 4991 88 THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this e-mail is prohibited, and you should delete this e-mail from your system. This message has been scanned for viruses and spam by Viatel MailControl - www.viatel.com From jgreco at ns.sol.net Sat Oct 24 05:17:24 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 24 Oct 2009 05:17:24 -0500 (CDT) Subject: ISP port blocking practice In-Reply-To: from "Owen DeLong" at Oct 23, 2009 07:46:34 PM Message-ID: <200910241017.n9OAHOF8027711@aurora.sol.net> > > Isn't blocking any port against the idea of Net Neutrality? > > Yes. > > Owen No. The idea of net neutrality, in this context, is for service providers to avoid making arbitrary decisions about the services that a customer will be allowed. Blocking 25, or 137-139, etc., are common steps taken to promote the security of the network. This is not an arbitrary decision (and I am defining it this way; I will not play semantics about "arbitrary". Read along and figure out what I mean.) For 25, SMTP has proven to be a protocol that has adapted poorly to modern life, and a variety of issues have conspired that make it undesirable to allow random home PC's to use 25. Reasonable alternatives exist, such as using 587, or the ISP's mail server. A customer isn't being disallowed the use of SMTP to send mail (which WOULD be a problem). A customer may use any number of other mail servers to send mail. Not a serious issue, and not arbitrary... it's generally considered a good, or even best current, practice. Blocking VoIP from your network to Vonage, because you want your customers to buy your own VoIP service? That's a very clear problem. There's no justifiable reason that any viable broadband service provider would have for blocking VoIP. Yet there could be a reason to forbid VoIP; I can, for example, imagine some of the rural WISP setups where the loads caused on the infrastructure interfere with providing service. Similarly, it'd be ridiculous to expect an 802.11b based rural WISP to be able to support HD Netflix streaming, or dialup ISP's to be able to support fast downloading of movies. These are not arbitrary restrictions, but rather technological ones. When you buy a 56k dialup, you should expect you won't get infinite speed. When you buy WISP access on a shared 802.11b setup, you should expect that you're sharing that theoretical max 11Mbps with other subs. It gets murkier when you get into situations such as where your cableco has sold you a 15Mbps Internet connection, but proceeds to "traffic engineer" your activities down to a slower speed. There are real questions that should be addressed; for example, if you are paying extra for a "premium" service (as in when the default speed is 7Mbps and you've upgraded), should a customer expect that they will actually get substantially more capacity? How does the reliance on overcommit affect things? The ideal is to sell a high speed connection to someone who uses none of it, of course... but if you're selling lots of capacity, and betting that only a little will be used at a time, and you've guessed wrong, the big question is, is that tolerable, or is net neutrality going to force you to provide what you've sold? So, now, back to blocking... many service providers block 80, on the basis that they don't want customers running servers. This could very well be a net neutrality issue. It's probably not a security issue. It's a decision being made at a business level, in order to promote the purchase of "business class" services. It's an arbitrary decision about what a customer will be allowed to do. There's lots of interesting stuff to think about. Net neutrality isn't going to mean that we kill BCP38 and port 25 filtering. It is about service providers arbitrarily interfering with the service that they're providing. Customers should be given, to the maximum extent reasonably possible, Internet connectivity suitable for general purpose use. Where service providers start infringing on that, that's what should be addressed by network neutrality. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From ops.lists at gmail.com Sat Oct 24 07:36:36 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 24 Oct 2009 18:06:36 +0530 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <7543076B-1E20-4CDD-BD13-D871F5C3FF2D@marcoh.net> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <7543076B-1E20-4CDD-BD13-D871F5C3FF2D@marcoh.net> Message-ID: On Sat, Oct 24, 2009 at 2:48 PM, Marco Hogewoning wrote: > On Oct 24, 2009, at 9:00 AM, Suresh Ramasubramanian wrote: \>> http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 > > With more on that: > http://www.ripe.net/news/rbn.html I am glad this ugly situation has been resolved - and I do wish the resolution gets better coverage than this. suresh From william.allen.simpson at gmail.com Sat Oct 24 08:00:15 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 24 Oct 2009 09:00:15 -0400 Subject: DMCA takedowns of networks Message-ID: <4AE2FA5F.4090403@gmail.com> http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html Hurricane Electric obeyed the Chamber's letter and shut down the spoof site. But in the process, they shut down hundreds of other sites maintained by May First / People Link, the Yes Men's direct provider (Hurricane Electric is its "upstream" provider). What's going on? Since when are we required to take down an entire customer's net for one of their subscriber's so-called infringement? Heck, it takes years to agree around here to take down a peering to an obviously criminal enterprise network.... My first inclination would be to return the request (rejected), saying it was sent to the wrong provider. From bclark at spectraaccess.com Sat Oct 24 08:26:30 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Sat, 24 Oct 2009 09:26:30 -0400 Subject: DMCA takedowns of networks In-Reply-To: <4AE2FA5F.4090403@gmail.com> References: <4AE2FA5F.4090403@gmail.com> Message-ID: <4AE30086.7030807@spectraaccess.com> BS to say the least...first the US Chamber of Commerce is not a government organization. And even if there were what right does anyone have to tread on Freedom of Speech?!? Was there a court order? I'd really be interested in know what strong arm tactic they used with HE. William Allen Simpson wrote: > http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html > > > Hurricane Electric obeyed the Chamber's letter and shut down the spoof > site. But in the process, they shut down hundreds of other sites > maintained by May First / People Link, the Yes Men's direct provider > (Hurricane Electric is its "upstream" provider). > > What's going on? Since when are we required to take down an entire > customer's net for one of their subscriber's so-called infringement? > > Heck, it takes years to agree around here to take down a peering to an > obviously criminal enterprise network.... > > My first inclination would be to return the request (rejected), saying > it was sent to the wrong provider. > From jeffrey.lyon at blacklotus.net Sat Oct 24 08:28:43 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 24 Oct 2009 09:28:43 -0400 Subject: DMCA takedowns of networks In-Reply-To: <4AE2FA5F.4090403@gmail.com> References: <4AE2FA5F.4090403@gmail.com> Message-ID: <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> Outside of child pornography there is no content that I would ever consider censoring without a court order nor would I ever purchase transit from a company that engages in this type of behavior. Jeff On Oct 24, 2009 9:01 AM, "William Allen Simpson" < william.allen.simpson at gmail.com> wrote: http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html Hurricane Electric obeyed the Chamber's letter and shut down the spoof site. But in the process, they shut down hundreds of other sites maintained by May First / People Link, the Yes Men's direct provider (Hurricane Electric is its "upstream" provider). What's going on? Since when are we required to take down an entire customer's net for one of their subscriber's so-called infringement? Heck, it takes years to agree around here to take down a peering to an obviously criminal enterprise network.... My first inclination would be to return the request (rejected), saying it was sent to the wrong provider. From patrick at ianai.net Sat Oct 24 08:36:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 09:36:05 -0400 Subject: DMCA takedowns of networks In-Reply-To: <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> Message-ID: On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: > Outside of child pornography there is no content that I would ever > consider > censoring without a court order nor would I ever purchase transit > from a > company that engages in this type of behavior. A DMCA takedown order has the force of law. This does not mean you should take down an entire network with unrelated sites. Given He's history, I'm guessing it was a mistake. Not buying services from any network that has made a mistake would quickly leave you with exactly zero options for transit. -- TTFN, patrick > On Oct 24, 2009 9:01 AM, "William Allen Simpson" < > william.allen.simpson at gmail.com> wrote: > > http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html > > Hurricane Electric obeyed the Chamber's letter and shut down the spoof > site. But in the process, they shut down hundreds of other sites > maintained by May First / People Link, the Yes Men's direct provider > (Hurricane Electric is its "upstream" provider). > > What's going on? Since when are we required to take down an entire > customer's net for one of their subscriber's so-called infringement? > > Heck, it takes years to agree around here to take down a peering to an > obviously criminal enterprise network.... > > My first inclination would be to return the request (rejected), saying > it was sent to the wrong provider. > From patrick at ianai.net Sat Oct 24 08:39:40 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 09:39:40 -0400 Subject: DMCA takedowns of networks In-Reply-To: References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> Message-ID: <6835AC53-0BFF-459C-9AB7-DB45A5C79D0D@ianai.net> On Oct 24, 2009, at 9:36 AM, Patrick W. Gilmore wrote: > On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: > >> Outside of child pornography there is no content that I would ever >> consider >> censoring without a court order nor would I ever purchase transit >> from a >> company that engages in this type of behavior. P.S. Good to know you would keep spammers, DDoS'ers, hackers, etc. connected, even in the face of evidence provided by other ISPs, "... nor would I ever purchase transit from a company that engages in this type of behavior." -- TTFN, patrick > A DMCA takedown order has the force of law. > > This does not mean you should take down an entire network with > unrelated sites. Given He's history, I'm guessing it was a mistake. > > Not buying services from any network that has made a mistake would > quickly leave you with exactly zero options for transit. > > -- > TTFN, > patrick > > > >> On Oct 24, 2009 9:01 AM, "William Allen Simpson" < >> william.allen.simpson at gmail.com> wrote: >> >> http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html >> >> Hurricane Electric obeyed the Chamber's letter and shut down the >> spoof >> site. But in the process, they shut down hundreds of other sites >> maintained by May First / People Link, the Yes Men's direct provider >> (Hurricane Electric is its "upstream" provider). >> >> What's going on? Since when are we required to take down an entire >> customer's net for one of their subscriber's so-called infringement? >> >> Heck, it takes years to agree around here to take down a peering to >> an >> obviously criminal enterprise network.... >> >> My first inclination would be to return the request (rejected), >> saying >> it was sent to the wrong provider. >> > From patrick at ianai.net Sat Oct 24 08:54:47 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 09:54:47 -0400 Subject: Slashdotted - Peering Disputes Migrate To IPv6 In-Reply-To: References: Message-ID: <78AF334A-EE13-46BF-8E07-C70848F954E5@ianai.net> On Oct 23, 2009, at 10:56 PM, Scott Howard wrote: > http://tech.slashdot.org/story/09/10/23/1715235/Peering-Disputes-Migrate-To-IPv6 > > I wouldn't bother with the comments unless you really need to know > how the > analogy between IP peering and two gay guys ends up... (hey, it's > Slashdot, > what did you expect?) When I read that, I thought about the GPF, Guy & I winning the Newly Peered Game, and ... well, it went downhill from there. -- TTFN, patrick From daniel.karrenberg at ripe.net Sat Oct 24 08:59:49 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 24 Oct 2009 15:59:49 +0200 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <25b132e90910240105k3641905fwfd234e4ab37e1b37@mail.gmail.com> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <25b132e90910240101xe2ddbe0g40a361b4ba191d06@mail.gmail.com> <25b132e90910240105k3641905fwfd234e4ab37e1b37@mail.gmail.com> Message-ID: <20091024135949.GX7093@guest-57.ripe.net> On 24.10 03:05, Paul Bosworth wrote: > I think the larger point is that ripe turned a blind eye to an > internationally recognized criminal network. That may be a point but not a convincing one. Imagine the outcry on this list if ARIN were to deny some organisation address space or ASNs just because they are "internationally recognised" criminals. Wouldn't we demand a little more due process? Especially since the alternatives are not as easy as walking to the next fastfood joint. The RIPE NCC operates in a region where whole sovereign states call each other criminals or worse on a daily basis. The only tenable position for each RIR is to strictly apply the policies developed in its bottom-up self-regulatory process. Doing anything else would require intervention via a proper legal process, e.g. a *judge* with appropriate jurisdiction telling the RIR that its actions are unlawful. Frustration is a bad advisor when trying to stop crime, unrelenting application of due process is the only way ... frustrating as it may be. Daniel Karrenberg Chief Scientist RIPE NCC Speaking only for himself as is customary here. PS: This is old news, compare http://www.h-online.com/security/news/item/Security-expert-calls-for-IP-address-ranges-of-criminal-providers-to-be-sent-direct-to-the-police-737905.html And see the press release that Marco pointed out. Daniel From ralph.brandt at pateam.com Sat Oct 24 09:20:21 2009 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Sat, 24 Oct 2009 10:20:21 -0400 Subject: DMCA takedowns of networks In-Reply-To: References: <4AE2FA5F.4090403@gmail.com><16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> Message-ID: <51C66083768C2949A7EB14910C78B017A5E351@embgsr24.pateam.com> HE certainly was right in shutting down that site. It had copyright infringement. That they took down other sites is reprehensible unless they lacked the technical capability to do otherwise. (The question then arises, should they be in business if that is the case?) I am a strong advocate of free speech and have a track record for both supporting and exercising it. But the dissenters must be responsible. Copying a site - copyright infringement - is never free speech, it is illegal activity. I really don't even care if there is a legal copyright notice is its morally wrong and it puts the dissenter in a category that is probably worse than the other party. That someone would do that tells me that they are not responsible in dissent and their message is horse crap. It is flashy lacking in thought and content. Why would I consider them a valid source of information? I think the present administration is illegally there and should be removed speedily by impeachment. But I would never steal copyright material to dissent. I have never used his picture because I am not aware of a free use picture. Ralph Brandt www.triond.com/users/Ralph+Brandt -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Saturday, October 24, 2009 9:36 AM To: North American Network Operators Group Subject: Re: DMCA takedowns of networks On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: > Outside of child pornography there is no content that I would ever > consider > censoring without a court order nor would I ever purchase transit > from a > company that engages in this type of behavior. A DMCA takedown order has the force of law. This does not mean you should take down an entire network with unrelated sites. Given He's history, I'm guessing it was a mistake. Not buying services from any network that has made a mistake would quickly leave you with exactly zero options for transit. -- TTFN, patrick > On Oct 24, 2009 9:01 AM, "William Allen Simpson" < > william.allen.simpson at gmail.com> wrote: > > http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332 087.html > > Hurricane Electric obeyed the Chamber's letter and shut down the spoof > site. But in the process, they shut down hundreds of other sites > maintained by May First / People Link, the Yes Men's direct provider > (Hurricane Electric is its "upstream" provider). > > What's going on? Since when are we required to take down an entire > customer's net for one of their subscriber's so-called infringement? > > Heck, it takes years to agree around here to take down a peering to an > obviously criminal enterprise network.... > > My first inclination would be to return the request (rejected), saying > it was sent to the wrong provider. > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jlewis at lewis.org Sat Oct 24 09:39:33 2009 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 24 Oct 2009 10:39:33 -0400 (EDT) Subject: DMCA takedowns of networks In-Reply-To: <51C66083768C2949A7EB14910C78B017A5E351@embgsr24.pateam.com> References: <4AE2FA5F.4090403@gmail.com><16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <51C66083768C2949A7EB14910C78B017A5E351@embgsr24.pateam.com> Message-ID: On Sat, 24 Oct 2009, Brandt, Ralph wrote: > HE certainly was right in shutting down that site. It had copyright > infringement. That they took down other sites is reprehensible unless > they lacked the technical capability to do otherwise. (The question > then arises, should they be in business if that is the case?) Not sure how much I believe of the article and its lack of detail and chopped quotes...but did HE really disconnect an entire downstream network over a DMCA notice, or did they null route a /32 that was used by a customer to host hundreds of virtual web sites? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ras at e-gerbil.net Sat Oct 24 09:53:30 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 24 Oct 2009 09:53:30 -0500 Subject: DMCA takedowns of networks In-Reply-To: References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> Message-ID: <20091024145330.GX51443@gerbil.cluepon.net> On Sat, Oct 24, 2009 at 09:36:05AM -0400, Patrick W. Gilmore wrote: > On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: > > >Outside of child pornography there is no content that I would ever > >consider > >censoring without a court order nor would I ever purchase transit > >from a > >company that engages in this type of behavior. > > A DMCA takedown order has the force of law. The DMCA defines a process by which copyright violations can be handled. One of the options in that process is to send a counter-notice to the takedown notice. http://chillingeffects.org/dmca512/faq.cgi#QID130 http://chillingeffects.org/dmca512/faq.cgi#QID132 To quote: > In order to ensure that copyright owners do not wrongly insist on the > removal of materials that actually do not infringe their copyrights, > the safe harbor provisions require service providers to notify the > subscribers if their materials have been removed and to provide them > with an opportunity to send a written notice to the service provider > stating that the material has been wrongly removed. [512(g)] If a > subscriber provides a proper "counter-notice" claiming that the > material does not infringe copyrights, the service provider must then > promptly notify the claiming party of the individual's objection. > [512(g)(2)] If the copyright owner does not bring a lawsuit in > district court within 14 days, the service provider is then required > to restore the material to its location on its network. [512(g)(2)(C)] This seems like a very obvious case of parody/fair use, so the proper response would be for the victim to send a counter-notice and then wait for the complainer to settle the issue in court. No doubt the lawsuit would never come, because they don't stand a chance in hell of actually winning, but sending letters is cheap and surprisingly effective against the uninformed. The reason you don't typically see these kinds of issues with providers blocking large amounts of content by taking out whole IPs of their downstreams is that it is cheap and easy to become your own service provider for the purposes of DMCA. If you are hosting any content yourself, you should really go to http://www.copyright.gov/onlinesp/ and file for a designated agent. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From mysidia at gmail.com Sat Oct 24 09:56:57 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 24 Oct 2009 09:56:57 -0500 Subject: DMCA takedowns of networks In-Reply-To: <4AE2FA5F.4090403@gmail.com> References: <4AE2FA5F.4090403@gmail.com> Message-ID: <6eb799ab0910240756u192c3ab5w8800aad604556982@mail.gmail.com> On Sat, Oct 24, 2009 at 8:00 AM, William Allen Simpson > What's going on? ?Since when are we required to take down an entire > customer's net for one of their subscriber's so-called infringement? Since people are afraid. Organizations may send DMCA letters, whether they are valid or not; the recipient may disconnect what the sender wants, and is unlikely to consider whether they really must do it or not. It's easier to do what the bully wants than be a guinea pig and have some risk of being sued, or other unforseen consequences. Note that the 512(a) safe harbor of the DMCA does not include a requirement of removing material when notified; only the 512(c) safe harbor includes that requirement, and it's for providers that actually store the material. - http://www.chillingeffects.org/dmca512/faq.cgi#QID472 US Title 17, Chapter 5, Sec 512, (c) http://www.copyright.gov/title17/92chap5.html#512 " (c) Information Residing on Systems or Networks at Direction of Users." ersus "(a) Transitory Digital Network Communications. ... A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider's transmitting, routing, or providing connections for, ...." It's a bit hard (impossible) to "expeditiously remove" material that your equipment isn't storing, but that a downstream network is storing. The DMCA doesn't say anything about severing connectivity to computers on a network. That's just what the wronged party wants, the collateral damage doesn't effect them. -- -J From patrick at ianai.net Sat Oct 24 10:06:29 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 11:06:29 -0400 Subject: DMCA takedowns of networks In-Reply-To: <20091024145330.GX51443@gerbil.cluepon.net> References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <20091024145330.GX51443@gerbil.cluepon.net> Message-ID: <022C646C-E04F-47EB-B59F-EA75F276266C@ianai.net> On Oct 24, 2009, at 10:53 AM, Richard A Steenbergen wrote: > On Sat, Oct 24, 2009 at 09:36:05AM -0400, Patrick W. Gilmore wrote: >> On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: >> >>> Outside of child pornography there is no content that I would ever >>> consider >>> censoring without a court order nor would I ever purchase transit >>> from a >>> company that engages in this type of behavior. >> >> A DMCA takedown order has the force of law. > > The DMCA defines a process by which copyright violations can be > handled. > One of the options in that process is to send a counter-notice to the > takedown notice. Laws frequently have multiple options for compliance. Doesn't mean you don't have to follow the law. > This seems like a very obvious case of parody/fair use, Possibly, but I do not blame a provider to not being willing to make that distinction. > so the proper > response would be for the victim to send a counter-notice and then > wait > for the complainer to settle the issue in court. See previous comment. The website owner, however, has that option. Let's just agree that there were multiple avenues open to lots of people here, that HE should not have taken down more than the site in question (if, in fact, that is what happened), and that the DCMA has silly parts. Doesn't mean you should "wait for a court order" though. -- TTFN, patrick From rbf+nanog at panix.com Sat Oct 24 10:20:51 2009 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 24 Oct 2009 10:20:51 -0500 Subject: DMCA takedowns of networks In-Reply-To: <022C646C-E04F-47EB-B59F-EA75F276266C@ianai.net> References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <20091024145330.GX51443@gerbil.cluepon.net> <022C646C-E04F-47EB-B59F-EA75F276266C@ianai.net> Message-ID: <20091024152051.GA3203@panix.com> On Sat, Oct 24, 2009 at 11:06:29AM -0400, Patrick W. Gilmore wrote: > On Oct 24, 2009, at 10:53 AM, Richard A Steenbergen wrote: >> On Sat, Oct 24, 2009 at 09:36:05AM -0400, Patrick W. Gilmore wrote: >>> On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: >>> >>>> Outside of child pornography there is no content that I would ever >>>> consider censoring without a court order nor would I ever purchase >>>> transit from a company that engages in this type of behavior. >>> >>> A DMCA takedown order has the force of law. It most certainly does not. >> The DMCA defines a process by which copyright violations can be >> handled. One of the options in that process is to send a >> counter-notice to the takedown notice. > > Laws frequently have multiple options for compliance. Doesn't mean you > don't have to follow the law. But you should understand the law. The DMCA does NOT require that any provider, anywhere, ever, take down material because they were notified that the material is infringing on a copyright holder's rights. What the DMCA does say is that if a provider receives such a notification, and promptly takes down the material, then the ISP is immune from being held liable for the infringement. Many providers routinely take down material when they receive a DMCA take-down notice. But if they do so out of the belief that they are required to do so, they are confused. They are not required to do so. They can choose to take it down in exchange for getting the benefit of immunity from being sued (many, probably most, providers make this choice). Or they can choose to leave it up, which leaves them vulnerable to a lawsuit by the copyright holder. (In such a lawsuit, they copyright holder would have to prove that infringement occurred and that the provider is liable for it.) (I'm not commenting on the merits of HE's actions here. Just on that the DMCA actually says. It's certainly a good practice for providers that don't want to spend time evaluating copyright claims and defending copyright infringement suits (which, I think, is most providers) to take advantage of the DMCAs safe-harbor provisions. I'm not disputing that.) -- Brett From patrick at ianai.net Sat Oct 24 10:21:38 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 11:21:38 -0400 Subject: ISP port blocking practice In-Reply-To: <614BF03D-27BD-482B-A680-BFB1383EA44E@delong.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> <4AE23194.3010501@justinshore.com> <614BF03D-27BD-482B-A680-BFB1383EA44E@delong.com> Message-ID: <47DF34AA-9DBF-49EB-A607-FBCA1923C9AA@ianai.net> On Oct 23, 2009, at 10:54 PM, Owen DeLong wrote: > On Oct 23, 2009, at 3:43 PM, Justin Shore wrote: >> Dan White wrote: >>> On 23/10/09 17:58 -0400, James R. Cutler wrote: >>>> Blocking the well known port 25 does not block sending of mail. >>>> Or the >>>> message content. >>> It does block incoming SMTP traffic on that well known port. >> >> Then the customer should have bought a class of service that >> permits servers. >> > Then you shouldn't be marketing what the customer bought as > "Internet Access". We disagree. But is this really the place to discuss what MARKETING people should be doing? :) Blocking port 25 is not, IMHO, a violation of Network Neutrality. I explained why in a very long, probably boring, post. Your definition of Network neutrality may differ. Which is fine, but doesn't make mine wrong. As for how it is marketed, well, I'm not even going to try to argue that. -- TTFN, patrick From jcdill.lists at gmail.com Sat Oct 24 10:41:33 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 24 Oct 2009 08:41:33 -0700 Subject: ISP port blocking practice In-Reply-To: <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> References: <4761eff1fe5f8c51a625d6a3396bd4f8@yyc.orthanc.ca> <1E682C23-0DCA-4166-A295-C5E0ED265121@gizmopartners.com> Message-ID: <4AE3202D.4050103@gmail.com> Chris Boyd wrote: > > > Once it's set up correctly we've found customers really like it since > their email "just works" in most places. Earlier this week I had an experience at a San Jose[1] Public Library, where they blocked ports 995, 587, 465, and 119. None of my mail services (or usenet service) worked, except for the news server I use that runs on port 443 (heh) and my webmail backup. Using gmail/webmail I sent an email to the tech admin, and they opened up those ports the next day. This is the first time I've had problems with using these ports - in other cases it does "just work" as expected. I was rather stunned to run into this at a public library. Usually librarians are major defenders of free speech and fight vigorously against censoring, blocking, and filtering of any type on library computers and networks. My guess is that none of the librarians *knew* that the IT department had setup these blocks. I'll have a chat with them the next time I drop in. jc [1] San Jose is the 3rd largest city in California, 10th largest city in the US and the center of Silicon Valley - I had expected a higher level of IT clue than I found. From patrick at ianai.net Sat Oct 24 10:51:33 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 11:51:33 -0400 Subject: DMCA takedowns of networks In-Reply-To: <20091024152051.GA3203@panix.com> References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <20091024145330.GX51443@gerbil.cluepon.net> <022C646C-E04F-47EB-B59F-EA75F276266C@ianai.net> <20091024152051.GA3203@panix.com> Message-ID: On Oct 24, 2009, at 11:20 AM, Brett Frankenberger wrote: > On Sat, Oct 24, 2009 at 11:06:29AM -0400, Patrick W. Gilmore wrote: >> On Oct 24, 2009, at 10:53 AM, Richard A Steenbergen wrote: >>> On Sat, Oct 24, 2009 at 09:36:05AM -0400, Patrick W. Gilmore wrote: >>>> On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: >>>> >>>>> Outside of child pornography there is no content that I would ever >>>>> consider censoring without a court order nor would I ever purchase >>>>> transit from a company that engages in this type of behavior. >>>> >>>> A DMCA takedown order has the force of law. > > It most certainly does not. It "most certainly" does. >>> The DMCA defines a process by which copyright violations can be >>> handled. One of the options in that process is to send a >>> counter-notice to the takedown notice. >> >> Laws frequently have multiple options for compliance. Doesn't mean >> you >> don't have to follow the law. > > But you should understand the law. That's a matter of opinion. :) > The DMCA does NOT require that any provider, anywhere, ever, take down > material because they were notified that the material is infringing on > a copyright holder's rights. Who said it does? I "most certainly" did not. If you think I did, try reading again. > What the DMCA does say is that if a provider receives such a > notification, and promptly takes down the material, then the ISP is > immune from being held liable for the infringement. Many providers > routinely take down material when they receive a DMCA take-down > notice. > But if they do so out of the belief that they are required to do so, > they are confused. They are not required to do so. They can choose > to > take it down in exchange for getting the benefit of immunity from > being > sued (many, probably most, providers make this choice). Or they can > choose to leave it up, which leaves them vulnerable to a lawsuit by > the > copyright holder. (In such a lawsuit, they copyright holder would > have > to prove that infringement occurred and that the provider is liable > for > it.) See, we agree. So what was the problem again? =) And if anyone wants to get upset at a provider for doing what is best for their business, perhaps by saying they are 'giving in to a bully' or other silliness, then they should be ignored. Sometimes it's worth the $$ on lawyers so you can get more customers because people believe you will stand up for them. Sometimes it is not. But a for-profit business is, well, for-profit. And even if you make the wrong business decision, it's still YOUR decision. You risk your business either way you decide, and things are rarely cut-and- dried. People from the outside without all the information telling you you what to do are being silly. Like I always say: Your Network, Your Decision. Anyone care to argue otherwise? -- TTFN, patrick P.S. still doesn't mean HE should have taken down non-infringing sites. From owen at delong.com Sat Oct 24 11:13:27 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Oct 2009 09:13:27 -0700 Subject: ISP port blocking practice In-Reply-To: <200910241017.n9OAHOF8027711@aurora.sol.net> References: <200910241017.n9OAHOF8027711@aurora.sol.net> Message-ID: <1E5A92E0-8E7B-4307-BA04-2A5129C18D38@delong.com> On Oct 24, 2009, at 3:17 AM, Joe Greco wrote: >>> Isn't blocking any port against the idea of Net Neutrality? >> >> Yes. >> >> Owen > > No. > > The idea of net neutrality, in this context, is for service providers > to avoid making arbitrary decisions about the services that a customer > will be allowed. > Right. > Blocking 25, or 137-139, etc., are common steps taken to promote the > security of the network. This is not an arbitrary decision (and I am > defining it this way; I will not play semantics about "arbitrary". > Read along and figure out what I mean.) For 25, SMTP has proven to be > a protocol that has adapted poorly to modern life, and a variety of > issues have conspired that make it undesirable to allow random home > PC's to use 25. Reasonable alternatives exist, such as using 587, or > the ISP's mail server. A customer isn't being disallowed the use of > SMTP to send mail (which WOULD be a problem). A customer may use any > number of other mail servers to send mail. Not a serious issue, and > not arbitrary... it's generally considered a good, or even best > current, practice. > A common practice of breaking the network for your customers does not make the network any less broken and does not make the action network neutral The SMTP protocol has adapted just fine. Certain operators of SMTP servers, on the other hand, are a different issue. I don't take exception if you want to block those SMTP servers. I do take exception if you block the protocol entirely. 587 is the exact same protocol as 25, just with different host configuration policies. As such, I would hold up 587 as an example to prove my point. > Blocking VoIP from your network to Vonage, because you want your > customers to buy your own VoIP service? That's a very clear problem. > There's no justifiable reason that any viable broadband service > provider would have for blocking VoIP. Yet there could be a reason > to forbid VoIP; I can, for example, imagine some of the rural WISP > setups where the loads caused on the infrastructure interfere with > providing service. > Some providers block outbound 25 to other email service providers because they want your outgoing email to go only through their own unauthenticated, unsecure mail servers. (I have had at least one former ISP refuse to unblock port 25 or 587 for me to a host that was running TLS and SMTPAUTH while they insisted that I use their port 25 server which did not listen on port 587 and would not accept TLS or SMTPAUTH). > Similarly, it'd be ridiculous to expect an 802.11b based rural WISP > to be able to support HD Netflix streaming, or dialup ISP's to be > able to support fast downloading of movies. These are not arbitrary > restrictions, but rather technological ones. When you buy a 56k > dialup, you should expect you won't get infinite speed. When you > buy WISP access on a shared 802.11b setup, you should expect that > you're sharing that theoretical max 11Mbps with other subs. > Right... Those are not arbitrary, they are valid. Blocking all access to port 25 is, on the other hand, arbitrary. > > > There's lots of interesting stuff to think about. Net neutrality > isn't going to mean that we kill BCP38 and port 25 filtering. It > is about service providers arbitrarily interfering with the service > that they're providing. Customers should be given, to the maximum > extent reasonably possible, Internet connectivity suitable for > general purpose use. Where service providers start infringing on > that, that's what should be addressed by network neutrality. > BCP-38 is good. SMTP blocking is not in BCP-38. Not allowing a user to send forged packets is a perfectly legitimate action. Not allowing a user to send or receive valid packets properly formatted, carrying legitimate traffic for purposes which are not a violation of the providers AUP, on the other hand, is not good. Owen From jeffrey.lyon at blacklotus.net Sat Oct 24 13:24:14 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 24 Oct 2009 14:24:14 -0400 Subject: DMCA takedowns of networks In-Reply-To: <6835AC53-0BFF-459C-9AB7-DB45A5C79D0D@ianai.net> References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <6835AC53-0BFF-459C-9AB7-DB45A5C79D0D@ianai.net> Message-ID: <16720fe00910241124w62a51796m8ba132ffd9ae0716@mail.gmail.com> Patrick, My comment was geared toward freedom of content and should not be interpreted to mean that network abuse will be permitted. We're very conservative about how we handle DMCA requests. If we receive one it better be valid and if there is any doubt we will challenge the sender vice punish our customer. Most DMCA we receive are completely bogus. Jeff On Sat, Oct 24, 2009 at 9:39 AM, Patrick W. Gilmore wrote: > On Oct 24, 2009, at 9:36 AM, Patrick W. Gilmore wrote: >> >> On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: >> >>> Outside of child pornography there is no content that I would ever >>> consider >>> censoring without a court order nor would I ever purchase transit from a >>> company that engages in this type of behavior. > > P.S. Good to know you would keep spammers, DDoS'ers, hackers, etc. > connected, even in the face of evidence provided by other ISPs, "... nor > would I ever purchase transit from a company that engages in this type of > behavior." > > -- > TTFN, > patrick > > >> A DMCA takedown order has the force of law. >> >> This does not mean you should take down an entire network with unrelated >> sites. ?Given He's history, I'm guessing it was a mistake. >> >> Not buying services from any network that has made a mistake would quickly >> leave you with exactly zero options for transit. >> >> -- >> TTFN, >> patrick >> >> >> >>> On Oct 24, 2009 9:01 AM, "William Allen Simpson" < >>> william.allen.simpson at gmail.com> wrote: >>> >>> >>> http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html >>> >>> Hurricane Electric obeyed the Chamber's letter and shut down the spoof >>> site. But in the process, they shut down hundreds of other sites >>> maintained by May First / People Link, the Yes Men's direct provider >>> (Hurricane Electric is its "upstream" provider). >>> >>> What's going on? ?Since when are we required to take down an entire >>> customer's net for one of their subscriber's so-called infringement? >>> >>> Heck, it takes years to agree around here to take down a peering to an >>> obviously criminal enterprise network.... >>> >>> My first inclination would be to return the request (rejected), saying >>> it was sent to the wrong provider. >>> >> > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From jeffrey.lyon at blacklotus.net Sat Oct 24 13:28:41 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 24 Oct 2009 14:28:41 -0400 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <20091024135949.GX7093@guest-57.ripe.net> References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <25b132e90910240101xe2ddbe0g40a361b4ba191d06@mail.gmail.com> <25b132e90910240105k3641905fwfd234e4ab37e1b37@mail.gmail.com> <20091024135949.GX7093@guest-57.ripe.net> Message-ID: <16720fe00910241128w26ba60e6h427e9b4481fcd0f5@mail.gmail.com> The decision to filter networks should remain with the collective network operators. Everyone, even criminals, has a "right" to distribute content but it's up to each operator to decide if that content will be allowed to transit their network. Personally, if an entire /22 does not have a single legitimate resource on it in the case of 91.202.60.0/22 *and* is widely suspected of being owned/operated by a criminal enterprise then filtering makes sense. Historically it takes a few pioneers to present a case for filtering specific networks before larger networks will begin to see the light. Jeff On Sat, Oct 24, 2009 at 9:59 AM, Daniel Karrenberg wrote: > On 24.10 03:05, Paul Bosworth wrote: >> I think the larger point is that ripe turned a blind eye to an >> internationally recognized criminal network. > > That may be a point but not a convincing one. > > Imagine the outcry on this list if ARIN were to deny some organisation > address space or ASNs just because they are "internationally recognised" > criminals. ?Wouldn't we demand a little more due process? > Especially since the alternatives are not as easy as walking to the > next fastfood joint. > > The RIPE NCC operates in a region where whole sovereign states call each > other criminals or worse on a daily basis. > > The only tenable position for each RIR is to strictly apply the > policies developed in its bottom-up self-regulatory process. ?Doing > anything else would require intervention via a proper legal process, > e.g. ?a *judge* with appropriate jurisdiction telling the RIR that > its actions are unlawful. > > Frustration is a bad advisor when trying to stop crime, unrelenting > application of due process is the only way ... frustrating as it may be. > > Daniel Karrenberg > Chief Scientist RIPE NCC > Speaking only for himself as is customary here. > > PS: This is old news, compare > http://www.h-online.com/security/news/item/Security-expert-calls-for-IP-address-ranges-of-criminal-providers-to-be-sent-direct-to-the-police-737905.html > > And see the press release that Marco pointed out. > > Daniel > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From jgreco at ns.sol.net Sat Oct 24 13:28:25 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 24 Oct 2009 13:28:25 -0500 (CDT) Subject: DMCA takedowns of networks In-Reply-To: <022C646C-E04F-47EB-B59F-EA75F276266C@ianai.net> from "Patrick W. Gilmore" at Oct 24, 2009 11:06:29 AM Message-ID: <200910241828.n9OISQab045425@aurora.sol.net> > On Oct 24, 2009, at 10:53 AM, Richard A Steenbergen wrote: > > On Sat, Oct 24, 2009 at 09:36:05AM -0400, Patrick W. Gilmore wrote: > >> On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: > >> > >>> Outside of child pornography there is no content that I would ever > >>> consider > >>> censoring without a court order nor would I ever purchase transit > >>> from a > >>> company that engages in this type of behavior. > >> > >> A DMCA takedown order has the force of law. > > > > The DMCA defines a process by which copyright violations can be > > handled. > > One of the options in that process is to send a counter-notice to the > > takedown notice. > > Laws frequently have multiple options for compliance. Doesn't mean > you don't have to follow the law. A DMCA takedown notice isn't "law," Patrick, and does not have the "force of law" claimed above. It is merely a claim by a third party as to some particular infringement. A service provider CAN take certain steps listed in the DMCA and gain absolute protection under the law against almost any sort of copyright liability regarding the incident. This does not, however, make it correct or perhaps even legal for a service provider to take that action in all cases. There are plenty of examples of DMCA notices having been sent for the sole purpose of getting something someone doesn't like shut down, even where the party issuing the notice obviously does not own the copyright in question. There are a variety of techniques to deal with this... > > This seems like a very obvious case of parody/fair use, > > Possibly, but I do not blame a provider to not being willing to make > that distinction. Yes, but it's troubling that a nontrivial provider of transit would make such a mistake. This is like Cogent, who, at one point, received a DMCA (or possibly just abuse complaint) about content being posted through a server of a client's, and who proceeded to try to null-route that Usenet news server's address. Of course, they picked a hostname out of the headers of the message in question, and null-routed that. To no effect, since the users accessed servers through SLB. Duh. And since Usenet is a flood fill system, blocking the injecting host isn't sufficient anyways, since the article is instantly available at every other Usenet site, including the other local servers. Double duh. And since the subscriber's account had already been closed and cancels had been issued earlier in the day, the content wasn't even on the server anymore. Three duhs and Cogent's out... The annoying part was that Cogent decided at 2 *AM* in the morning that this was a problem, and insisted on an answer within an hour. I allocated a whole lot more time than that for reading several tiers of management and sales the riot act. Not that it had any operational impact whatsoever, but when a service provider starts implementing arbitrary kneejerk "fixes" upon receipt of a complaint, that's a bad thing, and that seems like what may have happened here, too. To be clear: I agree that a provider might not want to make a distinction between a legitimate DMCA takedown and something that's not, but it is reasonable to limit oneself to the things required by the DMCA. Null-routing a virtual web server's IP and interfering with the operation of other services is probably overreaching, at least as a first step. > > so the proper > > response would be for the victim to send a counter-notice and then > > wait > > for the complainer to settle the issue in court. > > See previous comment. The website owner, however, has that option. > > Let's just agree that there were multiple avenues open to lots of > people here, that HE should not have taken down more than the site in > question (if, in fact, that is what happened), and that the DCMA has > silly parts. > > Doesn't mean you should "wait for a court order" though. That is, of course, completely correct. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From patrick at ianai.net Sat Oct 24 13:30:46 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 14:30:46 -0400 Subject: DMCA takedowns of networks In-Reply-To: <16720fe00910241124w62a51796m8ba132ffd9ae0716@mail.gmail.com> References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <6835AC53-0BFF-459C-9AB7-DB45A5C79D0D@ianai.net> <16720fe00910241124w62a51796m8ba132ffd9ae0716@mail.gmail.com> Message-ID: <888AD16E-A255-450A-9655-3AA1E7D6A548@ianai.net> On Oct 24, 2009, at 2:24 PM, Jeffrey Lyon wrote: > My comment was geared toward freedom of content and should not be > interpreted to mean that network abuse will be permitted. We're very > conservative about how we handle DMCA requests. If we receive one it > better be valid and if there is any doubt we will challenge the sender > vice punish our customer. > > Most DMCA we receive are completely bogus. Like most "discussions" on NANOG, this was the result of a miscommunication. You said you would never censor anything other than CP without a court order. What you meant is that you could follow DCMA if it is not bogus even without a court order, and you would stop abuse, and you would in general act like many other reasonable providers. I'm going to assume that means you would also buy transit from such providers. Wow, it seems like we completely agree. Glad to have cleared that up. Try not to be so absolute next time. -- TTFN, patrick > On Sat, Oct 24, 2009 at 9:39 AM, Patrick W. Gilmore > wrote: >> On Oct 24, 2009, at 9:36 AM, Patrick W. Gilmore wrote: >>> >>> On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: >>> >>>> Outside of child pornography there is no content that I would ever >>>> consider >>>> censoring without a court order nor would I ever purchase transit >>>> from a >>>> company that engages in this type of behavior. >> >> P.S. Good to know you would keep spammers, DDoS'ers, hackers, etc. >> connected, even in the face of evidence provided by other ISPs, >> "... nor >> would I ever purchase transit from a company that engages in this >> type of >> behavior." >> >> -- >> TTFN, >> patrick >> >> >>> A DMCA takedown order has the force of law. >>> >>> This does not mean you should take down an entire network with >>> unrelated >>> sites. Given He's history, I'm guessing it was a mistake. >>> >>> Not buying services from any network that has made a mistake would >>> quickly >>> leave you with exactly zero options for transit. >>> >>> -- >>> TTFN, >>> patrick >>> >>> >>> >>>> On Oct 24, 2009 9:01 AM, "William Allen Simpson" < >>>> william.allen.simpson at gmail.com> wrote: >>>> >>>> >>>> http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332087.html >>>> >>>> Hurricane Electric obeyed the Chamber's letter and shut down the >>>> spoof >>>> site. But in the process, they shut down hundreds of other sites >>>> maintained by May First / People Link, the Yes Men's direct >>>> provider >>>> (Hurricane Electric is its "upstream" provider). >>>> >>>> What's going on? Since when are we required to take down an entire >>>> customer's net for one of their subscriber's so-called >>>> infringement? >>>> >>>> Heck, it takes years to agree around here to take down a peering >>>> to an >>>> obviously criminal enterprise network.... >>>> >>>> My first inclination would be to return the request (rejected), >>>> saying >>>> it was sent to the wrong provider. >>>> >>> >> >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - > 21 to find out how to "protect your booty." > From patrick at ianai.net Sat Oct 24 13:42:51 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 14:42:51 -0400 Subject: DMCA takedowns of networks In-Reply-To: <200910241828.n9OISQab045425@aurora.sol.net> References: <200910241828.n9OISQab045425@aurora.sol.net> Message-ID: On Oct 24, 2009, at 2:28 PM, Joe Greco wrote: >> Laws frequently have multiple options for compliance. Doesn't mean >> you don't have to follow the law. > > A DMCA takedown notice isn't "law," Patrick, and does not have the > "force > of law" claimed above. You say potato, I say whatever. "In the field of law, the word force has two main meanings: unlawful violence and lawful compulsion." They are lawfully compelling you to take down the content, or explain why you should not. This is no different from many "legal" notices. If you ignore the notice, you risk legal ramifications, including the loss of Safe Harbor defense. This pice of paper has the "force" of the US gov't behind it. What would you call "the force of law?" Feel free to believe otherwise. IANAL (or even an ISP :), so maybe I'm wrong. But I'm not going to think poorly of any provider who thinks otherwise. >>> This seems like a very obvious case of parody/fair use, >> >> Possibly, but I do not blame a provider to not being willing to make >> that distinction. > > Yes, but it's troubling that a nontrivial provider of transit would > make > such a mistake. This is like Cogent, who, at one point, received a > DMCA > (or possibly just abuse complaint) about content being posted > through a > server of a client's, and who proceeded to try to null-route that > Usenet > news server's address. [snip - bunch of stuff about Cogent] It is almost certainly not "like" anything. I'm guessing that you have no clue what actually happened. People are making assumptions from third-party accounts using 5th hand info. Generalization is bad, generalization on such flimsy info is silly. Maybe they typo'ed a filter list. Maybe some newbie over-reacted. Maybe the customer did not pay their bill. WE HAVE NO IDEA WHY THIS HAPPENED. > To be clear: I agree that a provider might not want to make a > distinction between a legitimate DMCA takedown and something that's > not, but it is reasonable to limit oneself to the things required by > the DMCA. Null-routing a virtual web server's IP and interfering > with the operation of other services is probably overreaching, at > least as a first step. I have stated over & over that it is not right for HE to take down non- infringing sites - _if_ that is what happened. So why are we having this discussion? >> Doesn't mean you should "wait for a court order" though. > > That is, of course, completely correct. Glad we agree. -- TTFN, patrick From jgreco at ns.sol.net Sat Oct 24 14:07:42 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 24 Oct 2009 14:07:42 -0500 (CDT) Subject: ISP port blocking practice In-Reply-To: <1E5A92E0-8E7B-4307-BA04-2A5129C18D38@delong.com> from "Owen DeLong" at Oct 24, 2009 09:13:27 AM Message-ID: <200910241907.n9OJ7gi5046570@aurora.sol.net> > On Oct 24, 2009, at 3:17 AM, Joe Greco wrote: > >>> Isn't blocking any port against the idea of Net Neutrality? > >> > >> Yes. > >> > >> Owen > > > > No. > > > > The idea of net neutrality, in this context, is for service providers > > to avoid making arbitrary decisions about the services that a customer > > will be allowed. > > Right. > > > Blocking 25, or 137-139, etc., are common steps taken to promote the > > security of the network. This is not an arbitrary decision (and I am > > defining it this way; I will not play semantics about "arbitrary". > > Read along and figure out what I mean.) For 25, SMTP has proven to be > > a protocol that has adapted poorly to modern life, and a variety of > > issues have conspired that make it undesirable to allow random home > > PC's to use 25. Reasonable alternatives exist, such as using 587, or > > the ISP's mail server. A customer isn't being disallowed the use of > > SMTP to send mail (which WOULD be a problem). A customer may use any > > number of other mail servers to send mail. Not a serious issue, and > > not arbitrary... it's generally considered a good, or even best > > current, practice. > > A common practice of breaking the network for your customers does not > make the network any less broken and does not make the action network > neutral > > The SMTP protocol has adapted just fine. Certain operators of SMTP > servers, on the other hand, are a different issue. I don't take > exception > if you want to block those SMTP servers. I do take exception if you > block the protocol entirely. > > 587 is the exact same protocol as 25, just with different host > configuration > policies. As such, I would hold up 587 as an example to prove my point. Except it doesn't. 587 is "submission done right"; whereas 25 is "transit." 587 and 25 are conceptually completely different, even if they use a common underlying protocol. That's why 587 not only does not prove your point, but it actually allows me to show that it isn't SMTP being interfered with, but rather just the uncontrolled submission of e-mail to remote machines. Does network neutrality mean that dialup operators will have to allow PPP users to connect without a login and password? > > Blocking VoIP from your network to Vonage, because you want your > > customers to buy your own VoIP service? That's a very clear problem. > > There's no justifiable reason that any viable broadband service > > provider would have for blocking VoIP. Yet there could be a reason > > to forbid VoIP; I can, for example, imagine some of the rural WISP > > setups where the loads caused on the infrastructure interfere with > > providing service. > > Some providers block outbound 25 to other email service providers > because they want your outgoing email to go only through their > own unauthenticated, unsecure mail servers. (I have had at least > one former ISP refuse to unblock port 25 or 587 for me to a host > that was running TLS and SMTPAUTH while they insisted that > I use their port 25 server which did not listen on port 587 and > would not accept TLS or SMTPAUTH). Blocking 25 isn't a problem. Blocking 587 is. Requiring all e-mail to go through their servers is also a problem. That's because there is a good reason for the 25 blocking, one that you can trivially work around on 587. Blocking 587 is overreaching, and is dictating that you must use their servers. That is not neutral. > > Similarly, it'd be ridiculous to expect an 802.11b based rural WISP > > to be able to support HD Netflix streaming, or dialup ISP's to be > > able to support fast downloading of movies. These are not arbitrary > > restrictions, but rather technological ones. When you buy a 56k > > dialup, you should expect you won't get infinite speed. When you > > buy WISP access on a shared 802.11b setup, you should expect that > > you're sharing that theoretical max 11Mbps with other subs. > > Right... Those are not arbitrary, they are valid. Blocking all access > to port 25 is, on the other hand, arbitrary. It's not, because there is an obvious ongoing problem with infected end-user machines sending spam, and no particular reason that an end- user machine needs to be able to send e-mail to random remote sites. A huge amount of good is accomplished for the 'net as a whole when a service provider blocks 25. They're not preventing you from sending e-mail, they're just requiring that it be sent in a manner that complies with current community standards. And there are standards, and you can submit via 587 to alternative e-mail services of your choice. It is not entirely ideal, but it is laughable to construe 25 blocking as making it impossible (or even hard) to send e-mail, given that it most certainly isn't. > > There's lots of interesting stuff to think about. Net neutrality > > isn't going to mean that we kill BCP38 and port 25 filtering. It > > is about service providers arbitrarily interfering with the service > > that they're providing. Customers should be given, to the maximum > > extent reasonably possible, Internet connectivity suitable for > > general purpose use. Where service providers start infringing on > > that, that's what should be addressed by network neutrality. > > BCP-38 is good. SMTP blocking is not in BCP-38. > > Not allowing a user to send forged packets is a perfectly legitimate > action. Not allowing a user to send or receive valid packets > properly formatted, carrying legitimate traffic for purposes which > are not a violation of the providers AUP, on the other hand, is > not good. Oh. Really. But the problem is, you can't play both "BCP38 is good" and "25 blocking is bad." They're of the same cloth. If I'm assigned 24.1.2.3 by Comcast, and Comcast filters my ingress to prevent me from emitting other addresses, you claim that's fine because it's BCP38. There's a problem: I can validly emit a variety of other addresses, in particular any address in 206.55.64.0/20 and some other networks. I am not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a Comcast pipe. How many people realistically have this problem? Well, potentially, lots. Anyone who uses a VPN could have a legitimate IP address on their machine; because of BCP38 (and other security policy) it is common for a VPN setup to forward Internet-bound traffic back to the VPN server rather than directly out the Internet. In some cases, one could reasonably argue that this is undesirable. But overall, security is greatly increased by eliminating the ability to inject forged traffic. We do this through BCP38. BCP38 carries with it some amount of inconvenience to users whose legitimate traffic can not be sent due to the simplistic filtering typically employed. This does not mean BCP38 violates net neutrality, any more than it means 25 blocking violates it. On the other hand, if your ISP is intercepting your DNS, forcing /all/ SMTP through their servers, mandating the use of web proxy servers that add banner ads, blocking VoIP, and RST'ing BitTorrent traffic, then you have a serious net neutrality problem. As operators, the readers in this group should be uniquely qualified to understand: common technical steps taken to ensure the security and continued smooth operation of your network are probably not violating net neutrality, but once you move into the realm of steps taken that damage a competitor, degrade or forbid particular services, or other decisions made for "business" reasons, where such things affect the set of potential things a user could reasonably expect to want to be able to do, then you have to look a bit more carefully at it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Sat Oct 24 14:23:57 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 24 Oct 2009 14:23:57 -0500 (CDT) Subject: DMCA takedowns of networks In-Reply-To: from "Patrick W. Gilmore" at Oct 24, 2009 02:42:51 PM Message-ID: <200910241923.n9OJNvXl047092@aurora.sol.net> > On Oct 24, 2009, at 2:28 PM, Joe Greco wrote: > >> Laws frequently have multiple options for compliance. Doesn't mean > >> you don't have to follow the law. > > > > A DMCA takedown notice isn't "law," Patrick, and does not have the > > "force > > of law" claimed above. > > You say potato, I say whatever. "In the field of law, the word force > has two main meanings: unlawful violence and lawful compulsion." They > are lawfully compelling you to take down the content, or explain why > you should not. I think you need to read the DMCA. You may feel free to point out where it says "service provider must do X." Because I suspect you will find out that it _really_ says, "in order to retain safe harbor protection, service provider must do X." The latter is not lawfully compelling me to do anything. > This is no different from many "legal" notices. If > you ignore the notice, you risk legal ramifications, including the > loss of Safe Harbor defense. > > This pice of paper has the "force" of the US gov't behind it. What > would you call "the force of law?" > > Feel free to believe otherwise. IANAL (or even an ISP :), so maybe > I'm wrong. But I'm not going to think poorly of any provider who > thinks otherwise. I "believe" what the lawyers tell me. They tell me that we may lose safe harbor if we do not comply with a takedown notice. That's about all. > >>> This seems like a very obvious case of parody/fair use, > >> > >> Possibly, but I do not blame a provider to not being willing to make > >> that distinction. > > > > Yes, but it's troubling that a nontrivial provider of transit would > > make > > such a mistake. This is like Cogent, who, at one point, received a > > DMCA > > (or possibly just abuse complaint) about content being posted > > through a > > server of a client's, and who proceeded to try to null-route that > > Usenet > > news server's address. > > [snip - bunch of stuff about Cogent] > > It is almost certainly not "like" anything. > > I'm guessing that you have no clue what actually happened. People are > making assumptions from third-party accounts using 5th hand info. > Generalization is bad, generalization on such flimsy info is silly. > > Maybe they typo'ed a filter list. Maybe some newbie over-reacted. > Maybe the customer did not pay their bill. WE HAVE NO IDEA WHY THIS > HAPPENED. Of course not. But there are at least some of us who have been through all of this; we can fill in the blanks and make some reasonable conclusions. > > To be clear: I agree that a provider might not want to make a > > distinction between a legitimate DMCA takedown and something that's > > not, but it is reasonable to limit oneself to the things required by > > the DMCA. Null-routing a virtual web server's IP and interfering > > with the operation of other services is probably overreaching, at > > least as a first step. > > I have stated over & over that it is not right for HE to take down non- > infringing sites - _if_ that is what happened. > > So why are we having this discussion? Because it appears that HE took down non-infringing sites? Excuse me for stating the obvious. :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From joly at punkcast.com Sat Oct 24 14:52:47 2009 From: joly at punkcast.com (Joly MacFie) Date: Sat, 24 Oct 2009 15:52:47 -0400 Subject: DMCA takedowns of networks In-Reply-To: <200910241923.n9OJNvXl047092@aurora.sol.net> References: <200910241923.n9OJNvXl047092@aurora.sol.net> Message-ID: <313b48d0910241252w4ffba427v8803deb011ba10e5@mail.gmail.com> I've excerpted, and posted anonymously, a few quotes from this thread on the ISOC-NY website. I hope that this is acceptable - if not, let me know off list. http://www.isoc-ny.org/?p=996 -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From kmedcalf at dessus.com Sat Oct 24 15:05:09 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 24 Oct 2009 16:05:09 -0400 Subject: ISP port blocking practice In-Reply-To: <4FxLTmHsMKRd.TVRTrj86@smtp.gmail.com> Message-ID: > Free speech doesn't include the freedom to shout fire in a crowded theatre. It most certainly does! There is absolutely nothing to prevent one from shouting "FIRE" in a crowded theatre. In fact, any attempt to legislate a prohibition against such behaviour would, in all civilized countries and legal systems, constitute unlawful prior restraint. You are confusing (as are all the myriad idiots who keep repeating this fictitious statement) prior restraint with positive law. Nothing prevents you from shouting "FIRE" in a crowded theatre (or anywhere else for that matter). However the proof of the FACT that you shouted "FIRE", and the proof of the FACT that this caused panic and injury, and proof of the FACT that the act of shouting "FIRE" caused pandemonium and injury will lead to a conviction for the offense of RECKLESS ENDANGERMENT or other offences against positive law. It is not the shouting of "FIRE" in a crowded theatre that is unlawful, it is the reckless act and the reckless disregard for the consequences of that act which is criminal. In fact, if one were to shout "FIRE" in a crowded theatre and everyone simply ignored it, no offense would have been committed at all! Please keep your facts straight and do not abridge and summarize to the point of absolute absurdity! > Neither does it include the freedom to carry out a DDOS on the fire brigade control room. This, of course, falls in the same category. You are totally free to DDoS the fire brigade control room. It is not illegal nor can such action be prohibited by positive law. It is however entirely possible that the consequence of such behaviour is perilous to property, life and limb; and that as a consequence the act itself becomes reckless endangerment ONLY AFTER IT HAS BEEN COMMITTED. There is not, and cannot be, any lawful prior restraint in this case either. > You aren't allowed to levy a toll on the roads and except your mates - roads are neutral. Of course you can, and governments do it all the time. > But that doesn't invalidate the speed limit or the obligation to drive on the left. Once again, you are confusing prior restraint with the consequence of doing an action. The Act itself cannot be prohibited. Their may be consequences assigned to having proven that an act was done, but the doing of the act is not and cannot be prohibited. Of course, both the United States and the UK have become Fascist states, and as such it is reasonable to expect that they will behave like Fascists. -- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From herrin-nanog at dirtside.com Sat Oct 24 17:20:29 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 24 Oct 2009 18:20:29 -0400 Subject: Advice about Qwest, Cogent, and Equinix facilities In-Reply-To: <3C5B084431653D4A9C469A22AFCDB5B903E9B7CE@LOGAN.billtrust.local> References: <3C5B084431653D4A9C469A22AFCDB5B903E9B7CE@LOGAN.billtrust.local> Message-ID: <3c3e3fca0910241520p7aa3388atfad1468c88da9e6a@mail.gmail.com> On Mon, Oct 19, 2009 at 10:32 AM, Jeffrey Negro wrote: > My company is planning on implementing a new strategy for our web > application deployment. [...] I would welcome any advice or > experiences other nanog members may have with regards to these > providers, as well as any suggestions about other providers that may fit > the bill. Two words: carrier neutral. With a carrier neutral facility like Equinix you'll have a greater wealth of data services available to you from a wide range of carriers at on-net prices. And alternatives available when one of those services doesn't pan out quite what the salesman claimed. With a particular carrier's facility such as Verizon, Qwest, Level3 or Cogent, you're more limited. Other carriers occasionally vend some services there but the variety is generally very limited and they tend to be much more expensive than the incumbent. And God help you when you want to leave... The DNC moved out of the Verizon Business data center in Ashburn VA in 2006 and tried to buy a Verizon Business line at another data center in order to keep the IP addresses. Verizon Business refused to move the IP address blocks to a VB line outside of the data center. With a carrier neutral facility, the carriers have no vested interest in keeping you in that particular data center. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cluestore at gmail.com Sat Oct 24 18:55:30 2009 From: cluestore at gmail.com (Clue Store) Date: Sat, 24 Oct 2009 18:55:30 -0500 Subject: ISP port blocking practice In-Reply-To: <47DF34AA-9DBF-49EB-A607-FBCA1923C9AA@ianai.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> <0B69C279-1DFF-4005-9D7F-6F2EA207363D@consultant.com> <20091023221545.GH4947@dan.olp.net> <4AE23194.3010501@justinshore.com> <614BF03D-27BD-482B-A680-BFB1383EA44E@delong.com> <47DF34AA-9DBF-49EB-A607-FBCA1923C9AA@ianai.net> Message-ID: <580af3b90910241655i2b38be2dw1575e2dde1dbbe7e@mail.gmail.com> > > > > Blocking port 25 is not, IMHO, a violation of Network Neutrality. I > explained why in a very long, probably boring, post. Your definition of > Network neutrality may differ. Which is fine, but doesn't make mine wrong. > > > > -- > TTFN, > patrick > > > I agree with this. I would think that from an administrator/engineers perspective, it's more of being proactive to help protect the network, the end-user and help keep SLA's (keep from getting listed on RBL because of a non-patched or virused pc, not wasting network resources due to SPAM, trying to keep your own house clean, etc) more than it is an attack on Net Neutrality. But on the other hand, the end-user, customer, or whoever is having a port blocked, might wonder about the services they are buying and if it's time to jump ship to another provider if they aren't willing to work with the customer. I think that most providers are willing to work with the customer if ports such as SMTP need to be unblocked for whatever reason. If they aren't, then i would suggest finding another provider. Clue From davet1 at gmail.com Sat Oct 24 20:45:17 2009 From: davet1 at gmail.com (Dave Temkin) Date: Sat, 24 Oct 2009 18:45:17 -0700 Subject: Advice about Qwest, Cogent, and Equinix facilities In-Reply-To: <3c3e3fca0910241520p7aa3388atfad1468c88da9e6a@mail.gmail.com> References: <3C5B084431653D4A9C469A22AFCDB5B903E9B7CE@LOGAN.billtrust.local> <3c3e3fca0910241520p7aa3388atfad1468c88da9e6a@mail.gmail.com> Message-ID: <4AE3ADAD.5030800@gmail.com> Completely agreed; in many situations even if one of those carrier locked data centers allow another carrier in, they may severely limit the portfolio of services that are allowed to be offered by them. For example, one of the vendors listed below only allows "lit" crossconnects from 3rd party carriers and only from a demarc that they specify, generally not within the same data center that you're housed. It means that any type of circuit that you drop into there is effectively type 2. It's ugly. -Dave William Herrin wrote: > On Mon, Oct 19, 2009 at 10:32 AM, Jeffrey Negro wrote: > >> My company is planning on implementing a new strategy for our web >> application deployment. [...] I would welcome any advice or >> experiences other nanog members may have with regards to these >> providers, as well as any suggestions about other providers that may fit >> the bill. >> > > Two words: carrier neutral. > > With a carrier neutral facility like Equinix you'll have a greater > wealth of data services available to you from a wide range of carriers > at on-net prices. And alternatives available when one of those > services doesn't pan out quite what the salesman claimed. > > With a particular carrier's facility such as Verizon, Qwest, Level3 or > Cogent, you're more limited. Other carriers occasionally vend some > services there but the variety is generally very limited and they tend > to be much more expensive than the incumbent. > > And God help you when you want to leave... The DNC moved out of the > Verizon Business data center in Ashburn VA in 2006 and tried to buy a > Verizon Business line at another data center in order to keep the IP > addresses. Verizon Business refused to move the IP address blocks to a > VB line outside of the data center. With a carrier neutral facility, > the carriers have no vested interest in keeping you in that particular > data center. > > Regards, > Bill Herrin > > > > > From ilopezlists at sandboxitsolutions.com Sat Oct 24 20:55:18 2009 From: ilopezlists at sandboxitsolutions.com (Israel Lopez-LISTS) Date: Sat, 24 Oct 2009 18:55:18 -0700 Subject: Nanog Mentioned in TED Video: Jonathan Zittrain Message-ID: <4AE3B006.8010407@sandboxitsolutions.com> Remember when youtube went down? Mr. Zittrain briefly mentions nanog during his TED talk in July 2009. http://www.ted.com/talks/jonathan_zittrain_the_web_is_a_random_act_of_kindness.html Enjoy. From patrick at ianai.net Sat Oct 24 20:59:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 Oct 2009 21:59:05 -0400 Subject: Nanog Mentioned in TED Video: Jonathan Zittrain In-Reply-To: <4AE3B006.8010407@sandboxitsolutions.com> References: <4AE3B006.8010407@sandboxitsolutions.com> Message-ID: <3A1A6269-1E97-4C6B-9854-D0E5CD3A7DF9@ianai.net> On Oct 24, 2009, at 9:55 PM, Israel Lopez-LISTS wrote: > Remember when youtube went down? > Mr. Zittrain briefly mentions nanog during his TED talk in July 2009. > > http://www.ted.com/talks/jonathan_zittrain_the_web_is_a_random_act_of_kindness.html Been discussed. He's obviously wrong about some things. No one does anything without getting paid. But he is kinda right in some ways too. -- TTFN, patrick From joelja at bogus.com Fri Oct 23 22:48:35 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 23 Oct 2009 20:48:35 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091022234616.GC3418@isc.org> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> Message-ID: <4AE27913.7060607@bogus.com> On wireless networks you can note the mac address of the rouge server and dissociate it from the wireless network, this is rather similar to what we did on switches prior to dhcp protection, it is reactive but it certainly can be automatic. Some controller based wireless systems have ips or nac functionality that does this already. joelja David W. Hankins wrote: > On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: >> Really. How do we deal with rouge DHCP on the wireless LAN, obviously >> this is such a complex issue that we couldn't possibly have a solution >> that could be applied to RA. > > There are some wireless equipment that claim to have a setting that > forces all packets through the wireless bridge (where all traffic is > between clients and bridge, and never client to client), and so one > can filter DHCPv6 and maybe RA, but I am kind of skeptical about how > much of this is elective and dependent upon client implementation... > > In both cases there may still be some wireless adapters that receive > bogus packets directly from attackers. > > And then you bring ND into the question and wonder why you bothered > with either RA or DHCP filtering. > > > DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic > authentication. > > The problem however has been the key distribution model. Here it all > falls down, and leads to poor deployment. > > But with DHCPv*, we have a hope that we can secure it if we can solve > that last problem (and at least I think we can). > > So if you accept that as an outcome, one must ponder the question: > > How long will people accept that a secured DHCPv6 session must rely, > in order to function to expectations, upon the unsecurable RA and/or > questionably secure SEND? > From kauer at biplane.com.au Sun Oct 25 01:33:34 2009 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 25 Oct 2009 17:33:34 +1100 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <4AE27913.7060607@bogus.com> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <4AE27913.7060607@bogus.com> Message-ID: <1256452414.10858.13.camel@karl> On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: > the mac address of the rouge server It's R-O-G-U-E - rogue. Rouge is French for red and English for red make-up. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Oct 25 03:07:58 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 25 Oct 2009 18:37:58 +1030 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <1256452414.10858.13.camel@karl> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <4AE27913.7060607@bogus.com> <1256452414.10858.13.camel@karl> Message-ID: <20091025183758.2ac4bf7a@opy.nosense.org> On Sun, 25 Oct 2009 17:33:34 +1100 Karl Auer wrote: > On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: > > the mac address of the rouge server > > > > It's R-O-G-U-E - rogue. > > Rouge is French for red and English for red make-up. > > > Also the colour of the faces of angry net admins when they discover a rogue, possibly rouge coloured server. > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) > > GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF > From nsosoc at gmail.com Sun Oct 25 05:30:22 2009 From: nsosoc at gmail.com (nsosoc -G-) Date: Sun, 25 Oct 2009 11:30:22 +0100 Subject: application recommendation Message-ID: <011001ca555e$28f9b260$7aed1720$@com> Hey guys, I have a need for your candid opinion. I am searching for an enterprise sized application (commercial or otherwise) that can accomplish diversified network access from the inside. This is roughly the situation: A diversified very large (multinational) enterprise, consisting of a multitude of local networks. Each of the local networks provide direct hard-wired local and Internet access with our equipment to our employees. Our company has many third-party users. We would want to provide to the latter (after a secure admission session) Internet access with their own equipment through our (the same hard-wired) connection (and subsequently with our firewall services and using our corporate endpoint security), but no access to the internal/local networks. Which application would accomplish this? Appreciating your recommendations. Best, Jack Jack Ryan Network Architecture National Railway System nsosoc at gmail.com From swm at emanon.com Sun Oct 25 08:34:14 2009 From: swm at emanon.com (Scott Morris) Date: Sun, 25 Oct 2009 09:34:14 -0400 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <1256452414.10858.13.camel@karl> References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <4AE27913.7060607@bogus.com> <1256452414.10858.13.camel@karl> Message-ID: <4AE453D6.6080607@emanon.com> Could have been a server in drag? ;) Karl Auer wrote: > On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: > >> the mac address of the rouge server >> > > > > It's R-O-G-U-E - rogue. > > Rouge is French for red and English for red make-up. > > > > Regards, K. > > From Richard.E.Brown at dartware.com Sun Oct 25 09:04:43 2009 From: Richard.E.Brown at dartware.com (Richard E. Brown) Date: 25 Oct 2009 10:04:43 -0400 Subject: ISP port blocking practice/Free Speech Message-ID: <4653035@blitz.dartware.com> > > Free speech doesn't include the freedom to shout fire in a crowded theatre. > > It most certainly does! There is absolutely nothing to prevent one from > shouting "FIRE" in a crowded theatre. Actually, it doesn't. When I was on-staff at the computer center at Dartmouth, our provost also happened to be a first-amendment scholar, and he gave us an impromptu speech about the first amendment at a staff meeting :-) The US Supreme Court recognizes a couple exceptions to the broad permission to speak freely: - Shouting fire in a crowded theater is explicitly prohibited because of the obvious danger and risk of injury. - "Fighting words", that by their very utterance inflict injury or tend to incite an immediate breach of the peace". [Wikipedia] The example he gave was this: someone standing on a soapbox in Hanover NH, saying that we should storm the gates in Washington and burn the place down is just exercising their free speech rights - there's no credible *imminent* threat. However, standing there and saying that we should burn down the Town Hall could clearly be believed to be a real threat, and the government would be justified in stepping in. Rich Brown richard.e.brown at dartware.com Dartware, LLC http://www.dartware.com 66-7 Benning Street Telephone: 603-643-9600 West Lebanon, NH 03784-3407 Fax: 603-643-2289 From kmedcalf at dessus.com Sun Oct 25 09:19:13 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 25 Oct 2009 10:19:13 -0400 Subject: ISP port blocking practice/Free Speech In-Reply-To: <4653035@blitz.dartware.com> Message-ID: <356ba1bdf1c4bc43be30d42f76c4108f@mail.dessus.com> Your scholar is wrong -- or he is giving the simplified explanation for children and others incapable of rational though and understanding, and you are believing the summary because it is simpler for you than understanding the underlying rational. Notice that in both cases your presumption of prohibition is based on the actualization of a consequence. It is the intentional causing of the consequence that is the Criminal Act, and not the method by which that consequence is actualized. In other words, it is the causing of panic, mayhem and injury that is the Criminal Act which cannot be saved by your first amendment protections, and the shouting FIRE is but an example of an item WHICH MAY CAUSE such a result. It is not the shouting FIRE which is wrong, it is the mayhem that it causes. In any event of the cause, prior restraint is prohibited in any system of positive law. (Though I have already pointed out that both the UK and the United States are no longer systems of positive law, but rather have become Fascist Dictatorships and a priori prohibition is a hallmark of such regimes). Anyway, if you fail to understand cause and effect and the difference between them when you have obviously passed the age of four years, it is unlikely that I will be able to educate you at this point in your life. This is OT and we will not continue this any further. -- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Richard E. Brown [mailto:Richard.E.Brown at dartware.com] > Sent: Sunday, 25 October, 2009 10:05 > To: nanog at nanog.org > Subject: RE: ISP port blocking practice/Free Speech > > > > Free speech doesn't include the freedom to shout fire in > a crowded theatre. > > > > It most certainly does! There is absolutely nothing to > prevent one from > > shouting "FIRE" in a crowded theatre. > > Actually, it doesn't. When I was on-staff at the computer > center at Dartmouth, > our provost also happened to be a first-amendment scholar, > and he gave us an impromptu > speech about the first amendment at a staff meeting :-) > > The US Supreme Court recognizes a couple exceptions to the > broad permission to > speak freely: > > - Shouting fire in a crowded theater is explicitly prohibited > because of the obvious > danger and risk of injury. > > - "Fighting words", that by their very utterance inflict > injury or tend to incite > an immediate breach of the peace". [Wikipedia] The example he > gave was this: someone > standing on a soapbox in Hanover NH, saying that we should > storm the gates in > Washington and burn the place down is just exercising their > free speech rights > - there's no credible *imminent* threat. However, standing > there and saying that > we should burn down the Town Hall could clearly be believed > to be a real threat, > and the government would be justified in stepping in. > > Rich Brown richard.e.brown at dartware.com > Dartware, LLC http://www.dartware.com > 66-7 Benning Street Telephone: 603-643-9600 > West Lebanon, NH 03784-3407 Fax: 603-643-2289 > > From owen at delong.com Sun Oct 25 13:24:41 2009 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Oct 2009 11:24:41 -0700 Subject: Nanog Mentioned in TED Video: Jonathan Zittrain In-Reply-To: <3A1A6269-1E97-4C6B-9854-D0E5CD3A7DF9@ianai.net> References: <4AE3B006.8010407@sandboxitsolutions.com> <3A1A6269-1E97-4C6B-9854-D0E5CD3A7DF9@ianai.net> Message-ID: <583194B6-B8DA-4F67-A29E-12BA80C9D926@delong.com> On Oct 24, 2009, at 6:59 PM, Patrick W. Gilmore wrote: > On Oct 24, 2009, at 9:55 PM, Israel Lopez-LISTS wrote: > >> Remember when youtube went down? >> Mr. Zittrain briefly mentions nanog during his TED talk in July 2009. >> >> http://www.ted.com/talks/jonathan_zittrain_the_web_is_a_random_act_of_kindness.html > > Been discussed. > > He's obviously wrong about some things. No one does anything > without getting paid. But he is kinda right in some ways too. > Lots of us actually do lots of things without getting paid. We also do some things for which we get paid. Owen From johnl at iecc.com Sun Oct 25 14:45:01 2009 From: johnl at iecc.com (John Levine) Date: 25 Oct 2009 19:45:01 -0000 Subject: ISP port blocking practice/Free Speech In-Reply-To: <356ba1bdf1c4bc43be30d42f76c4108f@mail.dessus.com> Message-ID: <20091025194501.51705.qmail@simone.iecc.com> >Your scholar is wrong -- or he is giving the simplified explanation >for children and others incapable of rational though and >understanding, and you are believing the summary because it is >simpler for you than understanding the underlying rational. Ah, the classic nerd legal misconception. Laws are not software, because they are interpreted by politicians and judges, not CPU chips. Dartmouth has a fine tradition of legal scholarship dating back at least to Daniel Webster, and he knows what he is talking about. There is plenty of documention of the way that judges around the country interpret the First Amendment, and if you look, you will find that his description is the way they interpret it. You are of course welcome to interpret the law any way you want, but don't expect to impress any courts with your theories. ObOperations: Since ISPs are not government actors, the First Amendment doesn't apply unless we get intrusive Net Neut laws. R's, John PS: I used to be the mayor of my small municipality, and we learned quite a lot about the First Amendment as applied when we tried to revise our sign ordinance. From sean at donelan.com Sun Oct 25 17:13:05 2009 From: sean at donelan.com (Sean Donelan) Date: Sun, 25 Oct 2009 18:13:05 -0400 (EDT) Subject: What should ISPs ASPs MSPs xSPs do? Message-ID: <200910251709360.32BF5B92.26106@clifden.donelan.com> Other than the usual damned if they do, damned if they don't; is there any rough consensus about some practical things ISPs, ASPs, MSPs, xSPs (and customers/users) should do or should not do? Or is it just rough consensus what other people should do, but you'll get upset if that rough consensus stopped you from doing something? Stop stuff you don't like immediately, anytime of the day or night; but give you years to fix your stuff even if it is hurting other people's stuff. From jmaimon at ttec.com Sun Oct 25 18:04:27 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 25 Oct 2009 19:04:27 -0400 Subject: What should ISPs ASPs MSPs xSPs do? In-Reply-To: <200910251709360.32BF5B92.26106@clifden.donelan.com> References: <200910251709360.32BF5B92.26106@clifden.donelan.com> Message-ID: <4AE4D97B.8080404@ttec.com> Sean Donelan wrote: > Other than the usual damned if they do, damned if they don't; is there > any rough consensus about some practical things ISPs, ASPs, MSPs, xSPs > (and customers/users) should do or should not do? It depends mostly on the environment they operate under which needs to take into account the vagaries of their customer base. You will need to define things a whole lot better to get rough consensus on any specifics. Act locally think globally is probably the best you can get otherwise. > Or is it just rough consensus what other people should do, but you'll > get upset if that rough consensus stopped you from doing something? > Stop stuff you don't like immediately, anytime of the day or night; but > give you years to fix your stuff even if it is hurting other people's > stuff. > Thats just human nature. From jmaimon at ttec.com Sun Oct 25 18:05:07 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 25 Oct 2009 19:05:07 -0400 Subject: ingress filtering and multiple Internet conenctions In-Reply-To: <200910241907.n9OJ7gi5046570@aurora.sol.net> References: <200910241907.n9OJ7gi5046570@aurora.sol.net> Message-ID: <4AE4D9A3.1010406@ttec.com> Joe Greco wrote: > > There's a problem: I can validly emit a variety of other addresses, in > particular any address in 206.55.64.0/20 and some other networks. I am > not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a > Comcast pipe. > > How many people realistically have this problem? Well, potentially, > lots. Anyone who uses a VPN could have a legitimate IP address on their > machine; because of BCP38 (and other security policy) it is common > for a VPN setup to forward Internet-bound traffic back to the VPN > server rather than directly out the Internet. In some cases, one could > reasonably argue that this is undesirable. I would like to take the opportunity to urge vendors of routers and firewalls to take extra special care and attention to make sure that The Right Thing can always happen whenever multiple egress services are employed. This means that policy routing for network AND ALL locally generated traffic should be available and work as the operator intends it to. Right now things still suck pretty hard, depending on what you are using. Joe From nanog-post at rsuc.gweep.net Sun Oct 25 18:25:26 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 25 Oct 2009 19:25:26 -0400 Subject: ISP port blocking practice In-Reply-To: <4AE21DDB.8050204@bestline.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <13B9939F-19C4-46D5-89B1-F1EE1B70C788@delong.com> <4AE1C20A.1020405@justinshore.com> <4AE21DDB.8050204@bestline.net> Message-ID: <20091025232526.GA6398@gweep.net> On Fri, Oct 23, 2009 at 04:19:23PM -0500, Lee Riemer wrote: > Isn't blocking any port against the idea of Net Neutrality? Which demonstrates just how relevant to reality such things are. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jgreco at ns.sol.net Sun Oct 25 18:58:32 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 25 Oct 2009 17:58:32 -0600 (CST) Subject: ingress filtering and multiple Internet conenctions In-Reply-To: <4AE4D9A3.1010406@ttec.com> from "Joe Maimon" at Oct 25, 2009 07:05:07 PM Message-ID: <200910252358.n9PNwWgA050849@aurora.sol.net> > Joe Greco wrote: > > There's a problem: I can validly emit a variety of other addresses, in > > particular any address in 206.55.64.0/20 and some other networks. I am > > not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a > > Comcast pipe. > > > > How many people realistically have this problem? Well, potentially, > > lots. Anyone who uses a VPN could have a legitimate IP address on their > > machine; because of BCP38 (and other security policy) it is common > > for a VPN setup to forward Internet-bound traffic back to the VPN > > server rather than directly out the Internet. In some cases, one could > > reasonably argue that this is undesirable. > > I would like to take the opportunity to urge vendors of routers and > firewalls to take extra special care and attention to make sure that The > Right Thing can always happen whenever multiple egress services are > employed. > > This means that policy routing for network AND ALL locally generated > traffic should be available and work as the operator intends it to. > > Right now things still suck pretty hard, depending on what you are using. Who defines what "The Right Thing" is? Allowing (what are to the service provider) random IP's inbound, even if there's some mechanism to limit it, means that the ISP now has some additional responsibilities to be able to transport packets for space that isn't theirs; a transit upstream or peer might filter, especially for smaller service providers. Basically, allowing this dooms BCP38. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jmaimon at ttec.com Sun Oct 25 19:52:02 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 25 Oct 2009 20:52:02 -0400 Subject: ingress filtering and multiple Internet conenctions In-Reply-To: <200910252358.n9PNwWgA050849@aurora.sol.net> References: <200910252358.n9PNwWgA050849@aurora.sol.net> Message-ID: <4AE4F2B2.8060903@ttec.com> Joe Greco wrote: >> Joe Greco wrote: >> >> Right now things still suck pretty hard, depending on what you are using. > > Who defines what "The Right Thing" is? The right thing is to allow the operator to twiddle the knobs so that everything works properly with multiple internet connections specifically when the ISP is using BCP38. > Basically, allowing this dooms BCP38. > > ... JG Basically getting this wrong dooms BCP38. From patrick at ianai.net Sun Oct 25 19:56:54 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 25 Oct 2009 20:56:54 -0400 Subject: Nanog Mentioned in TED Video: Jonathan Zittrain In-Reply-To: <583194B6-B8DA-4F67-A29E-12BA80C9D926@delong.com> References: <4AE3B006.8010407@sandboxitsolutions.com> <3A1A6269-1E97-4C6B-9854-D0E5CD3A7DF9@ianai.net> <583194B6-B8DA-4F67-A29E-12BA80C9D926@delong.com> Message-ID: <5CB296E1-30EF-4487-8B06-8F2CE6D0A56D@ianai.net> On Oct 25, 2009, at 2:24 PM, Owen DeLong wrote: > On Oct 24, 2009, at 6:59 PM, Patrick W. Gilmore wrote: >> On Oct 24, 2009, at 9:55 PM, Israel Lopez-LISTS wrote: >> >>> Remember when youtube went down? >>> Mr. Zittrain briefly mentions nanog during his TED talk in July >>> 2009. >>> >>> http://www.ted.com/talks/jonathan_zittrain_the_web_is_a_random_act_of_kindness.html >> >> Been discussed. >> >> He's obviously wrong about some things. No one does anything >> without getting paid. But he is kinda right in some ways too. >> > Lots of us actually do lots of things without getting paid. Mea culpa! You are (most obviously) correct. I meant to say "no one passes a packet without getting paid", specifically in response to his passing the beer in the stadium analogy. While it is true there are a few packets passed without payment, I'm pretty sure it's 0% of the total, to several decimal places. Thank you for pointing out my error. -- TTFN, patrick > We also do some things for which we get paid. > > Owen > From owen at delong.com Sun Oct 25 22:51:13 2009 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Oct 2009 20:51:13 -0700 Subject: ingress filtering and multiple Internet conenctions In-Reply-To: <4AE4D9A3.1010406@ttec.com> References: <200910241907.n9OJ7gi5046570@aurora.sol.net> <4AE4D9A3.1010406@ttec.com> Message-ID: <305CE909-656A-4F32-B51B-F5A25D21BDAA@delong.com> On Oct 25, 2009, at 4:05 PM, Joe Maimon wrote: > > > Joe Greco wrote: > >> There's a problem: I can validly emit a variety of other >> addresses, in >> particular any address in 206.55.64.0/20 and some other networks. >> I am >> not "forging" packets if I emit 206.55.64.0/20-sourced addresses >> down a >> Comcast pipe. >> How many people realistically have this problem? Well, potentially, >> lots. Anyone who uses a VPN could have a legitimate IP address on >> their >> machine; because of BCP38 (and other security policy) it is common >> for a VPN setup to forward Internet-bound traffic back to the VPN >> server rather than directly out the Internet. In some cases, one >> could >> reasonably argue that this is undesirable. > > > I would like to take the opportunity to urge vendors of routers and > firewalls to take extra special care and attention to make sure that > The Right Thing can always happen whenever multiple egress services > are employed. > > This means that policy routing for network AND ALL locally generated > traffic should be available and work as the operator intends it to. > This includes the ability to turn OFF stateful inspection in all cases if desired, and, full ability to support asymmetrical (or Triangle) routing in cases where it is desired. Also, not breaking PMTU-D would be good. > Right now things still suck pretty hard, depending on what you are > using. > Indeed. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Sun Oct 25 22:52:29 2009 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Oct 2009 20:52:29 -0700 Subject: ingress filtering and multiple Internet conenctions In-Reply-To: <200910252358.n9PNwWgA050849@aurora.sol.net> References: <200910252358.n9PNwWgA050849@aurora.sol.net> Message-ID: <2C3E1F1C-5EA4-4595-91DD-0ACFC687B68C@delong.com> On Oct 25, 2009, at 4:58 PM, Joe Greco wrote: >> Joe Greco wrote: >>> There's a problem: I can validly emit a variety of other >>> addresses, in >>> particular any address in 206.55.64.0/20 and some other networks. >>> I am >>> not "forging" packets if I emit 206.55.64.0/20-sourced addresses >>> down a >>> Comcast pipe. >>> >>> How many people realistically have this problem? Well, potentially, >>> lots. Anyone who uses a VPN could have a legitimate IP address on >>> their >>> machine; because of BCP38 (and other security policy) it is common >>> for a VPN setup to forward Internet-bound traffic back to the VPN >>> server rather than directly out the Internet. In some cases, one >>> could >>> reasonably argue that this is undesirable. >> >> I would like to take the opportunity to urge vendors of routers and >> firewalls to take extra special care and attention to make sure >> that The >> Right Thing can always happen whenever multiple egress services are >> employed. >> >> This means that policy routing for network AND ALL locally generated >> traffic should be available and work as the operator intends it to. >> >> Right now things still suck pretty hard, depending on what you are >> using. > > Who defines what "The Right Thing" is? > > Allowing (what are to the service provider) random IP's inbound, even > if there's some mechanism to limit it, means that the ISP now has some > additional responsibilities to be able to transport packets for space > that isn't theirs; a transit upstream or peer might filter, especially > for smaller service providers. > > Basically, allowing this dooms BCP38. > Allowing the operator the configuration OPTION in all cases is good. Rational defaults in favor of BCP-38 are acceptable. The inability to override those defaults is bad. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Sun Oct 25 23:01:58 2009 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Oct 2009 21:01:58 -0700 Subject: Nanog Mentioned in TED Video: Jonathan Zittrain In-Reply-To: <5CB296E1-30EF-4487-8B06-8F2CE6D0A56D@ianai.net> References: <4AE3B006.8010407@sandboxitsolutions.com> <3A1A6269-1E97-4C6B-9854-D0E5CD3A7DF9@ianai.net> <583194B6-B8DA-4F67-A29E-12BA80C9D926@delong.com> <5CB296E1-30EF-4487-8B06-8F2CE6D0A56D@ianai.net> Message-ID: <98041BE2-2D1A-4233-A69A-B89C60CC0B3B@delong.com> On Oct 25, 2009, at 5:56 PM, Patrick W. Gilmore wrote: > On Oct 25, 2009, at 2:24 PM, Owen DeLong wrote: >> On Oct 24, 2009, at 6:59 PM, Patrick W. Gilmore wrote: >>> On Oct 24, 2009, at 9:55 PM, Israel Lopez-LISTS wrote: >>> >>>> Remember when youtube went down? >>>> Mr. Zittrain briefly mentions nanog during his TED talk in July >>>> 2009. >>>> >>>> http://www.ted.com/talks/jonathan_zittrain_the_web_is_a_random_act_of_kindness.html >>> >>> Been discussed. >>> >>> He's obviously wrong about some things. No one does anything >>> without getting paid. But he is kinda right in some ways too. >>> >> Lots of us actually do lots of things without getting paid. > > Mea culpa! You are (most obviously) correct. > > I meant to say "no one passes a packet without getting paid", > specifically in response to his passing the beer in the stadium > analogy. > Hurricane Electric offers free IPv6 transit to virtually anyone. We also provide IPv4 transit for free to a number of non-profit and community benefit organizations. > While it is true there are a few packets passed without payment, I'm > pretty sure it's 0% of the total, to several decimal places. > Maybe 2 or 3 decimal places, but, I honestly don't have the exact statistic. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From randy at psg.com Mon Oct 26 00:06:30 2009 From: randy at psg.com (Randy Bush) Date: Mon, 26 Oct 2009 14:06:30 +0900 Subject: ISP port blocking practice/Free Speech In-Reply-To: <356ba1bdf1c4bc43be30d42f76c4108f@mail.dessus.com> References: <4653035@blitz.dartware.com> <356ba1bdf1c4bc43be30d42f76c4108f@mail.dessus.com> Message-ID: should we now look forward to deep technical opinons from law clerks From richard at bennett.com Mon Oct 26 04:10:06 2009 From: richard at bennett.com (Richard Bennett) Date: Mon, 26 Oct 2009 02:10:06 -0700 Subject: ISP port blocking practice/Free Speech In-Reply-To: References: <4653035@blitz.dartware.com> <356ba1bdf1c4bc43be30d42f76c4108f@mail.dessus.com> Message-ID: <4AE5676E.2040005@bennett.com> The U. S. Congress is on the spot already, proposing "strict scrutiny tests" for filtering and forwarding decisions of all kinds. RB Randy Bush wrote: > should we now look forward to deep technical opinons from law clerks > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From nanog-post at rsuc.gweep.net Mon Oct 26 05:03:59 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 26 Oct 2009 06:03:59 -0400 Subject: ISP port blocking practice In-Reply-To: <200910241907.n9OJ7gi5046570@aurora.sol.net> References: <1E5A92E0-8E7B-4307-BA04-2A5129C18D38@delong.com> <200910241907.n9OJ7gi5046570@aurora.sol.net> Message-ID: <20091026100359.GB34644@gweep.net> [tangent of interst for the archives] On Sat, Oct 24, 2009 at 02:07:42PM -0500, Joe Greco wrote: [snip] > If I'm assigned 24.1.2.3 by Comcast, and Comcast filters my ingress to > prevent me from emitting other addresses, you claim that's fine because > it's BCP38. > > There's a problem: I can validly emit a variety of other addresses, in > particular any address in 206.55.64.0/20 and some other networks. I am > not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a > Comcast pipe. Only in your service agreement allows this. Most folks realized both - the bad guys figured out this 'triangle routing' ages ago (was common to send bulk abuse traffic down broadband and receive the ack stream on dialup Back In The Day) and specificlly disallow it. - such hacks to attempt multihoming without BGP fail in spectacular ways nd can't be reled on for any real traffic. So while you may have an allocation and therefore not be 'forging' by strict definitions, you are injecting martian traffic as far as the resi broadband provider is concerned and it should be dropped. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From pstewart at nexicomgroup.net Mon Oct 26 05:19:31 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 26 Oct 2009 06:19:31 -0400 Subject: Simple Change Management Tracking Message-ID: Hi folks... I'm just looking for some feedback ... we are looking for a *really* simple Change Management ticket system. All we want is a system that does the following: Technician opens ticket requesting a network level or server level change outlining the brief details, severity level and date for work to be performed. Senior technical staff/management review and approve/deny Technician completes change and records information in ticket to have it closed off. Ideal would be some kind of email notification option as well. On the surface, this seems really simple but every option (open source and commercial) wants to tie this into a MUCH larger package solution which we don't need. This is to manage approximately 6 people in a specific group of the company. Any input would be appreciated... Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From sven at cb3rob.net Mon Oct 26 05:26:49 2009 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Mon, 26 Oct 2009 10:26:49 +0000 (GMT) Subject: DMCA takedowns of networks In-Reply-To: <51C66083768C2949A7EB14910C78B017A5E351@embgsr24.pateam.com> References: <4AE2FA5F.4090403@gmail.com><16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <51C66083768C2949A7EB14910C78B017A5E351@embgsr24.pateam.com> Message-ID: > I am a strong advocate of free speech and have a track record for both > supporting and exercising it. But the dissenters must be responsible. > Copying a site - copyright infringement - is never free speech, it is > illegal activity. I really don't even care if there is a legal omg... "it's morally wrong"..!!1oneoneeleven well.. that's up for discussion and btw, copyright law was created to protect the investment in a book printing press in order to accomodate people to be able to publish their views on things. now that they can use our internet to publish their work, copyright has become obsolete. (and no, their jedi mind tricks don't work). not to provide leeching attorney firms and lazy artists with free money over the back of the general population. when considering if a law holds any legal value one must look at the situation for which the law was created, as well as democratic aspects and wether it can and should be enforced. (putting 99% of the population in prison because 1% has corrupted the governments and wants to make money on products people clearly no longer want, which they try to sell using an even more outdated business model, isn't rather democratic ;) darwin bitch, the 70s are over. as my 386 already generated all possible combinations of sheet music somewhere in 1996, i'd say all copyrights on music now belong to me. so far for "feasability" (i'm quite sure they piss their pants we would ever enforce their own laws against them, blocking them from ever releasing anything again). there are also people that consider porn "morally wrong" yet porn paid for the entire internet infrastructure, and then ofcourse there are people that consider computers in general "the tool of the devil". you can't give any idiot with some fake "morals" their way. furthermore, we own the internet, we make the rules. use is on an as-is basis and if anyone is to be kicked out they can be damn sure it will be the MPAA/RIAA members first (there is after all, as they so nicely point out themselves, no basic right to having your packets relayed, so they'd better act friendly to isps, or paramount pictures may well find their own networks inaccessible from most of the world rather soon). at this moment, we can see such people as nothing else but a clear threat to the internet itself. -- Sven Olaf Kamphuis CB3ROB DataServices Phone: +31/87-8747479 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sat, 24 Oct 2009, Brandt, Ralph wrote: > HE certainly was right in shutting down that site. It had copyright > infringement. That they took down other sites is reprehensible unless > they lacked the technical capability to do otherwise. (The question > then arises, should they be in business if that is the case?) > > I am a strong advocate of free speech and have a track record for both > supporting and exercising it. But the dissenters must be responsible. > Copying a site - copyright infringement - is never free speech, it is > illegal activity. I really don't even care if there is a legal > copyright notice is its morally wrong and it puts the dissenter in a > category that is probably worse than the other party. That someone > would do that tells me that they are not responsible in dissent and > their message is horse crap. It is flashy lacking in thought and > content. Why would I consider them a valid source of information? > > I think the present administration is illegally there and should be > removed speedily by impeachment. But I would never steal copyright > material to dissent. I have never used his picture because I am not > aware of a free use picture. > > Ralph Brandt > > www.triond.com/users/Ralph+Brandt > > -----Original Message----- > From: Patrick W. Gilmore [mailto:patrick at ianai.net] > Sent: Saturday, October 24, 2009 9:36 AM > To: North American Network Operators Group > Subject: Re: DMCA takedowns of networks > > On Oct 24, 2009, at 9:28 AM, Jeffrey Lyon wrote: > > > Outside of child pornography there is no content that I would ever > > consider > > censoring without a court order nor would I ever purchase transit > > from a > > company that engages in this type of behavior. > > A DMCA takedown order has the force of law. > > This does not mean you should take down an entire network with > unrelated sites. Given He's history, I'm guessing it was a mistake. > > Not buying services from any network that has made a mistake would > quickly leave you with exactly zero options for transit. > > -- > TTFN, > patrick > > > > > On Oct 24, 2009 9:01 AM, "William Allen Simpson" < > > william.allen.simpson at gmail.com> wrote: > > > > > http://www.huffingtonpost.com/2009/10/23/chamber-of-commerce-stron_n_332 > 087.html > > > > Hurricane Electric obeyed the Chamber's letter and shut down the spoof > > site. But in the process, they shut down hundreds of other sites > > maintained by May First / People Link, the Yes Men's direct provider > > (Hurricane Electric is its "upstream" provider). > > > > What's going on? Since when are we required to take down an entire > > customer's net for one of their subscriber's so-called infringement? > > > > Heck, it takes years to agree around here to take down a peering to an > > obviously criminal enterprise network.... > > > > My first inclination would be to return the request (rejected), saying > > it was sent to the wrong provider. > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > X-CONTACT-FILTER-MATCH: "nanog" > X-CONTACT-FILTER-MATCH: "peering" > From bclark at spectraaccess.com Mon Oct 26 05:52:41 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 26 Oct 2009 06:52:41 -0400 Subject: Simple Change Management Tracking In-Reply-To: References: Message-ID: <4AE57F79.7010809@spectraaccess.com> We use [1]http://www.troubleticketexpress.com/ to do just that. While it leans more towards being a customer support system, we've had no problem using it as our internal provisioning/network maintenance system too. Basic, simple and ties into a SQL db. Bret Paul Stewart wrote: Hi folks... I'm just looking for some feedback ... we are looking for a *really* simple Change Management ticket system. All we want is a system that does the following: Technician opens ticket requesting a network level or server level change outlining the brief details, severity level and date for work to be performed. Senior technical staff/management review and approve/deny Technician completes change and records information in ticket to have it closed off. Ideal would be some kind of email notification option as well. On the surface, this seems really simple but every option (open source and commercial) wants to tie this into a MUCH larger package solution which we don't need. This is to manage approximately 6 people in a specific group of the company. Any input would be appreciated... Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you rec eived this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or discl osing same. Thank you." References 1. http://www.troubleticketexpress.com/ From duane.waddle at gmail.com Mon Oct 26 06:08:18 2009 From: duane.waddle at gmail.com (Duane Waddle) Date: Mon, 26 Oct 2009 06:08:18 -0500 Subject: Simple Change Management Tracking In-Reply-To: References: Message-ID: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> On Mon, Oct 26, 2009 at 5:19 AM, Paul Stewart wrote: > Hi folks... > > > > I'm just looking for some feedback ... we are looking for a *really* > simple Change Management ticket system. ?All we want is a system that > does the following: > Hi Paul, Have you considered any of these? [1] Request Tracker -- http://bestpractical.com/ -- Really nice open source ticketing system [2] Bugzilla -- http://www.bugzilla.org -- Another nice tool, built more "for the programmer" then operations. Used by Mozilla and Redhat for their bug trackers. [3] Atlassian JIRA -- http://www.atlassian.com/software/jira/ -- Commercial tool, also more developer-centric then operations-centric, but should be easily adaptable to your needs. Used by ASF many Apache subprojects. Atlassian recently changed their pricing model to include 10 users for $10. Of the three, I personally prefer JIRA -- to the point of setting up one of the $10 systems to keep up with the honey-do list at home. --D From pstewart at nexicomgroup.net Mon Oct 26 06:11:33 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 26 Oct 2009 07:11:33 -0400 Subject: Simple Change Management Tracking In-Reply-To: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> Message-ID: Thanks very much.. We ran RT for a while but every time a new update came out on CentOS it broke the installation (perl mods), making it a pain to keep running. Bugzilla we haven't tried nor the JIRA. I'll take a look... does JIRA have an approval process or some type? Cheers, Paul -----Original Message----- From: Duane Waddle [mailto:duane.waddle at gmail.com] Sent: October 26, 2009 7:08 AM To: nanog at nanog.org Subject: Re: Simple Change Management Tracking On Mon, Oct 26, 2009 at 5:19 AM, Paul Stewart wrote: > Hi folks... > > > > I'm just looking for some feedback ... we are looking for a *really* > simple Change Management ticket system. ?All we want is a system that > does the following: > Hi Paul, Have you considered any of these? [1] Request Tracker -- http://bestpractical.com/ -- Really nice open source ticketing system [2] Bugzilla -- http://www.bugzilla.org -- Another nice tool, built more "for the programmer" then operations. Used by Mozilla and Redhat for their bug trackers. [3] Atlassian JIRA -- http://www.atlassian.com/software/jira/ -- Commercial tool, also more developer-centric then operations-centric, but should be easily adaptable to your needs. Used by ASF many Apache subprojects. Atlassian recently changed their pricing model to include 10 users for $10. Of the three, I personally prefer JIRA -- to the point of setting up one of the $10 systems to keep up with the honey-do list at home. --D ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From regnauld at nsrc.org Mon Oct 26 06:22:26 2009 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 26 Oct 2009 12:22:26 +0100 Subject: Simple Change Management Tracking In-Reply-To: References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> Message-ID: <20091026112223.GE1608@macbook.catpipe.net> Paul Stewart (pstewart) writes: > Thanks very much.. > > We ran RT for a while but every time a new update came out on CentOS it broke the installation (perl mods), making it a pain to keep running. Hi Paul, I'm maintaining RT installs on FreeBSD, Debian, CentOS/RHEL, and so far haven't had any problems. Have you considered using cpan2rpm for the myriad Perl modules required by RT ? Alternatively, there ARE RT36 / RT38 packages for Redhat dists: http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Everything/source/SRPMS/repoview/rt3.html Cheers, Phil From lists at quux.de Mon Oct 26 06:35:43 2009 From: lists at quux.de (Jens Link) Date: Mon, 26 Oct 2009 12:35:43 +0100 Subject: Simple Change Management Tracking In-Reply-To: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> (Duane Waddle's message of "Mon\, 26 Oct 2009 06\:08\:18 -0500") References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> Message-ID: <87bpjubd68.fsf@laphroiag.quux.de> Duane Waddle writes: > [1] Request Tracker -- http://bestpractical.com/ -- Really nice open > source ticketing system OTRS (http://www.otrs.org) might also be an option but as RT it doesn't relay fit the subject (Simple Change...). cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From pstewart at nexicomgroup.net Mon Oct 26 06:37:04 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 26 Oct 2009 07:37:04 -0400 Subject: Simple Change Management Tracking In-Reply-To: <20091026112223.GE1608@macbook.catpipe.net> References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> <20091026112223.GE1608@macbook.catpipe.net> Message-ID: Thanks - it's been a little while since we ran RT .. I believe we were using the actual packages at the time (but could be mistaken). -----Original Message----- From: Phil Regnauld [mailto:regnauld at nsrc.org] Sent: October 26, 2009 7:22 AM To: Paul Stewart Cc: Duane Waddle; nanog at nanog.org Subject: Re: Simple Change Management Tracking Paul Stewart (pstewart) writes: > Thanks very much.. > > We ran RT for a while but every time a new update came out on CentOS it broke the installation (perl mods), making it a pain to keep running. Hi Paul, I'm maintaining RT installs on FreeBSD, Debian, CentOS/RHEL, and so far haven't had any problems. Have you considered using cpan2rpm for the myriad Perl modules required by RT ? Alternatively, there ARE RT36 / RT38 packages for Redhat dists: http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Everythin g/source/SRPMS/repoview/rt3.html Cheers, Phil ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From pstewart at nexicomgroup.net Mon Oct 26 06:39:14 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 26 Oct 2009 07:39:14 -0400 Subject: Simple Change Management Tracking In-Reply-To: <87bpjubd68.fsf@laphroiag.quux.de> References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> <87bpjubd68.fsf@laphroiag.quux.de> Message-ID: Thanks - we're not really looking for so much a ticketing system as more of a "change management approval" system I guess. There was a hosted package offering called "Sargeant Change" at one time but the website disappeared - while I'd rather not have something hosted it was exactly what would work for us... too bad I can't find it any longer. Appreciate the input.. Paul -----Original Message----- From: Jens Link [mailto:lists at quux.de] Sent: October 26, 2009 7:36 AM To: nanog at nanog.org Subject: Re: Simple Change Management Tracking Duane Waddle writes: > [1] Request Tracker -- http://bestpractical.com/ -- Really nice open > source ticketing system OTRS (http://www.otrs.org) might also be an option but as RT it doesn't relay fit the subject (Simple Change...). cheers Jens -- ------------------------------------------------------------------------ - | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------ - ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From lists at quux.de Mon Oct 26 06:56:26 2009 From: lists at quux.de (Jens Link) Date: Mon, 26 Oct 2009 12:56:26 +0100 Subject: Simple Change Management Tracking In-Reply-To: (Paul Stewart's message of "Mon\, 26 Oct 2009 07\:39\:14 -0400") References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> <87bpjubd68.fsf@laphroiag.quux.de> Message-ID: <87d44a9xn9.fsf@laphroiag.quux.de> "Paul Stewart" writes: > Thanks - we're not really looking for so much a ticketing system as more > of a "change management approval" system I guess. Thats why I suggested OTRS only after RT was mentioned. CheckPoint R70.1 has something like this build in but it's only for Check Point and there is (IMHO) a lot of functionality missing. And it's rather slow. cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From nanog at daork.net Mon Oct 26 07:46:05 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 27 Oct 2009 01:46:05 +1300 Subject: Simple Change Management Tracking In-Reply-To: References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> Message-ID: <2E39285F-BE7D-4573-AD93-CC2B68CA2E07@daork.net> On 27/10/2009, at 12:11 AM, Paul Stewart wrote: > We ran RT for a while but every time a new update came out on CentOS > it broke the installation (perl mods), making it a pain to keep > running. Bugzilla we haven't tried nor the JIRA. I'll take a > look... does JIRA have an approval process or some type? I suggest sticking with RT. I run RT on CentOS by maintaining a separate Perl libs dir for the cpan modules that are required by RT and keeping it separate from the OS managed stuff, it works very well. -- Nathan Ward From bjohnson at drtel.com Mon Oct 26 09:40:35 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 26 Oct 2009 09:40:35 -0500 Subject: DMCA takedowns of networks In-Reply-To: <200910241923.n9OJNvXl047092@aurora.sol.net> References: from "Patrick W.Gilmore" at Oct 24, 2009 02:42:51 PM <200910241923.n9OJNvXl047092@aurora.sol.net> Message-ID: <29A54911243620478FF59F00EBB12F4701A61285@ex01.drtel.lan> > > So why are we having this discussion? > > Because it appears that HE took down non-infringing sites? > > Excuse me for stating the obvious. :-) > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - On the technical side of this question... Let's say that a customer is doing virtual hosting. So they have a bunch of sites (Let's say hundreds) on a single IP address. Given that one of the sites is misbehaving (use your own definition), how would a provider block the one site, without blocking others that share the same IP address, without looking at every port 80 request and parsing for the header for the URL? Is there a better solution that doesn't require intrusive parsing? - Brian From jgreco at ns.sol.net Mon Oct 26 09:45:09 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 26 Oct 2009 08:45:09 -0600 (CST) Subject: DMCA takedowns of networks In-Reply-To: <29A54911243620478FF59F00EBB12F4701A61285@ex01.drtel.lan> from "Brian Johnson" at Oct 26, 2009 09:40:35 AM Message-ID: <200910261445.n9QEj9CX027566@aurora.sol.net> > > > So why are we having this discussion? > > > > Because it appears that HE took down non-infringing sites? > > > > Excuse me for stating the obvious. :-) > > > > ... JG > > -- > > Joe Greco - sol.net Network Services - Milwaukee, WI - > > On the technical side of this question... > > Let's say that a customer is doing virtual hosting. So they have a bunch > of sites (Let's say hundreds) on a single IP address. Given that one of > the sites is misbehaving (use your own definition), how would a provider > block the one site, without blocking others that share the same IP > address, without looking at every port 80 request and parsing for the > header for the URL? > > Is there a better solution that doesn't require intrusive parsing? Sure. Tell the hoster they've got to shut it down, or else lose their connectivity. Sometimes it can be both simple *and* obvious. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From john at vanoppen.com Mon Oct 26 09:51:04 2009 From: john at vanoppen.com (John van Oppen) Date: Mon, 26 Oct 2009 07:51:04 -0700 Subject: DMCA takedowns of networks References: <200910261445.n9QEj9CX027566@aurora.sol.net> Message-ID: I think that is a pretty standard procedure. We generally give our users 12 hours to remove the content before we null-route the IP... The only time this does not apply is with active spam sources, simple and quite effective. Thanks, John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Monday, October 26, 2009 7:45 AM To: Brian Johnson Cc: North American Network Operators Group Subject: Re: DMCA takedowns of networks > > > So why are we having this discussion? > > > > Because it appears that HE took down non-infringing sites? > > > > Excuse me for stating the obvious. :-) > > > > ... JG > > -- > > Joe Greco - sol.net Network Services - Milwaukee, WI - > > On the technical side of this question... > > Let's say that a customer is doing virtual hosting. So they have a bunch > of sites (Let's say hundreds) on a single IP address. Given that one of > the sites is misbehaving (use your own definition), how would a provider > block the one site, without blocking others that share the same IP > address, without looking at every port 80 request and parsing for the > header for the URL? > > Is there a better solution that doesn't require intrusive parsing? Sure. Tell the hoster they've got to shut it down, or else lose their connectivity. Sometimes it can be both simple *and* obvious. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jbates at brightok.net Mon Oct 26 09:52:01 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Oct 2009 09:52:01 -0500 Subject: DMCA takedowns of networks In-Reply-To: References: <200910261445.n9QEj9CX027566@aurora.sol.net> Message-ID: <4AE5B791.4020208@brightok.net> John van Oppen wrote: > I think that is a pretty standard procedure. We generally give our > users 12 hours to remove the content before we null-route the IP... > The only time this does not apply is with active spam sources, simple > and quite effective. > And yet, that may have been exactly what happened. Lack of information always leads to much speculation. Jack From bjohnson at drtel.com Mon Oct 26 10:11:47 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 26 Oct 2009 10:11:47 -0500 Subject: DMCA takedowns of networks In-Reply-To: <4AE5B791.4020208@brightok.net> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> Message-ID: <29A54911243620478FF59F00EBB12F4701A61298@ex01.drtel.lan> > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Monday, October 26, 2009 9:52 AM > To: John van Oppen > Cc: Joe Greco; Brian Johnson; North American Network Operators Group > Subject: Re: DMCA takedowns of networks > > John van Oppen wrote: > > I think that is a pretty standard procedure. We generally give our > > users 12 hours to remove the content before we null-route the IP... > > The only time this does not apply is with active spam sources, simple > > and quite effective. > > > > And yet, that may have been exactly what happened. Lack of information > always leads to much speculation. > > > Jack You beat me to it, but my point exactly. Is there any reason to believe that HE didn't do that? The report doesn't mention if HE contacted the customer before doing this. Let's put away our rollers and take out our watercolor brushes. - Brian From deleskie at gmail.com Mon Oct 26 10:12:39 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 26 Oct 2009 15:12:39 +0000 Subject: What should ISPs ASPs MSPs xSPs do? Message-ID: <26294456-1256572135-cardhu_decombobulator_blackberry.rim.net-78134738-@bda023.bisx.prod.on.blackberry> I always make the assumption that I'm on my own and now one will help. If they do GREAT if not, sucks to be but I'm prepared. In a perfect world we all help others, but if the people paying any givens person paycheck have other issues tasked to higher priority levels then I can blame or fault them for not helping me. -jim ------Original Message------ From: Sean Donelan To: nanog at nanog.org Subject: What should ISPs ASPs MSPs xSPs do? Sent: Oct 25, 2009 7:13 PM Other than the usual damned if they do, damned if they don't; is there any rough consensus about some practical things ISPs, ASPs, MSPs, xSPs (and customers/users) should do or should not do? Or is it just rough consensus what other people should do, but you'll get upset if that rough consensus stopped you from doing something? Stop stuff you don't like immediately, anytime of the day or night; but give you years to fix your stuff even if it is hurting other people's stuff. Sent from my BlackBerry device on the Rogers Wireless Network From zeusdadog at gmail.com Mon Oct 26 10:55:42 2009 From: zeusdadog at gmail.com (Jay Nakamura) Date: Mon, 26 Oct 2009 11:55:42 -0400 Subject: Alcatel-Lucent VPN Firewall Brick Message-ID: <9418aca70910260855l5234c769j96ca628a717d1e7d@mail.gmail.com> Hello all, Looking for input on Alcatel-Lucent VPN Firewall Brick. I can look up spec and other published information but, as always, the devil is in the detail and you just never know what wall you run into until you actually try it so I wanted to see if anyone has used this and can point out good/bad things about this device. Our other option is Cisco IOS router right now. Are there better options than these two? If there is a better forum to post this question, my apologies. Please direct me to the right place. :) Our goal : We want to provide managed firewall/VPN for Colo/DIA customers. Our specific requirements are - Able to provide VRF/virtual router per customer since address range can overlap between customers. - Able to do client based VPN to the inside network. It could be IPSec or SSL. It has to support Vista/Win7-x64 - Able to do site to site VPN with various devices.(Cisco, - Can rate limit traffic in and out. - Control NAT per customer instance. - Stateful firewall per customer instance. - Good logging Thanks! From awacs at ziskind.us Mon Oct 26 11:06:10 2009 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Mon, 26 Oct 2009 12:06:10 -0400 Subject: DMCA takedowns of networks In-Reply-To: <4AE5B791.4020208@brightok.net> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> Message-ID: <20091026120610.C17121@egps.egps.com> Jack Bates wrote (on Mon, Oct 26, 2009 at 09:52:01AM -0500): > John van Oppen wrote: > >I think that is a pretty standard procedure. We generally give our > >users 12 hours to remove the content before we null-route the IP... > >The only time this does not apply is with active spam sources, simple > >and quite effective. > > > > And yet, that may have been exactly what happened. Lack of information > always leads to much speculation. > > > Jack But, if HE *didn't* do that, why aren't they commenting? Like, on this forum, for example? HE ppl seem to know the address of NANOG ... -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From shrdlu at deaddrop.org Mon Oct 26 11:11:48 2009 From: shrdlu at deaddrop.org (Shrdlu) Date: Mon, 26 Oct 2009 09:11:48 -0700 Subject: DMCA takedowns of networks In-Reply-To: <20091026120610.C17121@egps.egps.com> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> <20091026120610.C17121@egps.egps.com> Message-ID: <4AE5CA44.4030706@deaddrop.org> N. Yaakov Ziskind wrote: > Jack Bates wrote (on Mon, Oct 26, 2009 at 09:52:01AM -0500): >>John van Oppen wrote: >>>I think that is a pretty standard procedure. We generally give our >>>users 12 hours to remove the content before we null-route the IP... >>And yet, that may have been exactly what happened. Lack of information >>always leads to much speculation. > But, if HE *didn't* do that, why aren't they commenting? Like, on this > forum, for example? HE ppl seem to know the address of NANOG ... They aren't commenting (this is an opinion, and I have NO inside information) because it's a legal matter. Jeeze, people, go on their reputation. Hurricane Electric are the good guys. Enough already. -- Open source should be about giving away things voluntarily. When you force someone to give you something, it's no longer giving, it's stealing. Persons of leisurely moral growth often confuse giving with taking. -- Larry Wall From dyoung at mesd.k12.or.us Mon Oct 26 11:19:00 2009 From: dyoung at mesd.k12.or.us (Dan Young) Date: Mon, 26 Oct 2009 09:19:00 -0700 Subject: Simple Change Management Tracking In-Reply-To: <20091026112223.GE1608@macbook.catpipe.net> References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> <20091026112223.GE1608@macbook.catpipe.net> Message-ID: <994441ae0910260919m57a21623w39736790daa68b1c@mail.gmail.com> On Mon, Oct 26, 2009 at 4:22 AM, Phil Regnauld wrote: > Paul Stewart (pstewart) writes: >> Thanks very much.. >> >> We ran RT for a while but every time a new update came out on CentOS it broke the installation (perl mods), making it a pain to keep running. > > ? ? ? ?Hi Paul, > > ? ? ? ?I'm maintaining RT installs on FreeBSD, Debian, CentOS/RHEL, and so far > ? ? ? ?haven't had any problems. > > ? ? ? ?Have you considered using cpan2rpm for the myriad Perl modules required > ? ? ? ?by RT ? > > ? ? ? ?Alternatively, there ARE RT36 / RT38 packages for Redhat dists: If you want Fedora-ish packages built for RHEL/CentOS, getting them from EPEL is a better choice: http://download.fedora.redhat.com/pub/epel/5/i386/repoview/rt3.html http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/rt3.html http://fedoraproject.org/wiki/EPEL Oh, and my recommendation for something simpler would be: http://roundup.sourceforge.net/ http://download.fedora.redhat.com/pub/epel/5/i386/repoview/roundup.html http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/roundup.html -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From mohacsi at niif.hu Mon Oct 26 11:25:33 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 26 Oct 2009 17:25:33 +0100 (CET) Subject: Simple Change Management Tracking In-Reply-To: <2E39285F-BE7D-4573-AD93-CC2B68CA2E07@daork.net> References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> <2E39285F-BE7D-4573-AD93-CC2B68CA2E07@daork.net> Message-ID: On Tue, 27 Oct 2009, Nathan Ward wrote: > On 27/10/2009, at 12:11 AM, Paul Stewart wrote: >> We ran RT for a while but every time a new update came out on CentOS it >> broke the installation (perl mods), making it a pain to keep running. >> Bugzilla we haven't tried nor the JIRA. I'll take a look... does JIRA have >> an approval process or some type? > > I suggest sticking with RT. > > I run RT on CentOS by maintaining a separate Perl libs dir for the cpan > modules that are required by RT and keeping it separate from the OS managed > stuff, it works very well. If you are already using drupal portal software I recommend this: http://drupal.org/project/ticketing Best Regards, Janos Mohacsi From regnauld at nsrc.org Mon Oct 26 11:29:24 2009 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 26 Oct 2009 17:29:24 +0100 Subject: Simple Change Management Tracking In-Reply-To: <994441ae0910260919m57a21623w39736790daa68b1c@mail.gmail.com> References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> <20091026112223.GE1608@macbook.catpipe.net> <994441ae0910260919m57a21623w39736790daa68b1c@mail.gmail.com> Message-ID: <20091026162920.GA5209@macbook.catpipe.net> Dan Young (dyoung) writes: > If you want Fedora-ish packages built for RHEL/CentOS, getting them > from EPEL is a better choice: > http://download.fedora.redhat.com/pub/epel/5/i386/repoview/rt3.html > http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/rt3.html Yes, EPEL is ok, but they're out of date. > Oh, and my recommendation for something simpler would be: > http://roundup.sourceforge.net/ > http://download.fedora.redhat.com/pub/epel/5/i386/repoview/roundup.html > http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/roundup.html That's another possibility -- but the original request (to stay somewhat on topic) is to implement a Change Management Tracking, possibly with Approval. This is possible in RT using Scrips and custom keywords: http://wiki.bestpractical.com/view/ApprovalCreation Would roundup allow this ? Cheers, Phil From streiner at cluebyfour.org Mon Oct 26 11:36:08 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 26 Oct 2009 12:36:08 -0400 (EDT) Subject: Alcatel-Lucent VPN Firewall Brick In-Reply-To: <9418aca70910260855l5234c769j96ca628a717d1e7d@mail.gmail.com> References: <9418aca70910260855l5234c769j96ca628a717d1e7d@mail.gmail.com> Message-ID: On Mon, 26 Oct 2009, Jay Nakamura wrote: > Looking for input on Alcatel-Lucent VPN Firewall Brick. I can look up > spec and other published information but, as always, the devil is in > the detail and you just never know what wall you run into until you > actually try it so I wanted to see if anyone has used this and can > point out good/bad things about this device. > > Our other option is Cisco IOS router right now. Are there better > options than these two? Fair warning: v6 honestly seems to have caught most firewall vendors with their pants down. I've had Lucent Bricks hanging around here in various capacities for some time, and have been involved in a several bake-offs to some degree. Granted, the bricks we have are older models (1100s, mostly). We're looking at some new options as well as a number of ours are going EOL soon. Good: * The code and a basic config is very small - just enough to get it on the network to communicate with the LSMS server and download its full config. * Support is reasonably responsive. * Rule changes can be staged pretty easily in the LSMS, and then the changes can be applied later, if you only do changes during maintenance windows. * IPSEC LAN-to-LAN VPN interoperability is pretty good. It can take a few tweaks to get things working with different vendors, but I've gotten VPNs working with Cisco routers, Cisco PIX/ASAs, Linksys, Checkpoint, Netscreen, etc... * It does do TCP state enforcement (can be disabled) and you can configure the timeout if you enable enforcement. * It does layer-2 firewalling, if you need it. * Does partitions, which provides VRF-like functionality. * Rate limiting and NAT are supported, but I don't know how robust the NAT support is - we don't use it. * Logging is fairly robust but somewhat cryptic - it's not in a standard syslog format. Writing a script to parse the logs and make them a little more human-friendly or convert them into a syslog format would be pretty straightforward. Newer versions of LSMS might provide the option of logging in a syslog-compatible format. Bad: * Without the LSMS server(s), the Bricks are, quite literally, bricks. All of the management has to be done through the LSMS and its Windows- only GUI. There is a command-line interface, but it is not very robust. Newer versions of LSMS might have a web front-end, but I don't know for sure. If there is a web front-end to LSMS, the trick is finding out if it has feature parity with the Windows GUI (has presented an issue with other Lucent products). * Licensing can be a PITA. * Last time I looked at the IPSEC VPN client, it did not support Vista or 64-bit XP. I haven't looked into this in a long time, as we do not use the Bricks for landing client VPNs. It's possible that Lucent has SSL VPN capabilities now. No idea if they support Windows 7 yet. * If things start failing or hanging in neat and interesting ways, more often than not, the issue can be fixed by restarting LSMS :) * IPv6 support plans are unknown at this time. Since we're migrating away from this platform, I haven't looked into Lucent's position on this. I don't know if the newer models do 10G yet, but that might be worth checking if you plan to firewall customers who need lots of bandwidth. We can talk offline if you want to discuss in more detail. jms > If there is a better forum to post this question, my apologies. > Please direct me to the right place. :) > > Our goal : > > We want to provide managed firewall/VPN for Colo/DIA customers. > > Our specific requirements are > - Able to provide VRF/virtual router per customer since address range > can overlap between customers. > - Able to do client based VPN to the inside network. It could be > IPSec or SSL. It has to support Vista/Win7-x64 > - Able to do site to site VPN with various devices.(Cisco, > - Can rate limit traffic in and out. > - Control NAT per customer instance. > - Stateful firewall per customer instance. > - Good logging > > > Thanks! > > From sven at cyberbunker.com Mon Oct 26 12:24:46 2009 From: sven at cyberbunker.com (Sven Olaf Kamphuis) Date: Mon, 26 Oct 2009 17:24:46 +0000 (GMT) Subject: DMCA takedowns of networks In-Reply-To: <200910261445.n9QEj9CX027566@aurora.sol.net> References: <200910261445.n9QEj9CX027566@aurora.sol.net> Message-ID: > > Is there a better solution that doesn't require intrusive parsing? > > Sure. Tell the hoster they've got to shut it down, or else lose their > connectivity. which would be called "blackmail". sure, have the cops arrest the guy that actually runs the site or uploaded it onto the site, if they cannot (because it simply doesnt happen to be illegal in the country where he resides) they are out of luck and have to live with it. furthermore, in any case, a proper court order specifically mentioning the url, the customer, the right company out of our christmastree of companies worldwide, etc would be required as we dont plan to decide whats illegal and what not. ofcourse all of this only applies to "real crime". not to whining dmca idiots, whom are criminals themselves. -- Sven Olaf Kamphuis CB3ROB DataServices Phone: +31/87-8747479 Skype: CB3ROB MSN: sven at cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Mon, 26 Oct 2009, Joe Greco wrote: > > > > So why are we having this discussion? > > > > > > Because it appears that HE took down non-infringing sites? > > > > > > Excuse me for stating the obvious. :-) > > > > > > ... JG > > > -- > > > Joe Greco - sol.net Network Services - Milwaukee, WI - > > > > On the technical side of this question... > > > > Let's say that a customer is doing virtual hosting. So they have a bunch > > of sites (Let's say hundreds) on a single IP address. Given that one of > > the sites is misbehaving (use your own definition), how would a provider > > block the one site, without blocking others that share the same IP > > address, without looking at every port 80 request and parsing for the > > header for the URL? > > > > Is there a better solution that doesn't require intrusive parsing? > > Sure. Tell the hoster they've got to shut it down, or else lose their > connectivity. > > Sometimes it can be both simple *and* obvious. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. > > > X-CONTACT-FILTER-MATCH: "nanog" > From dyoung at mesd.k12.or.us Mon Oct 26 12:40:57 2009 From: dyoung at mesd.k12.or.us (Dan Young) Date: Mon, 26 Oct 2009 10:40:57 -0700 Subject: Simple Change Management Tracking In-Reply-To: <20091026162920.GA5209@macbook.catpipe.net> References: <80e7195b0910260408x10c3f09fvb066e17c321b35d2@mail.gmail.com> <20091026112223.GE1608@macbook.catpipe.net> <994441ae0910260919m57a21623w39736790daa68b1c@mail.gmail.com> <20091026162920.GA5209@macbook.catpipe.net> Message-ID: <994441ae0910261040y4fb92090o129063bf615996f4@mail.gmail.com> On Mon, Oct 26, 2009 at 9:29 AM, Phil Regnauld wrote: > Dan Young (dyoung) writes: >> If you want Fedora-ish packages built for RHEL/CentOS, getting them >> from EPEL is a better choice: >> http://download.fedora.redhat.com/pub/epel/5/i386/repoview/rt3.html >> http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/rt3.html > > ? ? ? ?Yes, EPEL is ok, but they're out of date. If there's not a security issue, that's a feature, not a bug. The OP's complaint seems to be that the upgrade treadmill breaks things. >> Oh, and my recommendation for something simpler would be: >> http://roundup.sourceforge.net/ >> http://download.fedora.redhat.com/pub/epel/5/i386/repoview/roundup.html >> http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/roundup.html > > ? ? ? ?That's another possibility -- but the original request (to stay somewhat > ? ? ? ?on topic) is to implement a Change Management Tracking, possibly with > ? ? ? ?Approval. > > ? ? ? ?This is possible in RT using Scrips and custom keywords: > ? ? ? ?http://wiki.bestpractical.com/view/ApprovalCreation > > ? ? ? ?Would roundup allow this ? Roundup has role-based permissions, including "signoff" by a manager role: http://roundup.sourceforge.net/doc-1.0/design.html#use-cases -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From ras at e-gerbil.net Mon Oct 26 12:48:20 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 26 Oct 2009 12:48:20 -0500 Subject: DMCA takedowns of networks In-Reply-To: <29A54911243620478FF59F00EBB12F4701A61298@ex01.drtel.lan> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> <29A54911243620478FF59F00EBB12F4701A61298@ex01.drtel.lan> Message-ID: <20091026174820.GF51443@gerbil.cluepon.net> On Mon, Oct 26, 2009 at 10:11:47AM -0500, Brian Johnson wrote: > > Is there any reason to believe that HE didn't do that? The report > doesn't mention if HE contacted the customer before doing this. According to May First's own statement, this is exactly what happened: https://support.mayfirst.org/wiki/chamber-he-statement > The U.S. Chamber of Commerce sent Hurricane Electric a letter > complaining about a website spoofing the Chamber's obstructionism on > climate change policies that was created by MF/PL member the Yes Men > (read more about the spoof). > > Hurricane Electric immediately ordered us to remove the spoofed site > or face a turn-off of service. We responded that such a demand was: > > * arbitrary since it represented a legally untested complaint; > * unconstitutional since it quashed the fair use of logos in a > satirical way; > * and overreaching because it affected 3/4 of of our membership (over > 300 organizations) whose websites, email and other online tools > would be taken down in such an action. 1. Hurricane receives complaint letter 2. Hurricane notifies customer and requests that they remove content 3. Customer claims that content is fair use and not violating copyright 4. Hurricane turns customer off anyways 5. Customer agrees to move content elsewhere 6. Hurricane turns them back on They neglect to mention if May First has a registered DMCA agent (in which case they could have handled the complaint directly and not involved Hurricane), or if they responded with a proper DMCA counter notification. Had either of these been the case, Hurricane would have had no liability in the matter. Of course Hurricane is well within their rights not to serve any customer that they please, but the customer is also well within their rights to find another provider who better respects the rights of free speech on the Internet (if the above is what actually happened). -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From joly at punkcast.com Mon Oct 26 13:03:03 2009 From: joly at punkcast.com (Joly MacFie) Date: Mon, 26 Oct 2009 14:03:03 -0400 Subject: DMCA takedowns of networks In-Reply-To: References: <4AE2FA5F.4090403@gmail.com> <16720fe00910240628o3d9156d7v18f63e7bd634b135@mail.gmail.com> <51C66083768C2949A7EB14910C78B017A5E351@embgsr24.pateam.com> Message-ID: <313b48d0910261103r58cb3606p41311af9dc0c9caa@mail.gmail.com> [realizing that I am veering OT] Last Thursday I videotaped a talk "Jefferson's Moose in Cyberspace" in NYC. http://www.isoc-ny.org/?p=959 (still editing - soon come) One point made was that the "progress" vs "moral rights" dichotomy in copyright philosophy is so deep that there really is little, if any, prospect of consensus. About 10 days ago I videotaped another one - William Patry, Chief Copyright Counsel at Google - "Moral Panics & Copyright Wars" http://www.isoc-ny.org/?p=990 His theme is that the two points of view are irrelevant, all that's needed is an effective law in the public interest. At the 'Moose' talk one attendee, who I later learned is a criminal court judge was particularly vociferous on the moral right side. I spoke with him afterwards and he volunteered the opinion that the internet itself was not in the public interest and should be shut down forthwith by the governments of the world, since it is they who control the satellites! joly On Mon, Oct 26, 2009 at 6:26 AM, Sven Olaf Kamphuis wrote: > omg... "it's morally wrong"..!!1oneoneeleven > > well.. that's up for discussion and btw, copyright law was created to > protect the investment in a book printing press in order to accomodate > people to be able to publish their views on things. > -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From operator at etbweb.net Mon Oct 26 13:24:56 2009 From: operator at etbweb.net (Eric RICHARD) Date: Mon, 26 Oct 2009 19:24:56 +0100 Subject: Alcatel-Lucent VPN Firewall Brick In-Reply-To: <9418aca70910260855l5234c769j96ca628a717d1e7d@mail.gmail.com> References: <9418aca70910260855l5234c769j96ca628a717d1e7d@mail.gmail.com> Message-ID: <005a01ca5669$a2c14390$e843cab0$@net> Hello, I am working for a French ISP, we are working with this product in order to provide a firewall for our VRF customers. Quickly : Used to : * Firewall / NAT for IPV4 VRF * Rate limit bandwidth & sessions * A few logging Pro: * stable * ipsec & pptp passthrough Cons : * ugly java interface Really good feedbacks to provide . If you need further detail I can share. Eric -----Message d'origine----- De?: Jay Nakamura [mailto:zeusdadog at gmail.com] Envoy??: lundi 26 octobre 2009 16:56 ??: NANOG Objet?: Alcatel-Lucent VPN Firewall Brick Hello all, Looking for input on Alcatel-Lucent VPN Firewall Brick. I can look up spec and other published information but, as always, the devil is in the detail and you just never know what wall you run into until you actually try it so I wanted to see if anyone has used this and can point out good/bad things about this device. Our other option is Cisco IOS router right now. Are there better options than these two? If there is a better forum to post this question, my apologies. Please direct me to the right place. :) Our goal : We want to provide managed firewall/VPN for Colo/DIA customers. Our specific requirements are - Able to provide VRF/virtual router per customer since address range can overlap between customers. - Able to do client based VPN to the inside network. It could be IPSec or SSL. It has to support Vista/Win7-x64 - Able to do site to site VPN with various devices.(Cisco, - Can rate limit traffic in and out. - Control NAT per customer instance. - Stateful firewall per customer instance. - Good logging Thanks! From jbates at brightok.net Mon Oct 26 13:44:25 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Oct 2009 13:44:25 -0500 Subject: DMCA takedowns of networks In-Reply-To: <20091026174820.GF51443@gerbil.cluepon.net> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> <29A54911243620478FF59F00EBB12F4701A61298@ex01.drtel.lan> <20091026174820.GF51443@gerbil.cluepon.net> Message-ID: <4AE5EE09.2090207@brightok.net> Richard A Steenbergen wrote: > had no liability in the matter. Of course Hurricane is well within their > rights not to serve any customer that they please, but the customer is > also well within their rights to find another provider who better > respects the rights of free speech on the Internet (if the above is what > actually happened). > I'm sure HE respects the rights of free speech just fine. That being said, a notice was delivered, customer may not have replied with the appropriate legal notice, and so HE honored it's obligation to maintain safe harbor. One would have to be an idiot to jeopardize their company by rolling the dice in an effort to protect free speech (which may not legally be free speech). Courts determine what is free speech. ISPs just try to stay the hell out of the way. Jack From williams.bruce at gmail.com Mon Oct 26 14:16:57 2009 From: williams.bruce at gmail.com (Bruce Williams) Date: Mon, 26 Oct 2009 12:16:57 -0700 Subject: DMCA takedowns of networks In-Reply-To: <4AE5EE09.2090207@brightok.net> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> <29A54911243620478FF59F00EBB12F4701A61298@ex01.drtel.lan> <20091026174820.GF51443@gerbil.cluepon.net> <4AE5EE09.2090207@brightok.net> Message-ID: <775e001a0910261216h4ba7b1b6k71687b2df40cb11e@mail.gmail.com> On Mon, Oct 26, 2009 at 11:44 AM, Jack Bates wrote: > Richard A Steenbergen wrote: >> >> had no liability in the matter. Of course Hurricane is well within their >> rights not to serve any customer that they please, but the customer is also >> well within their rights to find another provider who better respects the >> rights of free speech on the Internet (if the above is what actually >> happened). >> > > I'm sure HE respects the rights of free speech just fine. That being said, a > notice was delivered, customer may not have replied with the appropriate > legal notice, and so HE honored it's obligation to maintain safe harbor. > > One would have to be an idiot to jeopardize their company by rolling the > dice in an effort to protect free speech (which may not legally be free > speech). Courts determine what is free speech. ISPs just try to stay the > hell out of the way. > > Jack > > Just to add some facts to the debate, the "Yes Men" get them themselves somehow on as speakers to some group such as the COC and give a speech that exposes the organization to ridicule. For example they pretended to discover climate change would be bad for business at the COC and proposed the return to slavery as a solution to Africa's economic problems at a Wharton Business School conference. The amazing thing is their pronouncements are taken seriously by the audience. I am not a lawyer, but I know satire when I see it and this is damn good political satire, something the courts have given broad free speech protection to. Satire can incorporate a great deal without copyright infringement. The Supreme Court ruled that a song named "Pretty Woman" that used much of the words and all the music of another song "Pretty Woman" that satires the original song by having the "pretty woman walking down the street" being a prostitute in their neighborhood and arrested was protected speech in spite of consisting of over 90% of the original work. Not that HE should act as a judge, but just to clarify what is being done. http://theyesmen.org/ Bruce Williams From simon at darkmere.gen.nz Mon Oct 26 14:26:32 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Tue, 27 Oct 2009 08:26:32 +1300 (NZDT) Subject: ADMIN: DMCA takedowns of networks In-Reply-To: <4AE5EE09.2090207@brightok.net> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> <29A54911243620478FF59F00EBB12F4701A61298@ex01.drtel.lan> <20091026174820.GF51443@gerbil.cluepon.net> <4AE5EE09.2090207@brightok.net> Message-ID: A reminder that discussion of the following topics and off-topic for the NANOG list: 6. Postings of political, philosophical, and legal nature are prohibited. Simon Lyall NANOG MLC ( on behalf of) -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From jbates at brightok.net Mon Oct 26 15:23:43 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 26 Oct 2009 15:23:43 -0500 Subject: DMCA takedowns of networks In-Reply-To: <775e001a0910261216h4ba7b1b6k71687b2df40cb11e@mail.gmail.com> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> <29A54911243620478FF59F00EBB12F4701A61298@ex01.drtel.lan> <20091026174820.GF51443@gerbil.cluepon.net> <4AE5EE09.2090207@brightok.net> <775e001a0910261216h4ba7b1b6k71687b2df40cb11e@mail.gmail.com> Message-ID: <4AE6054F.8030301@brightok.net> Bruce Williams wrote: > Not that HE should act as a judge, but just to clarify what is being done. > Hey. I think it's great satire. Given the nature of their content, you'd expect them to have been better prepared for a DMCA notice. I suspect they will be in the future. Jack From feldman at twincreeks.net Mon Oct 26 15:40:07 2009 From: feldman at twincreeks.net (Steve Feldman) Date: Mon, 26 Oct 2009 13:40:07 -0700 Subject: [NANOG-announce] NANOG 47 wrap-up (and survey reminder!) Message-ID: <30DB57B9-9EC3-4CA1-95E5-7A8E5124F5B1@twincreeks.net> Thanks again to everyone who attended NANOG 47 in Dearborn, or watched remotely. Arbor Networks and Merit Network were wonderful hosts, and the Program Committee and presenters combined to give us an excellent program. Special thanks also go to the ARIN staff, who worked closely with Merit and the PC to produce a successful week of meetings. A reminder to those of you who participated: please fill out the meeting survey, at http://tinyurl.com/nanog47. We depend on that information to provide you with useful and high-quality meetings. I look forward to seeing everyone again at NANOG 48 on February 21-24, 2010 in Austin, Texas. The call for presentations will be announced soon, and registration will open next week. Steve Feldman SC Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From brandon.galbraith at gmail.com Mon Oct 26 15:58:59 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 26 Oct 2009 15:58:59 -0500 Subject: Power Analysis/Management Tools Message-ID: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> Not to go too off-topic, but if there is a more preferred location for me to ask, please let me know. I'm looking for recommendations on open source packages that people are using for monitoring power utilization of their network/server gear. We're using Cacti currently, pulling the data from APCs via SNMP, and I wanted to check if someone had come across a better method before I reinvented the wheel. From dpeterson at sixapart.com Mon Oct 26 16:12:39 2009 From: dpeterson at sixapart.com (David B. Peterson) Date: Mon, 26 Oct 2009 14:12:39 -0700 Subject: Power Analysis/Management Tools In-Reply-To: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> References: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> Message-ID: <34654A72-DAD3-4D46-AF6C-122C818C1628@sixapart.com> I do the same, but with ganglia. I've noticed that different APCs report power differently (after comparing APC output to BCMS output.) Our newer servers also report power consumption via IPMI: /usr/bin/ ipmitool sdr type "Current". We also graph that via ganglia. -Dave On Oct 26, 2009, at 1:58 PM, Brandon Galbraith wrote: > Not to go too off-topic, but if there is a more preferred location > for me to > ask, please let me know. I'm looking for recommendations on open > source > packages that people are using for monitoring power utilization of > their > network/server gear. > > We're using Cacti currently, pulling the data from APCs via SNMP, > and I > wanted to check if someone had come across a better method before I > reinvented the wheel. From morrowc.lists at gmail.com Mon Oct 26 16:29:23 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 26 Oct 2009 17:29:23 -0400 Subject: Alcatel-Lucent VPN Firewall Brick In-Reply-To: References: <9418aca70910260855l5234c769j96ca628a717d1e7d@mail.gmail.com> Message-ID: <75cb24520910261429h54a97bddp591005ee90aff596@mail.gmail.com> On Mon, Oct 26, 2009 at 12:36 PM, Justin M. Streiner wrote: > On Mon, 26 Oct 2009, Jay Nakamura wrote: > >> Looking for input on Alcatel-Lucent VPN Firewall Brick. ?I can look up >> spec and other published information but, as always, the devil is in >> the detail and you just never know what wall you run into until you >> actually try it so I wanted to see if anyone has used this and can >> point out good/bad things about this device. >> >> Our other option is Cisco IOS router right now. ?Are there better >> options than these two? > > Fair warning: v6 honestly seems to have caught most firewall vendors with > their pants down. I'm not really sure that in the year 2009 that's a fair thing to still expect... honestly ipv6 has been in 'production' for ~7 years, for a CPE deployment it's certainly been to the point where it should be included by default. -1 alcalu :( -Chris From Greg.Whynott at oicr.on.ca Mon Oct 26 16:33:01 2009 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 26 Oct 2009 17:33:01 -0400 Subject: Power Analysis/Management Tools In-Reply-To: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> References: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> Message-ID: I'd think SNMP will be what any product uses to query APC gear, even their own suite uses SNMP to collect information and receive traps. We use cacti to graph our loads on the APC power bars and UPS gear, gives you everything you need on all phases/legs, was there something in particular you were after? -g -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Monday, October 26, 2009 4:59 PM To: nanog at nanog.org Subject: Power Analysis/Management Tools Not to go too off-topic, but if there is a more preferred location for me to ask, please let me know. I'm looking for recommendations on open source packages that people are using for monitoring power utilization of their network/server gear. We're using Cacti currently, pulling the data from APCs via SNMP, and I wanted to check if someone had come across a better method before I reinvented the wheel. From randy at psg.com Mon Oct 26 16:54:43 2009 From: randy at psg.com (Randy Bush) Date: Tue, 27 Oct 2009 06:54:43 +0900 Subject: DMCA takedowns of networks In-Reply-To: <20091026120610.C17121@egps.egps.com> References: <200910261445.n9QEj9CX027566@aurora.sol.net> <4AE5B791.4020208@brightok.net> <20091026120610.C17121@egps.egps.com> Message-ID: > But, if HE *didn't* do that, why aren't they commenting? Like, on this > forum, for example? HE ppl seem to know the address of NANOG ... probably because they, like many of us, are deeply amused by days of conjecturbation. randy From bjohnson at drtel.com Mon Oct 26 17:03:29 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 26 Oct 2009 17:03:29 -0500 Subject: DMCA takedowns of networks In-Reply-To: References: <200910261445.n9QEj9CX027566@aurora.sol.net> Message-ID: <29A54911243620478FF59F00EBB12F4701A612F4@ex01.drtel.lan> Per Dictionary.com: blackmail -noun 1. any payment extorted by intimidation, as by threats of injurious revelations or accusations. 2. the extortion of such payment: He confessed rather than suffer the dishonor of blackmail. 3. a tribute formerly exacted in the north of England and in Scotland by freebooting chiefs for protection from pillage. -verb (used with object) 4. to extort money from (a person) by the use of threats. 5. to force or coerce into a particular action, statement, etc.: The strikers claimed they were blackmailed into signing the new contract. ... thus, this is not blackmail. Please thrown your grenades and run. :) - Brian > -----Original Message----- > From: Sven Olaf Kamphuis [mailto:sven at cyberbunker.com] > Sent: Monday, October 26, 2009 12:25 PM > To: Joe Greco > Cc: Brian Johnson; North American Network Operators Group > Subject: Re: DMCA takedowns of networks > > > > Is there a better solution that doesn't require intrusive parsing? > > > > Sure. Tell the hoster they've got to shut it down, or else lose > their > > connectivity. > > which would be called "blackmail". > > sure, have the cops arrest the guy that actually runs the site or > uploaded > it onto the site, if they cannot (because it simply doesnt happen to be > illegal in the country where he resides) they are out of luck and have > to > live with it. > > furthermore, in any case, a proper court order specifically > mentioning the url, the customer, the right company out of our > christmastree of companies worldwide, etc would > be required as we dont plan to decide whats illegal and what not. > > ofcourse all of this only applies to "real crime". not to whining dmca > idiots, whom are criminals themselves. > > -- > > Sven Olaf Kamphuis > CB3ROB DataServices > > Phone: +31/87-8747479 > Skype: CB3ROB > MSN: sven at cb3rob.net > C.V.: http://www.linkedin.com/in/cb3rob > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > > On Mon, 26 Oct 2009, Joe Greco wrote: > > > > > > So why are we having this discussion? > > > > > > > > Because it appears that HE took down non-infringing sites? > > > > > > > > Excuse me for stating the obvious. :-) > > > > > > > > ... JG > > > > -- > > > > Joe Greco - sol.net Network Services - Milwaukee, WI - > > > > > > On the technical side of this question... > > > > > > Let's say that a customer is doing virtual hosting. So they have a > bunch > > > of sites (Let's say hundreds) on a single IP address. Given that > one of > > > the sites is misbehaving (use your own definition), how would a > provider > > > block the one site, without blocking others that share the same IP > > > address, without looking at every port 80 request and parsing for > the > > > header for the URL? > > > > > > Is there a better solution that doesn't require intrusive parsing? > > > > Sure. Tell the hoster they've got to shut it down, or else lose > their > > connectivity. > > > > Sometimes it can be both simple *and* obvious. > > > > ... JG > > -- > > Joe Greco - sol.net Network Services - Milwaukee, WI - > http://www.sol.net > > "We call it the 'one bite at the apple' rule. Give me one chance > [and] then I > > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > > With 24 million small businesses in the US alone, that's way too many > apples. > > > > > > X-CONTACT-FILTER-MATCH: "nanog" > > From nanog2 at adns.net Mon Oct 26 17:06:17 2009 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Mon, 26 Oct 2009 17:06:17 -0500 Subject: Colocation needed in the Chicago area (I know, second request) Message-ID: <6FA106A7A98943E192571355340C218D@TAKA> Looking for 24U space 5Mbps bandwidth BGP Peer 15amps Chicago or Chicago suburbs (including Northern Indiana (Merrillville, Hammond, etc). Budget NO MORE THAN $750/month. If you know of colocation space that meets these parameters, please let me know. Sorry this is my second request, I wasn't specific on price and was getting ourageous quotes. Thanks John (promise - this is the last time). From todd at velocitytelephone.com Mon Oct 26 17:31:28 2009 From: todd at velocitytelephone.com (Todd Mueller) Date: Mon, 26 Oct 2009 17:31:28 -0500 (CDT) Subject: Colocation needed in the Chicago area (I know, second request) In-Reply-To: <6FA106A7A98943E192571355340C218D@TAKA> References: <6FA106A7A98943E192571355340C218D@TAKA> Message-ID: <47B0A0C1ADE1ED4BA114480988FE878F0273C4@dc1.gv-office.local> Check with Continuum Data Centers. I have a server racked there and have toured the facility. Very nice and the owner Tom is a great guy. Pricing is very good and service is reliable. http://continuumdatacenters.com/ -----Original Message----- From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] Sent: Monday, October 26, 2009 5:08 PM To: NANOG list Subject: Colocation needed in the Chicago area (I know, second request) Looking for 24U space 5Mbps bandwidth BGP Peer 15amps Chicago or Chicago suburbs (including Northern Indiana (Merrillville, Hammond, etc). Budget NO MORE THAN $750/month. If you know of colocation space that meets these parameters, please let me know. Sorry this is my second request, I wasn't specific on price and was getting ourageous quotes. Thanks John (promise - this is the last time). From streiner at cluebyfour.org Mon Oct 26 17:32:48 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 26 Oct 2009 18:32:48 -0400 (EDT) Subject: Alcatel-Lucent VPN Firewall Brick In-Reply-To: <75cb24520910261429h54a97bddp591005ee90aff596@mail.gmail.com> References: <9418aca70910260855l5234c769j96ca628a717d1e7d@mail.gmail.com> <75cb24520910261429h54a97bddp591005ee90aff596@mail.gmail.com> Message-ID: On Mon, 26 Oct 2009, Christopher Morrow wrote: > On Mon, Oct 26, 2009 at 12:36 PM, Justin M. Streiner > wrote: >> On Mon, 26 Oct 2009, Jay Nakamura wrote: >> >>> Looking for input on Alcatel-Lucent VPN Firewall Brick. ?I can look up >>> spec and other published information but, as always, the devil is in >>> the detail and you just never know what wall you run into until you >>> actually try it so I wanted to see if anyone has used this and can >>> point out good/bad things about this device. >>> >>> Our other option is Cisco IOS router right now. ?Are there better >>> options than these two? >> >> Fair warning: v6 honestly seems to have caught most firewall vendors with >> their pants down. > > I'm not really sure that in the year 2009 that's a fair thing to still > expect... honestly ipv6 has been in 'production' for ~7 years, for a > CPE deployment it's certainly been to the point where it should be > included by default. > > -1 alcalu :( I don't know about AL's v6 status because I'm in the process of migrating away from them, and have been in the process of lots of due diligence with vendors in the past 6-ish months. v6 support is pretty high on our list of 'must have' items. I've been pretty disappointed with the response from most vendors. Many of those have been along the lines of: "Yeah... our v6 code should be out of customer trials in Q2 2010..." "We do v6 in software today, and the next spin of XYZ hardware will do it in the ASICs..." "We're working some kinks out, so the box forwards X pps of v6 today (let Y = the amount of v4 traffic the box can handle, let X = some amount significantly lower than Y), but we should have all of that sorted out in the next major code release and be able to handle Y pps of v6 then." "The firewall handles v6 today, but v6 support in the management front-end is still baking. Should be ready to go in the next release." Vendor responses to my "v6 has been around for about 10 years... why is all of this only happening *now*?" questions have largely been along the lines of "Customers only started asking for or requiring v6 support in the last X months/years...". This gets us back to chicken-and-egg time. I can understand their position to a degree, i.e. why waste resources on things that customers aren't requesting (read: won't compel them to buy more/bigger hardware or renew/upgrade support contracts)? This might have been a somewhat valid position several years ago, but v6 as a necessity has been on many customers' radars for several years ago. Frankly, not having fully baked v6 support today is pretty much inexcusable IMHO. jms From mpetach at netflight.com Mon Oct 26 21:52:07 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 26 Oct 2009 19:52:07 -0700 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <1256452414.10858.13.camel@karl> References: <4AE07444.2000905@kl.net> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <4AE27913.7060607@bogus.com> <1256452414.10858.13.camel@karl> Message-ID: <63ac96a50910261952n690a43afhecece16ed13d9724@mail.gmail.com> On Sat, Oct 24, 2009 at 11:33 PM, Karl Auer wrote: > On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: >> the mac address of the rouge server > > > > It's R-O-G-U-E - rogue. > > Rouge is French for red and English for red make-up. Also the name of the Ford assembly plant at which the Monday night social was held. I blame the repeated repetition of the plant name throughout the night for planting it so thoroughly in our collective subconscious. ;) > > > Regards, K. From bblackford at gmail.com Mon Oct 26 23:05:48 2009 From: bblackford at gmail.com (Bill Blackford) Date: Mon, 26 Oct 2009 21:05:48 -0700 Subject: Power Analysis/Management Tools In-Reply-To: References: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> Message-ID: <680a83090910262105v70fcea63i82137800e98293b9@mail.gmail.com> Same. Cacti -b On Mon, Oct 26, 2009 at 2:33 PM, Greg Whynott wrote: > I'd think SNMP will be what any product uses to query APC gear, even their > own suite uses SNMP to collect information and receive traps. > We use cacti to graph our loads on the APC power bars and UPS gear, gives > you everything you need on all phases/legs, was there something in > particular you were after? > > -g > > > -----Original Message----- > From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] > Sent: Monday, October 26, 2009 4:59 PM > To: nanog at nanog.org > Subject: Power Analysis/Management Tools > > Not to go too off-topic, but if there is a more preferred location for me > to > ask, please let me know. I'm looking for recommendations on open source > packages that people are using for monitoring power utilization of their > network/server gear. > > We're using Cacti currently, pulling the data from APCs via SNMP, and I > wanted to check if someone had come across a better method before I > reinvented the wheel. > -- Bill Blackford Network Engineer From wavetossed at googlemail.com Tue Oct 27 07:05:52 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 27 Oct 2009 12:05:52 +0000 Subject: ISP/VPN's to China? In-Reply-To: <4ADF4B53.7020001@chrisserafin.com> References: <4ADF4B53.7020001@chrisserafin.com> Message-ID: <877585b00910270505w58af6d0bi9c5de1d93d888a8d@mail.gmail.com> > I have a client in the US looking to connect up an office in China and I'm > wondering what type of connections are avilable and wether IPSEC VPNs can be > established through the 'Great firewall of China'. If you want an IP-MPLS VPN, BT has PoPs in Beijing, Guangzhou, Shanghai and Hong Kong. Check the web for more details and contact info: You won't run into any problems running IPSEC over the MPLS network if you still feel the need for encryption. You can also get Internet access over the VPN and that access is from a gateway outside the Great Firewall. I imagine we are not the only global network offering such connectivity in China. --Michael Dillon From wavetossed at googlemail.com Tue Oct 27 09:05:36 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Tue, 27 Oct 2009 14:05:36 +0000 Subject: IPv6 could change things - Was: DMCA takedowns of networks Message-ID: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> > Not sure how much I believe of the article and its lack of detail and > chopped quotes...but did HE really disconnect an entire downstream network > over a DMCA notice, or did they null route a /32 that was used by a customer > to host hundreds of virtual web sites? Since the tools at a network operator's disposal are ACLs which make it easy to block traffic to a /32 without the need for deep packet inspection, one would expect that this regularly causes collateral damage if that /32 is a web server hosting hundreds of virtual websites. But, when IPv6 is a bit more common, there is no need for virtual hosters to share a single IP address between several sites. They may as well use a unique IPv6 address for every single site, even if they are all on the same server. The side effect of this is that it makes the network operator's tool sharper, and able to knock down single sites with a /32 ACL. For a hosting provider, I would think that this strengthens the business case for IPv6. --Michael Dillon From jeroen at unfix.org Tue Oct 27 09:13:38 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 15:13:38 +0100 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> Message-ID: <4AE70012.3050500@spaghetti.zurich.ibm.com> Michael Dillon wrote: [..] > [..] The > side effect of this is > that it makes the network operator's tool sharper, and able to knock > down single sites > with a /32 ACL. You actually mean a /128 in the case of IPv6, the /32 would be the complete ISP... > For a hosting provider, I would think that this strengthens the > business case for IPv6. and they can just use a single /64 for a single 'virtual webhost', then assign a 32 bit customer-id and have every customer have 2^32 sites, bingo. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From jeff at ocjtech.us Tue Oct 27 09:20:52 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 27 Oct 2009 09:20:52 -0500 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> Message-ID: <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> On Tue, Oct 27, 2009 at 9:05 AM, Michael Dillon wrote: > > But, when IPv6 is a bit more common, there is no need for ?virtual > hosters to share > a single IP address between several sites. They may as well use a > unique IPv6 address > for every single site, even if they are all on the same server. The > side effect of this is > that it makes the network operator's tool sharper, and able to knock > down single sites > with a /32 ACL. > > For a hosting provider, I would think that this strengthens the > business case for IPv6. But do the commonly-used operating systems support adding hundreds or thousands of addresses to an interface, and what would the performance implications be? -- Jeff Ollie From frederick at dahype.org Tue Oct 27 09:25:31 2009 From: frederick at dahype.org (Renato Frederick) Date: Tue, 27 Oct 2009 10:25:31 -0400 Subject: ALTDB Problems Message-ID: Hello I'm having some problems to send a new record to ALTDB by using mail. Old records work OK and I can update. Someone here at nanog is having same issues? Is there any ALTDB admins here? Thanks! From jeroen at unfix.org Tue Oct 27 09:32:09 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 15:32:09 +0100 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> Message-ID: <4AE70469.4000201@spaghetti.zurich.ibm.com> Jeffrey Ollie wrote: [..] > But do the commonly-used operating systems support adding hundreds or > thousands of addresses to an interface, and what would the performance > implications be? Remember that IP addresses are 128bits, while hostnames (the ones for the "Host:" header in the HTTP query) are well, quite a bit longer than that on average. If thus something like this would become common-place, there definitely will be quite some people who will be paying some attention on optimizing Apache. But yes, the network stack itself is a different question, then again, you can just route a /64 into the loopback device and let your apache listen there... (which also allows you to do easy-failover as you can move that complete /64 to a different box ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From adrian at creative.net.au Tue Oct 27 09:39:52 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 27 Oct 2009 22:39:52 +0800 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <4AE70469.4000201@spaghetti.zurich.ibm.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> <4AE70469.4000201@spaghetti.zurich.ibm.com> Message-ID: <20091027143952.GA13291@skywalker.creative.net.au> On Tue, Oct 27, 2009, Jeroen Massar wrote: > But yes, the network stack itself is a different question, then again, > you can just route a /64 into the loopback device and let your apache > listen there... (which also allows you to do easy-failover as you can > move that complete /64 to a different box ;) Funny you should mention that. A couple of tricks I've seen: * instead of a linked list and O(n) searching of interface aliases, use some kind of tree to map local IP -> interface. * hacks to do a "bind to all damned IP addresses and let userspace sort it out". I've done the former for a few thousand aliases with no degredation in performance. The hacks available for freebsd-4.x for the Web Polygraph software did something similar. 2c, Adrian From jbates at brightok.net Tue Oct 27 10:41:46 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 27 Oct 2009 10:41:46 -0500 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <4AE70469.4000201@spaghetti.zurich.ibm.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> <4AE70469.4000201@spaghetti.zurich.ibm.com> Message-ID: <4AE714BA.8030906@brightok.net> Jeroen Massar wrote: > But yes, the network stack itself is a different question, then again, > you can just route a /64 into the loopback device and let your apache > listen there... (which also allows you to do easy-failover as you can > move that complete /64 to a different box ;) > You are still comparing an application level decision to a stack level decision. Thousands of addresses on a stack could definitely pose an issue depending on the OS. Jack From rps at maine.edu Tue Oct 27 09:45:02 2009 From: rps at maine.edu (Ray Soucy) Date: Tue, 27 Oct 2009 10:45:02 -0400 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> Message-ID: <7a6830090910270745s5080d833r68f2ca0200866a81@mail.gmail.com> > But do the commonly-used operating systems support adding hundreds or > thousands of addresses to an interface, and what would the performance > implications be? > > Jeff Ollie Last time I checked, and this may have changed, the limit in Linux was around 4096. In practice though, you also have to consider the physical limitations of the server itself. The biggest bang for the buck in dense hosting environments seems to be running about 1000 sites per box, with a few boxes dedicated to your heavy hitters with 100 or less ea. Until we start seeing IPv6-only hosting though, I suspect that we will see IPv6 address mirror the configuration of the IP assignments. Sites with dedicated IPs will have dedicated IPv6, sites with shared IP will have shared IPv6, if only to maintain sanity. If you're trying to make the case for IPv6 to hosting companies, you're barking up the wrong tree. IP address just became a scarce commodity, instead of providing you with a free IP address, the can now charge $100 a mo for one. They know darn well that it will take a while for every user to have IPv6 from their SP and that if you want to run a site you'll need access to the "legacy" IP Internet to reach your customers. On the bright side, this will encourage the market to adopt IPv6 because they can't afford IP. Hopefully ARIN adopts a policy of decommissioning IP space as they reclaim it to prevent people from receiving new allocations as people begin to go IPv6-only, otherwise we'll be stuck with two Internets for a very long time. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From cmadams at hiwaay.net Tue Oct 27 09:57:14 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 27 Oct 2009 09:57:14 -0500 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> Message-ID: <20091027145714.GE1073921@hiwaay.net> Once upon a time, Jeffrey Ollie said: > But do the commonly-used operating systems support adding hundreds or > thousands of addresses to an interface, and what would the performance > implications be? I've got Linux (and even Windows) boxes with several hundred IPs bound today; I don't see why IPv6 addresses would be any different. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nicotine at warningg.com Tue Oct 27 10:13:27 2009 From: nicotine at warningg.com (Brandon Ewing) Date: Tue, 27 Oct 2009 10:13:27 -0500 Subject: ALTDB Problems In-Reply-To: References: Message-ID: <20091027151327.GE4060@radiological.warningg.com> On Tue, Oct 27, 2009 at 10:25:31AM -0400, Renato Frederick wrote: > Hello > > I'm having some problems to send a new record to ALTDB by using mail. > Old records work OK and I can update. > Someone here at nanog is having same issues? Is there any ALTDB admins here? > Thanks! > I recently submitted a new record -- I didn't receive an automated reply, but the database did reflect the entry when I had checked back the next day. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bjohnson at drtel.com Tue Oct 27 10:53:36 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 27 Oct 2009 10:53:36 -0500 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <7a6830090910270745s5080d833r68f2ca0200866a81@mail.gmail.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com><935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> <7a6830090910270745s5080d833r68f2ca0200866a81@mail.gmail.com> Message-ID: <29A54911243620478FF59F00EBB12F4701A61342@ex01.drtel.lan> > -----Original Message----- > From: Ray Soucy [mailto:rps at maine.edu] > Sent: Tuesday, October 27, 2009 9:45 AM > To: Jeffrey Ollie > Cc: North American Network Operators Group > Subject: Re: IPv6 could change things - Was: DMCA takedowns of networks > > > But do the commonly-used operating systems support adding hundreds or > > thousands of addresses to an interface, and what would the > performance > > implications be? > > > > Jeff Ollie > > Last time I checked, and this may have changed, the limit in Linux was > around 4096. So in this circumstance you could route a /116 to the server. COOL! > > In practice though, you also have to consider the physical limitations > of the server itself. The biggest bang for the buck in dense hosting > environments seems to be running about 1000 sites per box, with a few > boxes dedicated to your heavy hitters with 100 or less ea. So in this circumstance you could route a /118 to the server serving 1000 sites and a /125 to the server serving 100 sites. Also COOL! > > Until we start seeing IPv6-only hosting though, I suspect that we will > see IPv6 address mirror the configuration of the IP assignments. > Sites with dedicated IPs will have dedicated IPv6, sites with shared > IP will have shared IPv6, if only to maintain sanity. This passes my smell and duh tests. :) > > If you're trying to make the case for IPv6 to hosting companies, > you're barking up the wrong tree. IP address just became a scarce > commodity, instead of providing you with a free IP address, the can > now charge $100 a mo for one. They know darn well that it will take a > while for every user to have IPv6 from their SP and that if you want > to run a site you'll need access to the "legacy" IP Internet to reach > your customers. On the bright side, this will encourage the market to > adopt IPv6 because they can't afford IP. Hopefully ARIN adopts a > policy of decommissioning IP space as they reclaim it to prevent > people from receiving new allocations as people begin to go IPv6-only, > otherwise we'll be stuck with two Internets for a very long time. Agreed, except for one thing. ARIN shouldn't "decommission" IP space. The Internet will dictate that IPv4 will go away all on its own once IPv6 becomes the protocol of choice for enough of the net. At some point, the people who depend on IPv4 will not be able to pay for their providers supporting the IPv4 infrastructure as new devices become available that either only support IPv6, or don't implement a full suite of IPv4 to keep costs down. Also remember that at some point, there will be no IPv4 left. When this happens new entrants will suffer greatly at the hands of this circumstance. But we will get through it and there will be new sites that will be IPv6 only, then there will be demand for these sites, then there will be people who vote with their wallets for the new sites... Was I rambling there? :) In the end it will be economics that dictate a single protocol Internet. I am one who wishes we put a date in stone now to establish the "cut date" of IPv4 to IPv6, but that is unreasonable. This will take care of itself. _____________________________________ Brian Johnson Converged Network Engineer (CCNP, ENA) Dickey Rural Networks From brwatters at absfoc.com Tue Oct 27 10:23:17 2009 From: brwatters at absfoc.com (Brian R. Watters) Date: Tue, 27 Oct 2009 08:23:17 -0700 (PDT) Subject: Level 3 dup packets In-Reply-To: <680a83090910262105v70fcea63i82137800e98293b9@mail.gmail.com> Message-ID: <32918385.475.1256656997583.JavaMail.root@mail.absfoc.com> Is anyone seeing duplicate packets coming out of Level 3 on the West Coast of the US ?, we are seeing major issues routing across their network with horrible results to our end points with what looks to be duplicate packets and or split routes. Anyone on the list with level 3 ?? if so please contact me off list ASAP. BRW From nenolod at systeminplace.net Tue Oct 27 10:31:28 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 27 Oct 2009 15:31:28 +0000 Subject: DMCA takedowns of networks Message-ID: <54845733-1256661689-cardhu_decombobulator_blackberry.rim.net-1838737923-@bda145.bisx.prod.on.blackberry> Mayfirst / Peoplelink did not get any notice that service would be turned down prior to it happening. Hurricane has had a really bad history of handling copyright complaints. The situation for example resulting in mayfirst's circuit being turned down had nothing at all to do with copyright and was instead a trademark violation dispute. IANAL, but trademark issues are not copyright issues nor are they handled via the dmca. Therefore what hurricane did in this instance is really unacceptable. It should be emphasized that the dmca does not require turning down service - only sending the takedown notice along to an appropriate contact. See also: common-carrier immunity concept. I don't know about you, but hurricanes actions in this instance has made me reevaluate the use of their products in future projects. (this post definitely does not reflect the opinions of my employer.) William ------Original Message------ From: Jack Bates To: Richard A Steenbergen Cc: North American Network Operators Group Subject: Re: DMCA takedowns of networks Sent: Oct 26, 2009 1:44 PM Richard A Steenbergen wrote: > had no liability in the matter. Of course Hurricane is well within their > rights not to serve any customer that they please, but the customer is > also well within their rights to find another provider who better > respects the rights of free speech on the Internet (if the above is what > actually happened). > I'm sure HE respects the rights of free speech just fine. That being said, a notice was delivered, customer may not have replied with the appropriate legal notice, and so HE honored it's obligation to maintain safe harbor. One would have to be an idiot to jeopardize their company by rolling the dice in an effort to protect free speech (which may not legally be free speech). Courts determine what is free speech. ISPs just try to stay the hell out of the way. Jack -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From nenolod at systeminplace.net Tue Oct 27 10:41:07 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 27 Oct 2009 15:41:07 +0000 Subject: DMCA takedowns of networks In-Reply-To: <29A54911243620478FF59F00EBB12F4701A612F4@ex01.drtel.lan> References: <200910261445.n9QEj9CX027566@aurora.sol.net><29A54911243620478FF59F00EBB12F4701A612F4@ex01.drtel.lan> Message-ID: <1438433299-1256661707-cardhu_decombobulator_blackberry.rim.net-1700081007-@bda145.bisx.prod.on.blackberry> Option 5 sounds like it fits the bill to me. After all, what HE said was basically "take the site down or else" to which they backed down but then wound up turning service down anyway. It is truly disappointing to see HE evolve in this way. I hope that their management decides to change the way IP issues get handled. (again, not the opinions of my employer.) William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 -----Original Message----- From: "Brian Johnson" Date: Mon, 26 Oct 2009 17:03:29 To: North American Network Operators Group Subject: RE: DMCA takedowns of networks Per Dictionary.com: blackmail -noun 1. any payment extorted by intimidation, as by threats of injurious revelations or accusations. 2. the extortion of such payment: He confessed rather than suffer the dishonor of blackmail. 3. a tribute formerly exacted in the north of England and in Scotland by freebooting chiefs for protection from pillage. -verb (used with object) 4. to extort money from (a person) by the use of threats. 5. to force or coerce into a particular action, statement, etc.: The strikers claimed they were blackmailed into signing the new contract. ... thus, this is not blackmail. Please thrown your grenades and run. :) - Brian > -----Original Message----- > From: Sven Olaf Kamphuis [mailto:sven at cyberbunker.com] > Sent: Monday, October 26, 2009 12:25 PM > To: Joe Greco > Cc: Brian Johnson; North American Network Operators Group > Subject: Re: DMCA takedowns of networks > > > > Is there a better solution that doesn't require intrusive parsing? > > > > Sure. Tell the hoster they've got to shut it down, or else lose > their > > connectivity. > > which would be called "blackmail". > > sure, have the cops arrest the guy that actually runs the site or > uploaded > it onto the site, if they cannot (because it simply doesnt happen to be > illegal in the country where he resides) they are out of luck and have > to > live with it. > > furthermore, in any case, a proper court order specifically > mentioning the url, the customer, the right company out of our > christmastree of companies worldwide, etc would > be required as we dont plan to decide whats illegal and what not. > > ofcourse all of this only applies to "real crime". not to whining dmca > idiots, whom are criminals themselves. > > -- > > Sven Olaf Kamphuis > CB3ROB DataServices > > Phone: +31/87-8747479 > Skype: CB3ROB > MSN: sven at cb3rob.net > C.V.: http://www.linkedin.com/in/cb3rob > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > > On Mon, 26 Oct 2009, Joe Greco wrote: > > > > > > So why are we having this discussion? > > > > > > > > Because it appears that HE took down non-infringing sites? > > > > > > > > Excuse me for stating the obvious. :-) > > > > > > > > ... JG > > > > -- > > > > Joe Greco - sol.net Network Services - Milwaukee, WI - > > > > > > On the technical side of this question... > > > > > > Let's say that a customer is doing virtual hosting. So they have a > bunch > > > of sites (Let's say hundreds) on a single IP address. Given that > one of > > > the sites is misbehaving (use your own definition), how would a > provider > > > block the one site, without blocking others that share the same IP > > > address, without looking at every port 80 request and parsing for > the > > > header for the URL? > > > > > > Is there a better solution that doesn't require intrusive parsing? > > > > Sure. Tell the hoster they've got to shut it down, or else lose > their > > connectivity. > > > > Sometimes it can be both simple *and* obvious. > > > > ... JG > > -- > > Joe Greco - sol.net Network Services - Milwaukee, WI - > http://www.sol.net > > "We call it the 'one bite at the apple' rule. Give me one chance > [and] then I > > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > > With 24 million small businesses in the US alone, that's way too many > apples. > > > > > > X-CONTACT-FILTER-MATCH: "nanog" > > From David_Hankins at isc.org Tue Oct 27 13:00:05 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 27 Oct 2009 11:00:05 -0700 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> Message-ID: <20091027180005.GA4577@isc.org> On Tue, Oct 27, 2009 at 02:05:36PM +0000, Michael Dillon wrote: > But, when IPv6 is a bit more common, there is no need for virtual > hosters to share > a single IP address between several sites. They may as well use a > unique IPv6 address > for every single site, even if they are all on the same server. The > side effect of this is > that it makes the network operator's tool sharper, and able to knock > down single sites > with a /32 ACL. A /128 you mean. If you look in Apache's httpd/server/vhost.c, you may notice that the server locates addressed virtual hosts using a simple 32->8 bit integer reduction hash, which produces a well balanced hash table in typical virtual server applications (generally these servers get addresses in contiguous blocks). Named virtuals are relegated to an extra hash bucket, essentially placing them all on a single unsorted linear list, which is searched if a by-address match is not found. Probably in the modern day, the additional processing (and system calls) necessary to render a web object into a reply is significantly higher than the overhead to locate a virtual server even at these orders of magnitude, but it's interesting that the software works differently. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ser at tch.org Tue Oct 27 13:21:28 2009 From: ser at tch.org (Steve Rubin) Date: Tue, 27 Oct 2009 11:21:28 -0700 Subject: ALTDB Problems In-Reply-To: References: Message-ID: <9CCF0873-453C-4594-856F-367F90E8C97B@tch.org> On Oct 27, 2009, at 7:25 AM, Renato Frederick wrote: > Hello > > I'm having some problems to send a new record to ALTDB by using mail. > > Old records work OK and I can update. > > Someone here at nanog is having same issues? Is there any ALTDB > admins here? > > Thanks! > ALTDB is free and you get what you pay for. However. Donations to http://www.nanog.org/scholarships/abha.php would probably get requests done a lot faster. -- Steve Rubin / AE6CH / http://www.altdb.net/ Email: ser at tch.org / N6441C / http://www.tch.org/~ser/ From nenolod at systeminplace.net Tue Oct 27 13:29:18 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 27 Oct 2009 18:29:18 +0000 Subject: IPv6 could change things - Was: DMCA takedowns of networks Message-ID: <1877780688-1256671002-cardhu_decombobulator_blackberry.rim.net-1912004390-@bda145.bisx.prod.on.blackberry> To expand on this from a programmers perspective, usually at the kernel/network stack level, a "patricia" radix-style trie is used for fast ipv6 lookups. The benefit of the patricia trie being that if you only have a difference keylength of 8 bits (/120) then the ip lookup only takes 8 steps in a worst-case scenario. The same concept applies to ipv4 cidr as well, but it is less obvious. William ------Original Message------ From: Adrian Chadd To: Jeroen Massar Cc: North American Network Operators Group Subject: Re: IPv6 could change things - Was: DMCA takedowns of networks Sent: Oct 27, 2009 10:39 AM On Tue, Oct 27, 2009, Jeroen Massar wrote: > But yes, the network stack itself is a different question, then again, > you can just route a /64 into the loopback device and let your apache > listen there... (which also allows you to do easy-failover as you can > move that complete /64 to a different box ;) Funny you should mention that. A couple of tricks I've seen: * instead of a linked list and O(n) searching of interface aliases, use some kind of tree to map local IP -> interface. * hacks to do a "bind to all damned IP addresses and let userspace sort it out". I've done the former for a few thousand aliases with no degredation in performance. The hacks available for freebsd-4.x for the Web Polygraph software did something similar. 2c, Adrian -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From chris at nifry.com Tue Oct 27 18:34:46 2009 From: chris at nifry.com (Chris Russell) Date: Tue, 27 Oct 2009 23:34:46 -0000 Subject: Power Analysis/Management Tools In-Reply-To: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> References: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> Message-ID: <567F73A9D5674A2B8976CE643330267C@htpc> Cacti is a cracking bit of software, but I found this difficult to integrate and customize to what we required. I ended up writing our own, custom pollers, Database backend, web frontend and rrd to generate the graphing. We were quoted something like ?50k for something awfully similar.. Cheers, Chris -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: 26 October 2009 20:59 To: nanog at nanog.org Subject: Power Analysis/Management Tools Not to go too off-topic, but if there is a more preferred location for me to ask, please let me know. I'm looking for recommendations on open source packages that people are using for monitoring power utilization of their network/server gear. We're using Cacti currently, pulling the data from APCs via SNMP, and I wanted to check if someone had come across a better method before I reinvented the wheel. From leslie at craigslist.org Tue Oct 27 18:57:17 2009 From: leslie at craigslist.org (Leslie) Date: Tue, 27 Oct 2009 16:57:17 -0700 Subject: dealing with bogon spam ? Message-ID: <4AE788DD.3050605@craigslist.org> First off, I'm not certain if unallocated space in blocks less than a /8 is properly called bogon, so pardon my terminology if I'm incorrect. We're seeing a decent chunk of spam coming from an unallocated block of address space. We use CYMRU's great list of /8 bogon space to prevent completely off the wall abuse, but the granularity stops at /8's. Obviously, I've written the originating AS and its single upstream provider (sadly without any response). I'm not looking for a one time solution for this issue however -- I'd like to permanently block (and kick) anyone who's using unallocated space illegitimately. How have you dealt with this issue? Does anyone publish a more granular listing of unallocated space? Does arin have this information somewhere other than just probing any given ip via whois? Thanks! Leslie Craigslist Spam Hater From leslie at craigslist.org Tue Oct 27 19:10:56 2009 From: leslie at craigslist.org (Leslie) Date: Tue, 27 Oct 2009 17:10:56 -0700 Subject: dealing with bogon spam ? In-Reply-To: <4AE788DD.3050605@craigslist.org> References: <4AE788DD.3050605@craigslist.org> Message-ID: <4AE78C10.2000109@craigslist.org> I failed to mention we're seeing this from an unallocated /20 whose parent /8 is allocated to ARIN (and is partially in use) Leslie Leslie wrote: > First off, I'm not certain if unallocated space in blocks less than a /8 > is properly called bogon, so pardon my terminology if I'm incorrect. > > We're seeing a decent chunk of spam coming from an unallocated block of > address space. We use CYMRU's great list of /8 bogon space to prevent > completely off the wall abuse, but the granularity stops at /8's. > Obviously, I've written the originating AS and its single upstream > provider (sadly without any response). I'm not looking for a one time > solution for this issue however -- I'd like to permanently block (and > kick) anyone who's using unallocated space illegitimately. > > How have you dealt with this issue? Does anyone publish a more granular > listing of unallocated space? Does arin have this information somewhere > other than just probing any given ip via whois? > > Thanks! > Leslie > Craigslist Spam Hater From nanog at daork.net Tue Oct 27 19:13:51 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 28 Oct 2009 13:13:51 +1300 Subject: dealing with bogon spam ? In-Reply-To: <4AE788DD.3050605@craigslist.org> References: <4AE788DD.3050605@craigslist.org> Message-ID: <111E0725-B4A8-490B-BEE7-CB73BD49C717@daork.net> On 28/10/2009, at 12:57 PM, Leslie wrote: > First off, I'm not certain if unallocated space in blocks less than > a /8 is properly called bogon, so pardon my terminology if I'm > incorrect. > > We're seeing a decent chunk of spam coming from an unallocated block > of address space. We use CYMRU's great list of /8 bogon space to > prevent completely off the wall abuse, but the granularity stops at / > 8's. Obviously, I've written the originating AS and its single > upstream provider (sadly without any response). I'm not looking for > a one time solution for this issue however -- I'd like to > permanently block (and kick) anyone who's using unallocated space > illegitimately. > > How have you dealt with this issue? Does anyone publish a more > granular listing of unallocated space? Does arin have this > information somewhere other than just probing any given ip via whois? You *might* be able to get a copy of the whois database as an optimisation so you don't have to hit their servers all the time - does that help? I wouldn't rely on that though, but I don't see any other good options. Perhaps you can only accept stuff from networks that you first saw an announcement for greater than 7 days ago, to prevent people popping up with a network for a day, spamming, and then disappearing? Likely to get lots of false positives in that though, and as soon as someone figures out your technique it's not going to work. Religious war alert: does SIDR solve this? I guess only if you only accept signed advertisements.. I don't know if that is the intended default mode or not.. Need to do some reading I guess. -- Nathan Ward From nanog at daork.net Tue Oct 27 19:38:44 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 28 Oct 2009 13:38:44 +1300 Subject: Power Analysis/Management Tools In-Reply-To: <680a83090910262105v70fcea63i82137800e98293b9@mail.gmail.com> References: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> <680a83090910262105v70fcea63i82137800e98293b9@mail.gmail.com> Message-ID: <1AE86BEB-1993-4891-93CB-36948F3F3A15@daork.net> I haven't used cacti in a while, but does it let you combine several RRD files in to one graph? If so that's useful for power stuff, because you're likely to want to graph an aggregate of several things across different devices - for example a+b power of a server, or aggregate power usage for one customer with multiple power feeds. Note that RRD has some cool stuff that cacti can't use by default, including the "aberrant behavior detection" functionality - that's probably quite useful for power and environmental stuff.. On 27/10/2009, at 5:05 PM, Bill Blackford wrote: > Same. Cacti > > -b > > On Mon, Oct 26, 2009 at 2:33 PM, Greg Whynott > wrote: > >> I'd think SNMP will be what any product uses to query APC gear, >> even their >> own suite uses SNMP to collect information and receive traps. >> We use cacti to graph our loads on the APC power bars and UPS gear, >> gives >> you everything you need on all phases/legs, was there something in >> particular you were after? >> >> -g >> >> >> -----Original Message----- >> From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] >> Sent: Monday, October 26, 2009 4:59 PM >> To: nanog at nanog.org >> Subject: Power Analysis/Management Tools >> >> Not to go too off-topic, but if there is a more preferred location >> for me >> to >> ask, please let me know. I'm looking for recommendations on open >> source >> packages that people are using for monitoring power utilization of >> their >> network/server gear. >> >> We're using Cacti currently, pulling the data from APCs via SNMP, >> and I >> wanted to check if someone had come across a better method before I >> reinvented the wheel. >> > > > > -- > Bill Blackford > Network Engineer > > !DSPAM:22,4ae671cf233691970413987! > > From jay at west.net Tue Oct 27 19:42:15 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 27 Oct 2009 17:42:15 -0700 Subject: dealing with bogon spam ? In-Reply-To: <4AE788DD.3050605@craigslist.org> References: <4AE788DD.3050605@craigslist.org> Message-ID: <4AE79367.5080105@west.net> Leslie wrote: > First off, I'm not certain if unallocated space in blocks less than a /8 > is properly called bogon, so pardon my terminology if I'm incorrect. Bogon is probably the correct term for any IP space that doesn't belong on the public Internet because it is reserved, unallocated, etc. > We're seeing a decent chunk of spam coming from an unallocated block of > address space. We use CYMRU's great list of /8 bogon space to prevent > completely off the wall abuse, but the granularity stops at /8's. > Obviously, I've written the originating AS and its single upstream > provider (sadly without any response). I'm not looking for a one time > solution for this issue however -- I'd like to permanently block (and > kick) anyone who's using unallocated space illegitimately. Not too permanently, though. That space is likely to become allocated, and the new legitimate user thereof shouldn't have to beg thousands of networks to unblock it. so > How have you dealt with this issue? Does anyone publish a more granular > listing of unallocated space? Does arin have this information somewhere > other than just probing any given ip via whois? I'm not specifically aware of a more granular listing. It would have to be dynamic as new allocations occur all the time. The RIRs (ARIN, RIPE, APNIC, etc.) are the authoritative source for the space allocated to them, but I don't know if they have a real-time bogon list available. In addition to the published list, Team Cymru has a BGP feed and other resources, but I don't know how granular it is with respect to unallocated space. See here: http://www.team-cymru.org/Services/Bogons/ -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From frederick at dahype.org Tue Oct 27 19:43:36 2009 From: frederick at dahype.org (Renato Frederick) Date: Tue, 27 Oct 2009 20:43:36 -0400 Subject: ALTDB Problems In-Reply-To: <9CCF0873-453C-4594-856F-367F90E8C97B@tch.org> References: <9CCF0873-453C-4594-856F-367F90E8C97B@tch.org> Message-ID: Thanks Steve. I Know that ALTDB is free, they do a great job for free, I don't complain about the delay! :) I'm just checking if there are some outage or similar issue. I sure will see the donation question close. Thanks > -----Original Message----- > From: Steve Rubin [mailto:ser at tch.org] > Sent: ter?a-feira, 27 de outubro de 2009 16:21 > To: Renato Frederick > Cc: nanog at nanog.org > Subject: Re: ALTDB Problems > > > On Oct 27, 2009, at 7:25 AM, Renato Frederick wrote: > > > Hello > > > > I'm having some problems to send a new record to ALTDB by using mail. > > > > Old records work OK and I can update. > > > > Someone here at nanog is having same issues? Is there any ALTDB admins > > here? > > > > Thanks! > > > > > ALTDB is free and you get what you pay for. > > However. Donations to http://www.nanog.org/scholarships/abha.php > would probably get requests done a lot faster. > > > -- > Steve Rubin / AE6CH / http://www.altdb.net/ > Email: ser at tch.org / N6441C / http://www.tch.org/~ser/ > > From ops.lists at gmail.com Tue Oct 27 19:49:56 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 28 Oct 2009 06:19:56 +0530 Subject: dealing with bogon spam ? In-Reply-To: <4AE78C10.2000109@craigslist.org> References: <4AE788DD.3050605@craigslist.org> <4AE78C10.2000109@craigslist.org> Message-ID: What /20 would this be, and can you blame an out of date whois client or whois db for it? If the /20 is being routed, and announced - chances are it IS allocated. On Wed, Oct 28, 2009 at 5:40 AM, Leslie wrote: > I failed to mention we're seeing this from an unallocated /20 whose parent > /8 is allocated to ARIN (and is partially in use) > > Leslie From Jon.Kibler at aset.com Tue Oct 27 19:55:37 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Tue, 27 Oct 2009 20:55:37 -0400 Subject: dealing with bogon spam ? In-Reply-To: References: <4AE788DD.3050605@craigslist.org> <4AE78C10.2000109@craigslist.org> Message-ID: <4AE79689.8030105@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Suresh Ramasubramanian wrote: > If the /20 is being routed, and announced - chances are it IS allocated. Don't bet on it. This is one of the oldest spammer tricks in the book. I worked with ISPs as far back as the late 90s trying to track down poachers who temporarily squat on an unallocated block and announce it to the world. Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 s: 843-564-4224 s: JonRKibler e: Jon.Kibler at aset.com e: Jon.R.Kibler at gmail.com http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrnlokACgkQUVxQRc85QlOVgwCffnJ4nAYNypXOW4TlgNCO1CFo IjEAn3UGgf/aIgBAESg9oDzvJoTKvaCk =fqu/ -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From ops.lists at gmail.com Tue Oct 27 20:00:38 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 28 Oct 2009 06:30:38 +0530 Subject: dealing with bogon spam ? In-Reply-To: <4AE79689.8030105@aset.com> References: <4AE788DD.3050605@craigslist.org> <4AE78C10.2000109@craigslist.org> <4AE79689.8030105@aset.com> Message-ID: Having been postmastering at various places for about a decade, I have seen that too - yes. But cymru style filtering means its kind of out of fashion now. Though - a lot of the cases I've seen have been 1. Out of date whois client and the IP's been allocated after the whois client came out (with a hardcoded list of unallocated IPs) 2. Whois db is out of date - comparatively rarer but known to occur Especially if you see a mainstream carrier routing it instead of some small outfit in Eastern Europe .. chances are its stale db somewhere rather than totally unallocated block and phantom routing On Wed, Oct 28, 2009 at 6:25 AM, Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Suresh Ramasubramanian wrote: > >> If the /20 is being routed, and announced - chances are it IS allocated. > > Don't bet on it. This is one of the oldest spammer tricks in the book. I worked > with ISPs as far back as the late 90s trying to track down poachers who > temporarily squat on an unallocated block and announce it to the world. > From jlewis at lewis.org Tue Oct 27 20:08:12 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 27 Oct 2009 21:08:12 -0400 (EDT) Subject: dealing with bogon spam ? In-Reply-To: <4AE78C10.2000109@craigslist.org> References: <4AE788DD.3050605@craigslist.org> <4AE78C10.2000109@craigslist.org> Message-ID: On Tue, 27 Oct 2009, Leslie wrote: > I failed to mention we're seeing this from an unallocated /20 whose parent /8 > is allocated to ARIN (and is partially in use) What /20 would that be? If you're sure it's unallocated, and see nothing but spam from it, block it at your border. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nanog at daork.net Tue Oct 27 20:16:57 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 28 Oct 2009 14:16:57 +1300 Subject: dealing with bogon spam ? In-Reply-To: References: <4AE788DD.3050605@craigslist.org> <4AE78C10.2000109@craigslist.org> <4AE79689.8030105@aset.com> Message-ID: <867E8FA7-CFFF-4394-BEEA-370A50A70BC2@daork.net> On 28/10/2009, at 2:00 PM, Suresh Ramasubramanian wrote: > Having been postmastering at various places for about a decade, I have > seen that too - yes. But cymru style filtering means its kind of out > of fashion now. Sure, if the prefix is within something that cymru call a bogon. If it's within a current RIR pool, not so much. -- Nathan Ward From cchurc05 at harris.com Tue Oct 27 20:20:38 2009 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 27 Oct 2009 21:20:38 -0400 Subject: dealing with bogon spam ? Message-ID: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> This is puzzling me. If it's from non-announced space, at some point some router should report no route to it. How is the TCP handshake performed to allow a sync to turn into spam? Chuck Chuck Church Network Planning Engineer, CCIE #8776 Harris Information Technology Services DOD Programs 1210 N. Parker Rd. | Greenville, SC 29609 Office: 864-335-9473 | Cell: 864-266-3978 -------------------------- Sent using BlackBerry ----- Original Message ----- From: Jon Lewis To: Leslie Cc: NANOG Sent: Tue Oct 27 21:08:12 2009 Subject: Re: dealing with bogon spam ? On Tue, 27 Oct 2009, Leslie wrote: > I failed to mention we're seeing this from an unallocated /20 whose parent /8 > is allocated to ARIN (and is partially in use) What /20 would that be? If you're sure it's unallocated, and see nothing but spam from it, block it at your border. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nanog at daork.net Tue Oct 27 20:22:30 2009 From: nanog at daork.net (Nathan Ward) Date: Wed, 28 Oct 2009 14:22:30 +1300 Subject: dealing with bogon spam ? In-Reply-To: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> Message-ID: <47367935-3934-4CA3-8F43-188C06E72B28@daork.net> On 28/10/2009, at 2:20 PM, Church, Charles wrote: > This is puzzling me. If it's from non-announced space, at some > point some router should report no route to it. How is the TCP > handshake performed to allow a sync to turn into spam? Unallocated is not the same as unannounced. From jlewis at lewis.org Tue Oct 27 20:27:56 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 27 Oct 2009 21:27:56 -0400 (EDT) Subject: dealing with bogon spam ? In-Reply-To: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> Message-ID: Unallocated doesn't mean non-routed. All a spammer needs is a willing/non-filtering provider doing BGP with them, and they can announce any space they like, send out some spam, and then pull the announcement. Next morning, when you see the spam and try to figure out who to send complaints to, you're either going to complain to the wrong people or find that whois is of no help. On Tue, 27 Oct 2009, Church, Charles wrote: > This is puzzling me. If it's from non-announced space, at some point some router should report no route to it. How is the TCP handshake performed to allow a sync to turn into spam? > > Chuck > > Chuck Church > Network Planning Engineer, CCIE #8776 > Harris Information Technology Services > DOD Programs > 1210 N. Parker Rd. | Greenville, SC 29609 > Office: 864-335-9473 | Cell: 864-266-3978 > -------------------------- > Sent using BlackBerry > > > ----- Original Message ----- > From: Jon Lewis > To: Leslie > Cc: NANOG > Sent: Tue Oct 27 21:08:12 2009 > Subject: Re: dealing with bogon spam ? > > > On Tue, 27 Oct 2009, Leslie wrote: > >> I failed to mention we're seeing this from an unallocated /20 whose parent /8 >> is allocated to ARIN (and is partially in use) > > What /20 would that be? If you're sure it's unallocated, and see nothing > but spam from it, block it at your border. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ops.lists at gmail.com Tue Oct 27 20:47:43 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 28 Oct 2009 07:17:43 +0530 Subject: dealing with bogon spam ? In-Reply-To: References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> Message-ID: Seen it before - but mostly for malware rather than for spam. And certainly not long enough / persistent enough for a full fledged spam campaign (4..5 days rather than a day or two at the most when people start noticing and dropping the bogus announcement) On Wed, Oct 28, 2009 at 6:57 AM, Jon Lewis wrote: > Unallocated doesn't mean non-routed. ?All a spammer needs is a > willing/non-filtering provider doing BGP with them, and they can announce > any space they like, send out some spam, and then pull the announcement. > Next morning, when you see the spam and try to figure out who to send > complaints to, you're either going to complain to the wrong people or find > that whois is of no help. From joelja at bogus.com Wed Oct 28 00:23:29 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 27 Oct 2009 22:23:29 -0700 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <29A54911243620478FF59F00EBB12F4701A61342@ex01.drtel.lan> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com><935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> <7a6830090910270745s5080d833r68f2ca0200866a81@mail.gmail.com> <29A54911243620478FF59F00EBB12F4701A61342@ex01.drtel.lan> Message-ID: <4AE7D551.90702@bogus.com> Brian Johnson wrote: >> Last time I checked, and this may have changed, the limit in Linux was >> around 4096. > > So in this circumstance you could route a /116 to the server. COOL! These days what we might at one point have refered to as a host or server may actually be a hardware container with N > 1 or so virtual systems... which may variously be: attached to the network via dedicated interface individual vlans a virtual bridge a layer-3 topology >> In practice though, you also have to consider the physical limitations >> of the server itself. The biggest bang for the buck in dense hosting >> environments seems to be running about 1000 sites per box, with a few >> boxes dedicated to your heavy hitters with 100 or less ea. > > So in this circumstance you could route a /118 to the server serving > 1000 sites and a /125 to the server serving 100 sites. Also COOL! How many ips you can park on a particular hardware container is probably bounded only by the over-subscription rate of what you intend to serve. Most of the superficial limits (macs on a bridge table, ips on an interface etc can be worked around in fairly simple fashion but the number of connections per second or pps rate a given hardware container can pass though whatever abstraction is applied is less fungible. >> Until we start seeing IPv6-only hosting though, I suspect that we will >> see IPv6 address mirror the configuration of the IP assignments. >> Sites with dedicated IPs will have dedicated IPv6, sites with shared >> IP will have shared IPv6, if only to maintain sanity. > > This passes my smell and duh tests. :) > >> If you're trying to make the case for IPv6 to hosting companies, >> you're barking up the wrong tree. IP address just became a scarce >> commodity, instead of providing you with a free IP address, the can >> now charge $100 a mo for one. They know darn well that it will take a >> while for every user to have IPv6 from their SP and that if you want >> to run a site you'll need access to the "legacy" IP Internet to reach >> your customers. On the bright side, this will encourage the market to >> adopt IPv6 because they can't afford IP. Hopefully ARIN adopts a >> policy of decommissioning IP space as they reclaim it to prevent >> people from receiving new allocations as people begin to go IPv6-only, >> otherwise we'll be stuck with two Internets for a very long time. > > Agreed, except for one thing. ARIN shouldn't "decommission" IP space. > The Internet will dictate that IPv4 will go away all on its own once > IPv6 becomes the protocol of choice for enough of the net. At some > point, the people who depend on IPv4 will not be able to pay for their > providers supporting the IPv4 infrastructure as new devices become > available that either only support IPv6, or don't implement a full suite > of IPv4 to keep costs down. > > Also remember that at some point, there will be no IPv4 left. When this > happens new entrants will suffer greatly at the hands of this > circumstance. But we will get through it and there will be new sites > that will be IPv6 only, then there will be demand for these sites, then > there will be people who vote with their wallets for the new sites... > > Was I rambling there? :) In the end it will be economics that dictate a > single protocol Internet. I am one who wishes we put a date in stone now > to establish the "cut date" of IPv4 to IPv6, but that is unreasonable. > This will take care of itself. > > _____________________________________ > Brian Johnson > Converged Network Engineer (CCNP, ENA) > Dickey Rural Networks > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 28 00:35:01 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 28 Oct 2009 16:05:01 +1030 Subject: IPv6 could change things - Was: DMCA takedowns of networks In-Reply-To: <4AE714BA.8030906@brightok.net> References: <877585b00910270705i2b3e8324ifc0046c849b960b0@mail.gmail.com> <935ead450910270720y62dbf5bsa21c99d0c3c674fd@mail.gmail.com> <4AE70469.4000201@spaghetti.zurich.ibm.com> <4AE714BA.8030906@brightok.net> Message-ID: <20091028160501.22773486@opy.nosense.org> On Tue, 27 Oct 2009 10:41:46 -0500 Jack Bates wrote: > Jeroen Massar wrote: > > But yes, the network stack itself is a different question, then again, > > you can just route a /64 into the loopback device and let your apache > > listen there... (which also allows you to do easy-failover as you can > > move that complete /64 to a different box ;) > > > > You are still comparing an application level decision to a stack level > decision. Thousands of addresses on a stack could definitely pose an > issue depending on the OS. > Depends a bit on how the OS handles interface address assignments. Linux creates host routes in a separate 'local' route table, which you can see via ip route show table local or for IPv6 ip -6 route show table local which I think would suggest that Linux's interface address assignment scalability is as scalable as it's route table scalability. Performing concurrent IPv6 Duplicate Address Detection on that many addresses when the interface/host comes up might be an issue. Regards, Mark. From leslie at craigslist.org Wed Oct 28 01:44:40 2009 From: leslie at craigslist.org (Leslie) Date: Tue, 27 Oct 2009 23:44:40 -0700 Subject: dealing with bogon spam ? In-Reply-To: References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> Message-ID: <4AE7E858.4020109@craigslist.org> Yes, unallocated (at least according to ARIN's whois db) but not unannounced - obviously our network can get to the space or else I wouldn't be having a spam problem with them! I'm actually seeing this /20 as advertised through Savvis from AS40430 It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) Has anyone seen an IRR's DB's not being updated for more than 30 days after allocations? I always assumed that they are quickly updated. Thanks again, Leslie Jon Lewis wrote: > Unallocated doesn't mean non-routed. All a spammer needs is a > willing/non-filtering provider doing BGP with them, and they can > announce any space they like, send out some spam, and then pull the > announcement. Next morning, when you see the spam and try to figure out > who to send complaints to, you're either going to complain to the wrong > people or find that whois is of no help. > > On Tue, 27 Oct 2009, Church, Charles wrote: > >> This is puzzling me. If it's from non-announced space, at some point >> some router should report no route to it. How is the TCP handshake >> performed to allow a sync to turn into spam? >> >> Chuck >> >> Chuck Church >> Network Planning Engineer, CCIE #8776 >> Harris Information Technology Services >> DOD Programs >> 1210 N. Parker Rd. | Greenville, SC 29609 >> Office: 864-335-9473 | Cell: 864-266-3978 >> -------------------------- >> Sent using BlackBerry >> >> From ops.lists at gmail.com Wed Oct 28 02:26:41 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 28 Oct 2009 12:56:41 +0530 Subject: dealing with bogon spam ? In-Reply-To: <4AE7E858.4020109@craigslist.org> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> Message-ID: Ah, colo4jax I see. Jacksonville, Florida. 68.234.16.0/20 shows up as unallocated but as these guys own the previous /20 its probably a stale arin db and a brand new allocation Prefix AS Path Aggregation Suggestion 68.234.0.0/20 4777 2497 25973 40430 68.234.16.0/20 4608 1221 4637 3561 40430 69.174.96.0/21 4777 2497 25973 40430 173.205.80.0/20 4777 2497 25973 40430 204.237.184.0/21 4777 2497 25973 40430 204.237.192.0/22 4777 2497 25973 40430 208.153.96.0/22 4777 2497 25973 40430 208.169.228.0/22 4777 2497 25973 40430 On Wed, Oct 28, 2009 at 12:14 PM, Leslie wrote: > Yes, unallocated (at least according to ARIN's whois db) but not unannounced > - obviously our network can get to the space or else I wouldn't be having a > spam problem with them! ? I'm actually seeing this ?/20 as advertised > through Savvis from AS40430 > > It seems to me like the best solution might be a semi-hacky solution of > asking arin (and other IRR's) if i can copy its DB and creating an internal > peer which null routes unallocated blocks (updated nightly?) > > Has anyone seen an IRR's DB's not being updated for more than 30 days after > allocations? ?I always assumed that they are quickly updated. > > Thanks again, > Leslie > > Jon Lewis wrote: >> >> Unallocated doesn't mean non-routed. ?All a spammer needs is a >> willing/non-filtering provider doing BGP with them, and they can announce >> any space they like, send out some spam, and then pull the announcement. >> Next morning, when you see the spam and try to figure out who to send >> complaints to, you're either going to complain to the wrong people or find >> that whois is of no help. >> >> On Tue, 27 Oct 2009, Church, Charles wrote: >> >>> This is puzzling me. ?If it's from non-announced space, at some point >>> some router should report no route to it. ?How is the TCP handshake >>> performed to allow a sync to turn into spam? >>> >>> Chuck >>> >>> Chuck Church >>> Network Planning Engineer, CCIE #8776 >>> Harris Information Technology Services >>> DOD Programs >>> 1210 N. Parker Rd. | Greenville, SC 29609 >>> Office: 864-335-9473 | Cell: 864-266-3978 >>> -------------------------- >>> Sent using BlackBerry >>> >>> > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jtk at cymru.com Wed Oct 28 03:27:46 2009 From: jtk at cymru.com (John Kristoff) Date: Wed, 28 Oct 2009 03:27:46 -0500 Subject: dealing with bogon spam ? In-Reply-To: <4AE7E858.4020109@craigslist.org> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> Message-ID: <20091028032746.27ae36ba@t61p> On Tue, 27 Oct 2009 23:44:40 -0700 Leslie wrote: > It seems to me like the best solution might be a semi-hacky solution > of asking arin (and other IRR's) if i can copy its DB and creating an > internal peer which null routes unallocated blocks (updated nightly?) > > Has anyone seen an IRR's DB's not being updated for more than 30 days > after allocations? I always assumed that they are quickly updated. Note, ARIN is an RIR, a regional internet registry, which is what I presume you meant there. Nevertheless, while it might be worth a try from a research perspective, it may be a bit risky in a production environment. In addition, someone may announce a more specific so keep that scenario in mind. The CIDR Report monitors RIR allocation data. This may be of interest to you: You can get access to that allocation data as noted here: John From michiel at klaver.it Wed Oct 28 03:48:19 2009 From: michiel at klaver.it (Michiel Klaver) Date: Wed, 28 Oct 2009 09:48:19 +0100 Subject: dealing with bogon spam ? In-Reply-To: <4AE788DD.3050605@craigslist.org> References: <4AE788DD.3050605@craigslist.org> Message-ID: <4AE80553.4060602@klaver.it> I would suggest to report that netblock to SpamHaus to have it included at their DROP list, and also use that DROP list as extra filter in addition to your bogon filter setup at your border routers. The SpamHaus DROP (Don't Route Or Peer) list was specially designed for this kind of abuse of stolen 'hijacked' netblocks and netblocks controlled entirely by professional spammers. http://www.spamhaus.org/drop/ With kind regards, Michiel Klaver IT Professional From jeroen at unfix.org Wed Oct 28 04:36:46 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 28 Oct 2009 10:36:46 +0100 Subject: dealing with bogon spam ? In-Reply-To: <4AE7E858.4020109@craigslist.org> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> Message-ID: <4AE810AE.6030302@spaghetti.zurich.ibm.com> Leslie wrote: [..] > It seems to me like the best solution might be a semi-hacky solution of > asking arin (and other IRR's) if i can copy its DB and creating an > internal peer which null routes unallocated blocks (updated nightly?) What you want to take is: $rirs = array( "afrinic" => "ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest", "apnic" => "ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest", "arin" => "ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest", "lacnic" => "ftp://ftp.ripe.net/pub/stats/lacnic/delegated-lacnic-latest", "ripe" => "ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest", "brnic" => "ftp://ftp.registro.br/pub/stats/delegated-ipv6-nicbr-latest", //// Avoid broken/slow servers: //// "afrinic" => "ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest", //// "apnic" => "ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest", //// "lacnic" => "ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest", ); Yes, generally the latter three are broken, but as they are mirrored to RIPE anyway, you can just pull them off there. Then you have all IPv4 and IPv6 delegated blocks. If it is not in there, it is a bogon. Yes, those are updated only once in a day or so, thus if some one is going to start using the block before it is published in those files you will get some false-positives, but then ask the question why they get a block up so quickly and start spamming you in the first place..... Those /stats/ dirs contain other useful things btw. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From Valdis.Kletnieks at vt.edu Wed Oct 28 06:14:07 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 28 Oct 2009 07:14:07 -0400 Subject: dealing with bogon spam ? In-Reply-To: Your message of "Tue, 27 Oct 2009 16:57:17 PDT." <4AE788DD.3050605@craigslist.org> References: <4AE788DD.3050605@craigslist.org> Message-ID: <29974.1256728447@turing-police.cc.vt.edu> On Tue, 27 Oct 2009 16:57:17 PDT, Leslie said: > We're seeing a decent chunk of spam coming from an unallocated block of > address space. Fear not, this will end when we run out of IPv4 space not too many months down the road :) I admit to remaining confused as to why we still keep seeing providers who fail to do basic due-diligence like BCP38 filtering of packets, or asking a new BGP peer what they expect to announce and then filter based on that. I mean, come on guys - sure they may be 6 cents a meg cheaper, but do you really want to buy connectivity from a provider that can't run their network in a proper fashion? Don't answer that. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jared at puck.nether.net Wed Oct 28 06:17:15 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 28 Oct 2009 07:17:15 -0400 Subject: dealing with bogon spam ? In-Reply-To: <4AE7E858.4020109@craigslist.org> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> Message-ID: <42D977CA-897B-4AB3-B343-1AAA7C493CE7@puck.nether.net> On Oct 28, 2009, at 2:44 AM, Leslie wrote: > Yes, unallocated (at least according to ARIN's whois db) but not > unannounced - obviously our network can get to the space or else I > wouldn't be having a spam problem with them! I'm actually seeing > this /20 as advertised through Savvis from AS40430 > > It seems to me like the best solution might be a semi-hacky solution > of asking arin (and other IRR's) if i can copy its DB and creating > an internal peer which null routes unallocated blocks (updated > nightly?) > > Has anyone seen an IRR's DB's not being updated for more than 30 > days after allocations? I always assumed that they are quickly > updated. > > Thanks again, > Leslie You may want to take a look at what is going on in the SIDR working group if you want something similar to this. - Jared From jared at puck.nether.net Wed Oct 28 06:25:08 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 28 Oct 2009 07:25:08 -0400 Subject: dealing with bogon spam ? In-Reply-To: <29974.1256728447@turing-police.cc.vt.edu> References: <4AE788DD.3050605@craigslist.org> <29974.1256728447@turing-police.cc.vt.edu> Message-ID: <65C03EDE-EBF4-4A62-A093-EA7CA690FA9D@puck.nether.net> On Oct 28, 2009, at 7:14 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 Oct 2009 16:57:17 PDT, Leslie said: >> We're seeing a decent chunk of spam coming from an unallocated >> block of >> address space. > > Fear not, this will end when we run out of IPv4 space not too many > months > down the road :) > > I admit to remaining confused as to why we still keep seeing > providers who fail > to do basic due-diligence like BCP38 filtering of packets, or asking > a new BGP > peer what they expect to announce and then filter based on that. I > mean, come > on guys - sure they may be 6 cents a meg cheaper, but do you really > want to buy > connectivity from a provider that can't run their network in a > proper fashion? > > Don't answer that. ;) I can answer the above question regarding BCP38: Vendor software defects and architecture limitations make it challenging to deploy a solution whereby BCP38 can be universally deployed. Customers that are unwilling to announce all their space also make uRPF problematic. I'd like to see 'loose-rpf' universally deployed myself. There is no reason for unrouted space to have packets sourced from it. This makes up a fair percentage of traffic that root/gtld nameservers see (based on conversations i've had with operators over the years). If you configure CPE devices and don't utilize anti-spoofing capabilities on the CPE-Lan, please add that to your templates. It is helpful to the internet as a whole, while you may not personally see return on your investment, others will. - Jared From randy at psg.com Wed Oct 28 08:20:04 2009 From: randy at psg.com (Randy Bush) Date: Wed, 28 Oct 2009 22:20:04 +0900 Subject: dealing with bogon spam ? In-Reply-To: <4AE810AE.6030302@spaghetti.zurich.ibm.com> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE810AE.6030302@spaghetti.zurich.ibm.com> Message-ID: >> It seems to me like the best solution might be a semi-hacky solution of >> asking arin (and other IRR's) if i can copy its DB and creating an >> internal peer which null routes unallocated blocks (updated nightly?) > > What you want to take is: > > $rirs = array( > "afrinic" => > "ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest", > "apnic" => > "ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest", > "arin" => > "ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest", > "lacnic" => > "ftp://ftp.ripe.net/pub/stats/lacnic/delegated-lacnic-latest", > "ripe" => > "ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest", > "brnic" => > "ftp://ftp.registro.br/pub/stats/delegated-ipv6-nicbr-latest", > > //// Avoid broken/slow servers: > //// "afrinic" => > "ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest", > //// "apnic" => > "ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest", > //// "lacnic" => > "ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest", > ); this is brilliant. maybe we should form an org to do this and distribute via bgp? shall we have a contest for the name of the org? my bid is cymru randy From sfouant at novadatacom.com Wed Oct 28 08:26:01 2009 From: sfouant at novadatacom.com (Stefan Fouant) Date: Wed, 28 Oct 2009 09:26:01 -0400 Subject: Redundant Data Center Architectures Message-ID: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. I imagine VPLS has a big play here, but I'm willing to bet there are all sorts of weirdness that such environments can create, such as the effect it may have on DR elections, etc. Also, what are your experiences in replication of storage over WAN links? Are people tending towards iSCSI or do trends indicate that FCoE or FCoIP may become the preferred mechanism? Any experience with WAN acceleration in such environments? Thanks in advance! -- Stefan Fouant From jeroen at unfix.org Wed Oct 28 08:52:56 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 28 Oct 2009 14:52:56 +0100 Subject: dealing with bogon spam ? In-Reply-To: References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE810AE.6030302@spaghetti.zurich.ibm.com> Message-ID: <4AE84CB8.6020305@spaghetti.zurich.ibm.com> Randy Bush wrote: >>> It seems to me like the best solution might be a semi-hacky solution of >>> asking arin (and other IRR's) if i can copy its DB and creating an >>> internal peer which null routes unallocated blocks (updated nightly?) >> What you want to take is: >> >> $rirs = array( >> "afrinic" => >> "ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest", [..] > this is brilliant. maybe we should form an org to do this and > distribute via bgp? shall we have a contest for the name of the org? > my bid is cymru Who have it already indeed for a long long time and have a proven track record. I noted the above for the people who want to get their own copy from the IRRs, like what was asked above. For instance for the few who want to build their own setups, want to integrate it in their own systems etc. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From sherwin.ang at gmail.com Wed Oct 28 09:10:58 2009 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Wed, 28 Oct 2009 22:10:58 +0800 Subject: Strip AS in BGP peer Message-ID: Hello Nanog, am not sure if i should have placed this on the cisco-nsp or the juniper-nsp but someone may have a direct answer. well here it goes. we'll soon form a new internet exchange and i would like to suggest a model in the route-server wherein the route-server would strip out it's own AS and give the neighbors/peers the AS's of the members. I have seen this in Any2IX but i have no idea on how to implement it as if i am the Any2 route-server. if you could point me to the right direction or reading, i could take it from there. -Sherwin From adrian at creative.net.au Wed Oct 28 09:19:54 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 28 Oct 2009 22:19:54 +0800 Subject: Strip AS in BGP peer In-Reply-To: References: Message-ID: <20091028141954.GE13291@skywalker.creative.net.au> Take a read of the quagga documentation. There's a BGP neighbor option for stripping out the local AS when speaking eBGP. Adrian On Wed, Oct 28, 2009, Sherwin Ang wrote: > Hello Nanog, > > am not sure if i should have placed this on the cisco-nsp or the > juniper-nsp but someone may have a direct answer. > > well here it goes. we'll soon form a new internet exchange and i > would like to suggest a model in the route-server wherein the > route-server would strip out it's own AS and give the neighbors/peers > the AS's of the members. I have seen this in Any2IX but i have no > idea on how to implement it as if i am the Any2 route-server. > > if you could point me to the right direction or reading, i could take > it from there. From nanog at daork.net Wed Oct 28 09:24:17 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 29 Oct 2009 03:24:17 +1300 Subject: dealing with bogon spam ? In-Reply-To: <4AE84CB8.6020305@spaghetti.zurich.ibm.com> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE810AE.6030302@spaghetti.zurich.ibm.com> <4AE84CB8.6020305@spaghetti.zurich.ibm.com> Message-ID: On 29/10/2009, at 2:52 AM, Jeroen Massar wrote: > Randy Bush wrote: >>>> It seems to me like the best solution might be a semi-hacky >>>> solution of >>>> asking arin (and other IRR's) if i can copy its DB and creating an >>>> internal peer which null routes unallocated blocks (updated >>>> nightly?) >>> What you want to take is: >>> >>> $rirs = array( >>> "afrinic" => >>> "ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest", > [..] >> this is brilliant. maybe we should form an org to do this and >> distribute via bgp? shall we have a contest for the name of the org? >> my bid is cymru > > Who have it already indeed for a long long time and have a proven > track > record. > > I noted the above for the people who want to get their own copy from > the > IRRs, like what was asked above. For instance for the few who want to > build their own setups, want to integrate it in their own systems etc. I can't see anything on their site that provides a BGP feed of prefixes allocated by RIRs, which I think is what we're talking about here. -- Nathan Ward From chris at chrisserafin.com Wed Oct 28 09:56:18 2009 From: chris at chrisserafin.com (ChrisSerafin) Date: Wed, 28 Oct 2009 09:56:18 -0500 Subject: Redundant Data Center Architectures In-Reply-To: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> Message-ID: <4AE85B92.9000706@chrisserafin.com> We are doing: Citrix XenServer environments at both sites with NetApps for the SANs MPLS connections with Riverbeds for WAN op. Let me know if you wanna dig into this deeper. Stefan Fouant wrote: > I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. I imagine VPLS has a big play here, but I'm willing to bet there are all sorts of weirdness that such environments can create, such as the effect it may have on DR elections, etc. Also, what are your experiences in replication of storage over WAN links? Are people tending towards iSCSI or do trends indicate that FCoE or FCoIP may become the preferred mechanism? Any experience with WAN acceleration in such environments? > > Thanks in advance! > > -- > Stefan Fouant > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 10/28/09 09:34:00 > > From luan at netcraftsmen.net Wed Oct 28 09:57:14 2009 From: luan at netcraftsmen.net (Luan Nguyen) Date: Wed, 28 Oct 2009 10:57:14 -0400 Subject: ISP with CSC/CoC? Message-ID: <4AE85BCA.5030507@netcraftsmen.net> Hello, I am studying for the CCIE Service Provider and ran across a few CSC/CoC scenarios. I am wondering if any major ISP uses/offers this kind of service? Thanks. ----------------------------- Luan Nguyen Chesapeake NetCraftsmen, LLC. http://www.netcraftsmen.net ----------------------------- __________ Information from ESET NOD32 Antivirus, version of virus signature database 4551 (20091028) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From jtk at cymru.com Wed Oct 28 09:58:03 2009 From: jtk at cymru.com (John Kristoff) Date: Wed, 28 Oct 2009 09:58:03 -0500 Subject: dealing with bogon spam ? In-Reply-To: References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE810AE.6030302@spaghetti.zurich.ibm.com> <4AE84CB8.6020305@spaghetti.zurich.ibm.com> Message-ID: <20091028095803.7c7f0a34@t61p> On Thu, 29 Oct 2009 03:24:17 +1300 Nathan Ward wrote: > I can't see anything on their site that provides a BGP feed of > prefixes allocated by RIRs, which I think is what we're talking > about here. We currently provide A BGP bogon route server feed for the asking, which are routes of 'well known' aggregate prefixes published by IANA as well as special and reserved netblocks documented by a IETF that should not be seen on the public net. Providing a feed of allocations would be the opposite approach of course. I suppose if there is interest and a need we could do this. Shoot myself or the team (info at cymru.com) a note off list if you have thoughts on the matter or simply want to provide some feedback into such a service and how it might best be used. We're always on the look out for things we can do to help. John From leslie at craigslist.org Wed Oct 28 10:14:11 2009 From: leslie at craigslist.org (Leslie) Date: Wed, 28 Oct 2009 08:14:11 -0700 Subject: dealing with bogon spam ? In-Reply-To: <4AE7E858.4020109@craigslist.org> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> Message-ID: <4AE85FC3.9050002@craigslist.org> Just FYI the colo4jax guys got back to me and it is a stale ARIN db entry - I guess they don't update it as quickly as I thought. So this is now just a normal case of spam. Leslie Leslie wrote: > Yes, unallocated (at least according to ARIN's whois db) but not > unannounced - obviously our network can get to the space or else I > wouldn't be having a spam problem with them! I'm actually seeing this > /20 as advertised through Savvis from AS40430 > > It seems to me like the best solution might be a semi-hacky solution of > asking arin (and other IRR's) if i can copy its DB and creating an > internal peer which null routes unallocated blocks (updated nightly?) > > Has anyone seen an IRR's DB's not being updated for more than 30 days > after allocations? I always assumed that they are quickly updated. > > Thanks again, > Leslie > > Jon Lewis wrote: >> Unallocated doesn't mean non-routed. All a spammer needs is a >> willing/non-filtering provider doing BGP with them, and they can >> announce any space they like, send out some spam, and then pull the >> announcement. Next morning, when you see the spam and try to figure >> out who to send complaints to, you're either going to complain to the >> wrong people or find that whois is of no help. >> >> On Tue, 27 Oct 2009, Church, Charles wrote: >> >>> This is puzzling me. If it's from non-announced space, at some point >>> some router should report no route to it. How is the TCP handshake >>> performed to allow a sync to turn into spam? >>> >>> Chuck >>> >>> Chuck Church >>> Network Planning Engineer, CCIE #8776 >>> Harris Information Technology Services >>> DOD Programs >>> 1210 N. Parker Rd. | Greenville, SC 29609 >>> Office: 864-335-9473 | Cell: 864-266-3978 >>> -------------------------- >>> Sent using BlackBerry >>> >>> From chaz at chaz6.com Wed Oct 28 10:23:19 2009 From: chaz at chaz6.com (Chris Hills) Date: Wed, 28 Oct 2009 16:23:19 +0100 Subject: dealing with bogon spam ? In-Reply-To: <4AE788DD.3050605@craigslist.org> References: <4AE788DD.3050605@craigslist.org> Message-ID: On 28/10/09 00:57, Leslie wrote: > How have you dealt with this issue? Does anyone publish a more granular > listing of unallocated space? Does arin have this information somewhere > other than just probing any given ip via whois? You can at least get a list of all the allocated blocks. Presumably anything not allocated is unallocated and is a candidate for blocking. for rir in afrinic apnic arin lacnic ripencc; do wget ftp://ftp.ripe.net/pub/stats/$rir/delegated-$rir-latest; done These are updated daily and include both IPv4 and IPv6 allocations. Now, what I would really like is an arin version of ripe.db.inetnum.gz :-) From andy at nosignal.org Wed Oct 28 11:25:09 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 28 Oct 2009 16:25:09 +0000 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> Message-ID: <4AE87065.9040204@nosignal.org> Iljitsch van Beijnum wrote: > This would be a big mistake. Fate sharing between the device that > advertises the presence of a router and the device that forwards packets > makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! A From leslie at craigslist.org Wed Oct 28 11:52:47 2009 From: leslie at craigslist.org (Leslie) Date: Wed, 28 Oct 2009 09:52:47 -0700 Subject: dealing with bogon spam ? In-Reply-To: <20091028095803.7c7f0a34@t61p> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE810AE.6030302@spaghetti.zurich.ibm.com> <4AE84CB8.6020305@spaghetti.zurich.ibm.com> <20091028095803.7c7f0a34@t61p> Message-ID: <4AE876DF.8070300@craigslist.org> John Kristoff wrote: > On Thu, 29 Oct 2009 03:24:17 +1300 > Nathan Ward wrote: > >> I can't see anything on their site that provides a BGP feed of >> prefixes allocated by RIRs, which I think is what we're talking >> about here. > > We currently provide A BGP bogon route server feed for the asking, > which are routes of 'well known' aggregate prefixes published by IANA as > well as special and reserved netblocks documented by a IETF that should > not be seen on the public net. > > Providing a feed of allocations would be the opposite approach of > course. > > I suppose if there is interest and a need we could do this. Shoot > myself or the team (info at cymru.com) a note off list if you have > thoughts on the matter or simply want to provide some feedback into > such a service and how it might best be used. We're always on the look > out for things we can do to help. > My big issue isn't the larger blocks, it's the smaller unallocated blocks - which anyone with a not-too-strict transit provider could easily steal and abuse. Getting the allocated space is just another way of finding the smaller unallocated blocks (with a bit of extra work) From andrewy at webair.com Wed Oct 28 11:56:56 2009 From: andrewy at webair.com (andrew young) Date: Wed, 28 Oct 2009 12:56:56 -0400 Subject: looking for optonline/cablevision contact Message-ID: <4AE877D8.5010200@webair.com> ive been having a mailing issue with optonline/cablevision for several weeks now and normal business tech support is giving me the run around. can someone from optonline/cablevision contact me off thread so i can try to get this simple thing resolved. -- ---------------------------------------- Andrew Young Webair Internet Development, Inc. Phone: 1 866 WEBAIR 1 x143 http://www.webair.com Shift hours: Tues-Friday 12PM-8PM, Sat 9AM-5PM From rdobbins at arbor.net Wed Oct 28 12:38:29 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 29 Oct 2009 00:38:29 +0700 Subject: Redundant Data Center Architectures In-Reply-To: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> Message-ID: On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: > I'm wondering what are the growing trends in connecting Data Centers > for redundancy in DR/COOP environments. 'DR' is an obsolete 40-year-old mainframe concept; it never works, as funding/testing/scaling of the 'backup' systems is never adequate and/ or allowed. Layer-2 between sites is evil, as well. Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From charles at thewybles.com Wed Oct 28 12:42:26 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 28 Oct 2009 10:42:26 -0700 Subject: Redundant Data Center Architectures In-Reply-To: References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> Message-ID: <1BCED66A-6693-4BD8-A10A-65D7DD2308CD@thewybles.com> On Oct 28, 2009, at 10:38 AM, Roland Dobbins wrote: > > On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: > >> I'm wondering what are the growing trends in connecting Data >> Centers for redundancy in DR/COOP environments. > > 'DR' is an obsolete 40-year-old mainframe concept; it never works, > as funding/testing/scaling of the 'backup' systems is never adequate > and/or allowed. Very true. > > Layer-2 between sites is evil, as well. > Indeed. Now VmWare actually supports layer3 for vsphere, maybe we will start to see it go away. :) > Layer-3-independence and active/active/etc. is where it's at in > terms of high availability in the 21st Century. GSLB, et. al. Yep. That way all your environments get adequate(ish) funding. Vs management saying "oh it's just backup/dr, we will fund it next year". From ray.sanders at villagevoicemedia.com Wed Oct 28 12:42:51 2009 From: ray.sanders at villagevoicemedia.com (Ray Sanders) Date: Wed, 28 Oct 2009 10:42:51 -0700 Subject: Redundant Data Center Architectures In-Reply-To: References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> Message-ID: <4AE8829B.6010903@villagevoicemedia.com> Roland, Could you elaborate on "GSLB" (Global Load Balancing?) ? Pardon if that question seems a bit "noob-ish" Thanks Roland Dobbins wrote: > > On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: > >> I'm wondering what are the growing trends in connecting Data Centers >> for redundancy in DR/COOP environments. > > 'DR' is an obsolete 40-year-old mainframe concept; it never works, as > funding/testing/scaling of the 'backup' systems is never adequate > and/or allowed. > > Layer-2 between sites is evil, as well. > > Layer-3-independence and active/active/etc. is where it's at in terms > of high availability in the 21st Century. GSLB, et. al. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Sorry, sometimes I mistake your existential crises for technical > insights. > > -- xkcd #625 > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 10/28/09 09:34:00 > > -- -"Prediction is very difficult, especially about the future." -Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From ryan at hack.net Wed Oct 28 12:43:37 2009 From: ryan at hack.net (Ryan Brooks) Date: Wed, 28 Oct 2009 12:43:37 -0500 Subject: Redundant Data Center Architectures In-Reply-To: References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> Message-ID: <4AE882C9.9090206@hack.net> Roland Dobbins wrote: > > On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: > >> I'm wondering what are the growing trends in connecting Data Centers >> for redundancy in DR/COOP environments. > > 'DR' is an obsolete 40-year-old mainframe concept; it never works, as > funding/testing/scaling of the 'backup' systems is never adequate > and/or allowed. > > Layer-2 between sites is evil, as well. > > Layer-3-independence and active/active/etc. is where it's at in terms > of high availability in the 21st Century. GSLB, et. al. And that's about all you need to know. Never heard it put so succinctly - thanks, -Ryan Brooks From brandon.galbraith at gmail.com Wed Oct 28 12:44:07 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 28 Oct 2009 12:44:07 -0500 Subject: Redundant Data Center Architectures In-Reply-To: References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> Message-ID: <366100670910281044s525e7a78x69aac1ed8e1fca11@mail.gmail.com> >>Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. Somewhere on video.google.com is a Google I/O talk explaining the hell that is active/active redundancy and how hard it is to achieve at layers 4-7. I don't argue that it's the proper method for Layer 3 though. -brandon On Wed, Oct 28, 2009 at 12:38 PM, Roland Dobbins wrote: > > On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: > > I'm wondering what are the growing trends in connecting Data Centers for >> redundancy in DR/COOP environments. >> > > 'DR' is an obsolete 40-year-old mainframe concept; it never works, as > funding/testing/scaling of the 'backup' systems is never adequate and/or > allowed. > > Layer-2 between sites is evil, as well. > > Layer-3-independence and active/active/etc. is where it's at in terms of > high availability in the 21st Century. GSLB, et. al. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Sorry, sometimes I mistake your existential crises for technical > insights. > > -- xkcd #625 > > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From rdobbins at arbor.net Wed Oct 28 12:48:00 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 29 Oct 2009 00:48:00 +0700 Subject: Redundant Data Center Architectures In-Reply-To: <366100670910281044s525e7a78x69aac1ed8e1fca11@mail.gmail.com> References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> <366100670910281044s525e7a78x69aac1ed8e1fca11@mail.gmail.com> Message-ID: <51AD075C-C202-4DA4-9FBD-13502CD6B421@arbor.net> On Oct 29, 2009, at 12:44 AM, Brandon Galbraith wrote: > Somewhere on video.google.com is a Google I/O talk explaining the > hell that > is active/active redundancy and how hard it is to achieve at layers > 4-7. Depends upon the type of apps, amount of required concurrency, etc. It's easy on the front-end (which is where most of the drama tends to take place, anyways); it's the middle and back-end tiers which require some work, but it certainly can be and is accomplished daily, for both simple and more complex systems. The smart money makes use of various existing *aaS platforms to accomplish this without having to re-invent the wheel every time. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From rdobbins at arbor.net Wed Oct 28 12:57:34 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 29 Oct 2009 00:57:34 +0700 Subject: Redundant Data Center Architectures In-Reply-To: <4AE8829B.6010903@villagevoicemedia.com> References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> <4AE8829B.6010903@villagevoicemedia.com> Message-ID: On Oct 29, 2009, at 12:42 AM, Ray Sanders wrote: > Could you elaborate on "GSLB" (Global Load Balancing?) ? Architectural choices, implementation scenarios, DNS tricks to ensure optimal cleaving to and availability of distributed nodes within a given tier: ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From brandon.galbraith at gmail.com Wed Oct 28 13:01:23 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 28 Oct 2009 13:01:23 -0500 Subject: Redundant Data Center Architectures In-Reply-To: References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> <4AE8829B.6010903@villagevoicemedia.com> Message-ID: <366100670910281101y6da625d7j52acfb7a503f505e@mail.gmail.com> Props for mentioning mod_backhand. Excellent tool for GSLB. On Wed, Oct 28, 2009 at 12:57 PM, Roland Dobbins wrote: > > On Oct 29, 2009, at 12:42 AM, Ray Sanders wrote: > > Could you elaborate on "GSLB" (Global Load Balancing?) ? >> > > Architectural choices, implementation scenarios, DNS tricks to ensure > optimal cleaving to and availability of distributed nodes within a given > tier: > > > > > > > > > > > > > > > ----------------------------------------------------------------------- > Roland Dobbins // > > Sorry, sometimes I mistake your existential crises for technical > insights. > > -- xkcd #625 > > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From kizmet at kizmet.id.au Wed Oct 28 13:01:09 2009 From: kizmet at kizmet.id.au (Cody Appleby) Date: Thu, 29 Oct 2009 05:01:09 +1100 Subject: Strip AS in BGP peer In-Reply-To: <20091028141954.GE13291@skywalker.creative.net.au> References: <20091028141954.GE13291@skywalker.creative.net.au> Message-ID: <21ef81469e0a785dd72e393e5d6a83b3@localhost> More specifically: - neighbor *ip or peer-group* attribute-unchanged as-path Cheers, Cody On Wed, 28 Oct 2009 22:19:54 +0800, Adrian Chadd wrote: > Take a read of the quagga documentation. There's a BGP neighbor option > for stripping out the local AS when speaking eBGP. > > > > Adrian > > On Wed, Oct 28, 2009, Sherwin Ang wrote: >> Hello Nanog, >> >> am not sure if i should have placed this on the cisco-nsp or the >> juniper-nsp but someone may have a direct answer. >> >> well here it goes. we'll soon form a new internet exchange and i >> would like to suggest a model in the route-server wherein the >> route-server would strip out it's own AS and give the neighbors/peers >> the AS's of the members. I have seen this in Any2IX but i have no >> idea on how to implement it as if i am the Any2 route-server. >> >> if you could point me to the right direction or reading, i could take >> it from there. From justin at justinshore.com Wed Oct 28 13:46:39 2009 From: justin at justinshore.com (Justin Shore) Date: Wed, 28 Oct 2009 13:46:39 -0500 Subject: dealing with bogon spam ? In-Reply-To: <4AE80553.4060602@klaver.it> References: <4AE788DD.3050605@craigslist.org> <4AE80553.4060602@klaver.it> Message-ID: <4AE8918F.5010805@justinshore.com> Michiel Klaver wrote: > I would suggest to report that netblock to SpamHaus to have it included > at their DROP list, and also use that DROP list as extra filter in > addition to your bogon filter setup at your border routers. > > The SpamHaus DROP (Don't Route Or Peer) list was specially designed for > this kind of abuse of stolen 'hijacked' netblocks and netblocks > controlled entirely by professional spammers. As a brief off-shoot of the original topic, has anyone scripted the use of Spamhaus's DROP list in a RTBH, ACLs, null-routes, etc? I'm not asking if people think it's safe; that's up to the network wanting to deploy it. I'm wondering if anyone has any scripts for pulling down the DROP list, parsing it into whatever you need (static routes on a RTBH trigger router or ACLs on a border router and then deployed the config change(s). I don't want to reinvent the wheel is someone else has already done this. Thanks Justin From arnold at nipper.de Wed Oct 28 13:51:08 2009 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 28 Oct 2009 19:51:08 +0100 Subject: Strip AS in BGP peer In-Reply-To: <21ef81469e0a785dd72e393e5d6a83b3@localhost> References: <20091028141954.GE13291@skywalker.creative.net.au> <21ef81469e0a785dd72e393e5d6a83b3@localhost> Message-ID: <4AE8929C.1050700@nipper.de> On 28.10.2009 19:01 Cody Appleby wrote > More specifically: > - neighbor *ip or peer-group* attribute-unchanged as-path > To leave _everything_ unchanged (med and next hop which goes w/o saying ;-)) might even best. Hence go for neighbor attribute-unchanged Of course there are also other implemenations like OpenBGPD and BIRD (http://bird.network.cz/) which also do support that feature. You could even do per peer RIB to give each of your customer its own view. Does work for small to medium sized IXP but has not yet proven to run for really large IXP. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jason at i6ix.com Wed Oct 28 13:56:47 2009 From: jason at i6ix.com (Jason Bertoch) Date: Wed, 28 Oct 2009 14:56:47 -0400 Subject: dealing with bogon spam ? In-Reply-To: <4AE8918F.5010805@justinshore.com> References: <4AE788DD.3050605@craigslist.org> <4AE80553.4060602@klaver.it> <4AE8918F.5010805@justinshore.com> Message-ID: <4AE893EF.4080906@i6ix.com> Justin Shore wrote: > Michiel Klaver wrote: >> I would suggest to report that netblock to SpamHaus to have it >> included at their DROP list, and also use that DROP list as extra >> filter in addition to your bogon filter setup at your border routers. >> >> The SpamHaus DROP (Don't Route Or Peer) list was specially designed >> for this kind of abuse of stolen 'hijacked' netblocks and netblocks >> controlled entirely by professional spammers. > > As a brief off-shoot of the original topic, has anyone scripted the > use of Spamhaus's DROP list in a RTBH, ACLs, null-routes, etc? I'm > not asking if people think it's safe; that's up to the network wanting > to deploy it. I'm wondering if anyone has any scripts for pulling > down the DROP list, parsing it into whatever you need (static routes > on a RTBH trigger router or ACLs on a border router and then deployed > the config change(s). I don't want to reinvent the wheel is someone > else has already done this. Downloading and parsing is easy. I used to drop it into the config for a small dns server, rbldnsd I believe, that understands CIDR and used it as a local blacklist. It did very little to stop spam and I was never brave enough to script an automatic update to BGP. From jeroen at unfix.org Wed Oct 28 13:59:15 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 28 Oct 2009 19:59:15 +0100 Subject: dealing with bogon spam ? In-Reply-To: <4AE876DF.8070300@craigslist.org> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE810AE.6030302@spaghetti.zurich.ibm.com> <4AE84CB8.6020305@spaghetti.zurich.ibm.com> <20091028095803.7c7f0a34@t61p> <4AE876DF.8070300@craigslist.org> Message-ID: <4AE89483.3010501@spaghetti.zurich.ibm.com> Leslie wrote: > John Kristoff wrote: >> I suppose if there is interest and a need we could do this. Shoot >> myself or the team (info at cymru.com) a note off list if you have >> thoughts on the matter or simply want to provide some feedback into >> such a service and how it might best be used. We're always on the look >> out for things we can do to help. > > My big issue isn't the larger blocks, it's the smaller unallocated > blocks - which anyone with a not-too-strict transit provider could > easily steal and abuse. Getting the allocated space is just another way > of finding the smaller unallocated blocks (with a bit of extra work) The problem though with BGP is that when you have say a NonAllocatedFeed containing 10.0.0.0/8 then when somebody else announced 10.1.2.0/24 (or any other more specific) it will perfectly work. Unless you are able to pull of some tricks in hardware based routers (software based ones you can of course modify to do whatever you want but might not be the right thing to run in some scenarios). As such, pulling the delegated files and generating prefix filters yourself, which you most likely have anyway for things like blackholing prefixes you otherwise also don't want to talk too.... And don't forget to source-filter those prefixes too :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From bit.gossip at chello.nl Wed Oct 28 14:05:48 2009 From: bit.gossip at chello.nl (Luca Tosolini) Date: Wed, 28 Oct 2009 20:05:48 +0100 Subject: ip options Message-ID: <1256756748.2228.9.camel@nld06907> Experts, out of the well-known values for ip options: X at r4# set ip-options ? Possible completions: Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them. Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca. From dciccaro at cisco.com Wed Oct 28 14:17:03 2009 From: dciccaro at cisco.com (Dario Ciccarone (dciccaro)) Date: Wed, 28 Oct 2009 15:17:03 -0400 Subject: ip options In-Reply-To: <1256756748.2228.9.camel@nld06907> References: <1256756748.2228.9.camel@nld06907> Message-ID: <829173BE40A7F147AC51726688B0374B0754B47E@xmb-rtp-203.amer.cisco.com> Luca: Check http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/s ec_acl_sel_drop_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1 043334 Not the whole story, but :) Hope it helps, Dario > -----Original Message----- > From: Luca Tosolini [mailto:bit.gossip at chello.nl] > Sent: Wednesday, October 28, 2009 3:06 PM > To: nanog > Subject: ip options > > Experts, > out of the well-known values for ip options: > > X at r4# set ip-options ? > Possible completions: > Range of values > [ Open a set of values > any Any IP option > loose-source-route Loose source route > route-record Route record > router-alert Router alert > security Security > stream-id Stream ID > strict-source-route Strict source route > timestamp Timestamp > > I can only think of: > - RSVP using router-alert > - ICMP using route-record, timestamp > > But I can not think of any other use of any other IP option. > Considering the security hazard that they imply, I am > therefore thinking > to drop them. > > Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? > Thanks, > Luca. > > > From rdobbins at arbor.net Wed Oct 28 14:20:21 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 29 Oct 2009 02:20:21 +0700 Subject: ip options In-Reply-To: <1256756748.2228.9.camel@nld06907> References: <1256756748.2228.9.camel@nld06907> Message-ID: <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> On Oct 29, 2009, at 2:05 AM, Luca Tosolini wrote: > Considering the security hazard that they imply, I am therefore > thinking > to drop them. You should certainly consider the impact on traceroute and possibly QoS (i.e., RSVP, if it's relevant) in your environment. Some vendors/platforms also have the option to ignore, rather than drop. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From darren at bolding.org Wed Oct 28 15:57:02 2009 From: darren at bolding.org (Darren Bolding) Date: Wed, 28 Oct 2009 13:57:02 -0700 Subject: Redundant Data Center Architectures In-Reply-To: References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> <4AE8829B.6010903@villagevoicemedia.com> Message-ID: <5a318d410910281357i34876c8aq6fd6670f89303c3d@mail.gmail.com> Also, commercial solutions from F5 (their GTM product and their old 3-DNS product). Using CDN's is also a way of handling this, but you need to be prepared for all your traffic to come from their source-ip's or do creative things with x-forwarded-for etc. Making an active/active datacenter design work (or preferably one with enough sites such that more than one can be down without seriously impacted service) is a serious challenge. Lots of people will tell you (and sell you solutions for) parts of the puzzle. My experience has been that the best case is when the architecture of the application/infrastructure have been designed with these challenges in mind from the get-go. I have seen that done on the network and server side, but never on the software side- that has always required significant effort when the time came. The "drop in" solutions for this (active/active database replication, middleware solutions, proxies) are always expensive in one way or another and frequently have major deployment challenges. The network side of this can frequently be the easiest to resolve, in my experience. If you are serving up content that does not require synchronized data on the backend, then that will make your life much easier, and GSLB, a CDN or similar may help a great deal. --D On Wed, Oct 28, 2009 at 10:57 AM, Roland Dobbins wrote: > > On Oct 29, 2009, at 12:42 AM, Ray Sanders wrote: > > Could you elaborate on "GSLB" (Global Load Balancing?) ? >> > > Architectural choices, implementation scenarios, DNS tricks to ensure > optimal cleaving to and availability of distributed nodes within a given > tier: > > > > > > > > > > > > > > > ----------------------------------------------------------------------- > Roland Dobbins // > > Sorry, sometimes I mistake your existential crises for technical > insights. > > -- xkcd #625 > > > -- -- Darren Bolding -- -- darren at bolding.org -- From jdupuy-list at socket.net Wed Oct 28 16:20:36 2009 From: jdupuy-list at socket.net (JD) Date: Wed, 28 Oct 2009 16:20:36 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> Message-ID: <4AE8B5A4.4040404@socket.net> There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? :) ). There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things. Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers. Thanks, John From jbates at brightok.net Wed Oct 28 16:32:52 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 28 Oct 2009 16:32:52 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8B5A4.4040404@socket.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: <4AE8B884.6060207@brightok.net> JD wrote: > There seem to be pros and cons to both directions. Certainly true > bridging has less overhead. But modern CPEs can minimize the impact of > PPPoE. PPPoE allows for more flexible provisioning; including via > RADIUS. Useful for the call center turning customers on/off without NOC > help. But VLAN tricks can sometimes do many of the same things. Call your vendor and demand better radius backend support for dhcp. :) The largest fallback to PPPoE is the CPE needing to terminate the PPPoE or the customer's router/computer/etc needing to do so. This can be a pain especially in business environments. I have one section of my network (maintained by counterpart, not me) that is 90% PPPoE/A. The other 10% is bridge due to customer needs and CPE limitations. I personally run all my stuff as bridge, including all the CPEs. > BTW, I doubt it is relevant to the discussion, but most of our DSLAMS > are Adtran TA5000s (or are being migrated to that platform.) We are > mostly a cisco shop for the upstream routers. I have been extremely happy with unnumbered vlans in the cisco work for terminating mass vlans from dslams that support 802.1ad. The fact that it works right next to RBE works great for me. The current IPv6 layouts aren't as pretty for this setup, though. Jack From sfouant at novadatacom.com Wed Oct 28 16:39:28 2009 From: sfouant at novadatacom.com (Stefan Fouant) Date: Wed, 28 Oct 2009 17:39:28 -0400 Subject: Redundant Data Center Architectures In-Reply-To: <5a318d410910281357i34876c8aq6fd6670f89303c3d@mail.gmail.com> References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> <4AE8829B.6010903@villagevoicemedia.com> <5a318d410910281357i34876c8aq6fd6670f89303c3d@mail.gmail.com> Message-ID: <98F9072C6B4A354486105E1679432E130C34AC909D@NOVAMAIL.novadatacom.local> > -----Original Message----- > From: Darren Bolding [mailto:darren at bolding.org] > Sent: Wednesday, October 28, 2009 4:57 PM > To: Roland Dobbins > Cc: NANOG list > Subject: Re: Redundant Data Center Architectures > > Also, commercial solutions from F5 (their GTM product and their old 3- > DNS > product). > > Using CDN's is also a way of handling this, but you need to be prepared > for > all your traffic to come from their source-ip's or do creative things > with > x-forwarded-for etc. > > Making an active/active datacenter design work (or preferably one with > enough sites such that more than one can be down without seriously > impacted > service) is a serious challenge. Lots of people will tell you (and > sell you > solutions for) parts of the puzzle. My experience has been that the > best > case is when the architecture of the application/infrastructure have > been > designed with these challenges in mind from the get-go. I have seen > that > done on the network and server side, but never on the software side- > that > has always required significant effort when the time came. > > The "drop in" solutions for this (active/active database replication, > middleware solutions, proxies) are always expensive in one way or > another > and frequently have major deployment challenges. > > The network side of this can frequently be the easiest to resolve, in > my > experience. If you are serving up content that does not require > synchronized data on the backend, then that will make your life much > easier, > and GSLB, a CDN or similar may help a great deal. Thanks everyone who has responded so far. I should have clarified my intent a bit in the original email. I am definitely interested in architectures which support synchronized data between data center locations in as close to real-time as possible. More specifically, I am interested in designs which support zero down-time during failures, or as close to zero down-time as possible. GSLB, Anycast, CDNs... those types of approaches certainly have their place especially where the pull-model is employed (DNS, Netflix, etc.). However, what types of solutions are being used for synchronized data and even network I/O on back-end systems? I've been looking at the VMware vSphere 4 Fault Tolerance stuff to synchronize the data storage and network I/O across distributed virtual machines, but still worried about the consequences of doing this stuff across WAN links with high degrees of latency, etc. From the thread I get the feeling that L2 interconnects (VPLS, PWs) are generally considered a bad thing, I gathered as much as I figured there would be lots of unintended consequences with regards to designated router elections and other weirdness. Besides connecting sites via L3 VPNs, what other approaches are others using? Also, would appreciate any comments to the synchronization items above. Thanks, -- Stefan Fouant From saxon.jones at gmail.com Wed Oct 28 16:44:23 2009 From: saxon.jones at gmail.com (Saxon Jones) Date: Wed, 28 Oct 2009 15:44:23 -0600 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8B5A4.4040404@socket.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: <86b512c30910281444o537cd97fy8cec1cdf7a3f513a@mail.gmail.com> On Cisco hardware PPPoE was cleaner if you have other ISPs' customers on your network and you want to put them in their own VRF's. I've been out of that world for a while now, so maybe it's changed. -saxon 2009/10/28 JD > There is a debate among our engineering staff as to the best means of > provisioning broadband service over copper facilities. Due to our history, > we have a mix out in the field. Some customers are on DSLAMS set up for > bridged connections with DHCP; isolated by a variety of means including > VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE > over ethernet (PPPoEoE ?? :) ). > > There seem to be pros and cons to both directions. Certainly true bridging > has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE > allows for more flexible provisioning; including via RADIUS. Useful for the > call center turning customers on/off without NOC help. But VLAN tricks can > sometimes do many of the same things. > > Opinions on this? I'd be interested in hearing the latest real world > experience for both and the direction most folks are going in. > > BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are > Adtran TA5000s (or are being migrated to that platform.) We are mostly a > cisco shop for the upstream routers. > > Thanks, > > John > > From dave at mvn.net Wed Oct 28 17:10:07 2009 From: dave at mvn.net (David E. Smith) Date: Wed, 28 Oct 2009 17:10:07 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8B5A4.4040404@socket.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> > > Opinions on this? I'd be interested in hearing the latest real world > experience for both and the direction most folks are going in. > > I can't speak to which would be better on copper specifically, but in general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net From walter.keen at rainierconnect.net Wed Oct 28 17:33:58 2009 From: walter.keen at rainierconnect.net (Walter Keen) Date: Wed, 28 Oct 2009 15:33:58 -0700 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> Message-ID: <4AE8C6D6.4070309@rainierconnect.net> Most aDSL modems if set to PPPoE (I think Actiontec's come this way by default) will send the mac as the pppoe un/pw. David E. Smith wrote: Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. I can't speak to which would be better on copper specifically, but in general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 From ck at sandcastl.es Wed Oct 28 17:53:40 2009 From: ck at sandcastl.es (christian koch) Date: Wed, 28 Oct 2009 15:53:40 -0700 Subject: ALTDB Problems In-Reply-To: <9CCF0873-453C-4594-856F-367F90E8C97B@tch.org> References: <9CCF0873-453C-4594-856F-367F90E8C97B@tch.org> Message-ID: <8c308e8b0910281553le4d86efu282df7a6a9d9ba95@mail.gmail.com> On Tue, Oct 27, 2009 at 11:21 AM, Steve Rubin wrote: > > ALTDB is free and you get what you pay for. > > However. Donations to http://www.nanog.org/scholarships/abha.php would > probably get requests done a lot faster. > > > -- > Steve Rubin / AE6CH / http://www.altdb.net/ > Email: ser at tch.org / N6441C / http://www.tch.org/~ser/ > > so, each time someone wants to update they need to donate to make sure it gets processed in a timely matter? or do you track who donates and give priority to their updates? dont get me wrong - its a great cause, and people should donate if they can if the project is short of volunteers - i'm sure there are people in the community who would not mind helping out -ck From george at montco.net Wed Oct 28 18:30:03 2009 From: george at montco.net (George Carey) Date: Wed, 28 Oct 2009 19:30:03 -0400 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8B5A4.4040404@socket.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: <29D0CDD9-3839-41C6-9C85-C570F151F585@montco.net> We like PPPoE on the edge because we can use RADIUS to apply policy to the subscribers for bandwidth management, class-of-service, SNPs, etc. You probably have some of these features via your DSLAM, but we found it easier to do via RADIUS with a web based GUI for our provisioning folks. So if we need to snip someone's Internet and leave voice or VPN packets alone due to an abuse issue for example, we can apply the policy that references the appropriate ACL. George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 28 18:32:59 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 29 Oct 2009 10:02:59 +1030 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8C6D6.4070309@rainierconnect.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> <4AE8C6D6.4070309@rainierconnect.net> Message-ID: <20091029100259.50ae9306@opy.nosense.org> On Wed, 28 Oct 2009 15:33:58 -0700 Walter Keen wrote: > Most aDSL modems if set to PPPoE (I think Actiontec's come this way by > default) will send the mac as the pppoe un/pw. > David E. Smith wrote: > > Opinions on this? I'd be interested in hearing the latest real world > experience for both and the direction most folks are going in. > DOCSIS cable networks use DHCP and have for a long time. If you have Ethernet based DSLAMs, they can usually do the a number of tricks (e.g. Option 82 insertion into the DHCP request) that would make a DHCP ADSL deployment no harder (or easier) than a DOCSIS cable network. It seems to me that the fundamental purpose of PPPoE is to be able to uniquely identify the customer for billing/provisioning purposes. Even though you only need to be able to do that at the start of their session, with PPPoE you pay an 8 byte per packet overhead, on _every_ packet sent and received by the customer. Other methods of distinguishing the customer, e.g. Option 82, static DHCP mapped to a customer MAC address, or possibly 802.1x if it were available, have much, much lower overhead. I think PPPoE really only exists to make ADSL look like high speed dial-up, so that ISPs dial up backend systems didn't need to be changed when ADSL was introduced. That was a valid concern in the past, but with existing solutions or models such as the DOCSIS Cable methods, and Ethernet based DSLAMS, I'd suggest avoiding PPPoE if you can. > I can't speak to which would be better on copper specifically, but in > > > general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff > will be similar (you'll need a way to authenticate users, turn them off and > on, et cetera); the differences won't be all that big. Either you're storing > their MACs in a database, or their port assignments and VLAN tags, or their > usernames and passwords. > > With PPPoE, however, the end-user can't just plug in and go - they'll have > to configure their PC, or a DSL modem, or something. That means a phone call > to your tech support, most likely. In many cases, DHCP can lead to > plug-and-play simplicity, which means they don't have to call you, and you > don't have to answer their calls. Everyone wins. :) > > David Smith > MVN.net > > > -- > > > Walter Keen > Network Technician > Rainier Connect > (o) 360-832-4024 > (c) 253-302-0194 From randy at psg.com Wed Oct 28 18:40:46 2009 From: randy at psg.com (Randy Bush) Date: Thu, 29 Oct 2009 08:40:46 +0900 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE87065.9040204@nosignal.org> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4AE87065.9040204@nosignal.org> Message-ID: >> This would be a big mistake. Fate sharing between the device that >> advertises the presence of a router and the device that forwards packets >> makes RAs much more robust than DHCPv4. > No, what we want are better first hop redundancy protocols, and DHCP for > v6, so that everyone who has extracted any value from DHCP in their toolkit > can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is soooo wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy From nanog at daork.net Wed Oct 28 18:52:23 2009 From: nanog at daork.net (Nathan Ward) Date: Thu, 29 Oct 2009 12:52:23 +1300 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8C6D6.4070309@rainierconnect.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> <4AE8C6D6.4070309@rainierconnect.net> Message-ID: Apologies if this message is brief, it is sent from my cellphone. On 29/10/2009, at 11:33, Walter Keen wrote: > Most aDSL modems if set to PPPoE (I think Actiontec's come this > way by > default) will send the mac as the pppoe un/pw. > David E. Smith wrote: > > Opinions on this? I'd be interested in hearing the latest real world > experience for both and the direction most folks are going in. > > I can't speak to which would be better on copper specifically, but in > > > general I'd favor DHCP over PPPoE. Either way, most of the back-end > stuff > will be similar (you'll need a way to authenticate users, turn them > off and > on, et cetera); the differences won't be all that big. Either you're > storing > their MACs in a database, or their port assignments and VLAN tags, > or their > usernames and passwords. > > With PPPoE, however, the end-user can't just plug in and go - > they'll have > to configure their PC, or a DSL modem, or something. That means a > phone call > to your tech support, most likely. In many cases, DHCP can lead to > plug-and-play simplicity, which means they don't have to call you, > and you > don't have to answer their calls. Everyone wins. :) > > David Smith > MVN.net > > > -- > > > Walter Keen > Network Technician > Rainier Connect > (o) 360-832-4024 > (c) 253-302-0194 > > !DSPAM:22,4ae8c6fe233691194411224! > > From ser at tch.org Wed Oct 28 18:54:50 2009 From: ser at tch.org (Steve Rubin) Date: Wed, 28 Oct 2009 16:54:50 -0700 Subject: ALTDB Problems In-Reply-To: <8c308e8b0910281553le4d86efu282df7a6a9d9ba95@mail.gmail.com> References: <9CCF0873-453C-4594-856F-367F90E8C97B@tch.org> <8c308e8b0910281553le4d86efu282df7a6a9d9ba95@mail.gmail.com> Message-ID: <6100F09F-0091-4E96-B29F-4FC5579726A8@tch.org> On Oct 28, 2009, at 3:53 PM, christian koch wrote: > On Tue, Oct 27, 2009 at 11:21 AM, Steve Rubin wrote: > > ALTDB is free and you get what you pay for. > > However. Donations to http://www.nanog.org/scholarships/abha.php > would probably get requests done a lot faster. > > > -- > Steve Rubin / AE6CH / http://www.altdb.net/ > Email: ser at tch.org / N6441C / http://www.tch.org/~ser/ > > > so, each time someone wants to update they need to donate to make > sure it gets processed in a timely matter? > > or do you track who donates and give priority to their updates? > > dont get me wrong - its a great cause, and people should donate if > they can > > if the project is short of volunteers - i'm sure there are people in > the community who would not mind helping out > > > -ck > No, every update does not require a donation. In fact, very little of what goes on on the database requires my intervention at all. Only new maintainers and a few other bits of administrivia require that. Right now I am very busy and do not have time to deal with things at the speed required by some people. As I have always said, "if you require immediate support I recommend the very fine RADB service run by Merit." -- Steve Rubin / AE6CH / http://www.altdb.net/ Email: ser at tch.org / N6441C / http://www.tch.org/~ser/ From mmc at internode.com.au Wed Oct 28 19:09:28 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 29 Oct 2009 10:39:28 +1030 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4AE87065.9040204@nosignal.org> Message-ID: <4AE8DD38.3030902@internode.com.au> Amen to that Randy. MMC Randy Bush wrote: >>> This would be a big mistake. Fate sharing between the device that >>> advertises the presence of a router and the device that forwards packets >>> makes RAs much more robust than DHCPv4. >>> >> No, what we want are better first hop redundancy protocols, and DHCP for >> v6, so that everyone who has extracted any value from DHCP in their toolkit >> can continue to do so, and roll out v6 ! >> > > no. what we need is more religious v6 fanatics to make use of v6 hard > to roll out on existing networks. after all, v6 is soooo wonderful we > should be happy to double our opex for the privilege of using such a > fantastic protocol. > > v6 fanaticism has done vastly more damage to v6 deployment than the v6 > haters. arrogance kills. > > randy > > From ops.lists at gmail.com Wed Oct 28 19:26:01 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 29 Oct 2009 05:56:01 +0530 Subject: dealing with bogon spam ? In-Reply-To: <4AE893EF.4080906@i6ix.com> References: <4AE788DD.3050605@craigslist.org> <4AE80553.4060602@klaver.it> <4AE8918F.5010805@justinshore.com> <4AE893EF.4080906@i6ix.com> Message-ID: You are using it the wrong way .. most of the drop list is directly spammer controlled space used as, for example, C&C for botnets. You'd see tons of abuse and little or no smtp traffic from a lot of those hosts. On Thu, Oct 29, 2009 at 12:26 AM, Jason Bertoch wrote: > Justin Shore wrote: >> As a brief off-shoot of the original topic, has anyone scripted the use of >> Spamhaus's DROP list in a RTBH, ACLs, null-routes, etc? ?I'm not asking if >> people think it's safe; that's up to the network wanting to deploy it. ?I'm > Downloading and parsing is easy. ?I used to drop it into the config for a > small dns server, rbldnsd I believe, that understands CIDR and used it as a > local blacklist. ?It did very little to stop spam and I was never brave > enough to script an automatic update to BGP. From owen at delong.com Wed Oct 28 19:27:54 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Oct 2009 17:27:54 -0700 Subject: IPv6 Deployment for the LAN In-Reply-To: <4AE8DD38.3030902@internode.com.au> References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4AE87065.9040204@nosignal.org> <4AE8DD38.3030902@internode.com.au> Message-ID: <2528C01C-4E1D-4968-B893-84A1F3914AF9@delong.com> This is unusual, but, I have to agree with Randy here. Owen On Oct 28, 2009, at 5:09 PM, Matthew Moyle-Croft wrote: > Amen to that Randy. > > MMC > > Randy Bush wrote: >>>> This would be a big mistake. Fate sharing between the device that >>>> advertises the presence of a router and the device that forwards >>>> packets >>>> makes RAs much more robust than DHCPv4. >>>> >>> No, what we want are better first hop redundancy protocols, and >>> DHCP for >>> v6, so that everyone who has extracted any value from DHCP in >>> their toolkit >>> can continue to do so, and roll out v6 ! >>> >> >> no. what we need is more religious v6 fanatics to make use of v6 >> hard >> to roll out on existing networks. after all, v6 is soooo wonderful >> we >> should be happy to double our opex for the privilege of using such a >> fantastic protocol. >> >> v6 fanaticism has done vastly more damage to v6 deployment than the >> v6 >> haters. arrogance kills. >> >> randy >> >> From truman at suspicious.org Wed Oct 28 23:52:05 2009 From: truman at suspicious.org (Truman Boyes) Date: Thu, 29 Oct 2009 15:52:05 +1100 Subject: Redundant Data Center Architectures In-Reply-To: <98F9072C6B4A354486105E1679432E130C34AC909D@NOVAMAIL.novadatacom.local> References: <98F9072C6B4A354486105E1679432E130C34AC8EF4@NOVAMAIL.novadatacom.local> <4AE8829B.6010903@villagevoicemedia.com> <5a318d410910281357i34876c8aq6fd6670f89303c3d@mail.gmail.com> <98F9072C6B4A354486105E1679432E130C34AC909D@NOVAMAIL.novadatacom.local> Message-ID: <72257B37-2CA1-477E-98BA-30F85C02A8BF@suspicious.org> On 29/10/2009, at 8:39 AM, Stefan Fouant wrote: >> -----Original Message----- >> From: Darren Bolding [mailto:darren at bolding.org] >> Sent: Wednesday, October 28, 2009 4:57 PM >> To: Roland Dobbins >> Cc: NANOG list >> Subject: Re: Redundant Data Center Architectures >> >> Also, commercial solutions from F5 (their GTM product and their old >> 3- >> DNS >> product). >> >> Using CDN's is also a way of handling this, but you need to be >> prepared >> for >> all your traffic to come from their source-ip's or do creative things >> with >> x-forwarded-for etc. >> >> Making an active/active datacenter design work (or preferably one >> with >> enough sites such that more than one can be down without seriously >> impacted >> service) is a serious challenge. Lots of people will tell you (and >> sell you >> solutions for) parts of the puzzle. My experience has been that the >> best >> case is when the architecture of the application/infrastructure have >> been >> designed with these challenges in mind from the get-go. I have seen >> that >> done on the network and server side, but never on the software side- >> that >> has always required significant effort when the time came. >> >> The "drop in" solutions for this (active/active database replication, >> middleware solutions, proxies) are always expensive in one way or >> another >> and frequently have major deployment challenges. >> >> The network side of this can frequently be the easiest to resolve, in >> my >> experience. If you are serving up content that does not require >> synchronized data on the backend, then that will make your life much >> easier, >> and GSLB, a CDN or similar may help a great deal. > > Thanks everyone who has responded so far. > > I should have clarified my intent a bit in the original email. I am > definitely interested in architectures which support synchronized > data between data center locations in as close to real-time as > possible. More specifically, I am interested in designs which > support zero down-time during failures, or as close to zero down- > time as possible. GSLB, Anycast, CDNs... those types of approaches > certainly have their place especially where the pull-model is > employed (DNS, Netflix, etc.). However, what types of solutions are > being used for synchronized data and even network I/O on back-end > systems? I've been looking at the VMware vSphere 4 Fault Tolerance > stuff to synchronize the data storage and network I/O across > distributed virtual machines, but still worried about the > consequences of doing this stuff across WAN links with high degrees > of latency, etc. From the thread I get the feeling that L2 > interconnects (VPLS, PWs) are generally considered a bad thing, I > gathered as much as I figured there would be lots of unintended > consequences with regards to designated router elections and other > weirdness. Besides connecting sites via L3 VPNs, what other > approaches are others using? Also, would appreciate any comments to > the synchronization items above. > > Thanks, > > -- > Stefan Fouant Layer 2 interconnects (whether they are VPLS / PWE3 / or other CCC- based models) are not bad in their own right, but I think it's important to realize that extending a (sub)network across large geographical regions because applications are not building intelligence about locality or presence is a move without intelligent engineering. I hear it all the time: just extend layer 2 between these two data centers so that we can have either (1) disaster recovery or (2) vmotion / heart beats / etc ... The truth is we can do things better and smarter than just extending bridging domains across disparate geographical locations. Real time storage should ideally be local .. but there is no reason why it can't be "available" over the cloud to other networks. The key is to have a single namespace for all storage, to not be tied to a particular storage technology, but to simply be able to present the storage/disk/ mount point to virtual machines. Extending layer 2 for iSCSI / SAN / and even FCoE is feasible. But, lets think about the technology in detail .. FCoE uses pause frames, and when there is significant geographical delay between sites, then FCoE is not the right technology. It works great locally .. and this should be just one technology to deliver storage locally in DCs. Internally I would explore DNS (GSLB / anycast / etc) .. and even ideas like mobile IPv4 / IPv6 mobility before I started extending layer 2 domains across the world. Kind regards, Truman From swmike at swm.pp.se Thu Oct 29 03:23:42 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 29 Oct 2009 09:23:42 +0100 (CET) Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8B5A4.4040404@socket.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: On Wed, 28 Oct 2009, JD wrote: I think the important thing is to have a separate L2 isolation per customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX will both solve this problem, but deploying multicast TV offering might be harder in this deployment model. There is really no devices out there to securely do IPv6 to the end user natively when you have a shared L2 domain (in v4 this implies the L2 device will do DHCP snooping and do filtering based on that). I don't really like tunneling, so I'd advocate the q-in-q model with separate vlan per customer (or having the L3 routing very close to the customer so you don't need to do q-in-q but still can do separate vlan per customer). -- Mikael Abrahamsson email: swmike at swm.pp.se From michiel at klaver.it Thu Oct 29 03:24:59 2009 From: michiel at klaver.it (Michiel Klaver) Date: Thu, 29 Oct 2009 09:24:59 +0100 Subject: dealing with bogon spam ? In-Reply-To: <4AE8918F.5010805@justinshore.com> References: <4AE788DD.3050605@craigslist.org> <4AE80553.4060602@klaver.it> <4AE8918F.5010805@justinshore.com> Message-ID: <4AE9515B.3060100@klaver.it> Justin Shore wrote: > Michiel Klaver wrote: >> I would suggest to report that netblock to SpamHaus to have it >> included at their DROP list, and also use that DROP list as extra >> filter in addition to your bogon filter setup at your border routers. >> >> The SpamHaus DROP (Don't Route Or Peer) list was specially designed >> for this kind of abuse of stolen 'hijacked' netblocks and netblocks >> controlled entirely by professional spammers. > > As a brief off-shoot of the original topic, has anyone scripted the use > of Spamhaus's DROP list in a RTBH, ACLs, null-routes, etc? I'm not > asking if people think it's safe; that's up to the network wanting to > deploy it. I'm wondering if anyone has any scripts for pulling down the > DROP list, parsing it into whatever you need (static routes on a RTBH > trigger router or ACLs on a border router and then deployed the config > change(s). I don't want to reinvent the wheel is someone else has > already done this. > > Thanks > Justin > SpamHaus already provides a link to a nice script for Cisco gear at their FAQ page: http://www.spamhaus.org/faq/answers.lasso?section=DROP%20FAQ And this shell command shoud give you a Juniper style prefix-list to include at your filter terms: wget -q -O - http://www.spamhaus.org/drop/drop.lasso | sed -e "s/;.*//" -e '/^[0-9]/ !d' -e "s/^/set policy-options prefix-list drop-lasso /" Hope it's helpfull! With kind regards, Michiel Klaver IT Professional From sean at donelan.com Thu Oct 29 04:07:12 2009 From: sean at donelan.com (Sean Donelan) Date: Thu, 29 Oct 2009 05:07:12 -0400 (EDT) Subject: PPPoE vs. Bridged ADSL In-Reply-To: <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> Message-ID: <200910290335310.32BF5B92.8688@clifden.donelan.com> On Wed, 28 Oct 2009, David E. Smith wrote: > With PPPoE, however, the end-user can't just plug in and go - they'll have > to configure their PC, or a DSL modem, or something. That means a phone call > to your tech support, most likely. In many cases, DHCP can lead to > plug-and-play simplicity, which means they don't have to call you, and you > don't have to answer their calls. Everyone wins. :) One of the reasons for UUNET's PPPOE design was to reduce phone calls and configuration hassles. But in a different way. In the "old" days, people thought there would be separation between the ISP and the wholesale network. The idea that the provider could control/manage the CPE, like a cable set-top box, was probably more radical at the time than a dumb modem and PPPOE client on the PC. PPPOE can allow changing ISPs just by changing the username at domain, without needing to call wholesale provider's tech support and reconfiguring the circuit. You could even have multiple PC's sharing the same circuit, each connecting to different ISPs at the same time. Or use PPPOE to "call" a business' DSLAM pool for work access, and then call AOL's DSLAM pool for personal use. The concept of multiple "dialers" was well supported on most operating systems, and more familar to the public at the time than trying to set hostnames or read MAC addresses in DHCP configurations. In those days, VPN/IPSEC tunnel support wasn't very common. Businesses still had dial-up modem pools, X.25 PADs, and private PPP/PPPOE/PPPOA/PPPOx connections. Compared to the overhead for other point-to-point and tunneling protocols at the time, PPPOE's overhead didn't look that bad. And since it was based on PPP, PPPOE made route addressing (and other routing stuff) easy. Addressing a single host is the simple case of the more general router PPP information. As Milo used to say, with enough thrust you could get DHCP to do many of those same things too. There were a lot of experiments, and not all of them worked well. As they say, the world changed. Ethernet won, vertically integrated ISPs won, VPN won, and yes DHCP (with lots of options) won too. We can have a betamax/vhs-style argument of technical superiority; but the market made a choice. From micheal at spmedicalgroup.com Thu Oct 29 05:06:35 2009 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Thu, 29 Oct 2009 05:06:35 -0500 Subject: Cox.net issues with their DNSBL Message-ID: <1A07F68D929149F0BBE934F49E615E0A@dredster> I'm not sure if this is the proper place to put this so I'll make this short. Cox.net is showing errors when I'm sending mail indicating that we're blocked by Invaluement, Cox error IPBL100. I've checked and my mx isn't listed. Attempts to contact the postmaster at cox.net address result in an autoresponder and then a bounce as that address is over quota. Is anyone else seeing this problem? Please feel free to contact me off list. -- Micheal Patterson Senior Communications Systems Engineer Southern Plains Medical Group 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message From lcaron at unix-scripts.info Thu Oct 29 06:09:50 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Thu, 29 Oct 2009 12:09:50 +0100 Subject: Unable to reach security.debian.org through an HurricaneElectric IPv6 pipe Message-ID: <20091029120734.yaxeeghu@trusted.unix-scripts.info> Hi, I'm currently unable to reach security.debian.org (2001:8d8:2:1:6564:a62:0:2) through IPv6. donald:~# traceroute -M tcpconn -p 80 wieck.debian.org -n -6 traceroute to wieck.debian.org (2001:8d8:2:1:6564:a62:0:2), 30 hops max, 80 byte packets 1 2001:7a8:820:1::1 0.170 ms 0.151 ms 0.126 ms 2 2001:7a8:820::1 0.317 ms 0.274 ms 0.515 ms 3 2001:7a8:1:9ff2::1 1.753 ms 1.745 ms 1.724 ms 4 2001:7a8:0:ff22::1 2.384 ms 2.374 ms 2.355 ms 5 2001:7a8:1:91::1 48.524 ms 48.530 ms 48.495 ms 6 2001:7a8:0:ffe1::fffe 10.203 ms 10.345 ms 10.270 ms 7 2001:7f8:4::2170:1 10.457 ms 10.390 ms 10.572 ms 8 2001:8d8:0:2::6 20.535 ms 19.820 ms 20.003 ms 9 2001:8d8:0:2::a 19.953 ms 20.517 ms 20.458 ms 10 2001:8d8:0:2::12 22.901 ms 2001:8d8:0:2::2a 22.333 ms 22.707 ms 11 2001:8d8:0:4::11 23.908 ms 2001:8d8:0:4::10 23.388 ms 2001:8d8:0:5::11 23.338 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * donald:~# traceroute -M tcpconn -p 25 wieck.debian.org -n -6 traceroute to wieck.debian.org (2001:8d8:2:1:6564:a62:0:2), 30 hops max, 80 byte packets 1 2001:7a8:820:1::1 0.185 ms 0.147 ms 0.128 ms 2 2001:7a8:820::1 0.435 ms 0.417 ms 0.396 ms 3 2001:7a8:1:9ff2::1 1.633 ms 1.860 ms 1.849 ms 4 2001:7a8:0:ff22::1 2.317 ms 2.305 ms 2.287 ms 5 2001:7a8:1:91::1 108.936 ms 108.943 ms 108.926 ms 6 2001:7a8:0:ffe1::fffe 10.407 ms 10.354 ms 10.305 ms 7 2001:7f8:4::2170:1 14.970 ms 15.158 ms 15.114 ms 8 2001:8d8:0:2::6 20.555 ms 20.161 ms 19.901 ms 9 2001:8d8:0:2::a 19.862 ms 19.425 ms 20.330 ms 10 2001:8d8:0:2::2a 22.282 ms 2001:8d8:0:2::12 23.129 ms 2001:8d8:0:2::2a 22.314 ms 11 2001:8d8:0:4::10 23.035 ms 2001:8d8:0:5::10 22.910 ms 2001:8d8:0:4::10 23.190 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -- lcaron at unix-scripts.info From wmaton at ryouko.imsb.nrc.ca Thu Oct 29 06:20:13 2009 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Thu, 29 Oct 2009 07:20:13 -0400 (EDT) Subject: Unable to reach security.debian.org through an HurricaneElectric IPv6 pipe In-Reply-To: <20091029120734.yaxeeghu@trusted.unix-scripts.info> References: <20091029120734.yaxeeghu@trusted.unix-scripts.info> Message-ID: On Thu, 29 Oct 2009, Laurent CARON wrote: > I'm currently unable to reach security.debian.org > (2001:8d8:2:1:6564:a62:0:2) through IPv6. Judging from the traceroute, it seems that Hurricane Electric and OneAndOne are peering, but perhaps there's a problem between Nerim and one of the other two? My traceroutes reach wieck, but the Nerim sTLA (2001:7a8::/32) isn't in my routing tables. Have you contacted Nerim NOC? wfms From lcaron at unix-scripts.info Thu Oct 29 06:40:59 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Thu, 29 Oct 2009 12:40:59 +0100 Subject: Unable to reach security.debian.org through an HurricaneElectric IPv6 pipe In-Reply-To: References: <20091029120734.yaxeeghu@trusted.unix-scripts.info> Message-ID: <4AE97F4B.1090001@unix-scripts.info> On 29/10/2009 12:20, William F. Maton Sotomayor wrote: > On Thu, 29 Oct 2009, Laurent CARON wrote: > >> I'm currently unable to reach security.debian.org >> (2001:8d8:2:1:6564:a62:0:2) through IPv6. > > Judging from the traceroute, it seems that Hurricane Electric and > OneAndOne are peering, but perhaps there's a problem between Nerim and > one of the other two? My traceroutes reach wieck, but the Nerim sTLA > (2001:7a8::/32) isn't in my routing tables. > > Have you contacted Nerim NOC? Thanks for your input. I'm gonna check with HE as I already checked with Nerim NOC. Thanks From fw at deneb.enyo.de Thu Oct 29 06:52:07 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 29 Oct 2009 12:52:07 +0100 Subject: Unable to reach security.debian.org through an HurricaneElectric IPv6 pipe In-Reply-To: <20091029120734.yaxeeghu@trusted.unix-scripts.info> (Laurent CARON's message of "Thu, 29 Oct 2009 12:09:50 +0100") References: <20091029120734.yaxeeghu@trusted.unix-scripts.info> Message-ID: <87my3aa048.fsf@mid.deneb.enyo.de> * Laurent CARON: > I'm currently unable to reach security.debian.org > (2001:8d8:2:1:6564:a62:0:2) through IPv6. > > donald:~# traceroute -M tcpconn -p 80 wieck.debian.org -n -6 > traceroute to wieck.debian.org (2001:8d8:2:1:6564:a62:0:2), 30 hops max, 80 byte packets It helps if you mention your own IP address. Using 2001:7a8:820:1::1 instead, I get this in the reverse direction (from wieck): traceroute to 2001:7a8:820:1::1 (2001:7a8:820:1::1), 30 hops max, 40 byte packets 1 vl-121.gw-dists-a.bs.ka.oneandone.net (2001:8d8:2:1::1) 1.530 ms 1.614 ms 1.709 ms 2 te-1-2.bb-c.bs.kae.de.oneandone.net (2001:8d8:0:5::1) 1.116 ms 1.169 ms 1.104 ms 3 te-4-2.bb-c.act.fra.de.oneandone.net (2001:8d8:0:2::11) 3.479 ms 3.540 ms 3.591 ms 4 te-1-1.bb-c.nkf.ams.nl.oneandone.net (2001:8d8:0:2::9) 10.139 ms 10.200 ms 10.247 ms 5 te-1-2.bb-c.the.lon.gb.oneandone.net (2001:8d8:0:2::5) 17.257 ms 17.321 ms 17.377 ms 6 linx.he.net (2001:7f8:4::1b1b:1) 17.281 ms 16.399 ms 16.456 ms 7 gige-g0-1.tserv17.lon1.ipv6.he.net (2001:470:0:a3::2) 16.546 ms 16.562 ms 16.512 ms 8 * * * [and nothing more] A traceroute from 2001:14b0:200:6::4 looks similar, despite taking a different entry point into HE: traceroute to 2001:7a8:820:1::1 (2001:7a8:820:1::1) from 2001:14b0:200:6::4, 30 hops max, 24 byte packets 1 2001:14b0:200:6::3 (2001:14b0:200:6::3) 27.324 ms 29.593 ms 26.593 ms 2 2a01:1e8:2:3::1 (2a01:1e8:2:3::1) 26.827 ms 26.772 ms * 3 2a01:1e8:2:4::1 (2a01:1e8:2:4::1) 30.685 ms 30.684 ms 30.767 ms 4 de-cix.he.net (2001:7f8::1b1b:0:1) 31.821 ms 35.31 ms 33.465 ms 5 gige-g0-1.tserv18.fra1.ipv6.he.net (2001:470:0:a5::2) 33.738 ms 33.368 ms 30.792 ms 6 * * * So this seems to be something beyound our (that is, Debian's) control, assuming that 2001:7a8:820:1::1 is as good as the IP address you've actually been assigned. From lcaron at unix-scripts.info Thu Oct 29 06:55:35 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Thu, 29 Oct 2009 12:55:35 +0100 Subject: Unable to reach security.debian.org through an HurricaneElectric IPv6 pipe In-Reply-To: <87my3aa048.fsf@mid.deneb.enyo.de> References: <20091029120734.yaxeeghu@trusted.unix-scripts.info> <87my3aa048.fsf@mid.deneb.enyo.de> Message-ID: <20091029125353.quaiyaph@trusted.unix-scripts.info> On Thu, Oct 29, 2009 at 12:52:07PM +0100, Florian Weimer wrote: > It helps if you mention your own IP address. Using 2001:7a8:820:1::1 > instead, I get this in the reverse direction (from wieck): My desktop's IP: 2001:7a8:820:1::31 > traceroute to 2001:7a8:820:1::1 (2001:7a8:820:1::1), 30 hops max, 40 byte packets > 1 vl-121.gw-dists-a.bs.ka.oneandone.net (2001:8d8:2:1::1) 1.530 ms 1.614 ms 1.709 ms > 2 te-1-2.bb-c.bs.kae.de.oneandone.net (2001:8d8:0:5::1) 1.116 ms 1.169 ms 1.104 ms > 3 te-4-2.bb-c.act.fra.de.oneandone.net (2001:8d8:0:2::11) 3.479 ms 3.540 ms 3.591 ms > 4 te-1-1.bb-c.nkf.ams.nl.oneandone.net (2001:8d8:0:2::9) 10.139 ms 10.200 ms 10.247 ms > 5 te-1-2.bb-c.the.lon.gb.oneandone.net (2001:8d8:0:2::5) 17.257 ms 17.321 ms 17.377 ms > 6 linx.he.net (2001:7f8:4::1b1b:1) 17.281 ms 16.399 ms 16.456 ms > 7 gige-g0-1.tserv17.lon1.ipv6.he.net (2001:470:0:a3::2) 16.546 ms 16.562 ms 16.512 ms > 8 * * * > [and nothing more] > > A traceroute from 2001:14b0:200:6::4 looks similar, despite taking a > different entry point into HE: > > traceroute to 2001:7a8:820:1::1 (2001:7a8:820:1::1) from 2001:14b0:200:6::4, 30 hops max, 24 byte packets > 1 2001:14b0:200:6::3 (2001:14b0:200:6::3) 27.324 ms 29.593 ms 26.593 ms > 2 2a01:1e8:2:3::1 (2a01:1e8:2:3::1) 26.827 ms 26.772 ms * > 3 2a01:1e8:2:4::1 (2a01:1e8:2:4::1) 30.685 ms 30.684 ms 30.767 ms > 4 de-cix.he.net (2001:7f8::1b1b:0:1) 31.821 ms 35.31 ms 33.465 ms > 5 gige-g0-1.tserv18.fra1.ipv6.he.net (2001:470:0:a5::2) 33.738 ms 33.368 ms 30.792 ms > 6 * * * > > So this seems to be something beyound our (that is, Debian's) control, > assuming that 2001:7a8:820:1::1 is as good as the IP address you've > actually been assigned. This is the IP of one of my BGP routers. From fw at deneb.enyo.de Thu Oct 29 07:02:13 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 29 Oct 2009 13:02:13 +0100 Subject: Unable to reach security.debian.org through an HurricaneElectric IPv6 pipe In-Reply-To: <20091029125353.quaiyaph@trusted.unix-scripts.info> (Laurent CARON's message of "Thu, 29 Oct 2009 12:55:35 +0100") References: <20091029120734.yaxeeghu@trusted.unix-scripts.info> <87my3aa048.fsf@mid.deneb.enyo.de> <20091029125353.quaiyaph@trusted.unix-scripts.info> Message-ID: <87eiom9zne.fsf@mid.deneb.enyo.de> * Laurent CARON: > On Thu, Oct 29, 2009 at 12:52:07PM +0100, Florian Weimer wrote: >> It helps if you mention your own IP address. Using 2001:7a8:820:1::1 >> instead, I get this in the reverse direction (from wieck): > > My desktop's IP: 2001:7a8:820:1::31 I can ping it from both locations, and latency is actually pretty good. Apparently, it's already been fixed, or it was a temporary glitch. From jzp-sc at rsuc.gweep.net Thu Oct 29 07:09:37 2009 From: jzp-sc at rsuc.gweep.net (Joe Provo) Date: Thu, 29 Oct 2009 08:09:37 -0400 Subject: [NANOG-announce] Communications Committee (formerly Mailing List Committee) Nominations close today! Message-ID: <20091029120937.GB18020@gweep.net> The nominations for the NANOG Committee (formerly known as the Mailing List Committee) close today, October 29. As Steve said in his last note, the new direction from the recent amendments means this is a chance to break new ground for NANOG and help define the future path for this team. If you are interested or know someone who is, please send the nomination to . If you are being nominated, please be prepared to confirm your interest and provide some bio data and a statement of interest (like those up on http://www.nanog.org/governance/elections/2009elections/2009mlc_candidates.php) before the Steering Committee meets on 3 November. Cheers! Joe Provo -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From vince at cisco.com Thu Oct 29 08:11:27 2009 From: vince at cisco.com (Vince Mammoliti) Date: Thu, 29 Oct 2009 09:11:27 -0400 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <200910290335310.32BF5B92.8688@clifden.donelan.com> References: <1256756748.2228.9.camel@nld06907><137DADDB-F961-460F-B051-AB931CD36289@arbor.net><4AE8B5A4.4040404@socket.net><8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> <200910290335310.32BF5B92.8688@clifden.donelan.com> Message-ID: <000501ca5899$539eff50$d374740a@cisco.com> This current draft DHCP Authentication http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt Adds the username/password that PPP has to DHCP and I believe support IPv6. Vince -----Original Message----- From: Sean Donelan [mailto:sean at donelan.com] Sent: Thursday, October 29, 2009 5:07 AM To: nanog at nanog.org Subject: Re: PPPoE vs. Bridged ADSL On Wed, 28 Oct 2009, David E. Smith wrote: > With PPPoE, however, the end-user can't just plug in and go - they'll > have to configure their PC, or a DSL modem, or something. That means a > phone call to your tech support, most likely. In many cases, DHCP can > lead to plug-and-play simplicity, which means they don't have to call > you, and you don't have to answer their calls. Everyone wins. :) One of the reasons for UUNET's PPPOE design was to reduce phone calls and configuration hassles. But in a different way. In the "old" days, people thought there would be separation between the ISP and the wholesale network. The idea that the provider could control/manage the CPE, like a cable set-top box, was probably more radical at the time than a dumb modem and PPPOE client on the PC. PPPOE can allow changing ISPs just by changing the username at domain, without needing to call wholesale provider's tech support and reconfiguring the circuit. You could even have multiple PC's sharing the same circuit, each connecting to different ISPs at the same time. Or use PPPOE to "call" a business' DSLAM pool for work access, and then call AOL's DSLAM pool for personal use. The concept of multiple "dialers" was well supported on most operating systems, and more familar to the public at the time than trying to set hostnames or read MAC addresses in DHCP configurations. In those days, VPN/IPSEC tunnel support wasn't very common. Businesses still had dial-up modem pools, X.25 PADs, and private PPP/PPPOE/PPPOA/PPPOx connections. Compared to the overhead for other point-to-point and tunneling protocols at the time, PPPOE's overhead didn't look that bad. And since it was based on PPP, PPPOE made route addressing (and other routing stuff) easy. Addressing a single host is the simple case of the more general router PPP information. As Milo used to say, with enough thrust you could get DHCP to do many of those same things too. There were a lot of experiments, and not all of them worked well. As they say, the world changed. Ethernet won, vertically integrated ISPs won, VPN won, and yes DHCP (with lots of options) won too. We can have a betamax/vhs-style argument of technical superiority; but the market made a choice. From dennis-lists at thenose.net Thu Oct 29 08:53:16 2009 From: dennis-lists at thenose.net (Dennis Dayman) Date: Thu, 29 Oct 2009 09:53:16 -0400 Subject: Cox.net issues with their DNSBL In-Reply-To: <1A07F68D929149F0BBE934F49E615E0A@dredster> References: <1A07F68D929149F0BBE934F49E615E0A@dredster> Message-ID: <7C5CFE65-740F-4EAF-9203-3E3146487191@thenose.net> not sure about seeing the same problem, but I am at MAAWG and their postmaster/abuse team is here. need an intro? -Dennis On Oct 29, 2009, at 6:06 AM, Micheal Patterson wrote: > I'm not sure if this is the proper place to put this so I'll make this > short. Cox.net is showing errors when I'm sending mail indicating > that we're > blocked by Invaluement, Cox error IPBL100. I've checked and my mx > isn't > listed. Attempts to contact the postmaster at cox.net address result > in an > autoresponder and then a bounce as that address is over quota. Is > anyone > else seeing this problem? > > Please feel free to contact me off list. > > -- > > Micheal Patterson > Senior Communications Systems Engineer > Southern Plains Medical Group > 405-917-0600 > > Confidentiality Notice: This e-mail message, including any > attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all > copies of the original message > > > > From rjm at wessexnetworks.com Thu Oct 29 09:38:19 2009 From: rjm at wessexnetworks.com (Richard Maynard / Wessex Networks) Date: Thu, 29 Oct 2009 14:38:19 +0000 Subject: RBS Worldpay Message-ID: Hi NANOG, Long time lurker here - this is my first post. Is there anyone here from RBS Worldpay? I could do with a hand troubleshooting an HTTP POST timeout reported from their from their end causing trouble on a customer server during the payment stages. I can't figure out if this is a network or server issue. Regards, Richard Maynard Wessex Networks Linchmere Place Ifield Crawley West Sussex RH11 0EX www.wessexnetworks.com rjm at wessexnetworks.com T: 01293 542080 F: 01293 553849 From jbates at brightok.net Thu Oct 29 10:02:35 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 29 Oct 2009 10:02:35 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: <4AE9AE8B.3000303@brightok.net> Mikael Abrahamsson wrote: > I think the important thing is to have a separate L2 isolation per > customer so you can more easily deploy IPv6 in the future. q-in-q or > PPPoX will both solve this problem, but deploying multicast TV offering > might be harder in this deployment model. In general, it shouldn't be. Local multicast TV offerings should be transmitted out of band from the standard internet connection, either different vlan or outside of the PPPoE. The nature of it usually indicates a specialized CPE maintained by the provider to support the necessary QOS, and division of Internet and Video traffic. For public multicast, splitting in the local pop just doesn't matter much. > There is really no devices out there to securely do IPv6 to the end user > natively when you have a shared L2 domain (in v4 this implies the L2 > device will do DHCP snooping and do filtering based on that). Several vendors claim to have v6 support for this in the next year. Currently, many of them completely break v6 due to the v4 security. Jack From jbates at brightok.net Thu Oct 29 10:10:44 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 29 Oct 2009 10:10:44 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <000501ca5899$539eff50$d374740a@cisco.com> References: <1256756748.2228.9.camel@nld06907><137DADDB-F961-460F-B051-AB931CD36289@arbor.net><4AE8B5A4.4040404@socket.net><8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> <200910290335310.32BF5B92.8688@clifden.donelan.com> <000501ca5899$539eff50$d374740a@cisco.com> Message-ID: <4AE9B074.4050707@brightok.net> Vince Mammoliti wrote: > This current draft > > DHCP Authentication > > http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt > > > Adds the username/password that PPP has to DHCP and I believe support IPv6. > Now if we could just tweak things perfectly so customers can hook up, log in to the ISP, and use tickets to access everything and it's dog, that would rock. :) A nice extension to allow corporate networks to interface with that system would be even cooler. *dreams of a secure authenticate once world* Jack From w.d.clayton at gmail.com Thu Oct 29 10:35:44 2009 From: w.d.clayton at gmail.com (William C) Date: Thu, 29 Oct 2009 10:35:44 -0500 Subject: Avantel Contact Information Message-ID: <69069bc20910290835o77cd906ata1fd4ffc37c42a99@mail.gmail.com> Does anyone have a technical or peering contact at Avantel who can address an apparent netblock hijacking issue? It seems that Avantel is advertising the 200.23.91.0/24 address space to their peers but they are unable to route to it for some reason. Level3's customers can though, and so can a whole bunch of the rest of the internet. Without posting all my traceroutes and route-views I'll just ask first as I'm sure there is a way to resolve this peacefully =] Any suggestions? From langseth at meridian-enviro.com Thu Oct 29 10:58:12 2009 From: langseth at meridian-enviro.com (Ryan Langseth) Date: Thu, 29 Oct 2009 10:58:12 -0500 Subject: Power Analysis/Management Tools In-Reply-To: <1AE86BEB-1993-4891-93CB-36948F3F3A15@daork.net> References: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> <680a83090910262105v70fcea63i82137800e98293b9@mail.gmail.com> <1AE86BEB-1993-4891-93CB-36948F3F3A15@daork.net> Message-ID: <4AE9BB94.7060508@meridian-enviro.com> Nathan Ward wrote: > I haven't used cacti in a while, but does it let you combine several RRD > files in to one graph? If so that's useful for power stuff, because > you're likely to want to graph an aggregate of several things across > different devices - for example a+b power of a server, or aggregate > power usage for one customer with multiple power feeds. Yes this is possible, without going into it too deeply since this is nanog, not cacti-users. You create the individual graphs, then create a new graph Graph management-> Add (with host and template set to none) then add data sources from other graphs/hosts. The nice thing about doing it this way is if you already have data being graphed, it will use the history to create the new graph. We use this with our bandwidth usage graph for our individual providers to show the aggregate bandwidth, and some other internal graphs that have history going back years. And at $oldjob I used it to show rf usage on our towers, quite handy with equipment that automatically changed frequency. From frnkblk at iname.com Thu Oct 29 15:12:46 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 29 Oct 2009 15:12:46 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE8B5A4.4040404@socket.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: Others commented on things I already had in mind only the username/password thing of PPPoE. We use the same username/pw on the modem as the customer users for their e-mail, so a password change necessitates a truck roll (I know, I know, TR-069). We started with PPPoE for our FTTH, because we were familiar with it, but we moved over to a "VLAN per service" model which ends up something like RBE in function. We can track customers based on the Option 82 info, so we're good to go in terms of tracking them. Frank -----Original Message----- From: JD [mailto:jdupuy-list at socket.net] Sent: Wednesday, October 28, 2009 4:21 PM To: NANOG list Subject: PPPoE vs. Bridged ADSL There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? :) ). There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things. Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers. Thanks, John From pstewart at nexicomgroup.net Thu Oct 29 15:52:06 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 29 Oct 2009 16:52:06 -0400 Subject: Tucows vs Postini Message-ID: Hi folks... Anyone have much experience with outsourcing antispam/antivirus to Tucows? We use Postini today and are overall pleased. The Tucows pricing seems to be MUCH lower so curious on any feedback... Thanks, Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From michael at linuxmagic.com Thu Oct 29 17:38:22 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 29 Oct 2009 15:38:22 -0700 Subject: Tucows vs Postini In-Reply-To: References: Message-ID: <200910291538.22443.michael@linuxmagic.com> Depends on your operational needs and size. For some people, nowadays you can go to a hosted email solution for the price of filtering.. and besides, any form of 'filtering' appliance or service comes at a price compared to solutions built into your mail servers.. It would be helpful if you provided the following: Type of Email Server/Service you want to protect Number of Email Boxes. Any other custom wants/needs. I never want to slag on anyones' service, but even if I did, I am sure you will get votes both ways. Your decision might need to be based on other factors that you are not aware of at this time. Cost is an obvious concern, but if say you are an ISP, and end up with more support calls with one company or the other.. it might outweigh the monthly cost differences. You would get better results if people with the same size and environment commented.... -- Michael -- On October 29, 2009, Paul Stewart wrote: > Hi folks... > > > > Anyone have much experience with outsourcing antispam/antivirus to > Tucows? We use Postini today and are overall pleased. The Tucows > pricing seems to be MUCH lower so curious on any feedback... > > > > Thanks, > > > > Paul > > > > > > > > > --------------------------------------------------------------------------- > - > > "The information transmitted is intended only for the person or entity to > which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all attachments, > without copying, distributing or disclosing same. Thank you." > -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From jaimie at featuretel.com Thu Oct 29 17:44:37 2009 From: jaimie at featuretel.com (Jaimie Livingston) Date: Thu, 29 Oct 2009 18:44:37 -0400 Subject: EdgeWater EdgeMarc 4610W Message-ID: <882C3355DFF9D3468379DD1E8C115FC7398BFD8FD7@EVS-RED.coloflorida.com> Has anyone had any recent direct experience with the EdgeWater EdgeMarc 4610W multi-service appliance used as a CPE device? I was recently handed a sales sheet on this swiss-army knife appliance, but there doesn't seem to be much publically available review of the beastie at the moment. If it is as advertised, it would be a very handy device as a CPE option... Thanks, Jaimie L. From mailvortex at gmail.com Thu Oct 29 18:10:36 2009 From: mailvortex at gmail.com (Ben Scott) Date: Thu, 29 Oct 2009 19:10:36 -0400 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE9B074.4050707@brightok.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> <8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> <200910290335310.32BF5B92.8688@clifden.donelan.com> <000501ca5899$539eff50$d374740a@cisco.com> <4AE9B074.4050707@brightok.net> Message-ID: <59f980d60910291610jdfc8778v1259989c1b02c475@mail.gmail.com> On Thu, Oct 29, 2009 at 11:10 AM, Jack Bates wrote: > *dreams of a secure authenticate once world* It may be worth noting here that there are times were one wants barriers between automation to keep malfunction or malice from spreading too far without human involvement. Of course, most of the current barriers we have are accidental, random, and ill-defined, so there's clearly room for improvement either way. :) -- Ben From pstewart at nexicomgroup.net Thu Oct 29 18:15:53 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 29 Oct 2009 19:15:53 -0400 Subject: Tucows vs Postini In-Reply-To: <200910291538.22443.michael@linuxmagic.com> References: <200910291538.22443.michael@linuxmagic.com> Message-ID: Thank you .... I apologize if this is off-topic... a couple of folks have answered me offline and mentioned that it might be... Basically, we are interested in one particular domain name containing 35,000 email addresses as an ISP. Antispam/Antivirus and a quarantine option for 14 days minimum. Preferably an API of some type that can automate against our SQL backend. Open to ideas (on-list or offline by all means). I'm very happy to stay where we are, but our GM got a phone call today from a sales rep at Tucows and now price is of great interest.. Basically the Tucows price is a fraction of our Postini costs so it's getting attention and I'm just looking for input... Paul -----Original Message----- From: Michael Peddemors [mailto:michael at linuxmagic.com] Sent: October 29, 2009 6:38 PM To: nanog at nanog.org Subject: Re: Tucows vs Postini Depends on your operational needs and size. For some people, nowadays you can go to a hosted email solution for the price of filtering.. and besides, any form of 'filtering' appliance or service comes at a price compared to solutions built into your mail servers.. It would be helpful if you provided the following: Type of Email Server/Service you want to protect Number of Email Boxes. Any other custom wants/needs. I never want to slag on anyones' service, but even if I did, I am sure you will get votes both ways. Your decision might need to be based on other factors that you are not aware of at this time. Cost is an obvious concern, but if say you are an ISP, and end up with more support calls with one company or the other.. it might outweigh the monthly cost differences. You would get better results if people with the same size and environment commented.... -- Michael -- On October 29, 2009, Paul Stewart wrote: > Hi folks... > > > > Anyone have much experience with outsourcing antispam/antivirus to > Tucows? We use Postini today and are overall pleased. The Tucows > pricing seems to be MUCH lower so curious on any feedback... > > > > Thanks, > > > > Paul > > > > > > > > > ------------------------------------------------------------------------ --- > - > > "The information transmitted is intended only for the person or entity to > which it is addressed and contains confidential and/or privileged > material. If you received this in error, please contact the sender > immediately and then destroy this transmission, including all attachments, > without copying, distributing or disclosing same. Thank you." > -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ggm at apnic.net Thu Oct 29 19:02:46 2009 From: ggm at apnic.net (George Michaelson) Date: Fri, 30 Oct 2009 10:02:46 +1000 Subject: dealing with bogon spam ? In-Reply-To: <4AE810AE.6030302@spaghetti.zurich.ibm.com> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE810AE.6030302@spaghetti.zurich.ibm.com> Message-ID: > > //// Avoid broken/slow servers: > //// "afrinic" => > "ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest", > //// "apnic" => > "ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest", > //// "lacnic" => > "ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest", > ); > > > Yes, generally the latter three are broken, but as they are mirrored > to > RIPE anyway, you can just pull them off there. > Having checked with Jeroen, I would like to observe that in the case of APNIC this is almost certainly IPv6 and pMTU problems. As he observes elsewhere in the email, we all shadow each others data in the FTP trees so you can very probably choose one RIR, and use it as a fetch-point for all of this data. BTW The last time this cropped up in any public eye facing NANOG type people it was the rfc editor. It can happen to anyone. Geoff wrote it up at: http://www.potaroo.net/ispcol/2009-01/mtu6.html So, this is not APNIC having "broken" FTP, its the innate problem of IPv6 in the wild. If you fall back to V4, the fetch works just fine. If tomorrow you have problems fetching the stats from ARIN or RIPE, you might want to look at your path.. -George From zeusdadog at gmail.com Thu Oct 29 19:59:50 2009 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 29 Oct 2009 20:59:50 -0400 Subject: EdgeWater EdgeMarc 4610W In-Reply-To: <882C3355DFF9D3468379DD1E8C115FC7398BFD8FD7@EVS-RED.coloflorida.com> References: <882C3355DFF9D3468379DD1E8C115FC7398BFD8FD7@EVS-RED.coloflorida.com> Message-ID: <9418aca70910291759p63c547ar4065c22942239280@mail.gmail.com> I am scatter brained at the moment so I will kind of babble along some bullet points. We have been using Edgemarcs for a while and we love it for hosted VoIP situation. Their strength is VoIP. Being able to failover SIP servers and Internet access connection is great. You can configure it so you can still make internal calls when the SIP server is unavailable or your internet connection is down. I have not used the wireless model so I don't know much about that part. We had some problem with some VPN to Cisco when you have more than one subnet that needed to tunnel through. The annoying part is when you change anything on the device, it will say voice traffic may get interrupted. I have not gotten around to test what kind of affect it has on voice when you change simple configuration. But it kind of gets old when you get the message when you are changing the DHCP server setting and you know it has nothing to do with passing VoIP packets along. Their support is pretty good. This thing is basically a linux box with Asterisk and Swan rolled into one. Sometimes if you need to do things that can't be done from the GUI, you can get around it by using some basic Linux/Asterisk CLI/config files. But that can get ugly fast. If you have VoIP, it's great! If not, I usually stick with a Cisco ISR. On Thu, Oct 29, 2009 at 6:44 PM, Jaimie Livingston wrote: > Has anyone had any recent direct experience with the EdgeWater EdgeMarc 4610W multi-service appliance used as a CPE device? > I was recently handed a sales sheet on this swiss-army knife appliance, but there doesn't seem to be much publically available review of the beastie at the moment. If it is as advertised, it would be a very handy device as a CPE option... > > Thanks, > > Jaimie L. > From randy at psg.com Thu Oct 29 20:05:52 2009 From: randy at psg.com (Randy Bush) Date: Fri, 30 Oct 2009 10:05:52 +0900 Subject: Tucows vs Postini In-Reply-To: <200910291538.22443.michael@linuxmagic.com> References: <200910291538.22443.michael@linuxmagic.com> Message-ID: > nowadays you can go to a hosted email solution for the price of > filtering iff you do not care about the privacy of your communications. i am horrified at the folk using gmail for corporate communication. their mommies need to read the google eula and tos. randy From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Oct 29 20:16:00 2009 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 30 Oct 2009 11:46:00 +1030 Subject: IPv6 Deployment for the LAN In-Reply-To: References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <4AE87065.9040204@nosignal.org> Message-ID: <20091030114600.4f74a9a8@m9.nosense.org> On Thu, 29 Oct 2009 08:40:46 +0900 Randy Bush wrote: > >> This would be a big mistake. Fate sharing between the device that > >> advertises the presence of a router and the device that forwards > >> packets makes RAs much more robust than DHCPv4. > > No, what we want are better first hop redundancy protocols, and > > DHCP for v6, so that everyone who has extracted any value from DHCP > > in their toolkit can continue to do so, and roll out v6 ! > > no. what we need is more religious v6 fanatics to make use of v6 hard > to roll out on existing networks. after all, v6 is soooo wonderful we > should be happy to double our opex for the privilege of using such a > fantastic protocol. > > v6 fanaticism has done vastly more damage to v6 deployment than the v6 > haters. arrogance kills. > As does excessive pessimism. From scott at sberkman.net Thu Oct 29 22:51:37 2009 From: scott at sberkman.net (Scott Berkman) Date: Thu, 29 Oct 2009 23:51:37 -0400 Subject: EdgeWater EdgeMarc 4610W In-Reply-To: <882C3355DFF9D3468379DD1E8C115FC7398BFD8FD7@EVS-RED.coloflorida.com> References: <882C3355DFF9D3468379DD1E8C115FC7398BFD8FD7@EVS-RED.coloflorida.com> Message-ID: <004e01ca5914$48af5ab0$da0e1010$@net> Haven't had my hands on the 4610W yet, but I've been using (and have been a big fan of) Edgemarcs for some time. It does what it says and well, I love the support guys, and their price point is much better than most of the competitors. Some of my favorite features do come from the fact that they are Linux based, such as being able to run tcpdump for troubleshooting SIP signaling (or any network issue) in real time. They also have a really nice EMS that's quite worth it if you have enough of these deployed. It can alert on call quality issues based on MOS score, as well as standard up/down status. The only real "downside" is the licensing of concurrent calls. The licensing of the T1's is actually really nice so that you can get the box at a lower pricepoint, but grow it in service if you need more T1 capacity later on. If anyone has any more specific questions about using these in the real world I'd be happy to answer. -Scott -----Original Message----- From: Jaimie Livingston [mailto:jaimie at featuretel.com] Sent: Thursday, October 29, 2009 6:45 PM To: nanog at nanog.org Subject: EdgeWater EdgeMarc 4610W Has anyone had any recent direct experience with the EdgeWater EdgeMarc 4610W multi-service appliance used as a CPE device? I was recently handed a sales sheet on this swiss-army knife appliance, but there doesn't seem to be much publically available review of the beastie at the moment. If it is as advertised, it would be a very handy device as a CPE option... Thanks, Jaimie L. From johnl at iecc.com Thu Oct 29 22:57:01 2009 From: johnl at iecc.com (John Levine) Date: 30 Oct 2009 03:57:01 -0000 Subject: Tucows vs Postini In-Reply-To: Message-ID: <20091030035701.1633.qmail@simone.iecc.com> >Anyone have much experience with outsourcing antispam/antivirus to >Tucows? We use Postini today and are overall pleased. The Tucows >pricing seems to be MUCH lower so curious on any feedback... Tucows' mail system had some fairly bad operational problems last year (no mail lost, but offline for a while). They've fixed them and in recent months they've been quite solid. I have some customers' mail hosted there and they've been happy. I also happen to know several of their managers who are reasonable people and actually respond to problem reports. If you're thinking of using them, it's also worth thinking about letting them handle the entire mail setup. Along with POP and IMAP they have usable web mail and a web management portal so your customers can do the usual stuff, add and remove accounts, reset passwords, and also an xml/http interface if you want to provide your own management front end. R's, John From jul_bsd at yahoo.fr Fri Oct 30 00:21:20 2009 From: jul_bsd at yahoo.fr (jul) Date: Fri, 30 Oct 2009 06:21:20 +0100 Subject: more ISP regulation for UK ? Message-ID: <4AEA77D0.9090404@yahoo.fr> After Nederlands, things may also move in UK against eCrime + apComms backs ISP cleanup activity http://www.lightbluetouchpaper.org/2009/10/17/apcomms-backs-isp-cleanup-activity/ Extract: The All Party Parliamentary Communications Group (apComms) recently published their report into an inquiry entitled ?Can we keep our hands off the net?? They looked at a number of issues, from ?network neutrality? to how best to deal with child sexual abuse images. Read the report for the all the details; in this post I?m just going to draw attention to one of the most interesting, and timely, recommendations: 51. We recommend that UK ISPs, through Ofcom, ISPA or another appropriate organisation, immediately start the process of agreeing a voluntary code for detection of, and effective dealing with, malware infected machines in the UK. 52. If this voluntary approach fails to yield results in a timely manner, then we further recommend that Ofcom unilaterally create such a code, and impose it upon the UK ISP industry on a statutory basis. Best regards, Julien From frnkblk at iname.com Fri Oct 30 04:51:22 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Fri, 30 Oct 2009 04:51:22 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <4AE9AE8B.3000303@brightok.net> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> <4AE9AE8B.3000303@brightok.net> Message-ID: For telco-delivered IPTV, the multicast channel, bi-directional control channel, and video are transmitted on different VP/VC. For VDSL2, I'm guessing it would be a different VLAN. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, October 29, 2009 10:03 AM To: nanog at nanog.org Subject: Re: PPPoE vs. Bridged ADSL Mikael Abrahamsson wrote: > I think the important thing is to have a separate L2 isolation per > customer so you can more easily deploy IPv6 in the future. q-in-q or > PPPoX will both solve this problem, but deploying multicast TV offering > might be harder in this deployment model. In general, it shouldn't be. Local multicast TV offerings should be transmitted out of band from the standard internet connection, either different vlan or outside of the PPPoE. The nature of it usually indicates a specialized CPE maintained by the provider to support the necessary QOS, and division of Internet and Video traffic. For public multicast, splitting in the local pop just doesn't matter much. > There is really no devices out there to securely do IPv6 to the end user > natively when you have a shared L2 domain (in v4 this implies the L2 > device will do DHCP snooping and do filtering based on that). Several vendors claim to have v6 support for this in the next year. Currently, many of them completely break v6 due to the v4 security. Jack From marcoh at marcoh.net Fri Oct 30 05:23:01 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 30 Oct 2009 11:23:01 +0100 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: References: <4ae2a617.Ptq2RNlqGPlst0uM%ops.lists@gmail.com> <7543076B-1E20-4CDD-BD13-D871F5C3FF2D@marcoh.net> Message-ID: On 24 okt 2009, at 14:36, Suresh Ramasubramanian wrote: > On Sat, Oct 24, 2009 at 2:48 PM, Marco Hogewoning > wrote: >> On Oct 24, 2009, at 9:00 AM, Suresh Ramasubramanian wrote: > \>> http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-accused-of-aiding-cybercrime-2165 >> >> With more on that: >> http://www.ripe.net/news/rbn.html > > I am glad this ugly situation has been resolved - and I do wish the > resolution gets better coverage than this. It finally hit the press as well: http://www.pcworld.com/businesscenter/article/174651/uk_police_smooth_over_rift_with_internet_registry.html MarcoH From nsosoc at gmail.com Fri Oct 30 06:03:06 2009 From: nsosoc at gmail.com (nsosoc -G-) Date: Fri, 30 Oct 2009 12:03:06 +0100 Subject: incident registration Message-ID: <017c01ca5950$8f70f1c0$ae52d540$@com> Hi guys, What would you recommend as a state-of-the-art web-based incident registration/warning tool for an enterprise size (multiple diverse wans) net? Thx Jack Jack Ryan National Railway Org. nsosoc at gmail.com From ops.lists at gmail.com Fri Oct 30 07:08:41 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 30 Oct 2009 17:38:41 +0530 Subject: incident registration In-Reply-To: <017c01ca5950$8f70f1c0$ae52d540$@com> References: <017c01ca5950$8f70f1c0$ae52d540$@com> Message-ID: RT has a incident response variant - RTIR http://bestpractical.com/rtir/ On Fri, Oct 30, 2009 at 4:33 PM, nsosoc -G- wrote: > Hi guys, > > What would you recommend as a state-of-the-art web-based incident > registration/warning tool for an enterprise size (multiple diverse wans) > net? > > Thx > > Jack > > Jack Ryan > National Railway Org. > nsosoc at gmail.com -- Suresh Ramasubramanian (ops.lists at gmail.com) From sean at donelan.com Fri Oct 30 07:18:44 2009 From: sean at donelan.com (Sean Donelan) Date: Fri, 30 Oct 2009 08:18:44 -0400 (EDT) Subject: PPPoE vs. Bridged ADSL In-Reply-To: <000501ca5899$539eff50$d374740a@cisco.com> References: <1256756748.2228.9.camel@nld06907><137DADDB-F961-460F-B051-AB931CD36289@arbor.net><4AE8B5A4.4040404@socket.net><8b731a020910281510u4dff338auc398e6944dfb1765@mail.gmail.com> <200910290335310.32BF5B92.8688@clifden.donelan.com> <000501ca5899$539eff50$d374740a@cisco.com> Message-ID: <200910300809210.32BF5B92.12477@clifden.donelan.com> On Thu, 29 Oct 2009, Vince Mammoliti wrote: > This current draft > > DHCP Authentication > > http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt That's what makes protocol wars so much fun. With enough options, almost any protocol can do almost anything. As you know, I did my best to kill PPPOx at an ISP and in the IPTV architecture several vendors were selling at the time. I still think that sometimes DHCP is the answer, and other times PPPOx is the answer, but you can usually make either work if necessary. And even though I chose DHCP, the vendor needed to fix several things. I haven't kept track if all of them were really fixed. From drew.weaver at thenap.com Fri Oct 30 10:48:04 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 30 Oct 2009 11:48:04 -0400 Subject: Abuse desk software Message-ID: Howdy, Can anyone recommend a decent software package one can use to download e-mail sent to an abuse alias which then grabs IPs/hostnames out of the body of the email and makes nice actionable reports? Anything out there exist? thanks, -Drew From bjamlists at gmail.com Fri Oct 30 11:05:32 2009 From: bjamlists at gmail.com (Brandon James) Date: Fri, 30 Oct 2009 11:05:32 -0500 Subject: Abuse desk software In-Reply-To: References: Message-ID: <4AEB0ECC.3050801@gmail.com> Drew Weaver wrote: > Howdy, > > Can anyone recommend a decent software package one can use to download e-mail sent to an abuse alias which then grabs IPs/hostnames out of the body of the email and makes nice actionable reports? > > Anything out there exist? > > thanks, > -Drew > > > Abacus - Is by far the best thing out there IMHO. http://wordtothewise.com/products/abacus.html From bradley.freeman at csirt.ja.net Fri Oct 30 11:23:19 2009 From: bradley.freeman at csirt.ja.net (Bradley Freeman) Date: Fri, 30 Oct 2009 16:23:19 -0000 Subject: Abuse desk software In-Reply-To: References: Message-ID: <003901ca597d$4aeed2b0$e0cc7810$@freeman@csirt.ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You can do something with RTIR, it picks up IPs/Hostnames in emails sent into it and with a single click you can view more information about that IP including open/closed incidents, blocks, whois, etc. Cheers Bradley - -----Original Message----- From: Drew Weaver [mailto:drew.weaver at thenap.com] Sent: 30 October 2009 15:48 To: 'nanog at nanog.org' Subject: Abuse desk software Howdy, Can anyone recommend a decent software package one can use to download e-mail sent to an abuse alias which then grabs IPs/hostnames out of the body of the email and makes nice actionable reports? Anything out there exist? thanks, - -Drew -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.12.0 (Build 1035) Charset: us-ascii wj8DBQFK6xMcT7xmwrSDM90RAlDAAJ9QTviIE8hr2KWXQO39VV148RZiygCfb1MQ nXO0lAUl9I5vgKhQS1lpbBs= =+lgz -----END PGP SIGNATURE----- From leslie at craigslist.org Fri Oct 30 11:34:47 2009 From: leslie at craigslist.org (Leslie) Date: Fri, 30 Oct 2009 09:34:47 -0700 Subject: dealing with bogon spam ? In-Reply-To: <4AE85FC3.9050002@craigslist.org> References: <290EF89F13F04F4E924BB235A46D18F1043B40145F@MLBMXUS2.cs.myharris.net> <4AE7E858.4020109@craigslist.org> <4AE85FC3.9050002@craigslist.org> Message-ID: <4AEB15A7.5060602@craigslist.org> Just in case anyone's curious - The prefix still hasn't been updated in ARIN and I am still seeing tons of spam (grrr spammers and grr transit providers who don't filter advertisements of smaller customers) I made a script which looks at our log files for ips that are unknown, double checks them against live database, and then reports the number of hits to me - that way I can at least take manual action against offenders. On the good side, the only offender I currently see is 40430, but I am still trying to remain vigilent for future spammers Leslie Leslie wrote: > Just FYI the colo4jax guys got back to me and it is a stale ARIN db > entry - I guess they don't update it as quickly as I thought. So this > is now just a normal case of spam. > > Leslie > > Leslie wrote: >> Yes, unallocated (at least according to ARIN's whois db) but not >> unannounced - obviously our network can get to the space or else I >> wouldn't be having a spam problem with them! I'm actually seeing >> this /20 as advertised through Savvis from AS40430 >> >> It seems to me like the best solution might be a semi-hacky solution >> of asking arin (and other IRR's) if i can copy its DB and creating an >> internal peer which null routes unallocated blocks (updated nightly?) >> >> Has anyone seen an IRR's DB's not being updated for more than 30 days >> after allocations? I always assumed that they are quickly updated. >> >> Thanks again, >> Leslie >> >> Jon Lewis wrote: >>> Unallocated doesn't mean non-routed. All a spammer needs is a >>> willing/non-filtering provider doing BGP with them, and they can >>> announce any space they like, send out some spam, and then pull the >>> announcement. Next morning, when you see the spam and try to figure >>> out who to send complaints to, you're either going to complain to the >>> wrong people or find that whois is of no help. >>> >>> On Tue, 27 Oct 2009, Church, Charles wrote: >>> >>>> This is puzzling me. If it's from non-announced space, at some >>>> point some router should report no route to it. How is the TCP >>>> handshake performed to allow a sync to turn into spam? >>>> >>>> Chuck >>>> >>>> Chuck Church >>>> Network Planning Engineer, CCIE #8776 >>>> Harris Information Technology Services >>>> DOD Programs >>>> 1210 N. Parker Rd. | Greenville, SC 29609 >>>> Office: 864-335-9473 | Cell: 864-266-3978 >>>> -------------------------- >>>> Sent using BlackBerry >>>> >>>> From jbates at brightok.net Fri Oct 30 13:15:56 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 30 Oct 2009 13:15:56 -0500 Subject: Abuse desk software In-Reply-To: <4AEB0ECC.3050801@gmail.com> References: <4AEB0ECC.3050801@gmail.com> Message-ID: <4AEB2D5C.2050507@brightok.net> Brandon James wrote: > Abacus - Is by far the best thing out there IMHO. > > http://wordtothewise.com/products/abacus.html Seconded. There isn't a lot of software available that is strictly abuse oriented. Abuse tends to have specific criteria that differs from support and even generic incident response. Jack From cscora at apnic.net Fri Oct 30 13:26:00 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Oct 2009 04:26:00 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200910301826.n9UIQ0NW007877@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 Oct, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 301627 Prefixes after maximum aggregation: 141194 Deaggregation factor: 2.14 Unique aggregates announced to Internet: 149168 Total ASes present in the Internet Routing Table: 32545 Prefixes per ASN: 9.27 Origin-only ASes present in the Internet Routing Table: 28267 Origin ASes announcing only one prefix: 13775 Transit ASes present in the Internet Routing Table: 4278 Transit-only ASes present in the Internet Routing Table: 104 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 30 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 615 Unregistered ASNs in the Routing Table: 126 Number of 32-bit ASNs allocated by the RIRs: 308 Prefixes from 32-bit ASNs in the Routing Table: 249 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 188 Number of addresses announced to Internet: 2123904864 Equivalent to 126 /8s, 152 /16s and 55 /24s Percentage of available address space announced: 57.3 Percentage of allocated address space announced: 64.9 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 79.5 Total number of prefixes smaller than registry allocations: 145034 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72646 Total APNIC prefixes after maximum aggregation: 25150 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 69165 Unique aggregates announced from the APNIC address blocks: 30414 APNIC Region origin ASes present in the Internet Routing Table: 3836 APNIC Prefixes per ASN: 18.03 APNIC Region origin ASes announcing only one prefix: 1038 APNIC Region transit ASes present in the Internet Routing Table: 595 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 467982112 Equivalent to 27 /8s, 228 /16s and 215 /24s Percentage of available APNIC address space announced: 79.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 127251 Total ARIN prefixes after maximum aggregation: 67119 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 101807 Unique aggregates announced from the ARIN address blocks: 38735 ARIN Region origin ASes present in the Internet Routing Table: 13307 ARIN Prefixes per ASN: 7.65 ARIN Region origin ASes announcing only one prefix: 5143 ARIN Region transit ASes present in the Internet Routing Table: 1315 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 709214976 Equivalent to 42 /8s, 69 /16s and 195 /24s Percentage of available ARIN address space announced: 62.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 69252 Total RIPE prefixes after maximum aggregation: 40685 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 62623 Unique aggregates announced from the RIPE address blocks: 41975 RIPE Region origin ASes present in the Internet Routing Table: 13681 RIPE Prefixes per ASN: 4.58 RIPE Region origin ASes announcing only one prefix: 7116 RIPE Region transit ASes present in the Internet Routing Table: 2053 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 402977216 Equivalent to 24 /8s, 4 /16s and 241 /24s Percentage of available RIPE address space announced: 75.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 25963 Total LACNIC prefixes after maximum aggregation: 6374 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24280 Unique aggregates announced from the LACNIC address blocks: 13431 LACNIC Region origin ASes present in the Internet Routing Table: 1201 LACNIC Prefixes per ASN: 20.22 LACNIC Region origin ASes announcing only one prefix: 382 LACNIC Region transit ASes present in the Internet Routing Table: 199 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC addresses announced to Internet: 68065280 Equivalent to 4 /8s, 14 /16s and 152 /24s Percentage of available LACNIC address space announced: 67.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6039 Total AfriNIC prefixes after maximum aggregation: 1579 AfriNIC Deaggregation factor: 3.82 Prefixes being announced from the AfriNIC address blocks: 4404 Unique aggregates announced from the AfriNIC address blocks: 1607 AfriNIC Region origin ASes present in the Internet Routing Table: 329 AfriNIC Prefixes per ASN: 13.39 AfriNIC Region origin ASes announcing only one prefix: 96 AfriNIC Region transit ASes present in the Internet Routing Table: 67 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12883712 Equivalent to 0 /8s, 196 /16s and 151 /24s Percentage of available AfriNIC address space announced: 38.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1765 6991 454 Korea Telecom (KIX) 17488 1473 139 140 Hathway IP Over Cable Interne 4755 1270 293 147 TATA Communications formerly 9583 1107 98 469 Sify Limited 4134 1006 19185 393 CHINANET-BACKBONE 18101 974 204 32 Reliance Infocom Ltd Internet 7545 905 199 101 TPG Internet Pty Ltd 9829 849 661 20 BSNL National Internet Backbo 17974 814 252 104 PT TELEKOMUNIKASI INDONESIA 24560 792 291 168 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4166 3883 313 bellsouth.net, inc. 4323 3723 1036 396 Time Warner Telecom 1785 1778 715 140 PaeTec Communications, Inc. 7018 1571 5843 1047 AT&T WorldNet Services 20115 1487 1481 670 Charter Communications 6478 1316 270 438 AT&T Worldnet Services 2386 1302 637 942 AT&T Data Communications Serv 3356 1221 10964 437 Level 3 Communications, LLC 11492 1137 206 13 Cable One 22773 1106 2600 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 516 95 210 Evolva Telecom 3292 448 1908 393 TDC Tele Danmark 702 414 1822 333 UUNET - Commercial IP service 9198 387 138 12 Kazakhtelecom Data Network Ad 35805 372 40 5 United Telecom of Georgia 8866 362 110 23 Bulgarian Telecommunication C 3320 354 7068 302 Deutsche Telekom AG 3215 349 3144 111 France Telecom Transpac 3301 348 1412 305 TeliaNet Sweden 9121 317 1698 26 TTnet Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1490 2899 236 UniNet S.A. de C.V. 10620 1024 228 102 TVCABLE BOGOTA 28573 790 661 89 NET Servicos de Comunicao S.A 7303 660 349 97 Telecom Argentina Stet-France 22047 546 302 14 VTR PUNTO NET S.A. 11830 475 310 61 Instituto Costarricense de El 11172 445 99 70 Servicios Alestra S.A de C.V 14117 438 29 11 Telefonica del Sur S.A. 7738 429 858 29 Telecomunicacoes da Bahia S.A 6471 422 96 31 ENTEL CHILE S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 989 188 7 TEDATA 24863 938 98 72 LINKdotNET AS number 3741 274 857 234 The Internet Solution 2018 194 188 117 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 145 15 8 Ci Telecom Autonomous system 33776 124 7 11 Starcomms Nigeria Limited 5536 122 8 13 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 20858 109 34 6 EgyNet Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4166 3883 313 bellsouth.net, inc. 4323 3723 1036 396 Time Warner Telecom 1785 1778 715 140 PaeTec Communications, Inc. 4766 1765 6991 454 Korea Telecom (KIX) 7018 1571 5843 1047 AT&T WorldNet Services 8151 1490 2899 236 UniNet S.A. de C.V. 20115 1487 1481 670 Charter Communications 17488 1473 139 140 Hathway IP Over Cable Interne 6478 1316 270 438 AT&T Worldnet Services 2386 1302 637 942 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3723 3327 Time Warner Telecom 1785 1778 1638 PaeTec Communications, Inc. 17488 1473 1333 Hathway IP Over Cable Interne 4766 1765 1311 Korea Telecom (KIX) 8151 1490 1254 UniNet S.A. de C.V. 11492 1137 1124 Cable One 4755 1270 1123 TATA Communications formerly 18566 1062 1052 Covad Communications 22773 1106 1040 Cox Communications, Inc. 8452 989 982 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:63 /12:176 /13:356 /14:636 /15:1211 /16:10718 /17:4910 /18:8486 /19:17531 /20:21126 /21:21141 /22:27474 /23:27088 /24:157858 /25:937 /26:1109 /27:562 /28:164 /29:10 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2692 4166 bellsouth.net, inc. 4323 2353 3723 Time Warner Telecom 4766 1436 1765 Korea Telecom (KIX) 17488 1250 1473 Hathway IP Over Cable Interne 1785 1242 1778 PaeTec Communications, Inc. 11492 1061 1137 Cable One 18566 1043 1062 Covad Communications 9583 958 1107 Sify Limited 7018 938 1571 AT&T WorldNet Services 10620 929 1024 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:228 12:2139 13:7 15:22 16:3 17:5 20:36 24:1227 32:52 34:2 38:605 40:99 41:1802 43:1 44:2 46:1 47:21 52:6 55:2 56:2 57:23 58:613 59:640 60:441 61:1090 62:960 63:2001 64:3665 65:2367 66:4087 67:1764 68:989 69:2785 70:589 71:153 72:1728 73:2 74:1995 75:183 76:359 77:866 78:559 79:374 80:924 81:818 82:477 83:443 84:538 85:1003 86:374 87:692 88:423 89:1489 90:54 91:2628 92:416 93:1221 94:1233 95:934 96:182 97:270 98:380 99:30 109:82 110:260 111:465 112:144 113:161 114:278 115:434 116:1118 117:590 118:359 119:792 120:128 121:797 122:1297 123:780 124:1053 125:1372 128:222 129:216 130:138 131:424 132:76 133:16 134:186 135:42 136:232 137:167 138:180 139:82 140:443 141:123 142:387 143:352 144:362 145:49 146:395 147:170 148:552 149:201 150:149 151:173 152:212 153:159 154:2 155:272 156:167 157:310 158:92 159:359 160:292 161:171 162:279 163:172 164:276 165:468 166:483 167:390 168:750 169:162 170:465 171:42 172:2 173:385 174:384 175:1 178:1 180:150 182:1 184:1 186:155 187:183 188:1206 189:621 190:3183 192:5736 193:4273 194:3320 195:2750 196:1168 198:3552 199:3354 200:5208 201:1352 202:7908 203:8223 204:3930 205:2168 206:2406 207:3010 208:3985 209:3428 210:2548 211:1147 212:1645 213:1627 214:177 215:40 216:4447 217:1343 218:474 219:459 220:1138 221:457 222:303 End of report From cidr-report at potaroo.net Fri Oct 30 17:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Oct 2009 22:00:02 GMT Subject: BGP Update Report Message-ID: <200910302200.n9UM02MJ028400@wattle.apnic.net> BGP Update Report Interval: 22-Oct-09 -to- 29-Oct-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9706 31932 2.3% 2902.9 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 2 - AS41661 20078 1.4% 542.6 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 3 - AS35805 19764 1.4% 41.2 -- UTG-AS United Telecom AS 4 - AS9829 17808 1.3% 20.9 -- BSNL-NIB National Internet Backbone 5 - AS8452 14506 1.0% 14.6 -- TEDATA TEDATA 6 - AS17974 14242 1.0% 17.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS11735 13212 0.9% 6606.0 -- ITRON-OAKLAND-HOSTING - ITRON 8 - AS29049 10662 0.8% 35.4 -- DELTA-TELECOM-AS Delta Telecom LTD. 9 - AS17488 10486 0.8% 7.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 10 - AS23700 9710 0.7% 9.2 -- BM-AS-ID PT. Broadband Multimedia, Tbk 11 - AS4323 9442 0.7% 2.2 -- TWTC - tw telecom holdings, inc. 12 - AS7643 8976 0.6% 6.2 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 13 - AS6389 8299 0.6% 2.0 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 14 - AS4755 7835 0.6% 6.2 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 15 - AS8151 7738 0.6% 5.0 -- Uninet S.A. de C.V. 16 - AS10620 7707 0.6% 7.4 -- TV Cable S.A. 17 - AS9198 7302 0.5% 18.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 18 - AS6478 6890 0.5% 5.1 -- ATT-INTERNET3 - AT&T WorldNet Services 19 - AS9299 6539 0.5% 36.9 -- IPG-AS-AP Philippine Long Distance Telephone Company 20 - AS3 6419 0.5% 213.0 -- ELKATV ELEKTRONIKA - KATV d.o.o. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS11735 13212 0.9% 6606.0 -- ITRON-OAKLAND-HOSTING - ITRON 2 - AS9706 31932 2.3% 2902.9 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 3 - AS36239 1892 0.1% 1892.0 -- EXIGEN-CANADA - Exigen Canada 4 - AS27667 1027 0.1% 1027.0 -- Universidad Autonoma de la Laguna 5 - AS41661 20078 1.4% 542.6 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 6 - AS3 486 0.0% 143.0 -- ELKATV ELEKTRONIKA - KATV d.o.o. 7 - AS45405 2099 0.1% 419.8 -- ONAIRIC-AS-KR ONAIR IC 8 - AS49562 417 0.0% 417.0 -- XMS Xtra Media Services 9 - AS48309 791 0.1% 395.5 -- AGS-AS Ariana Gostar Spadana Autonomous Number 10 - AS2642 1799 0.1% 359.8 -- LEG-CA-GOV - State of California 11 - AS8668 2193 0.2% 313.3 -- TELONE-AS TelOne Zimbabwe P/L 12 - AS48640 291 0.0% 291.0 -- MAZ-AS MAZ Mutua de Accidentes de Trabajo y Enfermedades 13 - AS39803 578 0.0% 289.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 14 - AS26812 536 0.0% 268.0 -- ROTARYORC - Rotary International 15 - AS4050 254 0.0% 254.0 -- OMNINET-PRI-AS - Omninet Communications Services 16 - AS42693 226 0.0% 226.0 -- KMBBANK-AS KMB Bank 17 - AS39386 2679 0.2% 223.2 -- STC-IGW-AS Saudi Telecom Company 18 - AS22917 1323 0.1% 220.5 -- INFOCHANNEL - InfoChannel Ltd. 19 - AS3586 2516 0.2% 209.7 -- JAMNET - University of the West Indies 20 - AS5691 2642 0.2% 203.2 -- MITRE-AS-5 - The MITRE Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 63.82.251.0/24 6606 0.5% AS11735 -- ITRON-OAKLAND-HOSTING - ITRON 2 - 63.80.163.0/24 6606 0.5% AS11735 -- ITRON-OAKLAND-HOSTING - ITRON 3 - 211.182.0.0/16 3992 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 4 - 210.180.128.0/18 3992 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 5 - 211.43.64.0/21 3992 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 6 - 211.43.32.0/19 3990 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 7 - 211.43.29.0/24 3990 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 8 - 211.43.72.0/22 3990 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 9 - 210.180.192.0/19 3990 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 10 - 211.43.30.0/23 3990 0.3% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 11 - 95.78.176.0/21 2652 0.2% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 12 - 95.78.184.0/21 2648 0.2% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 13 - 95.78.160.0/20 2641 0.2% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 14 - 92.255.241.0/24 2640 0.2% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 15 - 192.12.120.0/24 2596 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 16 - 94.181.44.0/22 2194 0.1% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 17 - 94.181.0.0/19 2193 0.1% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 18 - 94.181.32.0/20 2183 0.1% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 19 - 92.255.247.0/24 2182 0.1% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 20 - 72.28.75.0/24 1892 0.1% AS36239 -- EXIGEN-CANADA - Exigen Canada Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 30 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Oct 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200910302200.n9UM00uF028395@wattle.apnic.net> This report has been generated at Fri Oct 30 21:11:17 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 23-10-09 306361 189631 24-10-09 306652 189682 25-10-09 306688 189731 26-10-09 306639 189627 27-10-09 306732 189682 28-10-09 306208 189788 29-10-09 306989 190212 30-10-09 306992 189783 AS Summary 32714 Number of ASes in routing system 13895 Number of ASes announcing only one prefix 4331 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 91473856 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 30Oct09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 306977 189830 117147 38.2% All ASes AS6389 4166 320 3846 92.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4331 1918 2413 55.7% TWTC - tw telecom holdings, inc. AS4766 1881 579 1302 69.2% KIXS-AS-KR Korea Telecom AS17488 1473 288 1185 80.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1102 76 1026 93.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 1779 847 932 52.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1488 573 915 61.5% Uninet S.A. de C.V. AS4755 1269 393 876 69.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1028 229 799 77.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 297 765 72.0% COVAD - Covad Communications Co. AS18101 973 256 717 73.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS8452 989 290 699 70.7% TEDATA TEDATA AS6478 1316 673 643 48.9% ATT-INTERNET3 - AT&T WorldNet Services AS3356 1222 594 628 51.4% LEVEL3 Level 3 Communications AS10620 1024 399 625 61.0% TV Cable S.A. AS17908 639 63 576 90.1% TCISL Tata Communications AS4808 759 197 562 74.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 660 99 561 85.0% Telecom Argentina S.A. AS9498 651 98 553 84.9% BBIL-AP BHARTI Airtel Ltd. AS4804 621 93 528 85.0% MPX-AS Microplex PTY LTD AS22047 546 18 528 96.7% VTR BANDA ANCHA S.A. AS7018 1574 1049 525 33.4% ATT-INTERNET4 - AT&T WorldNet Services AS11492 1137 653 484 42.6% CABLEONE - CABLE ONE, INC. AS9443 531 80 451 84.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS855 625 177 448 71.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 564 129 435 77.1% GIGAINFRA Softbank BB Corp. AS4780 561 142 419 74.7% SEEDNET Digital United Inc. AS7011 1030 621 409 39.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS28573 790 390 400 50.6% NET Servicos de Comunicao S.A. AS7738 428 29 399 93.2% Telecomunicacoes da Bahia S.A. Total 36219 11570 24649 68.1% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.248.71.0/24 AS11730 CIL-ASN - Circle Internet LTD 91.198.127.0/24 AS8972 PLUSSERVER-AS PlusServer AG, Germany 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 109.108.224.0/19 AS49223 EVEREST-AS "Everest" Broadcasting Company Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.77.128.0/24 AS4323 TWTC - tw telecom holdings, inc. 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.162.0/24 AS4841 202.140.168.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From stef-list at memberwebs.com Fri Oct 30 19:20:58 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Fri, 30 Oct 2009 18:20:58 -0600 Subject: Power Analysis/Management Tools In-Reply-To: <567F73A9D5674A2B8976CE643330267C@htpc> References: <366100670910261358g441f4281g965002723922cea2@mail.gmail.com> <567F73A9D5674A2B8976CE643330267C@htpc> Message-ID: <4AEB82EA.6080104@memberwebs.com> Chris Russell wrote: > I ended up writing our own, custom pollers, Database backend, web frontend > and rrd to generate the graphing. Shameless plug ... rrdbot does efficient light-weight snmp polling, and should be very flexible for mixing with other software: http://memberwebs.com/stef/software/rrdbot/ Cheers, Stef From alif.terranson at gmail.com Fri Oct 30 21:31:10 2009 From: alif.terranson at gmail.com (J.A. Terranson) Date: Fri, 30 Oct 2009 21:31:10 -0500 Subject: AT&T prefix flapping? In-Reply-To: References: Message-ID: As a *customer* of ATT who has been fighting with every version of "Technical Support", "IP Engineering", "Backbone Maintenance" and about 20 other made up names for level 1 support on this very issue for the last three weeks on this and ?related? latencies in the 2000++ ranges, can we ask again, IS ANYONE HOME AT ATT? Thank you for your "support" in this not pressing to ATT matter. ---------- Forwarded message ---------- From: Jonathan Park Date: Fri, Oct 16, 2009 at 3:26 PM Subject: AT&T prefix flapping? To: nanog at nanog.org Hi all, For the past two months, it seems that AS7132 (SBIS-AT&T) announces and withdraws about 1,500 prefixes to AS7018 (AT&T) monitor every ~80 seconds. This observation is based on AT&T's monitor peering with RouteViews and RIPE. Does anyone know what's going on? Thanks, Jonathan _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/ From sean at donelan.com Sat Oct 31 15:13:31 2009 From: sean at donelan.com (Sean Donelan) Date: Sat, 31 Oct 2009 16:13:31 -0400 (EDT) Subject: PPPoE vs. Bridged ADSL In-Reply-To: References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> Message-ID: <200910311545230.6B95064B.16404@clifden.donelan.com> On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote: > Others commented on things I already had in mind only the username/password > thing of PPPoE. We use the same username/pw on the modem as the customer > users for their e-mail, so a password change necessitates a truck roll (I > know, I know, TR-069). We started with PPPoE for our FTTH, because we were > familiar with it, but we moved over to a "VLAN per service" model which ends > up something like RBE in function. We can track customers based on the > Option 82 info, so we're good to go in terms of tracking them. You can have a "network username/password" for the customer different from the mail and other application-layer username/password. Some ISPs did that in the dial-up days, and also with PPPOx. The network account information is configured in the dialer or router/modem; and most users never need to know the network-layer stuff. The user can change their mail/application password (and use it for off-network access) without affecting their network-layer pasword. The same network account may have multiple mail/application accounts associated with it. It also helps in the debate whether you store unreversable passwords or cleartext passwords for things like CHAP/PAP; need to split accounts because people change households; network re-architecture moves circuits around or users move and re-associating the connections with the correct accounts. Yep, I sometimes found two households with swapped VPI/VCI, VLAN or PORT identifiers because someone/something made a data entry or circuit termination mistake. I like a combination of 802.1x and Option 82 as way of cross-checking, and layer 2/3 anti-spoof protection. I also like handling network things mostly at the network/hardware level, separate from the application layer identity so the user changes aren't affected. But there are almost always multiple ways to solve a problem. From globichen at gmail.com Sat Oct 31 15:37:03 2009 From: globichen at gmail.com (Andy B.) Date: Sat, 31 Oct 2009 21:37:03 +0100 Subject: Upstream BGP community support Message-ID: Hi, Quick question: Would you buy transit from someone who does not support BGP communities? Here is the story: My company is pushing several GBit/s through various upstream providers. We have reached the point where we rely on BGP communitiy support, especially communities that can be sent to the upstream to change the way he announces our prefixes to his peers/transits. While most decent upstream providers support this kind of traffic engineering, one of them refuses to send and accept BGP communities. I tried to contact my upstream several times through different channels to get some background as to why they would not be able to provide us this service, but all we get is tickets that get closed without an answer. Management itself does not seem to bother either. Is this normal or is it too much to ask for BGP communities from an upstream who has points of presence in the US, Europe and Asia? Andy From jeffrey.lyon at blacklotus.net Sat Oct 31 15:45:09 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 31 Oct 2009 16:45:09 -0400 Subject: Upstream BGP community support In-Reply-To: References: Message-ID: <16720fe00910311345s6685e1e1rcdde8185d39bf960@mail.gmail.com> We have transit through Peer1 and Telia, both accept communities. I wouldn't consider buying from someone who didn't. Jeff On Sat, Oct 31, 2009 at 4:37 PM, Andy B. wrote: > Hi, > > Quick question: Would you buy transit from someone who does not > support BGP communities? > > Here is the story: > > My company is pushing several GBit/s through various upstream > providers. We have reached the point where we rely on BGP communitiy > support, especially communities that can be sent to the upstream to > change the way he announces our prefixes to his peers/transits. > > While most decent upstream providers support this kind of traffic > engineering, one of them refuses to send and accept BGP communities. I > tried to contact my upstream several times through different channels > to get some background as to why they would not be able to provide us > this service, but all we get is tickets that get closed without an > answer. Management itself does not seem to bother either. > > Is this normal or is it too much to ask for BGP communities from an > upstream who has points of presence in the US, Europe and Asia? > > > Andy > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From ras at e-gerbil.net Sat Oct 31 17:09:38 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 31 Oct 2009 17:09:38 -0500 Subject: Upstream BGP community support In-Reply-To: References: Message-ID: <20091031220938.GE51443@gerbil.cluepon.net> On Sat, Oct 31, 2009 at 09:37:03PM +0100, Andy B. wrote: > While most decent upstream providers support this kind of traffic > engineering, one of them refuses to send and accept BGP communities. I > tried to contact my upstream several times through different channels > to get some background as to why they would not be able to provide us > this service, but all we get is tickets that get closed without an > answer. Management itself does not seem to bother either. > > Is this normal or is it too much to ask for BGP communities from an > upstream who has points of presence in the US, Europe and Asia? Yes and no. There are a handful of old stodgy networks who are of the belief that this kind of information is "proprietary", and therefore should not be sent to customers or other networks on the Internet. My opinion is that those networks are "idiots", and therefore money should not be sent to them. Even if (for whatever reason) you don't need a particular set of features in BGP communities, I personally think that they are an excellent indicator of the networks' general technical competence and ability to work with them on a wide variety of other issues. In this day and age a robust and functional set of communities should really be a requirement for any network provider. There was also a NANOG presentation on a pretty reasonable design and implementation of BGP communities for a service provider: http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From nanog-post at rsuc.gweep.net Sat Oct 31 17:55:13 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 31 Oct 2009 18:55:13 -0400 Subject: Upstream BGP community support In-Reply-To: References: Message-ID: <20091031225512.GA15643@gweep.net> On Sat, Oct 31, 2009 at 09:37:03PM +0100, Andy B. wrote: > Hi, > > Quick question: Would you buy transit from someone who does not > support BGP communities? No. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From frnkblk at iname.com Sat Oct 31 17:55:53 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Sat, 31 Oct 2009 17:55:53 -0500 Subject: PPPoE vs. Bridged ADSL In-Reply-To: <200910311545230.6B95064B.16404@clifden.donelan.com> References: <1256756748.2228.9.camel@nld06907> <137DADDB-F961-460F-B051-AB931CD36289@arbor.net> <4AE8B5A4.4040404@socket.net> <200910311545230.6B95064B.16404@clifden.donelan.com> Message-ID: Hindsight being what it is, we would have likely had a separate account/password for the PPP account. I guess we could theoretically have two layers of RADIUS checking, the first layer being the application-layer username/password, and failing that, the original username/password that we assigned to the PPP device. Frank -----Original Message----- From: Sean Donelan [mailto:sean at donelan.com] Sent: Saturday, October 31, 2009 3:14 PM To: NANOG list Subject: RE: PPPoE vs. Bridged ADSL On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote: > Others commented on things I already had in mind only the username/password > thing of PPPoE. We use the same username/pw on the modem as the customer > users for their e-mail, so a password change necessitates a truck roll (I > know, I know, TR-069). We started with PPPoE for our FTTH, because we were > familiar with it, but we moved over to a "VLAN per service" model which ends > up something like RBE in function. We can track customers based on the > Option 82 info, so we're good to go in terms of tracking them. You can have a "network username/password" for the customer different from the mail and other application-layer username/password. Some ISPs did that in the dial-up days, and also with PPPOx. The network account information is configured in the dialer or router/modem; and most users never need to know the network-layer stuff. The user can change their mail/application password (and use it for off-network access) without affecting their network-layer pasword. The same network account may have multiple mail/application accounts associated with it. It also helps in the debate whether you store unreversable passwords or cleartext passwords for things like CHAP/PAP; need to split accounts because people change households; network re-architecture moves circuits around or users move and re-associating the connections with the correct accounts. Yep, I sometimes found two households with swapped VPI/VCI, VLAN or PORT identifiers because someone/something made a data entry or circuit termination mistake. I like a combination of 802.1x and Option 82 as way of cross-checking, and layer 2/3 anti-spoof protection. I also like handling network things mostly at the network/hardware level, separate from the application layer identity so the user changes aren't affected. But there are almost always multiple ways to solve a problem. From globichen at gmail.com Sat Oct 31 18:00:20 2009 From: globichen at gmail.com (Andy B.) Date: Sun, 1 Nov 2009 00:00:20 +0100 Subject: Upstream BGP community support In-Reply-To: <20091031220938.GE51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> Message-ID: On Sat, Oct 31, 2009 at 11:09 PM, Richard A Steenbergen wrote: > Yes and no. There are a handful of old stodgy networks who are of the > belief that this kind of information is "proprietary", and therefore > should not be sent to customers or other networks on the Internet. My > opinion is that those networks are "idiots", and therefore money should > not be sent to them. I would not say that my upstream is an old stodgy network and certainly will I not consider them as "idiots", because they seem to know what they are doing. I'd rather say they are pretty ignorant when it comes to some "advanced" customer requirements. By "they", I am referring myself to Hurricane Electric. But you are right: money should not be sent to them while they lack any kind of BGP community support. > Even if (for whatever reason) you don't need a particular set of > features in BGP communities, I personally think that they are an > excellent indicator of the networks' general technical competence and > ability to work with them on a wide variety of other issues. In this day > and age a robust and functional set of communities should really be a > requirement for any network provider. We're almost 2010. Hurricane Electric, please do something about it! Andy From morrowc.lists at gmail.com Sat Oct 31 18:12:52 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 31 Oct 2009 19:12:52 -0400 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> Message-ID: <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> On Sat, Oct 31, 2009 at 7:00 PM, Andy B. wrote: >> In this day >> and age a robust and functional set of communities should really be a >> requirement for any network provider. > > We're almost 2010. Hurricane Electric, please do something about it! > maybe bake them a cake? -chris From ras at e-gerbil.net Sat Oct 31 18:27:38 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 31 Oct 2009 18:27:38 -0500 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> Message-ID: <20091031232738.GF51443@gerbil.cluepon.net> On Sun, Nov 01, 2009 at 12:00:20AM +0100, Andy B. wrote: > I would not say that my upstream is an old stodgy network and > certainly will I not consider them as "idiots", because they seem to > know what they are doing. I'd rather say they are pretty ignorant when > it comes to some "advanced" customer requirements. > > By "they", I am referring myself to Hurricane Electric. But you are > right: money should not be sent to them while they lack any kind of > BGP community support. Wow, really? I would never have guessed in a million years that HE would have a problem supporting communities. Typically lack of community support falls into one of two categories. 1) Old stodgy tier 1's who have communities but don't want to share them with the world, because of silly NDA concerns or the like. This covers a wide variety of positions, from "we won't export them to anyone" to "you have to sign some paperwork and/or yell a lot to get the secret decoder ring". 2) Those who lacks communities completely. IMHO both are idiots, but category #2 is a special breed which you should avoid like the plague. A common problem for service providers who lack communities is the inability to control their advertisements properly. Consider what happens when they have a multihomed customer who typically announces a prefix through them, but who decided to stop for some reason. They then end up hearing that prefix via some other route, such as a peer or transit provider, but without a community tag to know that it wasn't learned from a customer they will blindly readvertise it, providing unintentional (and typically unwanted) transit. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From dorian at blackrose.org Sat Oct 31 18:35:31 2009 From: dorian at blackrose.org (Dorian Kim) Date: Sat, 31 Oct 2009 18:35:31 -0500 Subject: Upstream BGP community support In-Reply-To: <20091031232738.GF51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> Message-ID: <20091031233531.GA81416@blackrose.org> On Sat, Oct 31, 2009 at 06:27:38PM -0500, Richard A Steenbergen wrote: > 1) Old stodgy tier 1's who have communities but don't want to share them > with the world, because of silly NDA concerns or the like. This covers a I'm curious, since when did respecting bounds of contracts and agreements one has signed become "stodgy"? -dorian From jcdill.lists at gmail.com Sat Oct 31 18:47:39 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 31 Oct 2009 16:47:39 -0700 Subject: Upstream BGP community support In-Reply-To: References: Message-ID: <4AECCC9B.9000504@gmail.com> Andy B. wrote: > I tried to contact my upstream several times through different channels > to get some background as to why they would not be able to provide us > this service, but all we get is tickets that get closed without an > answer. Management itself does not seem to bother either. > Completely separate from your question about BGP community support policies, the quoted text above is a stopper for me. Any company that wants my money shouldn't close tickets without an answer - about anything, ever. This is a huge customer support red-flag issue for me. As always, YMMV. jc From ras at e-gerbil.net Sat Oct 31 18:49:03 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 31 Oct 2009 18:49:03 -0500 Subject: Upstream BGP community support In-Reply-To: <20091031233531.GA81416@blackrose.org> References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> <20091031233531.GA81416@blackrose.org> Message-ID: <20091031234903.GG51443@gerbil.cluepon.net> On Sat, Oct 31, 2009 at 06:35:31PM -0500, Dorian Kim wrote: > On Sat, Oct 31, 2009 at 06:27:38PM -0500, Richard A Steenbergen wrote: > > 1) Old stodgy tier 1's who have communities but don't want to share them > > with the world, because of silly NDA concerns or the like. This covers a > > I'm curious, since when did respecting bounds of contracts and agreements > one has signed become "stodgy"? There is no excuse for not being able to tell people where you learned a route from (continent, region, city, country, etc). I'm personally of the opinion that this is a good thing to share with the entire Internet, as it lets people make intelligent TE decisions for your routes even if they don't have a direct relationship with your network. You should also be able to at a minimum allow no-export or prepend to specific ASNs, and not being able to provide these to customers is absolutely grounds for "should never ever buy from" status. The "we aren't allowed to say we're a peer" argument seems easily defeatable, realistically if you're a stodgy tier 1 all you need is "this is a customer" tag and you can figure out the rest with "not a customer" logic without explicitly violating any NDAs. The "alter export attributes within a specific region" argument is a somewhat legitimate one due to requirements for consistent announcements, but I prefer to enable it by default and deal with unhappy peers on a case by case basis. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From randy at psg.com Sat Oct 31 19:25:34 2009 From: randy at psg.com (Randy Bush) Date: Sun, 01 Nov 2009 09:25:34 +0900 Subject: Upstream BGP community support In-Reply-To: <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> Message-ID: while i can understand folk's wanting to signal upstream using communities, and i know it's all the rage. one issue needs to be raised. bgp is a brilliant information hiding protocol. policy is horribly opaque. complexity abounds. and it has unfun consequences, e.g. see tim on wedgies etc. and this just adds to the complexity and opacity. so i ain't sayin' don't do it. after all, who would deny you the ability to show off your bgp macho? just try to minimize its use to only when you *really* need it. randy From deleskie at gmail.com Sat Oct 31 19:30:38 2009 From: deleskie at gmail.com (jim deleskie) Date: Sat, 31 Oct 2009 21:30:38 -0300 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> Message-ID: Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) -jim On Sat, Oct 31, 2009 at 9:25 PM, Randy Bush wrote: > while i can understand folk's wanting to signal upstream using > communities, and i know it's all the rage. ?one issue needs to be > raised. > > bgp is a brilliant information hiding protocol. ?policy is horribly > opaque. ?complexity abounds. ?and it has unfun consequences, e.g. see > tim on wedgies etc. > > and this just adds to the complexity and opacity. > > so i ain't sayin' don't do it. ?after all, who would deny you the > ability to show off your bgp macho? > > just try to minimize its use to only when you *really* need it. > > randy > > From dorian at blackrose.org Sat Oct 31 19:33:52 2009 From: dorian at blackrose.org (Dorian Kim) Date: Sat, 31 Oct 2009 19:33:52 -0500 Subject: Upstream BGP community support In-Reply-To: <20091031234903.GG51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> <20091031233531.GA81416@blackrose.org> <20091031234903.GG51443@gerbil.cluepon.net> Message-ID: <20091101003352.GB81416@blackrose.org> On Sat, Oct 31, 2009 at 06:49:03PM -0500, Richard A Steenbergen wrote: > > I'm curious, since when did respecting bounds of contracts and agreements > > one has signed become "stodgy"? > > There is no excuse for not being able to tell people where you learned a > route from (continent, region, city, country, etc). I'm personally of > the opinion that this is a good thing to share with the entire Internet, > as it lets people make intelligent TE decisions for your routes even if > they don't have a direct relationship with your network. You should also > be able to at a minimum allow no-export or prepend to specific ASNs, and > not being able to provide these to customers is absolutely grounds for > "should never ever buy from" status. > > The "we aren't allowed to say we're a peer" argument seems easily > defeatable, realistically if you're a stodgy tier 1 all you need is > "this is a customer" tag and you can figure out the rest with "not a > customer" logic without explicitly violating any NDAs. The "alter export > attributes within a specific region" argument is a somewhat legitimate > one due to requirements for consistent announcements, but I prefer to > enable it by default and deal with unhappy peers on a case by case > basis. This is a strawman argument. I never said that any of the above was a bad thing, nor that transit providers shouldn't support them. They should. Only point I was addressing was your characterisation that networks who do support various communities but do not publish those supported communities were "stodgy" becuase they were doing so due to "silly NDA concerns or the like". Fact is, regardless of whether you or I think it makes any sense or not is that some peering agreements preclude disclosure of the locations of peering, and in some extreme cases even the disclosure of the existance of said peering. So if you were a party to such an agreement, you can not disclose things you are bound from doing without breeching the agreement. Apologies to the list for the derail, -dorian From randy at psg.com Sat Oct 31 19:34:28 2009 From: randy at psg.com (Randy Bush) Date: Sun, 01 Nov 2009 09:34:28 +0900 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> Message-ID: > Here is the problem as I see it. Sure some % fo the people using BGP > are bright nuff to use some upstreams communities, but sadly many are > not. So this ends up breaking one or more networks, who in turn twist > more dials causing other changes.. rinse, wash and repeat. But like > Randy said who am I to stop anyone from playing... just means those of > us with clue will be able to continue to earn a pay check for a very > long time still :) i would rather earn it by designing things, not by cleaning up messes made by kiddies needing to show off. randy From deleskie at gmail.com Sat Oct 31 19:35:46 2009 From: deleskie at gmail.com (jim deleskie) Date: Sat, 31 Oct 2009 21:35:46 -0300 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> Message-ID: Agree'd :) On Sat, Oct 31, 2009 at 9:34 PM, Randy Bush wrote: >> Here is the problem as I see it. ?Sure some % fo the people using BGP >> are bright nuff to use some upstreams communities, but sadly many are >> not. ?So this ends up breaking one or more networks, who in turn twist >> more dials causing other changes.. rinse, wash and repeat. ?But like >> Randy said who am I to stop anyone from playing... just means those of >> us with clue will be able to continue to earn a pay check for a very >> long time still :) > > i would rather earn it by designing things, not by cleaning up messes > made by kiddies needing to show off. > > randy > From ras at e-gerbil.net Sat Oct 31 20:03:12 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 31 Oct 2009 20:03:12 -0500 Subject: Upstream BGP community support In-Reply-To: <20091101003352.GB81416@blackrose.org> References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> <20091031233531.GA81416@blackrose.org> <20091031234903.GG51443@gerbil.cluepon.net> <20091101003352.GB81416@blackrose.org> Message-ID: <20091101010312.GH51443@gerbil.cluepon.net> On Sat, Oct 31, 2009 at 07:33:52PM -0500, Dorian Kim wrote: > This is a strawman argument. I never said that any of the above was > a bad thing, nor that transit providers shouldn't support them. They > should. > > Only point I was addressing was your characterisation that networks > who do support various communities but do not publish those supported > communities were "stodgy" becuase they were doing so due to "silly NDA > concerns or the like". > > Fact is, regardless of whether you or I think it makes any sense or > not is that some peering agreements preclude disclosure of the locations > of peering, and in some extreme cases even the disclosure of the > existance of said peering. > > So if you were a party to such an agreement, you can not disclose things > you are bound from doing without breeching the agreement. Ok I think we're commingling issues. As I said in my first message, I apply the stodgy label to folks who won't export any communities at all because they're considered "proprietary". In my second message I was trying to expand on their considerations (i.e. NDA concerns), which didn't come across well. Clearly there are a large variety of communities you can support which don't come with any such concerns. Obviously any time NDAs are involved you have to give them some serious consideration, but the question becomes at what point does an excessive concern start degrading the quality of service you provider to your customers for no reason. My opinion is that an NDA preventing you from disclosing who you peer with and in what locations means you shouldn't put up a website with the address of every interconnection address and capacity, not that you can't say "this route goes to the Chicago region". At a certain point there is only so much information you can obscure. I'm going to be able to figure out who your customers are when I see you readvertising them to the Internet. I'm going to be able to figure out where you peer because I can read the DNS in your traceroute and then walk around the major colo facilities until I see your router with the label on front, does this mean you can't use reverse DNS or label your routers? At some point all you're doing by obscuring most of this information is making it harder for me the customer, peer, or remote party who just happens to be exchanging information with someone on your network, resulting in poorer quality service for your customers. And I'll conclude my argument with this: whois -h whois.radb.net | grep remarks: If Level 3 can tag routes with pop codes, cities, and peer/customer origin tags, then you (for some value of you by which I mean anyone who might ever get the stodgy label :P) can too. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From ras at e-gerbil.net Sat Oct 31 20:07:49 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 31 Oct 2009 20:07:49 -0500 Subject: Upstream BGP community support In-Reply-To: <20091101010312.GH51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> <20091031233531.GA81416@blackrose.org> <20091031234903.GG51443@gerbil.cluepon.net> <20091101003352.GB81416@blackrose.org> <20091101010312.GH51443@gerbil.cluepon.net> Message-ID: <20091101010749.GI51443@gerbil.cluepon.net> On Sat, Oct 31, 2009 at 08:03:12PM -0500, Richard A Steenbergen wrote: > And I'll conclude my argument with this: > > whois -h whois.radb.net | grep remarks: Err insert "AS3356" in there, sorry failure in proofreading. I'll leave it there, but clearly this is being done by many other large networks without the world ending. And if you're a stodgy network reading this, maybe this explains where all your customers are going. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jackson.tim at gmail.com Sat Oct 31 20:13:46 2009 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 31 Oct 2009 20:13:46 -0500 Subject: Upstream BGP community support In-Reply-To: <20091031220938.GE51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> Message-ID: <4407932e0910311813v3fda284dp367177a1dd28326e@mail.gmail.com> Being the architect/head-nerd-in-charge of a fairly new network..... Not reading ras's HOWTOs and others is suicide.... There's no excuse... It really makes running your network easier.. If my customer needs to prepend X to Y transit/peer/customer or not announce to them at 3am, that means they don't have to call me... My customers like it, and so do I. RTFM and we'll all be happier... On 10/31/09, Richard A Steenbergen wrote: > On Sat, Oct 31, 2009 at 09:37:03PM +0100, Andy B. wrote: >> While most decent upstream providers support this kind of traffic >> engineering, one of them refuses to send and accept BGP communities. I >> tried to contact my upstream several times through different channels >> to get some background as to why they would not be able to provide us >> this service, but all we get is tickets that get closed without an >> answer. Management itself does not seem to bother either. >> >> Is this normal or is it too much to ask for BGP communities from an >> upstream who has points of presence in the US, Europe and Asia? > > Yes and no. There are a handful of old stodgy networks who are of the > belief that this kind of information is "proprietary", and therefore > should not be sent to customers or other networks on the Internet. My > opinion is that those networks are "idiots", and therefore money should > not be sent to them. > > Even if (for whatever reason) you don't need a particular set of > features in BGP communities, I personally think that they are an > excellent indicator of the networks' general technical competence and > ability to work with them on a wide variety of other issues. In this day > and age a robust and functional set of communities should really be a > requirement for any network provider. > > > There was also a NANOG presentation on a pretty reasonable design and > implementation of BGP communities for a service provider: > > http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf > > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > -- Sent from my mobile device From globichen at gmail.com Sat Oct 31 20:28:37 2009 From: globichen at gmail.com (Andy B.) Date: Sun, 1 Nov 2009 02:28:37 +0100 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <4407932e0910311813v3fda284dp367177a1dd28326e@mail.gmail.com> Message-ID: On Sun, Nov 1, 2009 at 2:13 AM, Tim Jackson wrote: > Being the architect/head-nerd-in-charge of a fairly new network..... > > Not reading ras's HOWTOs and others is suicide.... There's no > excuse... It really makes running your network easier.. If my customer > needs to prepend X to Y transit/peer/customer or not announce to them > at 3am, that means they don't have to call me... That's exactly what I expect from a decent upstream. So far all our upstreams (Level3, Cogent, Tata), with the exception of HE, provide this service. I don't even care about receiving their communities which describe where the prefix has been injected, since I can handle outbound traffic more or less myself. It's a nice-to-have feature though. It's the inbound that I cannot control without a little help from my upstreams, hence our desperate need to send BGP communities. Andy From tvarriale at comcast.net Sat Oct 31 20:50:47 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Sat, 31 Oct 2009 20:50:47 -0500 Subject: Upstream BGP community support References: Message-ID: The answer is fairly simple. Does your business benefit by having the ability to modify routing strategy as you see fit? Yes or no? IMO, the answer is yes. If your business partners aren't on the same page or align correctly with your requirements, seek new ones. tv ----- Original Message ----- From: "Andy B." To: Sent: Saturday, October 31, 2009 3:37 PM Subject: Upstream BGP community support > Hi, > > Quick question: Would you buy transit from someone who does not > support BGP communities? > > Here is the story: > > My company is pushing several GBit/s through various upstream > providers. We have reached the point where we rely on BGP communitiy > support, especially communities that can be sent to the upstream to > change the way he announces our prefixes to his peers/transits. > > While most decent upstream providers support this kind of traffic > engineering, one of them refuses to send and accept BGP communities. I > tried to contact my upstream several times through different channels > to get some background as to why they would not be able to provide us > this service, but all we get is tickets that get closed without an > answer. Management itself does not seem to bother either. > > Is this normal or is it too much to ask for BGP communities from an > upstream who has points of presence in the US, Europe and Asia? > > > Andy > From pauldotwall at gmail.com Sat Oct 31 21:03:26 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Sat, 31 Oct 2009 22:03:26 -0400 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> Message-ID: <620fd17c0910311903o2d65df1dq6ef51d985a540d02@mail.gmail.com> On Sat, Oct 31, 2009 at 8:25 PM, Randy Bush wrote: > while i can understand folk's wanting to signal upstream using > communities, and i know it's all the rage. ?one issue needs to be > raised. BGP communities are all the rage? I don't think this is new concept or fad. Signaling behaviors as well as informing users of types of routes have been around for awhile. For example, RFC1998 (Aug 1996) outlines some of these behaviors with modifying local preference. Even Sprint was advertising the ability to not advertise or prepend to individual peers back in 2002 (http://web.archive.org/web/20020607092619/www.sprintlink.net/policy/bgp.html). > so i ain't sayin' don't do it. ?after all, who would deny you the > ability to show off your bgp macho? How is providing better capabilities for your customers macho? People have been using these knobs 10 years ago and it worked then (just as well as it works now). Drive Slow (as there are trick-or-treaters out tonight) From ken.gilmour at gmail.com Sat Oct 31 22:31:34 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 31 Oct 2009 21:31:34 -0600 Subject: Peering in Latin America Message-ID: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> Hi There, I am looking for carriers who offer peering in Latin America (Specifically Costa Rica). So far the only carrier in Costa Rica who I have been able to find that does this is ADN (American Data Networks, www.data.cr). While they are already on my list for a quote, we need at least one other diverse connection, so I would appreciate if anyone else would be able to help me find other carriers who operate here? Here's who i've contacted so far: RACSA - Can't get past 1st level support (they don't know what BGP is) ICE - Tried contacting a person who's address I was previously given from NANOG to no avail Global Crossing - Said they contacted an engineer who would get back to me, mailed them 4 times since to no avail (no bounced emails either). Level 3 - Apparently don't operate in Latin America AT&T - Want us to have a minimum of 3 locations in the US to peer with first So far ADN are the only carrier who have actually been of any help. Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa Rica" and several variations thereof is not yielding any fruitful results. Thanks and regards, Ken From davet1 at gmail.com Sat Oct 31 22:40:53 2009 From: davet1 at gmail.com (Dave Temkin) Date: Sat, 31 Oct 2009 20:40:53 -0700 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> Message-ID: <4AED0345.4010501@gmail.com> Ken Gilmour wrote: > Hi There, > > I am looking for carriers who offer peering in Latin America > (Specifically Costa Rica). So far the only carrier in Costa Rica who I > have been able to find that does this is ADN (American Data Networks, > www.data.cr). While they are already on my list for a quote, we need > at least one other diverse connection, so I would appreciate if anyone > else would be able to help me find other carriers who operate here? > Here's who i've contacted so far: > > RACSA - Can't get past 1st level support (they don't know what BGP is) > ICE - Tried contacting a person who's address I was previously given > from NANOG to no avail > Global Crossing - Said they contacted an engineer who would get back > to me, mailed them 4 times since to no avail (no bounced emails > either). > Level 3 - Apparently don't operate in Latin America > AT&T - Want us to have a minimum of 3 locations in the US to peer with first > > So far ADN are the only carrier who have actually been of any help. > Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa > Rica" and several variations thereof is not yielding any fruitful > results. > > Thanks and regards, > > Ken > > To be clear; are you looking for paid transit connectivity within Costa Rica for the purposes of localizing traffic or are you looking for free or reduced cost connectivity to very specific SP's in Costa Rica? -Dave From ken.gilmour at gmail.com Sat Oct 31 22:53:27 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 31 Oct 2009 21:53:27 -0600 Subject: Peering in Latin America In-Reply-To: <4AED0345.4010501@gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> Message-ID: <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> 2009/10/31 Dave Temkin : > Ken Gilmour wrote: >> >> Hi There, >> >> I am looking for carriers who offer peering in Latin America >> (Specifically Costa Rica). So far the only carrier in Costa Rica who I >> have been able to find that does this is ADN (American Data Networks, >> www.data.cr). While they are already on my list for a quote, we need >> at least one other diverse connection, so I would appreciate if anyone >> else would be able to help me find other carriers who operate here? >> Here's who i've contacted so far: >> >> RACSA - Can't get past 1st level support (they don't know what BGP is) >> ICE - Tried contacting a person who's address I was previously given >> from NANOG to no avail >> Global Crossing - Said they contacted an engineer who would get back >> to me, mailed them 4 times since to no avail (no bounced emails >> either). >> Level 3 - Apparently don't operate in Latin America >> AT&T - Want us to have a minimum of 3 locations in the US to peer with >> first >> >> So far ADN are the only carrier who have actually been of any help. >> Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa >> Rica" and several variations thereof is not yielding any fruitful >> results. >> >> Thanks and regards, >> >> Ken >> >> > > To be clear; are you looking for paid transit connectivity within Costa Rica > for the purposes of localizing traffic or are you looking for free or > reduced cost connectivity to very specific SP's in Costa Rica? > > -Dave > Hi Dave, I am specifically looking for any of the following two items: 1. A point-to-point link which we can advertise our own PI space on 2. A carrier which we can peer with for diversity. The current problem we have is that none of our carriers here support BGP so connection failover is done by means of manually switching routes on leased lines which causes our IP addresses to change. We are a 24/7 operation which depends on 5 nines uptime at the network level. I expect to pay for transit - but would not say no to free stuff (especially pens and tshirts) :) Regards, Ken From ken.gilmour at gmail.com Sat Oct 31 23:03:03 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 31 Oct 2009 22:03:03 -0600 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> Message-ID: <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> 2009/10/31 Ken Gilmour : > 2009/10/31 Dave Temkin : >> Ken Gilmour wrote: >>> >>> Hi There, >>> >>> I am looking for carriers who offer peering in Latin America >>> (Specifically Costa Rica). So far the only carrier in Costa Rica who I >>> have been able to find that does this is ADN (American Data Networks, >>> www.data.cr). While they are already on my list for a quote, we need >>> at least one other diverse connection, so I would appreciate if anyone >>> else would be able to help me find other carriers who operate here? >>> Here's who i've contacted so far: >>> >>> RACSA - Can't get past 1st level support (they don't know what BGP is) >>> ICE - Tried contacting a person who's address I was previously given >>> from NANOG to no avail >>> Global Crossing - Said they contacted an engineer who would get back >>> to me, mailed them 4 times since to no avail (no bounced emails >>> either). >>> Level 3 - Apparently don't operate in Latin America >>> AT&T - Want us to have a minimum of 3 locations in the US to peer with >>> first >>> >>> So far ADN are the only carrier who have actually been of any help. >>> Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa >>> Rica" and several variations thereof is not yielding any fruitful >>> results. >>> >>> Thanks and regards, >>> >>> Ken >>> >>> >> >> To be clear; are you looking for paid transit connectivity within Costa Rica >> for the purposes of localizing traffic or are you looking for free or >> reduced cost connectivity to very specific SP's in Costa Rica? >> >> -Dave >> > > Hi Dave, > > I am specifically looking for any of the following two items: > > 1. A point-to-point link which we can advertise our own PI space on > 2. A carrier which we can peer with for diversity. > > The current problem we have is that none of our carriers here support > BGP so connection failover is done by means of manually switching > routes on leased lines which causes our IP addresses to change. We are > a 24/7 operation which depends on 5 nines uptime at the network level. > > I expect to pay for transit - but would not say no to free stuff > (especially pens and tshirts) :) > > Regards, > > Ken > To also reply to my own reply :) We have BGP4 networks in other locations (IPv4 and IPv6) - Costa Rica being one of the places that don't have it... We would really like to be able to implement it here but are finding it difficult to find SPs who support Customers who advertise their own PI space. From sethm at rollernet.us Sat Oct 31 23:22:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 31 Oct 2009 21:22:20 -0700 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> Message-ID: <4AED0CFC.8090105@rollernet.us> Ken Gilmour wrote: > > We have BGP4 networks in other locations (IPv4 and IPv6) - Costa Rica > being one of the places that don't have it... We would really like to > be able to implement it here but are finding it difficult to find SPs > who support Customers who advertise their own PI space. > It doesn't sound like you want peering - specifically AT&T's answer implies they think you want settlement-free peering when you just want to announce your routes via BGP (aka paid transit). ~Seth From ken.gilmour at gmail.com Sat Oct 31 23:30:46 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 31 Oct 2009 22:30:46 -0600 Subject: Peering in Latin America In-Reply-To: <4AED0CFC.8090105@rollernet.us> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> <4AED0CFC.8090105@rollernet.us> Message-ID: <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> 2009/10/31 Seth Mattinen : > Ken Gilmour wrote: >> >> We have BGP4 networks in other locations (IPv4 and IPv6) - Costa Rica >> being one of the places that don't have it... We would really like to >> be able to implement it here but are finding it difficult to find SPs >> who support Customers who advertise their own PI space. >> > > It doesn't sound like you want peering - specifically AT&T's answer > implies they think you want settlement-free peering when you just want > to announce your routes via BGP (aka paid transit). > > ~Seth > > Yes - Sorry my initial approach to NANOG was not very specific! However my approach to the SPs was very specific (and ADN understood exactly what I wanted when I first approached them and are working on a quote)... I specifically asked how we would go about getting a second point-to-point link and peer with them over that link (and for existing providers such as ICE and RACSA) how we could upgrade our current contract to allow us to announce our own PI space... I am not sure how I could be any more specific than that... Ken From mike.lyon at gmail.com Sat Oct 31 23:38:44 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 31 Oct 2009 21:38:44 -0700 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> <4AED0CFC.8090105@rollernet.us> <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> Message-ID: You may want to double check your verbage when talking with providers. Transit = you pay for the bandwidth. Peering = free and is a mutual agreement between the two providers. Sounds like you want transit. I'd stop using the "peering" word as it may be confusing people, including your providers. Cheers, Mike On Oct 31, 2009, at 21:30, Ken Gilmour wrote: > 2009/10/31 Seth Mattinen : >> Ken Gilmour wrote: >>> >>> We have BGP4 networks in other locations (IPv4 and IPv6) - Costa >>> Rica >>> being one of the places that don't have it... We would really like >>> to >>> be able to implement it here but are finding it difficult to find >>> SPs >>> who support Customers who advertise their own PI space. >>> >> >> It doesn't sound like you want peering - specifically AT&T's answer >> implies they think you want settlement-free peering when you just >> want >> to announce your routes via BGP (aka paid transit). >> >> ~Seth >> >> > > Yes - Sorry my initial approach to NANOG was not very specific! > However my approach to the SPs was very specific (and ADN understood > exactly what I wanted when I first approached them and are working on > a quote)... I specifically asked how we would go about getting a > second point-to-point link and peer with them over that link (and for > existing providers such as ICE and RACSA) how we could upgrade our > current contract to allow us to announce our own PI space... I am not > sure how I could be any more specific than that... > > Ken >