Re: IRRD & exceptions to RPKI-filtering

[Geoff Huston]

> On 12 Feb 2024, at 6:01 pm, Richard Laager  wrote:
> 
> On 2024-02-12 15:18, Job Snijders via NANOG wrote:
>> On Mon, Feb 12, 2024 at 04:07:52PM -0500, Geoff Huston wrote:
>>> I was making an observation that the presentation material was
>>> referring to "RPKI-Invalid" while their implementation was using
>>> "ROA-Invalid" There is a difference between these two terms, as I'm
>>> sure you're aware.
> 
> I'm sure Job is aware, but I'm not. Anyone want to teach me the difference?

this is _my_ take:

If the crypto leads to a validation failure (expired certificates, signature 
mismatch in the 
validation chain, number resource extension mismatch in the validation path, or 
similar
then the X.509 certificate cannot be validated against a trust anchor and the 
object
(a ROA in this case) is "RPKI-Invalid". RPKI validators discard such objects 
from
consideration as they cannot convey any useful information.

"ROA-Invalid" starts with a route object, not a ROA, and compares the route
against the locally assembled collection of RPKI-valid ROAs. If it can find a 
RPKI-valid 
ROA that matches the route object then its "ROA-valid". If if can only find 
valid
RPKI objects that match the prefix part of e ROA, but not the origin AS, or its 
a
more specific prefix of a RPKI-valid ROA, then its "ROA-invalid". If no such 
match
is found, then the route is "ROA-unknown"

The distinction being made is:

"RPKI-invalid" refers to a crypto object and the ability of a local party (a 
"relying 
party") to confirm its crypto-validity against a locally selected trust anchor 
(or set of
trust anchors).

"ROA-invalid" refers to a route object and a collection of RPKI-valid ROAs
that have been assembled by an observer and refers to the outcome
of the observer testing this route against this locally assembled collection of 
ROAs.

Geoff

Re: IRRD & exceptions to RPKI-filtering

[Geoff Huston]

> On 12 Feb 2024, at 3:14 pm, Job Snijders via NANOG  wrote:
> 
> Dear all,
> 
> At NANOG 90, Merit presented on their IRRd v4 deployment. At the
> microphone Geoff Huston raised a comment which I interpreted as:
> 
>"Can an exception be made for my research prefixes?"
> 



no - I was making an observation that the presentation material was referring 
to 
"RPKI-Invalid" while their implementation was using "ROA-Invalid" There is a 
difference between these two terms, as I'm sure you're aware.

cheers,

Geoff

Re: maximum ipv4 bgp prefix length of /24 ?

[Geoff Huston]

> On 10 Oct 2023, at 5:35 am, Delong.com  wrote:
> 
>> Now I’m trying to understand what your grimmer story for IPv4 might be here 
>> Owen. Since 2005 the number of IPv4 FIB entries per origin AS has increased 
>> fropm 8 to 12 in the past 20 years - or a 50% increase. Over ther same 
>> period the number of IPv6  prefix advertisements per origin AS has increased 
>> from 1.5 to 6, or a fourfold increase. If anything, the IPv6 story appears 
>> to me to be a far greater cause for concern, but you may have a different 
>> interpretation of this data.
> 
> I admit I’m surprised that IPv6 has gotten to an average of 6, but it would 
> be interesting to know why that is. Honestly, I expected it would end up 
> closer to 4. I wonder how much of that is PI stub networks being originated 
> by upstream transit networks. I also wonder to what extent the “average” 
> might be misleading here. Is it a few ASs with large numbers of prefixes and 
> mostly 1-2 prefixes per AS or is the average representative?
> 
> I know that in IPv4, for example, there are several ASs originating MANY 
> prefixes and lots of smaller ASs originating <4 prefixes.
> 
> My grimmer picture for IPv4 is about the intrinsic pressure to deaggregate 
> that comes from the ever finer splitting of blocks in the transfer market and 
> the ever finer grained dense packing of hosts into prefixes that is forced 
> from address scarcity. Those pressures don’t (or at least shouldn’t) exist 
> for IPv6.
> 


The questions you ask Owen are obviously answerable by anyone with access to a 
BGP routing table dump (which is pretty much anyone!).

BGP is many things - it is a topology maintenance protocol, but its a traffic 
engineering protocol and an attack mitigation protocol. In the latter two cases 
advertising more specifics play a crucial role. The pressure to slice and dice 
in IPv4 is a mix of reachability in a space where address availability is under 
acute pressure, and TE and DOS mitigation. The pressures on IPv6 are 
predominately from the latter two categories. I suspect that as IPv6 becomes a 
larger part of the traffic mix (and inexorably that appears to be happening) 
then the TE and DOS issues become more of an operational concern, hence rising 
more specifics in IPv6. 

Re: maximum ipv4 bgp prefix length of /24 ?

[Geoff Huston]

> On 6 Oct 2023, at 6:13 am, Owen DeLong  wrote:
> 
> Ratio of FIB to RIB is only part of the equation.
> 
> IPv6 is NOT under the disaggregation pressure that IPv4 is under because 
> there is no pressure (other than perhaps scarcity mentality from those that 
> don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize 
> IPv6 allocations.
> 
> Look at the difference in prefixes per ASN across the two tables and that 
> tells a much grimmer story for IPv4 in terms of RIB growth vs. IPv6.


hmm - IPv4 is at [1], IPv6 is at [2]

Now I’m trying to understand what your grimmer story for IPv4 might be here 
Owen. Since 2005 the number of IPv4 FIB entries per origin AS has increased 
fropm 8 to 12 in the past 20 years - or a 50% increase. Over ther same period 
the number of IPv6  prefix advertisements per origin AS has increased from 1.5 
to 6, or a fourfold increase. If anything, the IPv6 story appears to me to be a 
far greater cause for concern, but you may have a different interpretation of 
this data.

Geoff



[1] 
https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2%2e0%2fbgp%2dentries%2das%2etxt=Average%20entries%20per%20origin%20AS=Average%20entries%20per%20origin%20AS=step@%82%966%88U

[2] 
https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2%2e0%2fbgp%2dentries%2das%2etxt=Average%20entries%20per%20origin%20AS=Average%20entries%20per%20origin%20AS=step

Re: AS3356 Announcing 2000::/12

[Geoff Huston]

> On 10 Dec 2022, at 11:24 am, Matthew Petach  wrote:
> 
> 
> 
> As I said--I'm probably being overly paranoid, but I can't help but 
> wonder what packets such a collector might see, if left to run for a 
> week or two... ^_^;
> 


A decade ago it looked like this…

https://www.potaroo.net/presentations/2012-05-15-ipv6-background-radiation.pdf

Geoff

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Geoff Huston]

> On 11 Oct 2022, at 4:23 am, Tobias Fiebig  
> wrote:
> 
> Heho,
> Let alone $all the /24 assigned under the RIPE waiting list policy.
> 
> In the Geoff Huston spirit, I quickly took a look how less specifics for /24s 
> looks in my table:
> 
[…]

> So it seems like there is a healthy amount (~260k) prefixes which lack a less 
> specific.


I also looked using a slightly different approach - namely looking for /24s 
where there was no spanning aggregate that matched the /24’s AS Path. In my 
local table there are 224,580 of them.


Geoff

Re: rsync and RPKI Validation

[Geoff Huston]

> On 9 Sep 2022, at 4:36 pm, Vincent Bernat  wrote:
> 
> On 2022-09-09 04:56, Matt Corallo wrote:
>> Has anyone done an analysis of the rsync CVE-2022-29154 (which "allows 
>> malicious remote servers to write arbitrary files inside the directories of 
>> connecting peers") and its potential impact on RPKI validators? It looks 
>> like both Debian [1] and Ubuntu [2] opted *not* to patch rsync in their 
>> release/security package streams.
>> Are rsync-based (or rsync-fallback, which I believe is still required for 
>> all RPKI validators?) RPKI validators all vulnerable to takeover from this, 
>> or is there some reason why this doesn't apply to RPKI validation?
> 
> The attacker is still limited to the target directory. The attacker can send 
> files that were excluded or not requested, but they still end up in the 
> target directory. RPKI validators download stuff in a dedicated download 
> directory (but it may be shared with several peers), so they should be safe.

If the topic is whether rsync is fit for purpose for the RPKI I’d like to 
reference a still relevant presentation from IETF 89: 
https://www.ietf.org/proceedings/89/slides/slides-89-sidr-6.pdf As far as I am 
aware the issues raised in this presentation remain current.

My takeaway from that presentation is that there is some simple advice about 
using rsync in the context of the RPKI cache sync operation: don’t.

thanks,

 Geoff

Re: Allegedly Tier 1s in Wikipedia

[Geoff Huston]

> On 1 Aug 2022, at 11:10 am, Tom Paseka via NANOG  wrote:
> 
> Paying for "peering", doesn't stop you being a tier-1. 
> 
> Being a Tier-1 means you are "transit free" (technical term, not commercial). 
> No one is transiting your routes to other Tier-1 providers. 
> 

There are a lot of potential interpretations of “Tier 1” and often folk use the 
one that benefits their own classification (obviously!). The one I think 
corresponds to the conventional interpretation is "I’m a Tier 1 because I have 
a SKA peering agreement with other Tier 1 networks and I pay no other network 
for transit or peering”, or more informally, “I’m a Tier 1 because I pay nobody 
and everyone pays me, except for my peers.”

I suspect that what goes on is “I’m a Tier 1 because I say so, and noone has 
contradicted me yet!" :-)

Geoff

Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)

[Geoff Huston]

> On 25 May 2022, at 5:45 am, Jakob Heitz (jheitz) via NANOG  
> wrote:
> 
> This attack will work very well until the victim starts advertising
> its prefix. The victim may not notice the fake advertisement because the fake
> advertisement will not reach the victim AS due to AS-path loop checking.


Often the best forms of attack are ones that are scoped in locality. 
Advertising the
same prefix from a different location in BGP may create a localised preference 
to follow the
synthesised route which is not visible everywhere. Sometimes this is exactly 
what the
attacker wants to achieve.

Geoff

Re: multihoming

[Geoff Huston]

> On 25 Nov 2021, at 7:57 am, Christopher Morrow  
> wrote:
> 
> Are you proposing SCTP? There is sadly not much more hope for widespread 
> adoption of that as of IPv6.
> 
> or perhaps MP-TCP? :)  or shim6?

Shim6 died a comprehensive death many yers ago. I recall NANOG played a role in 
it's untimely demise. :-)

Geoff

Re: S.Korea broadband firm sues Netflix after traffic surge

[Geoff Huston]

> On 11 Oct 2021, at 7:18 am, Mark Tinka  wrote:
> 
> 
> 
> On 10/10/21 22:10, Geoff Huston wrote:
> 
>> I have to agree with Doug Barton's earlier observation is that the base 
>> problem is that the ISPs are using a flawed business model and they don't 
>> want to charge their customers what it really costs to provide them with 
>> high speed access, nor do they want to fund additional back-end capacity in 
>> their network without some form of offset revenue stream.
> 
> I think ISP's do want to charge their customers what it actually costs to 
> provide them with a service, but they can't because many ISP's business 
> models are based purely on undercutting their nearest competitor.
> 
> I might be naive and hopeful to think that operators will have a blood 
> handshake to set prices where customers can't wag the tail.
> 

In many environments, the words we use to describe this form of price setting 
are generally prefixed by the adjective “illegal” :-)

