Re: Edu versus Speakeasy Speedtest
On Thu, 2010-04-29 at 11:48 -0600, Stephen John Smoogen wrote: Take a vacuum cleaner with extensions. Make a set of end connectors A series of tubes anyone? I'd also show them the rrd/MRTG graph at the perimeter. Be clear to them about the units. Never miss the chance to ask for more budget though. Tell them the ACL filters clog and need changing regularly, just be inventive ;) Gord -- darken room - adjust heater current so that elements glow cherry red - apply drive - tune for maximum smoke and minimum sparking
Re: Edu versus Speakeasy Speedtest
On 2010.04.29 17:31, Robert Enger - NANOG wrote: 1) The capacity that a campus has into I2 or NLR is different than the BW the campus purchases from their commercial provider(s). 2) The commercial BW test sites are not optimized for speed. They do not have unlimited capacity network connections. And, they have not tuned their network stack for HS operation: notably, their OS will impose memory limits on the socket / transmit-buffer pool; so even if a receiver advertises a big window, frequently the transmitter (speed test server) will never queue enough data to fill the pipe 3) Peering capacity is not what it should be into the networks used by some of the BW test sites. Your observation is disturbingly bleak... do you have a recommendation? ...perhaps a site with good bandwidth and a cluster of iperf(1) boxes available? :) Steve
Re: [only half OT] A socio-psychological analysis of the first internetwar (Estonia)
On 4/29/10 6:04 PM, Michael Smith wrote: No GPL for the full paper, huh? Back to the cathedral What's the toll in case I can get some buddies to pitch-in to buy access to the full content? I don't really expect people to pay for it. I hope it will eventually become freely available. Gadi. -Original Message- From: Gadi Evron [mailto:g...@linuxbox.org] Sent: Wednesday, April 28, 2010 11:51 PM To: NANOG Subject: [only half OT] A socio-psychological analysis of the first internetwar (Estonia) Hi, In the past year I have been working in collaboration with psychologists Robert Cialdini and Rosanna Guadagno on a paper analyzing some of what I saw from the social perspective in Estonia, when I wrote the post-mortem analysis for the 2007 attacks, but didn't understand at the time. Aside to botnets and and flood-based attacks, many of the attacks were live mobs, or an online riot if you like, where individuals simply sent pings toward Estonian addresses. While it doesn't seem like pings would cause so much damage -- en masse they certainly did. Then of course, there is also the psychological aspect... ... When everyone and their grandmother attacked with pings, spammers, professionals and others who know what they are doing then got involved, attacking using more sophisticated tools. We analyze how the Russian-speaking population online was manipulated to attack Estonia (and Georgia) in the cyber war incidents, and how it could happen again (regardless of if any actor is behind it). The psychological aspect of this is indeed off-topic to NANOG, but the attack is analogous to network peak usages with user interest in high-bandwidth content, and how large networks prepare for such peaks. This is about the DDoS attacks, and how a human DDoS has been and can be initiated again. It also under-scores the power of individual activism on the internet, and how it can also be abused. I hope some here would find the research useful for their own interest, if nothing else. Otherwise, sorry for wasting your bandwidth and thanks for your time. Article on El Reg: http://www.theregister.co.uk/2010/04/28/web_war_one_anonymity/ Paper (for download with pay :( ): http://www.liebertonline.com/doi/abs/10.1089/cyber.2009.0134 Thanks, and any comments appreciated. If on psychology, please do it off-list, though. Gadi. -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.com/
Re: Edu versus Speakeasy Speedtest
On 4/30/10 3:15 AM, Steve Bertrand wrote: Your observation is disturbingly bleak... do you have a recommendation? ...perhaps a site with good bandwidth and a cluster of iperf(1) boxes available? :) There are better tools than a simple iperf server: http://psps.perfsonar.net/toolkit/ There are many perfsonar sites to choose from in I2/NLR land. Most gigapops and I2 networks run at least one. The problem is the Faculty^Wusers are smart, but not experienced in networking, so they buy into the marketing and eye candy of the speed dials on the Speakeasy and assorted speed testing tool sites. They see low numbers and then are difficult to convince that the devil is in the details. (which is odd, because that's what they do as scientists.) They also typically don't see the spent on i2/nlr connections vs the $ spent on commodity internet connections. ;) Jeff
Re: Edu versus Speakeasy Speedtest
On 4/30/2010 8:49 AM, Jeff wrote: There are better tools than a simple iperf server: http://psps.perfsonar.net/toolkit/ There is also http://netalyzr.icsi.berkeley.edu/ which is an excellent connectivity check, although your mileage may vary with higher-speed bandwidth testing from it. Jeff
RE: [only half OT] A socio-psychological analysis of the firstinternet war (Estonia)
What is/isn't a war? Was US/Vietnam a war? It wasn't declared legally... do you take issue with using the word war due to the nature of the event, or is it simply a question of scale? From what I've read so far of this paper, the incident being called a war isn't central to the thesis. Search / replace war with incident and the discussion works fine. Your issue with the choice of words might be significant on some level, but you haven't refuted any of the conclusions. -Original Message- From: andrew.wallace [mailto:andrew.wall...@rocketmail.com] Sent: Thursday, April 29, 2010 5:26 PM To: nanog@nanog.org; g...@linuxbox.org Subject: Re: [only half OT] A socio-psychological analysis of the firstinternet war (Estonia) --- On Thu, 29/4/10, Gadi Evron g...@linuxbox.org wrote: A socio-psychological analysis of the first internet war (Estonia) There has been no cyber war yet. Estonia was not a cyber war. You've got it fundamentally wrong on the world stage infront of everyone. Andrew
x-small IPv4 ISPs going to IPv6
As a data point, there are currently 866* x-small IPv4 ISP organizations in the ARIN region. There are a total of 3,562* ISP organizations in the ARIN region (including IPv4 and IPv6). x-small IPv4 providers as such, constitute about 1/4 of the total ARIN ISP constituency. The maximum revenue impact of an IPv6 waiver for them (removing the $1,000 surcharge for IPv6 /32 pricing) would be $833,000 per year, increasing as the number of organizations affected by the waiver increased. This information is provided strictly as a data point and not in the interests of pushing the discussion in either direction. Owen *The data I used to produce these numbers comes from ARIN staff and is current as of earlier April 29, 2010. ARIN will be publishing the data to their statistics page in the next few days. Please don't blame staff for the publication delay. I asked for the numbers late last night and they have been extremely responsive in getting the data to me and have taken the additional initiative to publish it as quickly as they can within their process.
Weekly Routing Table Report
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-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 01 May, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 320010 Prefixes after maximum aggregation: 147697 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 155292 Total ASes present in the Internet Routing Table: 33885 Prefixes per ASN: 9.44 Origin-only ASes present in the Internet Routing Table: 29405 Origin ASes announcing only one prefix: 14332 Transit ASes present in the Internet Routing Table:4480 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 (36992) 22 Prefixes from unregistered ASNs in the Routing Table: 352 Unregistered ASNs in the Routing Table: 126 Number of 32-bit ASNs allocated by the RIRs:543 Prefixes from 32-bit ASNs in the Routing Table: 598 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:189 Number of addresses announced to Internet: 2235997952 Equivalent to 133 /8s, 70 /16s and 159 /24s Percentage of available address space announced: 60.3 Percentage of allocated address space announced: 66.3 Percentage of available address space allocated: 90.9 Percentage of address space in use by end-sites: 82.4 Total number of prefixes smaller than registry allocations: 153558 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:76646 Total APNIC prefixes after maximum aggregation: 26650 APNIC Deaggregation factor:2.88 Prefixes being announced from the APNIC address blocks: 73318 Unique aggregates announced from the APNIC address blocks:32160 APNIC Region origin ASes present in the Internet Routing Table:4017 APNIC Prefixes per ASN: 18.25 APNIC Region origin ASes announcing only one prefix: 1102 APNIC Region transit ASes present in the Internet Routing Table:627 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 511561792 Equivalent to 30 /8s, 125 /16s and 208 /24s Percentage of available APNIC address space announced: 76.2 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 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, 133/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, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:133880 Total ARIN prefixes after maximum aggregation:68916 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106725 Unique aggregates announced from the ARIN address blocks: 40693 ARIN Region origin ASes present in the Internet Routing Table:13659 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix:5267 ARIN Region transit ASes present in the Internet Routing Table:1351 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 726007328 Equivalent to 43 /8s, 69 /16s and 254 /24s Percentage of available ARIN address
Re: Connectivity to an IPv6-only site
On 4/26/2010 8:07 AM, Christopher Morrow wrote: On Mon, Apr 26, 2010 at 10:34 AM, Stephen Sprunkstep...@sprunk.org wrote: Don't forget the hotspot vendor that returns an address of 0.0.0.1 for every A query if you have previously done an query for the same name (and timed out). That's a fun one. so... aside from the every 3 months bitching on this list (and some on v6ops maybe) about these sorts of things, what's happening to tell/educate/warn/notice the hotspot-vendors that this sort of practice (along with 'everything is at 1.1.1.1!') is just a bad plan? How can users, even more advanced users, tell a hotspot vendor in a meaningful way that their 'solution' is broken? Years ago I talked to a startup's funders about the fact that they had made a design decision to build hardcoded unassigned /8s into a captive portal and mobility gateway. We didn't buy their product, they changed it, company folded. The most meaningful thing one can do is vote with your wallet. -chris
BGP Update Report
BGP Update Report Interval: 22-Apr-10 -to- 29-Apr-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS35805 29526 2.2% 47.9 -- UTG-AS United Telecom AS 2 - AS17672 21731 1.6% 835.8 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 3 - AS982919342 1.5% 21.6 -- BSNL-NIB National Internet Backbone 4 - AS201819175 1.5% 88.4 -- TENET-1 5 - AS30890 15316 1.2% 36.0 -- EVOLVA Evolva Telecom s.r.l. 6 - AS38494 14916 1.1%3729.0 -- BBGISA-AS-ID-AP PT. Bakrie Brothers, Tbk 7 - AS22300 14653 1.1%4884.3 -- WIKIA - Wikia, Inc. 8 - AS23700 13773 1.1% 31.4 -- BM-AS-ID PT. Broadband Multimedia, Tbk 9 - AS24560 13328 1.0% 15.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - AS845212561 1.0% 12.0 -- TEDATA TEDATA 11 - AS28477 11673 0.9%1297.0 -- Universidad Autonoma del Esstado de Morelos 12 - AS4795 9791 0.8% 40.1 -- INDOSATM2-ID INDOSATM2 ASN 13 - AS9498 9475 0.7% 13.9 -- BBIL-AP BHARTI Airtel Ltd. 14 - AS220478711 0.7% 40.5 -- VTR BANDA ANCHA S.A. 15 - AS7018 8662 0.7% 13.4 -- ATT-INTERNET4 - ATT WorldNet Services 16 - AS124798631 0.7% 454.3 -- UNI2-AS Uni2 - Lince telecomunicaciones 17 - AS260258454 0.6%8454.0 -- COC - City of Calgary 18 - AS165698355 0.6%8355.0 -- ASN-CITY-OF-CALGARY - City of Calgary 19 - AS256207362 0.6% 43.6 -- COTAS LTDA. 20 - AS369927033 0.5% 11.3 -- ETISALAT-MISR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS260258454 0.6%8454.0 -- COC - City of Calgary 2 - AS165698355 0.6%8355.0 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS505315707 0.4%5707.0 -- FAST-L-AS1 Limited Liabilily Company FastLine 4 - AS8588 5638 0.4%5638.0 -- JD_ABRA_EU-AS Abra S.A. 5 - AS491215530 0.4%5530.0 -- ACADEMY-AS PE Pavlovskaya Natalia Leonidovna 6 - AS22300 14653 1.1%4884.3 -- WIKIA - Wikia, Inc. 7 - AS38494 14916 1.1%3729.0 -- BBGISA-AS-ID-AP PT. Bakrie Brothers, Tbk 8 - AS487542223 0.2%2223.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 9 - AS191711657 0.1%1657.0 -- STARGATE-VAN - Stargate Connections Inc. 10 - AS28477 11673 0.9%1297.0 -- Universidad Autonoma del Esstado de Morelos 11 - AS8100 3814 0.3%1271.3 -- IPTELLIGENT - IPTelligent LLC 12 - AS9814 3223 0.2%1074.3 -- FIBRLINK Beijing FibrLINK Networks Co.,Ltd. 13 - AS303412064 0.2%1032.0 -- SCTA-ASN - South Central Telephone Association 14 - AS45670 900 0.1% 900.0 -- SOFTCRYLICNET1-IN #160,North Usman Road, Third Floor 15 - AS17672 21731 1.6% 835.8 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 16 - AS28671 760 0.1% 760.0 -- Konecta Telecomunicações Ltda 17 - AS28052 756 0.1% 756.0 -- Arte Radiotelevisivo Argentino 18 - AS265984079 0.3% 582.7 -- Its Brasil Tecnologia 19 - AS50139 576 0.0% 576.0 -- E-ARENA National association of research scientific and educational electronic infrastructures E-ARENA 20 - AS5429 559 0.0% 559.0 -- IIP-NET-AS5429 South Moscow Backbone Network TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.13.36.0/2411633 0.8% AS28477 -- Universidad Autonoma del Esstado de Morelos 2 - 208.98.231.0/248454 0.6% AS26025 -- COC - City of Calgary 3 - 208.98.230.0/248355 0.6% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - 216.83.57.0/24 7327 0.5% AS22300 -- WIKIA - Wikia, Inc. 5 - 216.83.58.0/24 7325 0.5% AS22300 -- WIKIA - Wikia, Inc. 6 - 193.232.102.0/23 5707 0.4% AS50531 -- FAST-L-AS1 Limited Liabilily Company FastLine 7 - 91.208.133.0/245638 0.4% AS8588 -- JD_ABRA_EU-AS Abra S.A. 8 - 91.212.142.0/245530 0.4% AS49121 -- ACADEMY-AS PE Pavlovskaya Natalia Leonidovna 9 - 219.148.144.0/20 5410 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 10 - 222.223.0.0/16 5410 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 11 - 222.222.0.0/16 5408 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 12 - 219.148.128.0/20 5406 0.4% AS17672 -- CHINATELECOM-HE-AS-AP asn for Hebei Provincial Net of CT 13 - 96.47.228.0/23 3806 0.3% AS8100 -- IPTELLIGENT - IPTelligent LLC 14 - 123.176.127.0/24 3745 0.3% AS38494 -- BBGISA-AS-ID-AP PT. Bakrie Brothers,
The Cidr Report
This report has been generated at Fri Apr 30 21:11:43 2010 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 PrefixesCIDR Agg
23-04-10321746 198312
24-04-10321566 198048
25-04-10321224 198152
26-04-10321310 198243
27-04-10321604 199156
28-04-10321906 199541
29-04-10322244 198768
30-04-10322501 198956
AS Summary
34286 Number of ASes in routing system
14600 Number of ASes announcing only one prefix
4427 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
97310816 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').
--- 30Apr10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 322774 198900 12387438.4% All ASes
AS6389 3976 298 367892.5% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4427 1383 304468.8% TWTC - tw telecom holdings,
inc.
AS4766 1847 494 135373.3% KIXS-AS-KR Korea Telecom
AS4755 1292 203 108984.3% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS22773 1148 76 107293.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS17488 1313 279 103478.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS7545 1176 235 94180.0% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS18566 1059 159 90085.0% COVAD - Covad Communications
Co.
AS6478 1212 334 87872.4% ATT-INTERNET3 - ATT WorldNet
Services
AS10620 1014 159 85584.3% Telmex Colombia S.A.
AS8151 1547 694 85355.1% Uninet S.A. de C.V.
AS19262 1091 248 84377.3% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS8452 1020 386 63462.2% TEDATA TEDATA
AS7303 719 112 60784.4% Telecom Argentina S.A.
AS1785 1785 1181 60433.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS24560 888 288 60067.6% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS28573 931 334 59764.1% NET Servicos de Comunicao S.A.
AS4804 678 84 59487.6% MPX-AS Microplex PTY LTD
AS4808 843 255 58869.8% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS17908 636 52 58491.8% TCISL Tata Communications
AS7018 1556 989 56736.4% ATT-INTERNET4 - ATT WorldNet
Services
AS18101 659 113 54682.9% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS5668 833 306 52763.3% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS3356 1214 703 51142.1% LEVEL3 Level 3 Communications
AS4780 670 172 49874.3% SEEDNET Digital United Inc.
AS17676 569 78 49186.3% GIGAINFRA Softbank BB Corp.
AS9443 555 74 48186.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS35805 617 146 47176.3% UTG-AS United Telecom AS
AS7011 1120 673 44739.9% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS7738 477 30 44793.7% Telecomunicacoes da Bahia S.A.
Total 36872105382633471.4% Top 30 total
Possible Bogus Routes
14.0.0.0/8
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
On Thu, 29 Apr 2010 08:22:47 -0700 Bill Stewart nonobvi...@gmail.com wrote: On Tue, Apr 27, 2010 at 3:24 PM, Owen DeLong o...@delong.com wrote: Here's an exercise. Wipe a PC. Put it on that cable modem with no firewall. Install XP on it. See if you can get any service packs installed before the box is infected. 1. Yes, I can. I simply didn't put an IPv4 address on it. ;-) 2. I wouldn't hold XP up as the gold standard of hosts here. One of my coworkers was IPv6ing his home network. He had to turn off the Windows firewall on the machine with the IPv6 tunnel for a couple of minutes to install some stubborn software. Then he had to reimage the box because it was pwned, and he's pretty sure that the infection came in over the IPv6 tunnel, not the hardware-firewalled IPv4. Your friend should learn about causation verses correlation http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation Every noticed how people who have car accidents got out of bed that morning? -- 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.
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
Paul, On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote: If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address. Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do). Regards, -drc
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
On Apr 30, 2010, at 6:26 PM, David Conrad wrote: Paul, On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote: If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address. Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt Ideally, in the vast majority of cases, resolv.conf is populated by dhcpv6 or it's successor. It is actually possible (although I agree questionable practice) to have your NS glue records updated dynamically. Firewalls and NMS can usually be done by copying the existing rulesets and doing a global SR on the affected prefix. It's not like a v4 renumbering. You'll still be dealing with a 1:1 replacement of the prefix and the suffixes don't need to change. IPv6 also has the convenient concept of preferred and valid lifetimes on addresses facilitating a convenient overlap period while both prefixes still work, but, new flows should be universally originated from the specified prefix. This makes it easier to identify hosts in need of manual intervention by monitoring for traffic sourced from the incorrect prefix. The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do). There is a non-zero cost associated with renumbering. However, it is much closer to zero than in IPv4. There is also a non-zero cost to NAT. Unfortunately, the costs of NAT are more on the toxic polluter basis, where you must pay your own tab for renumbering. As such, NAT in IPv6 will probably be as popular as SPAM is in IPv4, to about the same level of detriment. Owen
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
David Conrad wrote: Paul, On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote: If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address. Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do). Put your recursors, network management systems, fileservers, etc on ULA addresses like I was talking about earlier. Then you don't have to renumber those. So the only change you should have to make is a firewall change. Imagine a world with RFC-1918 and public ip space safely overlayed. For anything you hardcode somewhere, unless it has to be publically reachable, use ULA addresses and don't ever change them. You could even choose to not have public IP space on your servers by removing autoconf, though you could have public space on them so they can apply updates, and simply block any inbound access to those statefully with a firewall to prevent any outside risk. -Paul
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
Owen, On Apr 30, 2010, at 7:04 PM, Owen DeLong wrote: Ideally, in the vast majority of cases, resolv.conf is populated by dhcpv6 or it's successor. :-). I haven't been following the religious war against DHCPv6 -- is it now acceptable to get DNS information via DHCPv6? I note that MacOSX still doesn't appear to support DHCPv6. Does Win7? IPv6 also has the convenient concept of preferred and valid lifetimes on addresses facilitating a convenient overlap period while both prefixes still work, but, new flows should be universally originated from the specified prefix. I'm aware of this. It would be interesting to see how many applications actually take advantage of this (rant about the socket API model deleted). There is a non-zero cost associated with renumbering. However, it is much closer to zero than in IPv4. I agree that it can or at least has the promise to be. There is also a non-zero cost to NAT. Yes. Unfortunately, the costs of NAT are more on the toxic polluter basis, where you must pay your own tab for renumbering. End users must pay the cost of renumbering in both cases. With NAT, renumbering is done on the NAT box. Without NAT, renumbering must be done within the entire network. NAT can have an additional initial capital cost (although most CPE support NATv4 at no additional cost) and can have a potentially non-obvious additional opex cost associated with debugging network problems, application support, etc. In the end, it would be nice if it was a simple business decision. In reality, I suspect most folks getting IPv6 prefixes from their ISP will follow the same model they use with IPv4 because that's what they know and it works for them. Hopefully, we'll see. Regards, -drc