Geoff

Re: S.Korea broadband firm sues Netflix after traffic surge

[Geoff Huston]

> On 11 Oct 2021, at 6:33 am, Matthew Petach  wrote:
> 
> […] Facebook, Microsoft, and Amazon all caved to SK's demands:
> 
> I will note that my $previous_employer was a top-10 web content provider 
> that did *not* pay SK Broadband.  Not all the content providers caved 
> to SKB.
> 


The situation in South Korea between content providers and broadband providers 
has a long history. Back in early 2012 Korea Telecom implemented a block on 
Samsung’s “smart TV” models because they had a streaming high def content 
service that KT claimed that was saturating their broadband network. According 
to KT, Samsung opted to take a "very negative response" to KT's actions. 
Samsung obtained a court injunction to lift KT's block on their TVs and an 
associated court order for KT and Samsung to enter into arbitration. At the 
same time Samsung filed a lawsuit against KT. In due course the temperature of 
the dispute abated and all the parties backed down. KT discontinued its block, 
and Samsung dropped its lawsuit. However, there was evidently some residual bad 
feeling here as Samsung expressed their desire for the national regulator to 
convey a "strict warning" to KT over its actions.

You have to wonder if the major difference some nine years later is that while 
Samsung is a Korean business, Netflix is a ‘foreign’ entity, and perhaps the 
broadband ISPs feel that the Korean legal actions in this round will have a 
different outcome and favour the local ISP enterprises over the foreign 
streamer.

I have to agree with Doug Barton's earlier observation is that the base problem 
is that the ISPs are using a flawed business model and they don't want to 
charge their customers what it really costs to provide them with high speed 
access, nor do they want to fund additional back-end capacity in their network 
without some form of offset revenue stream.

Geoff

Re: Question about Customer Population by ASN for Canada

[Geoff Huston]

> On 3 Oct 2017, at 7:17 am, Eric Dugas  wrote:
> 
> For some reason my previous email was empty.
> 
> What I wrote:
> 
> "Some of these numbers are largely inflated...
> 
> e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 users
> if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)?
> 
> Also, Allstream/Zayo AS15290 has a lot of IPs but it's mostly corps/govs.
> So it's a mix of inflated and false positives.

I wish there was better public data we could use here to generate these numbers.

But there is a dearth of such numbers that are vaguely current relatively 
inclusive
and not completely stupid.

So we use the ad placement mechanism as an indirect pointer to user count. Its 
very rough,
and at best one can say that there are large, medium and small eyeball 
networks, and
to a first order the algorithm appears to identify networks into these three 
categories.

I am not trying to tie in address density here - I’m not even sure that would 
be wise
because, as you well know, NATs hide all kinds of sins and virtues.

Geoff

Re: Question about Customer Population by ASN for Canada

[Geoff Huston]

> On 3 Oct 2017, at 6:57 am, Jacques Latour  wrote:
> 
> Hi all!
> 
> I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I 
> use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and 
> (https://stats.labs.apnic.net/ipv6/CA).
> 
> Labs.APNIC has a pretty cool system to measure this kind of stuff by 
> deploying specially crafted google ads, see "How Big is that Network?"  
> https://labs.apnic.net/?p=526, and APNIC is able to assess the population 
> behind a network based on ad placement distribution. See 
> https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.
> 
> The question I have is why does OVH come #6 with an estimated population of 
> 1,480,927 behind its ASN? Remember these are actual placement of ads.  Should 
> I count those users as part of my stats?
> 
> RankASN AS Name CC  Users (est.)% of country% of Internet 
>   Samples
> 1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc. 
> CA 5,420,034   16.72 
>   0.16555,718
> 2   AS577   BACOM - Bell Canada 
> CA 4,474,012   13.8  
>   0.132   458,722
> 3   AS6327  SHAW - Shaw Communications Inc. 
> CA 3,708,414   11.44 
>   0.109   380,225
> 4   AS852   ASN852 - TELUS Communications Inc.  
> CA 2,914,405   8.99  
>   0.086   298,815
> 5   AS5769  VIDEOTRON - Videotron Telecom Ltee  
> CA 2,189,946   6.76  
>   0.065   224,536
> 6   AS16276 OVH CA   
>   1,480,927   4.570.044   151,840
> 7   AS15290 ALLST-15290 - Allstream Corp.   
> CA 1,272,374   3.93  
>   0.038   130,457
> 8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications, Inc. 
> CA 1,211,485   3.74  
>   0.036   124,214
> 9   AS7992  COGECOWAVE - Cogeco Cable   
> CA 1,112,002   3.43  
>   0.033   114,014
> 10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc. 
> CA 967,401 2.980.029 
>   99,188
> 11  AS11260 EASTLINK-HSI - EastLink 
> CA 695,598 2.150.021 
>   71,320
> 12  AS47027 SEASIDE-COMM - Seaside Communications, Inc. 
> CA 425,561 1.310.013 
>   43,633
> 13  AS803   SASKTEL - Saskatchewan Telecommunications   
> CA 392,186 1.210.012 
>   40,211
> 14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.   
> CA 370,348 1.140.011 
>   37,972


Let me explain our system in a little more detail.

When we serve an ad we note the origin AS of the Ad. Now we assume (probably 
wrongly but we have no better data) that the ad’s are smeared evenly across the 
user population of each country. So we assume that the relative weight of ad 
placement within an AS is proportionate to the relative number of users in that 
same country. So if AS 131072 receives 50% of the Ads in a country then we 
assume that AS131072 holds one half of the number of users of the same country. 
Thats the first piece of data and the first assumption

The second assumption is that your government is not lying! That means that 
whatever stats your government lodged with the ITU-T relating to the number of 
Internet users in your country we believe. (and we actually use the world 
population data to update these numbers to represent the estimated user 
population today.)

Mashing the two togeether gives the table per country that you are citing here.

So your question is “:Why is Google delivering 4.57% of the ads in Canada into 
a network ASN that is the ASN registered against OVH”

OVH is an overlay network, but its certainly clear that it is used by a lot of 
folk and Google appear to find their users to be an attractive target to ad 
placement. So we get a high placement count of Ads coming from OVH and we 
geolocate those users to CA. Maybe there is a geolocation issue and IVH should 
not be CA. Of there really are a lot of eyeballs behind OVH in Canada.

regards,

   Geoff

Call For Presentations - DNS-OARC Workship 26, Madrid, 14-15 May 2017

[Geoff Huston]

[with apologies to those who see this on multiple lists]

Call For Presentations

The DNS-OARC 26th Workshop will take place in Madrid, Spain on May
14th and 15th 2017, the Sunday and Monday following the ICANN GDD
Industry Summit 2017.  The Workshop's Program Committee is now
requesting proposals for presentations.

This workshop intends to build from previous strong DNS-OARC workshops,
where both operational content and research are welcome. All DNS-related
subjects are welcome. If you are an OARC member, and have a sensitive
topic you would like to present for members-only, we will accommodate
those talks too. A timeslot will be available for lightning talks (5-10
minutes) on Monday May 15th, for which submissions will be accepted
during May 14th on a first-come first-served basis.

Workshop Milestones:

6th January 2017, Call for Presentations posted and open for submissions
24th February 2017, Deadline for submission
17th March 2017, Draft Programme published
14th April 2017, Final Program published
28th April 2017, Final deadline for slideset submission

Details for presentation submission will be published here:

https://indico.dns-oarc.net/event/26/call-for-abstracts/

The workshop presentations will be organized by common themes, depending
on the topics and the timing of each presentation. There are 30-minute
and 15-minute slots, let us know your preference in your submission.

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides.  Draft slides are acceptable on submission.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Ray Bellis, for the OARC Programme Committee

OARC depends on sponorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

Re: Do people even read these? Re: BGP Update Report

[Geoff Huston]

> On 19 Jun 2016, at 6:05 AM, Mikael Abrahamsson  wrote:
> 
> On Fri, 17 Jun 2016, cidr-rep...@potaroo.net wrote:
> 
>> 
>> TOP 20 Unstable Prefixes
>> Rank Prefix Upds % Origin AS -- AS Name
>> 1 - 202.65.32.0/2128086  0.8%   AS10131 -- CKTELECOM-CK-AP Telecom Cook 
>> Islands, CK
>> 2 - 110.170.17.0/24   21868  0.7%   AS134438 -- AIRAAIFUL-AS-AP Aira & Aiful 
>> Public Company Limited, TH
>> 3 - 123.231.192.0/24  21562  0.7%   AS133841 -- IDOLA-BROADBAND-AS-ID 
>> INDONESIA BROADBAND ACCESS - ANYWHERE, ID
>> 4 - 93.181.192.0/19   20895  0.6%   AS13118 -- ASN-YARTELECOM Verhnevolzhsky 
>> branch, RU
>> 5 - 123.231.206.0/24  19170  0.6%   AS133841 -- IDOLA-BROADBAND-AS-ID 
>> INDONESIA BROADBAND ACCESS - ANYWHERE, ID
>> 6 - 123.231.193.0/24  19082  0.6%   AS133841 -- IDOLA-BROADBAND-AS-ID 
>> INDONESIA BROADBAND ACCESS - ANYWHERE, ID
>> 7 - 195.128.159.0/24  15455  0.5%   AS56636 -- ASVEDARU , RU
>> 8 - 192.254.88.0/24   15452  0.5%   AS21859 -- ZNET - Zenlayer Inc, US
>> 9 - 185.11.121.0/24   14957  0.5%   AS202105 -- DSP-AS , SA
> 
> Everyone of these prefixes have managed to average one update per 40 seconds 
> during a week, or worse. How is that even possible? Yes, I know we don't 
> generally have dampening anymore, but geez, that's a lot of updates.
> 

In the case of Cook Islands Telecom the problem is not directly with them - its 
their one-up upstream Spark NZ (AS4648) who appears to be flicking this route 
across a number of transit upstreams 
(http://bgpupdates.potaroo.net/cgi-bin/per-prefix?prefix=202.65.32.0.21)

Geoff

Re: ASN to IP Mapping

[Geoff Huston]

 On 8 Mar 2015, at 6:35 pm, Hank Nussbacher h...@efes.iucc.ac.il wrote:
 
 At 14:37 08/03/2015 +1100, Geoff Huston wrote:
 
  On 8 Mar 2015, at 1:39 pm, Randy Bush ra...@psg.com wrote:
 
  If you want to know the registry assignments / allocations made to a
  single entity and be able group together these assignments of address
  prefixes and ASNs you should retrieve the combined extended stats file
  from the RIRs
  (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended)
  and group together all those entries with a common value in column 8
  (except for the entries corresponding to assignments and allocations
  made by the RIPE NCC, where this information is, unfortunately, not
  published by them in such a convenient format.)
 
  care to give a decode for the fields in that file?  :)
 
 
 sure, I'll try.
 
 Or:
 https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt


Users of this report should be aware that there are some subtle deviations from 
this spec in the published data:
 - the RIPE NCC uses the non-ISO 3166 2 letter code 'EU' for some allocations. 
I do not know exactly why;
 - the date field is not quite as described in that file for ARIN entries. 
Again, I do not know why.
 - the RIPE NCC does not provide the opaque-id in their records

Re: ASN to IP Mapping

[Geoff Huston]

 
 Is there a tool or method to determine IP blocks assigned to an
 organization by ASN?  I.e. if I have an organization's ASN number I want to
 know all blocks assigned to that ASN.
 
 

If you want to know the registry assignments / allocations made to a single 
entity and be able group together these assignments of address prefixes and 
ASNs you should retrieve the combined extended stats file from the RIRs  
(https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended) and 
group together all those entries with a common value in column 8 (except for 
the entries corresponding to assignments and allocations made by the RIPE NCC, 
where this information is, unfortunately, not published by them in such a 
convenient format.)

Geoff

 

Re: ASN to IP Mapping

[Geoff Huston]

 On 8 Mar 2015, at 1:39 pm, Randy Bush ra...@psg.com wrote:
 
 If you want to know the registry assignments / allocations made to a
 single entity and be able group together these assignments of address
 prefixes and ASNs you should retrieve the combined extended stats file
 from the RIRs
 (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended)
 and group together all those entries with a common value in column 8
 (except for the entries corresponding to assignments and allocations
 made by the RIPE NCC, where this information is, unfortunately, not
 published by them in such a convenient format.)
 
 care to give a decode for the fields in that file?  :)


sure, I'll try.

for example:
   arin|US|asn|32|1|19840924|assigned|658cc9c515b51665f88b7fd1bc213d20|e-stats

Col 1 - RIR name, or 'iana'
Col 2 - The country where the entity 'resides' (or 'EU' in some cases), or 'ZZ' 
for reserved and unassigned blocks
Col 3 - 'asn' or 'ipv4' or 'ipv6'
Col 4 - The size of the allocation (asn or IPv4) or the prefix length (ipv6)
Col 5 - The starting value of the block
Col 6 - A date. For some registries this is the date of the original allocation 
- for others (ARIN) its not so clear precisely what this date signifies (!)
Col 7 - Status of the block
Col 8 - A hash field of the entity code (mu;ltiple allocations to the same 
entity have the same code) or null (RIPE NCC, IANA)
Col 9 - The source of the record (either e-stats' where the original source is 
an extended stats file published by an RIR, or 'iana' if the data is lifted 
from an IANA registry)

Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today

[Geoff Huston]

On 14 Aug 2014, at 4:14 am, Paul Ferguson fergdawgs...@mykolab.com wrote:

 
 On 8/13/14 8:55 AM, Paul Ferguson wrote:
 Apologies for replying to my own post, but... below:
 
 On 8/13/2014 7:05 AM, Paul Ferguson wrote:
 
 
 p.s. I recall some IPv6 prefix growth routing projections by
 Vince Fuller and Tony Li from several years ago which
 illustrated this, but cannot find a reference at the
 moment
 


I shared some speculation on the next five years of routing table growth at 
NANOG 60.

BGP routing table growth has been remarkably stable for many years, and most of 
the older predictive exercises have proved to be reasonably accurate.  with all 
the usual caveats applying to a post-V4-exhaustion world having a lot more 
uncertainties than before the current figures show that the default free zone 
in IPv4 will hit 1 million entires in 2019 
(http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf. slide 30).

IPv6 is a much less certain exercise. If we take the most extreme picture of of 
the recent past and apply en exponential growth model to the IPv6 network, then 
the V6 table gets to 125,000 entries by the same 2019. (slide 34 of the same 
pack)

Frankly, these figures are not particularly alarming at present. Yes, we've 
crossed over some equipment thresholds in the past (TCAM banks of 256K entires, 
now 512K and at some point its looking possible that we'll get to 1M entries. 
If yesterday is a lot like tomorrow then this is some 4 years out for the 
global routing table if we add the IPv4 and IPv6 tables together.

If I were buying equipment today I'd want a minimum of 2M entries in the TCAM 
on the forwarding cards, and I'd also want to understand my options for field 
upgrades to at least 4M over the anticipated operational lifecycle of the 
equipment. But you may have a different crystal ball of course.

Geoff

Re: IPv6 at 50% for VZW (Re: NAT IP and Google)

[Geoff Huston]

On 23 May 2014, at 3:29 pm, Christopher Morrow morrowc.li...@gmail.com wrote:

 On Fri, May 23, 2014 at 1:24 AM, Julien Goodwin na...@studio442.com.au 
 wrote:
 On 23/05/14 11:21, Jared Mauch wrote:
 You can't cater to everyones broken network.  I can't reach 1.1.1.1 from 
 here either, but sometimes when I travel I can, even with TTL=1.  At some 
 point folks have to fix what's broken.
 
 1.1.1.1 is not private IP space.
 
 BGP routing table entry for 1.1.1.0/24
 Paths: (2 available, best #1)
  15169
  AS-path translation: { Google }
edge5.Amsterdam1 (metric 20040)
  Origin IGP, metric 10, localpref 86, valid, internal, best
  Community: Europe  Lclprf_86 Netherlands Level3_Peer Amsterdam
  Originator: edge5.Amsterdam1
  15169
  AS-path translation: { Google }
edge5.Amsterdam1 (metric 20040)
  Origin IGP, metric 10, localpref 86, valid, internal
  Community: Europe  Lclprf_86 Netherlands Level3_Peer Amsterdam
  Originator: edge5.Amsterdam1
 
 (Yes ok, it doesn't respond to any packets last I checked)
 
 coughsome times it does/cough
 (some portion of the space does/service replies to a sample of packets...)
 
 Geoff should have more info on the progress of his experiment though.


Some time back I did try responding to TCP SYNs with SYN ACKs, to see where it 
went. But
it massively increased load and I gave up. So if 1.1.1.1 responds to you 
its NOT me!

  Geoff

Re: We hit half-million: The Cidr Report

[Geoff Huston]

On 29 Apr 2014, at 12:39 pm, valdis.kletni...@vt.edu wrote:

 On Mon, 28 Apr 2014 21:59:43 -0400, Patrick W. Gilmore said:
 On Apr 28, 2014, at 19:41, Chris Boyd cb...@gizmopartners.com wrote:
 I'm in the middle of a physical move.  I promise I'll take the 3 deagg'd
 /24s out as soon as I can.
 Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table
 would drop precipitously. We all have to do our part.
 
 Do we have a handle on what percent of the de-aggrs are legitimate attempts
 at TE, and what percent are just whoopsies that should be re-aggregated?
 

I made a shot at such a number in a presentation to NANOG in Feb this year
(http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf)


If you assume that Traffic Engineering more specifics share a common origin AS 
with the
covering aggregate, then around 26% of more specifics are TE advertisements. 
This 
number (as a percentage) has gwon by 5% over the past three years


If you assume that Hole Punching more specifics are more specifics that use a 
different
origin AS, then these account for 30% of the more specifics in today's routing 
table.
This number has fallen by 5% over the past three years.

The remainder of the prefixes (45%) shares the same origin AS and the same path.
The could be TE prefixes, but as they are identical to their covering
aggregate its hard to appreciate exactly what the engineering intent may be. I 
could
make a wild guess and call these 45% of more specifics to be an act of 
senseless routing
vandalism. ( :-) ) This number has been steady as a % for the past three years.

Interestingly, it's the hole punching more specifics that are less stable, and 
the
senseless routing vandalism more specifics that are more stable than the 
average.

thanks,
   Geoff

Re: The Cidr Report

[Geoff Huston]

On 27 Apr 2014, at 5:19 am, Deepak Jain dee...@ai.net wrote:

 
 Historic event - 500K prefixes on the Internet.
 
 And now we wait for everything to fall over at 512k ;)
 
 Based on a quick plot graph on the CIDR report, it looks like we are adding 
 6,000 prefixes a month, or thereabouts. So platforms that break at 512K die 
 in two months or less?  Sup720s may need to be reconfigured/rebooted, etc.
 
 Does anyone have doomsday plots of IPv6 prefixes? We are already at something 
 like 20,000 prefixes there, and a surprising number of deaggregates (like 
 /64s) in the global table. IIRC, a bunch of platforms will fall over at 
 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack).
 
 
 

Check out pages 30 and 34 of 
http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf - a presentation I 
gave on predictions of BGP table size at NANOG 60 in February of this year.

Geoff

Re: 32-bit ASN acceptance by ISPs in ARIN region

[Geoff Huston]

On 23/09/2013, at 8:01 PM, Nick Hilliard n...@foobar.org wrote:

 On 23/09/2013 00:15, John Curran wrote:
 Not being able to use 32-bit ASNs in your network and support systems will  
 inevitably lead to confusion for those customers who are assigned them.
 
 I look forward to the day when we have proper 32 bit BGP community support
 and ASN32s finally become usable on nontrivial networks.
 

Is there some reference that describes the problems with the use of RFC5668? I 
was not aware
that there were residual issues here.


regards,

   Geoff

Re: 32-bit ASN acceptance by ISPs in ARIN region

[Geoff Huston]

On 24/09/2013, at 12:02 AM, Job Snijders job.snijd...@atrato.com wrote:

 On Mon, Sep 23, 2013 at 11:28:58PM +1000, Geoff Huston wrote:
 
 On 23/09/2013, at 8:01 PM, Nick Hilliard n...@foobar.org wrote:
 
 I look forward to the day when we have proper 32 bit BGP community
 support and ASN32s finally become usable on nontrivial networks.
 
 
 Is there some reference that describes the problems with the use of
 RFC5668? I was not aware that there were residual issues here.
 
 It would've been really nice if one could fit more than 16 bit in the
 locally administrated part. 
 
 Kind regards,
 
 Job


I'm sorry, but I'm still confused, as I see your comment as one that relates to 
the
size of the payload field here, as distinct from the support for 32 bit AS 
numbers
per se.


   Geoff

Re: Practical effects of DNSSEC deployment

[Geoff Huston]

Hi Steve,

 There was an interesting paper at Usenix Security on the effects of deploying 
 DNSSEC; see 
 https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact-dnssec-deployment
  .  The difference in geographical impact was quite striking.
 

George Michaelson and I have been undertaking similar work in DNSSEC, using an 
advertisement to enrol users' browsers to perform a set of URL loads that tests 
their ability to perform DNSSEC validation. Our methodology differed from that 
in the Usenix paper - we worked hard at setting up name structures that 
eliminated any benefits from DNS caching as well as web caching. We presented 
on this work at the IEPG meeting at IETF 87 a couple of weeks ago.

The bottom line: around 8% of clients across the Internet will perform DNSSEC 
validation - i.e. they are seen to fetch the DS and DNSKEY RRs for the signed 
objects, and will fetch the object that is correctly signed, and will not fetch 
the object that is badly signed. A further 4% of clients appears to use a set 
of resolvers where there is a mix of validating resolvers and non-validating 
resolvers. What we see is that the client's resolver will perform a set of 
fetches of the DS and DNSKEY records for the badly signed onject, then ask for 
the A record a second time (generally using a different resolver) and then 
fetch the object anyway - i.e. the original SERV FAIL response causes the 
client to turn to another resolver in its list, and use that result. 87% of 
clients only ask for A records - no signs of DNSSEC life for them.

We did some basic mapping of client to country (there is a LOT of DNSSEC 
validation in Sweden!) and network service provider bu origin AS, and also 
looked at the performance implications, both if you serve a zone thats signed, 
and if you serve a zone that is signed badly.

The presentation is at http://www.iepg.org/2013-07-ietf87/2013-07-28-dnssec.pdf 
if you are interested.


  Geoff

Re: IP allocations / bogon - ARIN Inconsistency

[Geoff Huston]

On 04/08/2013, at 2:06 PM, Rob Mosher rmos...@he.net wrote:

 Frank,
 
 HE uses the extended files for these stats since the standard ones will soon 
 be deprecated.  As Rene pointed out, the extended and standard delegation 
 files from ARIN do not match for this prefix. I do not know why there is 
 inconsistent data between the two, but this is something that ARIN should 
 look into.  

I have been lead to understand that, for ARIN, the extended stats file reflects 
the registry state at a slightly different time (earlier by ~1 day) than the 
standard stats file. This is a likely explanation of the observed 
inconsistency.

Geoff

Re: It's the end of the world as we know it -- REM

[Geoff Huston]

On 26/04/2013, at 4:27 PM, joel jaeggli joe...@bogus.com wrote:

 
 I also find it a bit strange that the runout in APNIC and RIPE was very 
 different. APNIC address allocation rate accelerated at the end, whereas 
 RIPE exhaustion date kept creeping forward in time instead of closer in 
 time, giving me the impression that there wasn't any panic there.
 
 apnic allocation reserved  the final /8 for /22 maximal allocations. Couple 
 that with some qualifying very large assignments towards the end of stage two 
 e.g between feb 1 and april 14 2011 7 provider assignments combined soaked up 
 more than 2 /8s and you get rapid runout towards the endgame.
 


APNIC used a 12 month allocation window right up to the point of exhaustion, 
while RIPE was operating on a 3 month window, as is ARIN. That may be a 
contributing factor in explaining the differences in behaviour in the final 
months / weeks.

But its not just that. 

Other factors include large developing countries with massive DSL deployments 
underway (China, India) mean that in the APNIC region we were not looking at a 
wired infrastructure market sector that was already saturated. Quite the 
opposite. Similarly the wireless market in Asia was / is expanding rapidly for 
much the same reason (wireless is cheaper to deploy than wired if you have 
absolutely no pre-installed wireless infrastructure). i.e. the unmet demand 
overhang as compared to the available address pools was massive in Asia. Now 
that does not imply that Europe and the Middle East has no demand overhang, but 
perhaps not on the same scale as was experienced by APNIC in early 2011.

Also in September last year the European financial situation was still 
impacting on the problems of the service industry (and still is in many 
countries). So the underlying capital-driven demand factors were different 
between Europe and Asia. Perhaps it was more challenging for European entities 
to demonstrate an expansion of their Internet service infrastructure over 
rolling 3 months windows due to a slow down in consumer demand in parts of 
Europe.

What factors will play out in the North American market? It might be 
interesting to look at address allocations by country by year. One such table 
of the top 10 countries in terms of IPv4 allocations since 2007 is at 
http://www.potaroo.net/ispcol/2013-01/2012.html, table 3.The peak US year was 
2007 with 48M addresses. in 2011 ARIN introduced the 3 month allocation window, 
and allocating that year halved from the previous year. Last year they were a 
little higher at 28M addresses. What drove last year's numbers in ARIN was a 
total of 16M addresses allocated to Canadian entities. So to what extent is 
this a saturated market already in terms of the deployment of service 
infrastructure? To what extent are new devices simply replacing old, and to 
what extent are the dynamics of the market in that region driven by provider 
churn as distinct from greenfields expansion? Obviously the answers to such 
questions have a strong impact on the underlying model of overall demand for 
more addresses in the region.

And of course one of the hardest factors of all: Panic is extremely difficult 
to model. Most forms of predictive modelling reach back in time and then use 
that date to push forward. but panic is of course different. It does not drive 
off past behaviour but feeds off itself. The APNIC runout was exceptionally 
hard to model at the time because the incidence of large allocations rose very 
quickly in March. Yes, I'd ascribe that to panic. That reaction was not so 
evident in RIPE in August / September last year. So it appears that panic, or 
the level of panic, is not a constant factor. Different regions at different 
times appear to elicit different responses to impending exhaustion.


Geoff

Re: It's the end of the world as we know it -- REM

[Geoff Huston]

On 24/04/2013, at 8:10 AM, Andrew Latham lath...@gmail.com wrote:

 On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks
 valdis.kletni...@vt.edu wrote:
 I didn't see any mention of this Tony Hain paper:
 
 http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
 
 ARIN predicted to run out of IP space to allocate in August this year.
 
 Are you ready?
 

The prediction of runout business is extremely hard. All of these predictions 
are based on the basic premise that what happened yesterday will most likely 
happen tomorrow. And in a world of very large populations this is highly likely 
- the larger the population its often the case that the smaller the impact of 
individual variations in behaviour. That means that once you get a very large 
population you'd expect a relatively low level of uncertainty in trend-based 
predictive models.

But the world of addresses is not so well behaved. For some years now we've 
seen the address world bifurcate into a small number of very large actors and a 
large number of much smaller actors. In the address world it was observed that 
less than 1% (its closer to around 0.5%)  individual allocations account for 
more than half of the number of allocated addresses. This becomes a problem in 
the predictive models, as the dominant factor in address consumption is now the 
actions of some 20 or so very large entities. If they all fronted at the 
registry's front doors and asked for a three month allocation, and do so again 
in 90 days, and so on, then its pretty obvious that ARIN's remaining 40M 
addresses would not last more than one or two iterations of this cycle.

But what has been apparent in the ARIN region since the IANA runout of February 
2011 has not been panic, but restraint. If you look at the run-down' of the 
address pool in ARIN over time 
(http://www.potaroo.net/tools/ipv4/arin-pool.png), you could certainly make the 
case that there was a pronounced run on address resources in ARIN in the last 
quarter of 2010, but it all changed in 2011. The ensuing 14 months following 
IANA runout, through 2011 and early 2012, saw a pronounced change in the 
region, and ARIN's address consumption in that period slowed down to a 
consumption rate that got as low as 1M addresses per month. This coincided in a 
change in the address allocation policy to reduce the time horizon of 
demonstrated need from 12 months to 3 months, but that factor alone would not 
account for the entirety of this slow down in the address consumption rates 
over this 14 month period. 

Following a single largish allocation in early 2012 we've seen the ARIN address 
consumption rate increase somewhat, and the average rate of address consumption 
is currently around 2M addresses per month. If this rate of address consumption 
continues, the ARIN will reach its last /8 in early 2014, and if this rate 
persists, then the registry will exhaust its pool around the end of that year, 
or early 2015.

But given the uncertainty factors here as they relate to the distribution of 
large and small consumers in this area and changing sentiment about whether or 
not panic is a factor in address demands, I'd have to comment that the 
uncertainty factor of any prediction is high. Its quite plausible that 
exhaustion could occur some 6 - 9 months earlier than these dates. 

However, personally I find it a little hard to place a high probability on 
Tony's projected exhaustion date of August this year. I also have to qualify 
that by noting that while I think that a runout of the remaining 40 M addresses 
within 4 months is improbable, its by no means impossible. If we saw a re-run 
of the address consumption rates that ARIN experienced in 2010, then it's not 
outside the bounds of plausibility that ARIN will be handing out its last 
address later this year. 

thanks,

Geoff

Re: It's the end of the world as we know it -- REM

[Geoff Huston]

On 24/04/2013, at 6:55 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:

 I also find it a bit strange that the runout in APNIC and RIPE was very 
 different. APNIC address allocation rate accelerated at the end, whereas RIPE 
 exhaustion date kept creeping forward in time instead of closer in time, 
 giving me the impression that there wasn't any panic there.
 
 Has anyone done any detailed analysis of the last year of allocation 
 behaviour for each of these regions, trying to understand the difference in 
 behaviour? I'd be very interested in this.
 
 My belief (not well founded) is that ARIN runout will look more like RIPE 
 region than APNIC...
 

I suspect that the extent of communication of expectations, the economic 
climate, the prevailing allocation window at the time (RIPE was working on 3 
months whereas APNIC still had the 12 month window in place right up to the 
last /8) all play a part in such things. 

The fast/slow nature of ARIN's address consumption profile over the last 30 
months is certainly a new factor here - again there is likely to be some 
interplay between economics, the saturation of the wired market in that region, 
and the  existing CGN deployments in some (much) of the mobile IPv4 space in 
North America which also give some credibility to a prediction of a more 
measured approach to exhaustion rather than a massive paniced run on what's 
left.

But then again APNIC and RIPE NCC both had last /8 policies in place, which has 
mitigated some of the impacts of address pool exhaustion. For smaller actors 
there is still a source of addresses in these regions, albeit a very limited 
trickle of addresses, but there is still some.  As I understand it, ARIN will 
continue allocating right to the end of their IPv4 address pool and not hold 
back any addresses for this last chance trickle feed, or have I missed 
something crucial in ARIN's policy handbook?


Geoff

Re: Big day for IPv6 - 1% native penetration

[Geoff Huston]

On 21/11/2012, at 3:05 AM, Patrick W. Gilmore patr...@ianai.net wrote:

 On Nov 20, 2012, at 08:45 , Owen DeLong o...@delong.com wrote:
 
 It is entirely possible that Google's numbers are artificially low for a 
 number
 of reasons.
 
 AMS-IX publishes stats too:
   https://stats.ams-ix.net/sflow/
 
 This is probably a better view of overall percentage on the Internet than a 
 specific company's content.  It shows order of 0.5%.
 
 Why do you think Google's numbers are lower than the real total?

It depends on what you are trying to measure and how you are measuring it.

I don't know Google's methodology, but lets say its a simple form of the 
experiment:

When presented with a dual stack object what percentage of users prefer to 
retrieve that object using IPv6 as compared to IPv4?

Up so a year or so ago if a browser had access to IPv6 and IPv4 it would first 
attempt to connect using IPv6 and if the connection failed then it timed out 
and then tried to use IPv4. So the experiment would be roughly commensurate 
with measuring working IPv6 systems on end sites connected to workin ipv6 
access networks of one sort or another.

More recently some browsers (Safari on Mac OSX, Chrome, Firefox with config 
settings enabled) have adopted a different strategy and when presented with a 
dual stack object some clients  may end up trying the connection using IPv4 
first and then fall back to IPv6 if IPv4 fails or times out. If the experiment 
simply counts the percent of clients who prefer to connect using IPv6 in a Dual 
Stack scenario, then some of these users running more recent versions of the 
browser will not be counted.

There are ways to compensate for this, including running a series of tests, and 
this form of approach is described at http://labs.apnic.net/measureipv6/

I personally have no knowledge if the numbers published by Google reflect the 
prefers to use IPv6 in dual stack mode or is capable of using IPv6 (by 
virtue of being able to retrieve a IPv6 only object) These days the second 
number is larger than the first.

Geoff

Re: [routing-wg] The Cidr Report

[Geoff Huston]

Re: Weekly Routing Table Report

[Geoff Huston]

On 21/07/2012, at 6:40 AM, Jared Mauch wrote:

 
 On Jul 20, 2012, at 4:30 PM, Ron Broersma wrote:
 
 
 On Jul 20, 2012, at 1:04 PM, valdis.kletni...@vt.edu wrote:
 On Sat, 21 Jul 2012 05:10:41 +1000, Routing Analysis Role Account said:
 BGP routing table entries examined:  418048
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)
 
 We added memory where we could, or bought bigger routers.  The new 
 (conventional wisdom) limit is 1M routes.
 
 I think you mean 512k IPv4 with 256k of IPv6 (taking double space).

512K of IPv4? That's getting close!

Geoff

IPv6 dark traffic collection restarted

[Geoff Huston]

Hi,

In 2010, and again in 2011, I ran an experiment to examine the dark traffic 
in IPv6. I did this by announcing the superblock 2400::/12 which has been 
allocated to APNIC for its IPv6 allocations. The superblock announcement is an 
aggregate and will not disrupt any IPv6 traffic - the packets that will head to 
this dark traffic collector were on their way to /dev/null in any case.

We are about to run this experiment up again to collect a 2012 data profile for 
IPv6 dark traffic in 2012. Accordingly, 2400::/12 will be announced by AS3562 - 
please don't filter it! IPv6 packets are scarce enough already! :-)

This time around we are being assisted by Sandia National Laboratories and 
ESnet, for which APNIC would like to acknowledge their assistance in this 
ongoing research activity.

Some URLs:
  - ESnet news item is at: 
http://www.es.net/services/ipv6-network/esnet-supports-sandia-and-apnic-ipv6-background-radiation-research/
  - LOA for the announcement: http://www.sandia.gov/apnic/authorization.pdf
  - Previous re[port: http://www.potaroo.net/ispcol/2010-07/dark6.pdf

thanks,

   Geoff

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Geoff Huston]

On 14/03/2012, at 9:16 AM, Randy Bush wrote:

 Yes, the economics of routing are strange, and the lack of any real
 strictures in the routing tables are testament to the observation that
 despite more than two decades of tossing the idea around we've yet to
 find the equivalent of a route deaggregation tax or a route
 advertisement tax or any other mechanism that effectively turns the
 routing space into a form of market that imposes some economic
 constraints on the activity.
 
 among other things, i suspect that the shadow of telco settlements makes
 us shy away from this.

Agreed. It's all ugly!

The shadow of telco settlement nonsense, the entire issue of route pull vs 
route push, and the spectre of any such payments morphing into a coerced
money flow towards to the so-called tier 1 networks all make this untenable. 

The topic has been coming up pretty regularly every 2  years since 
about 1994 to my knowledge, and probably earlier, and has never managed
to get anywhere useful.

 Geoff

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Geoff Huston]

On 13/03/2012, at 2:31 AM, Leo Bicknell wrote:

 In a message written on Mon, Mar 12, 2012 at 11:07:54AM -0400, Robert E. 
 Seastrom wrote:
 Grass-roots, bottom-up policy process
 +
 Need for multihoming
 +
 Got tired of waiting
 =
 IPv6 PI
 
 I'll also add that Shim6 folks never made a good economic argument.
 It's true that having routes in the DFZ costs money, and that
 reducing the number of routes will save the industry money in router
 upgrades and such to handle more routes.  However, it's also true
 that deploying SHIM6 (or similar solutions) also has a cost in
 rewritten software, traning for network engineers and administrators,
 and so on.
 
 It was never clear to me that even if it worked 100% as advertised that
 it would be cheaper / better in the global sense.
 

I think that's asking too much of the IETF Leo - Shim6 went through much the
same process as most of the IETF work these days: bubble of thought, BOF sanity
check, requirements work, protocol prototyping, technology specification.

Yes, the economics of routing are strange, and the lack of any real strictures
in the routing tables are testament to the observation that despite more than
two decades of tossing the idea around we've yet to find the equivalent of a 
route deaggregation tax or a route advertisement tax  or any other mechanism
that effectively turns the routing space into a form of market that imposes
some economic constraints on the activity. So after so long looking for such
a framework in routing, the hope that someday we will figure it out
gets smaller and smaller every day.

And in some ways the routing explosion problem is one of fear rather than 
actuality - the growth rates of the IPv4 routing table have been sitting at
around 8% - 15% p.a. for many years. oWhile you can't route the Internet on 
15 year old hardware, the growth figures are still low enough under Moore's 
Law that the unit cost of routing is not escalating at levels that are
notably higher than other cost elements for an ISP. Its not the routing
table explosion that will cause you to raise your fees or worse, go 
bankrupt tomorrow.

So in some ways for Shim6 to have a good economic argument I suspect
that Shim6 would have to have pulled out of thin air an approach that
completely externalised the cost of routing, and made routing completely
free for ISPs. And that is simply fantasy land!

Geoff


 

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Geoff Huston]

On 13/03/2012, at 8:14 AM, Iljitsch van Beijnum wrote:

 On 12 Mar 2012, at 21:15 , William Herrin wrote:
 
 Not at all. You just build a second tier to the routing system.
 
 It's so strange how people think a locator/identifier split will solve the 
 scalability problem. We already have two tiers: DNS names and IP addresses. 
 So that didn't solve anything. I don't see any reason a second second tier 
 would.

I think you have encountered an article of faith Iljitsch :-)

http://en.wikipedia.org/wiki/Indirectio:  Any problem can be solved by 
adding another layer of indirection.

Re: do not filter your customers

[Geoff Huston]

On 25/02/2012, at 7:54 AM, Christopher Morrow wrote:

 On Fri, Feb 24, 2012 at 3:04 PM, Shane Amante sh...@castlepoint.net wrote:
 
 Solving for route leaks is /the/ killer app for BGPSEC.  I can't 
 understand why people keep ignoring this.
 
 I don't think anyone's ignoring the problem... I think lots of people
 have said an equivalent of:
 1) How do I know that this path: A - B - C - D
  is a 'leak'?
 

If you are receiving  a path of the form (A B C D), and the origination of the 
prefix at D is good, then the only way you can figure out this is a leak as 
compare to the intentional operation of BGP is not by looking at the operation 
of protocol per se, but by looking at the routing policy intentions of A, B, C 
and D and working out if what you are seeing is intentional within the scope of 
the routing policies of these entities. RPSL is one such approach of describing 
such policy in a manner that one could perform some basic computation over the 
data.

It exposes a broader issue here about the difference between routing intent and 
protocol correctness. From the perspective of protocol correctness, regardless 
of whether the information was intended to be propagated, a protocol 
correctness tool should be able to tell you that the information has been 
faithfully propagated, but cannot tell you whether such propagation was 
intentional or not.


 Followed by:
 2) Tell me how to answer this programatically given the data we have
 today in the routing system (bgp data on the wire, IRR data, RIR
 data)
 

I wish.

 so far ... both of the above questions haven't been answered (well 1
 was answered with: I will know it when i see it which isn't helpful
 at all in finding a solution)


Some longstanding problems are longstanding because we have not quite managed 
to apply the appropriate analytical approach to the problem. Others are 
longstanding problems because they are damn difficult and this makes me wonder 
if we really understand the nature of the space we are working in. For example, 
if you think about routing not as a topology and reachability tool, but an 
distributed algorithm to solve a set of simultaneous equations (policies) would 
that provide a different insight as to the way in which routing policies and 
routing protocols interact? 

Geoff

Re: Weekly Routing Table Report

[Geoff Huston]

On 19/10/2011, at 9:02 PM, Philip Smith wrote:

 Hi Leo,
 
 Leo Vegoda said the following on 18/10/11 00:31 :
 
 128.0.87.0/2430977 JSC Yugra-Telecom
 
 This one seems to be an error. 128.0.80/21 appears to have been allocated on 
 5 October, nine days before the report was generated. 
 
 The report is as good as what is in the RIR allocation databases, as I
 grab those from the RIR public listings about 2 hours before the report
 is run. So if it was allocated, it wasn't listed in the file that I pick
 up. I'll investigate why.
 
 The report is not 100% accurate. Some of the resources listed do appear to 
 be used without being registered but not all of them.
 
 It is as accurate as the data I have access to. ;-) But I'd be delighted
 to hear suggestions for improvements.
 

You could try using http://bgp.potaroo.net/stats/nro/status.joint.txt

I use this as the basis of the bogon listing on the CIDR Report and I don't 
seem to be pickling up these false positives.

regards,

Geoff

Re: [routing-wg] The Cidr Report

[Geoff Huston]

From what I learned at the latest NANOG it's very clear that nobody reads this 
any more.

Is there any good reason to persist in spamming the nanog list with this report?


thanks,
   Geoff

Re: [routing-wg] BGP Update Report

[Geoff Huston]

While I am at it, does anyone read this report, or is this weekly report also 
just part of the spam load on this list?

regards,
   Geoff

Re: [routing-wg] The Cidr Report

[Geoff Huston]

Does anyone give a s**t about this any more?

From what I learned at the latest NANOG it's very clear that nobody reads this 
any more.

Is there any good reason to persist in spamming the nanog list with this report?


thanks,
  Geoff

Re: NAT444 or ?

[Geoff Huston]

On 08/09/2011, at 2:41 AM, Leigh Porter wrote:

 
 
 -Original Message-
 From: Daniel Roesen [mailto:d...@cluenet.de]
 Sent: 07 September 2011 17:38
 To: nanog@nanog.org
 Subject: Re: NAT444 or ?
 
 On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
 I'm going to have to deploy NAT444 with dual-stack real soon now.
 
 you may want to review the presentations from last week's apnic
 meeting
 in busan.  real mesurements.  sufficiently scary that people who were
 heavily pushing nat444 for the last two years suddenly started to say
 it was not me who pushed nat444, it was him!  as if none of us had
 a
 memory.
 
 Hm, I fail to find relevant slides discussing that. Could you please
 point us to those?
 
 I'm looking at http://meetings.apnic.net/32
 
 There is a lot in the IPv6 plenary sessions:
 
 http://meetings.apnic.net/32/program/ipv6
 
 This is what I am looking at right now. Randy makes some good comments in 
 those sessions. I have not found anything yet, but I am only on session 3, 
 pertaining specifically to issues around NAT444.

It may not be what Randy was referring to above, but as part of that program at 
APNIC32 I reported on the failure rate I am measuring for Teredo. I'm not sure 
its all in the slides I was using, but what I was trying to say was that STUN 
is simply terrible at reliably negotiating a NAT. I was then wondering what 
pixie dust CGNs were going to use that would have any impact on the ~50% 
connection failure rate I'm observing in Teredo. And if there is no such thing 
as pixie dust (damn!) I was then wondering if NATs are effectively unuseable if 
you want anything fancier than 1:1 TCP connections (like multi-user games, for 
example). After all, a 50% connection failure rate for STUN is hardly 
encouraging news for a CGN deployer if your basic objective is not to annoy 
your customers.

regards,
Geoff

Re: Comcast's 6to4 Relays

[Geoff Huston]

On 20/04/2011, at 11:43 AM, Martin Millnert wrote:
 
 Either way, there certainly IS a place in networks for Toredo services, 
 since SO
 MANY devices for the CPE end of the connectivity equation still have
 zero support for IPv6.

If you are prepared to tolerate a connection failure rate in the
order of 37% or so, then I could agree with you, but that's a 
pretty impressive failure rate!

 
 I must point you to Geoff Hustons most recent ISP posting:
 http://www.potaroo.net/ispcol/2011-04/teredo.html
 
 
...

 And there are some situations where it is OK that only 2 out of 3
 connections succeed, if it means your system can work better: Notably,
 peer-to-peer applications can make use of this to establish
 connections in a cloud, using DHT instead of DNS for peer propagation,
 and Teredo relays as the rendezvous mechanism.

In my opinion any service that runs at a 37% failure rate of
connections is a disservice. The peer-to-peer folk can tolerate its
miserable reliability and lousy performance because of the massive
redundancy in the peer-to-peer environment that means that that a peer-to-peer
player can just ignore the connections that fail. But do we need to head
to use applications that build in huge margins of oversupply in their
communications model just to tolerate  the unreliability of Teredo?

  Geoff

Re: How is IPv6 deployment going in the APNIC region?

[Geoff Huston]

On 14/04/2011, at 10:47 PM, Iljitsch van Beijnum wrote:

 On 14 apr 2011, at 13:50, Tore Anderson wrote:
 
 This is address space that's now marked as delegated and removed from
 the pile of unused address space for no obvious reason.
 
 I believe they are using those prefixes for research.
 
 and the delegated-extended file, it appears that these prefixes do count
 as assigned space like any other assignment. I would assume that when
 the research project is over, they will be returned to the free pool and
 assigned under the last /8 policy
 
 That is extremely curious. How can they justify taking 4 million addresses 
 for research two days before running out of regularly allocatable address 
 space? They could have taken that /10 out of the final /8 rather than taking 
 it from the last scraps of regular space if they really need a /10 for 
 research, which is already dubious in and of itself.
 
 Of course they didn't bother to respond to my request for information about 
 all of this.
 
 


The addresses were in flight to the recipient and got caught up in a set of 
scripted processes that inappropriately assigned them into the debogon project 
for a couple of days while some related administrative processes were underway.

Our apologies for the temporary confusion --  and we promise do better next 
time! :-)

And yes, APNIC is indeed  down to the last /8   - 
http://www.apnic.net/publications/news/2011/final-8 contains the announcement

Also, our apologies for not getting back to Iljitsch's request for information 
sooner - we have been somewhat busy in the last few days!

thanks,

 Geoff

Re: Weekly Routing Table Report

[Geoff Huston]

On 19/03/2011, at 6:08 AM, Mikael Abrahamsson wrote:

 On Sat, 19 Mar 2011, Routing Analysis Role Account wrote:
 
 Number of 32-bit ASNs allocated by the RIRs:   1207
 Prefixes from 32-bit ASNs in the Routing Table:   1
 
 Is the report not getting the routes from the real 32bit ASNs or is the above 
 figures really accurate?

Its probably not getting the routes - I see 915 AS's in the routing table using 
32 bit AS numbers (http://www.potaroo.net/tools/asn32/)

  Geoff

Request for assistance with BGP feeds

[Geoff Huston]

Hi

I am conducting some  research relating to BGP behaviour and I need some eBGP 
multihop feeds - IPv4 and/or IPv6 eBGP, and full eBGP route table feeds please. 
These are incoming feeds only (I will be announcing _nothing_ back in these 
sessions - I'll filtering outbound and you should defensively filter inbound of 
course). I am looking at the real time behaviour of BGP updates in a relatively 
dense multi-peer environment, which is why I am looking for a number of full 
route feeds.

Please drop me a note if you can assist me with this activity.

Thanks in advance,

   Geoff



--

Geoff Huston
APNIC

Re: Request for assistance with BGP feeds

[Geoff Huston]

thanks heaps everyone - I'm now well provisioned - now to configure them all!

   Geoff

On 02/03/2011, at 1:53 PM, Geoff Huston wrote:

 Hi
 
 I am conducting some  research relating to BGP behaviour and I need some eBGP 
 multihop feeds - IPv4 and/or IPv6 eBGP, and full eBGP route table feeds 
 please. These are incoming feeds only (I will be announcing _nothing_ back in 
 these sessions - I'll filtering outbound and you should defensively filter 
 inbound of course). I am looking at the real time behaviour of BGP updates in 
 a relatively dense multi-peer environment, which is why I am looking for a 
 number of full route feeds.
 
 Please drop me a note if you can assist me with this activity.
 
 Thanks in advance,
 
   Geoff
 
 
 
 --
 
 Geoff Huston
 APNIC
 
 
 
 
 

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
g...@apnic.net

Re: quietly....

[Geoff Huston]

 Are there any expectations of a Gold Rush for the remaining addresses?  I 
 would expect to see at least see some kind of escalation.
 

This question probably calls for another picture.

Here is a plot of 2009 and 2010 in terms of the average number of IPv4 
addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing 
function across the allocation data in order to clearly show the trend pattern 
over the two year period.

http://www.potaroo.net/tools/ipv4/daily-allocs.jpg


  Geoff

Re: ipv4's last graph

[Geoff Huston]

On 01/02/2011, at 7:02 PM, Randy Bush wrote:

 with the iana free pool run-out, i guess we won't be getting those nice
 graphs any more.  might we have one last one for the turnstiles?  :-)/2
 
 and would you mind doing the curves now for each of the five rirs?
 gotta give us all something to repeat endlessly on lists and in presos.

but of course.

http://www.potaroo.net/tools/ipv4/rir.jpg

This is a different graph - it is a probabilistic graph that shows the 
predicted month when the RIR will be down to its last /8 policy (whatever that 
policy may be), and the relative probability that the event will occur in that 
particular month.

The assumption behind this graph is that the barricades will go up across the 
regions and each region will work from its local address pools and service only 
its local client base, and that as each region gets to its last /8 policy the 
applicants will not transfer their demand to those regions where addresses are 
still available. Its not possible to quantify how (in)accurate this assumption 
may be, so beyond the prediction of the first exhaustion point (which is at 
this stage looking more likely to occur in July 2011 than not) the predictions 
for the other RIRs are highly uncertain.

Geoff

Re: quietly....

[Geoff Huston]

On 02/02/2011, at 1:11 PM, Owen DeLong wrote:

 
 On Feb 1, 2011, at 3:54 PM, Lee Howard wrote:
 
 People won't be able to access our site
 sure helps but being unable to put a date on it still reduces incentive
 (especially when Management get involved, and especially if there is a
 financial outlay involving firewalls etc.).  
 
 Geoff generously provided a probabilistic sense for RIR runout:
 http://www.potaroo.net/tools/ipv4/rir.jpg
 Pick your RIR and plot its runout date.  If it's ARIN, then the first
 ISP is out of IPv4 addresses at most three months later (since ARIN 
 now allocates for three months' need).  Of course, if demand increases,
 these dates might change.
 
 Will users be unable to reach your content on $RIR_runout_date + 3?
 They might have to get there through large-scale NAT.  That might
 bother management if you rely on IP geo-location, or need to 
 initiate connections downstream, or rate limit per IP address, or
 have anti-DOS techniques measuring hits per source IP address, 
 or have employees VPN in, or need to report intrusions, or any of
 the many problems widely documented.
 
 Oh, and when I said to pick your RIR, I meant the RIR of users
 who access your content.
 
 Lee
 
 
 I think there is a key problem with Geoff's graph.
 
 I think it fails to take into account the transitive probability of requests
 among the largest 3 regions. I agree that APNIC will probably run
 just about exactly as he predicts. I think, however, that the runout
 at APNIC will create a higher demand in ARIN and RIPE. Once that
 happens, their runout dates will get moved up much closer to
 the runout date of APNIC. As soon as the second of the three
 runs out, the remaining one will get another burst of acceleration.
 
 It does not appear to me that this probability is accounted for in the
 plots.
 
 Owen
 
 (Including Geoff because it's not fair to criticize his work behind his back)

Yes - a certain (X) percent of demand will shift out from a region once that 
region's stocks are depleted. What value X realistically takes is not something 
I can factor into these models, nor can I predict where this unmet demand may 
surface in the remaining regions. 

The future of IPv4 contains many uncertainties.

  Geoff

Route hijacking

[Geoff Huston]

My bgp monitor tells me:

* 1.2.3.0/24   203.119.76.3   0 4608 1221 4637 
3561 1299 12025 ?
* 5.4.3.0/24   202.12.28.10 4777 2516 1239 
1299 12025 ?


These are _not_ authorized announcements, so could

  AS3561  Savvis
  AS1299  Telia
  AS1239  Sprintlink


kindly DROP these unauthorized route advertisements (and clean up their route 
acceptance processes so that they stop announcing unauthorized noise to the 
rest of the Internet). 

And could the folk who run AS12025 IO-DATA-CENTERS - IO Data Centers kindly 
stop route hijacking?


thanks,

   Geoff

AS 7575 announcing 2400::/12

[Geoff Huston]

Hi,

As part of some ongoing collaborative research work in looking at the dark 
traffic in IPv6, APNIC has requested AARNet to originate a supernet 
advertisement of the IPv6 prefix 2400::/12 for the next two weeks. The 
originating AS is AS7575. We would appreciate it if you could adjust your 
routing filters to permit this advertisement if you are actively filtering IPv6 
routing advertisements.

Reports from previous  work in the IPv4 space can be found at 
http://www.potaroo.net/studies/ - we hope to add to this with a report 
describing data collected about the level (and type) of background traffic seen 
in this part of IPv6.

We would also be grateful if other operational lists received this notification 
- so please forward this as appropriate (but preferably only once!)

Many thanks,

   Geoff Huston, George Michaelson
   APNIC

Re: Connectivity to an IPv6-only site

[Geoff Huston]

On 23/04/2010, at 6:26 PM, Steve Bertrand wrote:
 
 This is a personal research project, in which I want to learn about the
 health of connectivity, and about other situations that causes breakage
 that I haven't considered before.
 

A very fine objective in my opinion. There are a few similar exercises underway 
-- the outputs from a similar set of IPv6 connectivity tests I've been doing is 
at http://www.potaroo.net/stats/1x1/

(yes, you can click on the graphs on that page to get larger images)

(and yes, visiting this URL will run the tests of V6 DNS, V6 dual stack 
preference and capability to retrieve a V6 only object on your browser client)

A discussion of the topic of IPv6 measurement work can be found at 
http://labs.ripe.net/node/ipv6-measurements

  Geoff

advertisements of 14/8 and 223/8

[Geoff Huston]

Hi,

APNIC and NTT are cooperating in a project to investigate the properties of 
unwanted traffic that is being sent to specific destinations in the address 
blocks of 14.0.0.0/8 and 223.0.0.0/8. These address blocks have been recently 
allocated to APNIC from the IANA, and APNIC and NTT are wanting to undertake 
this investigation prior to the commencement of ordinary allocations. 
Accordingly, APNIC has authorized AS38639 to advertise routes for 14.0.0.0/8 
and 223.0.0.0/8 from now until 26 April 2010, and requests that AS38639's peers 
and upstreams accept this as a legitimate routing advertisement.

thanks,

   Geoff Huston
   APNIC

Re: 1.0.0.0/8 route from MERIT ?

[Geoff Huston]

Hi,

As I noted in the previous note quoted below, APNIC are undertaking a second 
experiment with these two /24 routes originated by AS 36561. These two /24s 
appear to be the major attractors in the 1.0.0.0/8 space. YouTube have 
generously provided assistance for this second experiment, and we are very 
grateful for their help! 

  Geoff Huston
  APNIC




On 02/03/2010, at 6:59 PM, Tomoya Yoshida wrote:

 Are these from youtube also?
 
 1.1.1.0/24 *[BGP/170] 07:04:22, MED 0, localpref 100
  AS path: 2914 3356 36561 I
 1.2.3.0/24 *[BGP/170] 07:01:21, MED 0, localpref 100
  AS path: 2914 3356 36561 I
 
   tomoya
 
 
 On Thu, 25 Feb 2010 14:34:02 +1100
 Geoff Huston g...@apnic.net wrote:
 
 |
 |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote:
 |
 | 
 | Today I jumped into one of our routers, and I found that 1.0.0.0/8 is
 | announced from AS237, which is MERIT.
 | 
 | 
 |NetworkNext HopMetric LocPrf Weight Path
 | *  1.0.0.0/8  4.59.200.5  0  60 0  (65001
 | 65105) 3356 7018 237 i
 | 
 | Is this supposed to be?
 | I thought 1.0.0.0/8 is allocated to APNIC.
 |
 |Yes, this is supposed to be. This is one of a number of planned experiments 
 in advertising all and selected parts of 1/8 in the coming weeks.
 |
 |Geoff Huston
 |APNIC
 
 -- 
 Tomoya Yoshida yosh...@nttv6.jp
 

Re: 1.0.0.0/8 route from MERIT ?

[Geoff Huston]

On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote:

 
 Today I jumped into one of our routers, and I found that 1.0.0.0/8 is
 announced from AS237, which is MERIT.
 
 
NetworkNext HopMetric LocPrf Weight Path
 *  1.0.0.0/8  4.59.200.5  0  60 0  (65001
 65105) 3356 7018 237 i
 
 Is this supposed to be?
 I thought 1.0.0.0/8 is allocated to APNIC.

Yes, this is supposed to be. This is one of a number of planned experiments in 
advertising all and selected parts of 1/8 in the coming weeks.

Geoff Huston
APNIC

Re: draft-iana-ipv4-examples

[Geoff Huston]

On 03/09/2009, at 1:33 AM, Ron Bonica wrote:


Folks,

Please take a look at draft-iana-ipv4-examples. This draft discusses  
the

following subnet allocations:

- 192.0.2.0/24 (TEST-NET-1)
- 198.51.100.0/24 (TEST-NET-2)
- 203.0.113.0/24 (TEST-NET-3)

RFC 1166 allocates TEST-NET-1 for use in documentation. Because the
other two have been used in documentation, the current draft proposes
allocating them, too.


thats not exactly the case Ron.

198.151.100.0/24 and 203.0.113.0/24 were both recently passed to the  
IANA from APNIC for the specific purpose of having some diverse  
address blocks reserved for  documentation to assist document writers.  
They are new blocks, in terms of a proposed designation for  
documentation use. The problem being encountered was that it was  
difficult to construct realistic network examples using only a single / 
24 and the request made by the document authors was to add a couple of  
diverse /24's to the pool to help out here.


regards,

Geoff

Re: The Cidr Report

[Geoff Huston]

On 01/08/2009, at 6:44 PM, Paul Rolland (ポール・ロラン) wrote:


Hi Patrick,

On Fri, 31 Jul 2009 18:22:37 -0400
Patrick W. Gilmore patr...@ianai.net wrote:


On Jul 31, 2009, at 6:00 PM, cidr-rep...@potaroo.net wrote:


Recent Table History
  Date  PrefixesCIDR Agg
  24-07-09298785  182835
  25-07-09299168  182751
  26-07-09298909  182973
  27-07-09299265  183099
  28-07-09299345  183207
  29-07-09299380  182987
  30-07-09299354  183395
  31-07-09299904  183680


Only 94 prefixes short!

You mean 96, or is 28 important to you ? ;)


Any bets on whether next tomorrow is THREE HUNDRED (thousand) day?
Careful what you say, we actually dropped prefixes Wed - Thurs this
week.
Don't invite people to leak, you can be sure one of them will try  
to be

the one who helped reach the 300K range :(


done! Right now its 32 entries from this vantage point.

In amidst the teeming morass of updates of existing announced  
prefixes, sorting out the exact announcement of a new prefix that took  
the table over 30 entries will take a little time to work out.



   Geoff

Re: Redundant AS's

[Geoff Huston]

On 18/03/2009, at 6:18 PM, Henk Uijterwaal wrote:




When I look at this more recently, the conclusion still seems to be
valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013.  There
are a lot of unused ASN's out there.



I make it 25 June 2011 given current use patterns (http://www.potaroo.net/tools/asn16/ 
)




Recovering them will postpone the
problem by a few years but it won't solve it.  The basic problem with
recovery is how to decide if an ASN is really no longer used/needed.
There is (still) no mechanism to do this.


thats the problem - there are current 14902 AS numbers that allocated  
but not visible in my part of the public Internet, but its entirely  
inknown to what extent these numbers are used in various forms of  
private or semi-private contests


 Geoff

Re: IPv6 routing /48s

[Geoff Huston]

On 19/11/2008, at 4:26 AM, Christopher Morrow wrote:


On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward [EMAIL PROTECTED] wrote:

   I wish them good luck in reaching the DNS root servers.
 They are in critical infrastructure space, which is a single /32  
with


traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside
701) oh, not working...
traceroute6 to ipv6.google.com from inside 701, oh... not working  
either.


vzb's v6 table is far from complete :( which is pretty painful.

-chris



of the 1494 entries in the Ipv6 inter-domain routing table that is  
seen at the Ipv6 route-views router there are 347 /48's (and 1 /56 and  
12 /64s, I dunno why)


More details at http://bgp.potaroo.net/v6/as6447/ if anyone is  
interested

Re: Internet Traffic Begins to Bypass the U.S.

[Geoff Huston]

On 15/09/2008, at 10:36 PM, Joe Abley wrote:



On 14 Sep 2008, at 23:38, Matthew Moyle-Croft wrote:


Other cable systems predated FLAG (at least for voice).


The qualifier might be important.

As should have been obvious from all the IIRCs and related  
qualifiers in my note, I wasn't in Europe at the time I started  
paying attention to these things. However, in other parts of the  
world, circuits provisioned and planned for voice traffic growth  
started to become effectively full as soon as there was demand for  
circuits much bigger than an E1.


As an example, PacRimEast still had capacity in the late 90s,  
strictly speaking. But given the difficulty in ordering anything  
other than E1s on it at that time, did it really exist as a  
terrestrial option for New Zealand ISPs trying to send packets to  
the US?


yes, for Australia, certainly. A number of us were using E1 inverse  
MUX units to pull higher channel rates out of the circuits. Same thing  
happened a few years later with muxing up 155Mbpsd circuits.




There was a lot of satellite transmission sold around that time on  
PanAmSat, IntelSat and Loral transponders, and it's not as if  
anybody was really using satellite out of choice. There are only so  
many discrete E1s you can comfortably inverse-mux together before  
it's really not worth bothering.


heh heh - we ran out of cable capacity before we ran out of cascading  
inverse muxes at the time! Satellite really was a very inferior choice.






The timelines are no doubt different, since Europe experienced a  
giant boom in Internet demand and infrastructure while smaller  
markets like New Zealand were still preoccupied with X.25. However,  
the original question was whether there had ever been a time during  
which Europe had no option but to cross oceans to get to Asia, and  
I'd be surprised if that wasn't the case.


The original telegraph circuits in the latter half of the 19th century  
were largely overland, but, unless there are markets you want to  
intercept with in the middle, undersea tends to be a better option  
where you consider all aspects (territorial rights, political issues,  
total length, stability etc etc). There was a very informative article  
by Neal Stephenson in Wired some years back that was published at  
about the time FLAG was being constructed which still is about the  
best article on the submarine cable business I've read. Everyone  
interested in this submarine cable game except Joe should read it.


The problem with the routes in that part of the word include: the  
Wallace line, territorial waters, shallow waters, the Luzon strait,  
the stability of overland segments, the size of the markets in the  
middle, the cost and availability of the alternatives, and the major  
factor that spending 100% of your investment money to optimise 80% of  
your traffic needs makes more sense than many other investment  
strategies - hence the outcome that the Pacific has become the heavily  
favoured route for submarine cable systems in this area of the world.





Perhaps someone who actually knows this stuff can throw some facts  
into the thread and put a stop to my wild speculation.


nah - more fun to watch you speculate Joe.

Re: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion

[Geoff Huston]

Mike Leber wrote:
 Since nobody mentioned it yet, there are now less than 1000 days projected
 until IPv4 exhaustion:
 
 http://www.potaroo.net/tools/ipv4/

 

 ps. 1000 days assumes no rush, speculation, or hoarding.  Do people do
 that?
 
 pps. Of course these are provocative comments for amusement.  :)
 


I keep on saying: its just a mathematical model, and the way this will play
out is invariably different from our best guesses. So to say well there's 
x days to go is somewhat misleading as it appears to vest this model
with some air of authority about the future, and that's not a good idea!

IPv4 address allocation is a rather skewed distribution. Most address 
allocations are  relatively small, but a small number of them are relatively 
large. Its the the timing of this smaller set of actors who are undertaking
large deployments that will ultimately determine how this plays out. It
could be a lot faster than 1000 days, or it could be slower - its very
uncertain. There could be some last minute rush. There could be a change
in policies over remaining address pools as the pool diminishes, or 

So, yes, the pool is visibly draining and you now can see all the way to
the bottom. And it looks like there are around 3 years to go ... 
but thats with an uncertainty factor of at least +/- about 1 1/2 years.

regards,

Geoff




___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog