Re: Longest prepend( 255 times) as path found

[Mike Leber via NANOG]

Here's a related good article:

"Excessive BGP AS-PATH prepending is a self-inflicted vulnerability"

https://blog.apnic.net/2019/07/15/excessive-bgp-as-path-prepending-is-a-self-inflicted-vulnerability/

You probably should not use a limit greater than 50 unless you want to 
encourage this behavior.


There have been previous substantive discussions on network operator 
mailing lists regarding why to use one specific limit or another.


Unfortunately I wasn't able to find the discussion thread that I 
remember that represented some consensus among backbones roughly around 
50, so instead here are various random configuration examples that use 
"bgp maxas-limit 50"


https://www.nl-ix.net/nocdoc/

https://www.barryodonovan.com/wp-content/uploads/2019/04/BGP-101.pdf

https://www.ciscopress.com/articles/article.asp?p=1312796=3

https://www.networkworld.com/article/2234109/cisco-subnet-practical-bgp-security.html

(etc... there are more)

Excessive AS path prepending is a waste of global resources (router CPU, 
bandwidth, and memory in all the BGP speaking routers in the world with 
a full table).



On 8/24/22 7:00 PM, anonymous wrote:

Hey everyone,

Too many hops found as below.
Usually What shoud we do ? Should we filter it ?

91.246.12.0/24 


                      AS path: 4788 9002 41313 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 I


                      AS path: 9930 9002 41313 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 51196 
51196 51196 51196 51196 51196 51196 51196 51196 51196 I


/noname

Re: What's going on with AS147028?

[Mike Leber via NANOG]

This kind of thing is a problem from time to time with the data we get 
from route collectors.


When we see it we have to add the culprit ASN to a filter list we keep 
in bgp.he.net.


It tends to be a repeat problem with some collectors and some ASNs.

We haven't really figured out why people send junk routes to route 
collectors.


The things we've seen aren't just route leaks.  We've seen a variety of 
AS path spoofing.


We've already added this specific ASN to the filter list and pushed an 
update for bgp.he.net.


Note, this email is specifically talking about routes received from 
route collectors and not routes operationally received by he.net via BGP 
sessions with actual networks.


Mike.

On 7/12/22 12:49 PM, Eric Dugas via NANOG wrote:
A friend of mine mentioned that both our Canadian ASNs were listed in 
AS147028's peer list on https://bgp.he.net/AS147028 but we have no 
adjacency to this network.


Their peer count jumped from 1 in May 2022 to 1,800 and just a few 
days ago jumped to 8,800. Beside NL-IX, all the IX they are listed on 
are virtual IX with a few dozen "hobby networks".


The only lead I have is they use HE as transit and they're pumping 
back BGP feed to route collectors like RIPE RIS or Route Views with 
routes stripped of HE's ASN.


Eric

Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Mike Leber via NANOG]

I'm pleased to announce Hurricane Electric has completed our RPKI
INVALID filtering project and we now have 0 RPKI INVALIDs in our routing
table.

Hurricane Electric has 29021 BGP sessions with 22109 prefix filters with
7191 networks directly and 8239 networks including Internet exchanges.

We filter all BGP sessions using prefix filters based on IRR and RPKI.

These prefix filters are updated automatically both through a system of
daily updates and real time updates to prevent RPKI INVALID routes from
being carried in our routing table.

Re: Bgpmon alternatives?

[Mike Leber]

I'm sure if it doesn't do exactly that already, we can add it shortly.

Some of planned functionality for hijack detection is already live. 
That's one of the main reasons for creating this service.

Mike.

On 6/16/19 2:48 AM, Brian Kantor wrote:
> On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote:
>> As a beta service you can try out rt-bgp.he.net.  This is a real time
>> bgp monitoring service we are developing.
> It's interesting, but I don't see any way to do what I primarily
> use the existing BGPMon for: watch for hijacks.
>
> That is, set up one or more prefixes to be continuously monitored
> and have the monitor send me an email alert when that prefix or a
> subnet of it begins to be announced by someone new.
>
> For example, if I have told it to monitor 44.0.0.0/8 and someone
> somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very
> much like to know about that, along with details of who and where.
>
> Then if that announcement is authorized, I can tell the monitoring
> service that this new entry is NOT a hijack, and it won't bug me
> about it again.
>
> Can it be persuaded to do this?
>   - Brian

Re: Bgpmon alternatives?

[Mike Leber]

On 6/15/19 6:55 PM, TJ Trout wrote:
> Any simple and easy bgpmon alternatives you guys could recommend?

As a beta service you can try out rt-bgp.he.net.  This is a real time
bgp monitoring service we are developing.

It's a work in progress so please make sure to send Martin Winter
 any feedback or feature requests.

It works based on contributed BGP feeds, so if you see based on the heat
map that you can provide a feed from an area of the world we don't
currently have it would be a big favor.

Mike.

Re: Frontier rural FIOS & IPv6

[Mike Leber]

You are assuming the routing and transit relationships in IPv4 are the
same in IPv6.

IPv4 has many many many suboptimal transit relationships where routing
is purposely suboptimal on the part of the networks in the path due to
competitive reasons.  One example of suboptimal routing is traffic not
being exchanged in a closer location where both networks exist and
instead being routed hundreds or thousands of miles out of the way.

Customers don't get to influence the decisions of monopolies etc.

Customers choose based on inertia, brand experience, and what options
are even available to them to get IPv6 vs IPv4.

IPv6 has randomized some of these vendor relationships due to some
upstream networks not even implementing IPv6, meaning the downstream
networks were forced to make other choices.


On 3/31/19 6:21 PM, Keith Medcalf wrote:
> It is not possible for web pages to load faster over IPv6 than over IPv4.  
> All other factors being equal, IPv6 has higher overhead than IPv4 for the 
> same payload throughput.  This means that it is physically impossible for 
> IPv6 to be move payload bytes "faster" than IPv4 can move the same payload.
>
> In other words, IPv6 has a higher "packet tax" than IPv4.  Since you have no 
> choice but to pay the "packet tax" the actual payload data flows more slowly.
>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
> lot about anticipated traffic volume.
>
>
>> -Original Message-
>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ca By
>> Sent: Sunday, 31 March, 2019 18:53
>> To: Matt Hoppes
>> Cc: Aaron C. de Bruyn; NANOG mailing list
>> Subject: Re: Frontier rural FIOS & IPv6
>>
>>
>>
>> On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes
>>  wrote:
>>
>>
>>  Going to play devils advocate.
>>
>>  If frontier has a ton of ipv4 addresses, what benefit is there
>> to them in rolling out ipv6?
>>
>>  What benefit is there to you?
>>
>>
>> I love xbox and xbox works better on ipv6,
>>
>> https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47
>> .pdf
>>
>> Also, webpages load faster , and i love fast web pages
>>
>> https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on-
>> board/
>>
>>
>> https://www.akamai.com/fr/fr/multimedia/documents/technical-
>> publication/a-case-for-faster-mobile-web-in-cellular-ipv6-
>> networks.pdf
>>
>>
>>
>>
>>  On Mar 31, 2019, at 7:11 PM, C. A. Fillekes
>>  wrote:
>>
>>
>>
>>
>>  Still it's pretty darn good having real broadband on the
>> farm.  One thing at a time.
>>
>>
>>  But, let's start thinking about ways to get Frontier up to
>> speed on the IPv6 thing.
>>
>>
>>
>>  On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn
>>  wrote:
>>
>>
>>  You're not alone.
>>
>>  I talked with my local provider about 4 years ago and
>> they said "We will probably start looking into IPv6 next year".
>>  I talked with them last month and they said "Yeah,
>> everyone seems to be offering it.  I guess I'll have to start reading
>> how to implement it".
>>
>>  I'm sure 2045 will finally be the year of IPv6
>> everywhere.
>>
>>  -A
>>
>>  On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes
>>  wrote:
>>
>>
>>
>>  So by COB yesterday we now officially have FIOS
>> at our farm.
>>
>>
>>  Went from 3Mbps to around 30 measured average.
>> Yay.
>>
>>
>>  It's a business account, Frontier.  But...still
>> no IPv6.
>>
>>
>>  The new router's capable of it.  What's the hold
>> up?
>>
>>
>>  Customer service's response is "We don't offer
>> that".
>>
>>
>>
>>
>>

Re: Did IPv6 between HE and Google ever get resolved?

[Mike Leber]

The routes you see are Cogent using IPv6 leaks.

We chase these down as we see them.

Obviously if Cogent is happy enough to use leaks, we could just give
them our IPv6 customer routes directly.  ;)

As a backbone operator, I'd prefer all routing we do (for at least the
first hop leaving our network) to be intentional.  Perhaps they are the
same?

Should I wait for to get an interesting email?  (haha)

Mike.


On 3/31/19 6:10 PM, Christopher Morrow wrote:
> On Sun, Mar 31, 2019 at 6:07 PM Christopher Morrow
>  wrote:
>> thread subject still says 'google and he', I don't think there's ever
>> been problems between google/he for v6.
>> I think there are some issues from cogent - > he over v6 :(
>>
>> Looking at a sample AS6939 customer link I see no:
>>   ".* 174$"
>>   ".* 174 .*$"
>>
>> routes in the bgp stream :(
>>
>> Looking at a AS174 customer link session I see no:
>>   ".* 6939$"
>>   ".* 6939 .*"
>>
>> routes in the bgp stream :(
> Apologies, I do actually see a path from 174 -> 6939 (well 28 paths):
>   174  6939 
>
> it's clearly not all of HE -> Cogent, and it's clearly not supposed to
> be working (I would think).
> -chris
>
>> -chris
>>
 Matt

>>> Ah.  Sorry, the changed subject line didn't thread in with this,
>>> so this showed up as an unreplied singleton in my inbox.
>>>
>>> Apologies for the duplicated response; at least this won't
>>> be a lonely singleton in anyone else's inbox now.  ^_^;
>>>
>>> Matt
>>>

Re: Frontier rural FIOS & IPv6

[Mike Leber]

You mean like pulse dialing and stepper relays vs touch tone dialing?

I'm sure there were people that felt the same about that too.

That mindset is simply you already paid for the old stuff, it's working
fine, you would rather not understand or think about the problems the
new tech solves or benefits it provides.

To be motivated to do something you have to have a reason or goal.

Most all goal seeking behavior in business can be put two buckets: 1)
revenue at risk and 2) revenue enabled.

i.e. one is going away from pain and the other is going towards a reward.

Making a plan is based on your perception of current and future events.

At scale the market does a whole lot of testing of economic fitness
functions that are the result of the decisions of each of our companies
makes about what all of this means.

If you were an independent telephone company around 1955 to 1965 with
relay based switches deciding when and if and why to use DTMF or a
variant, I'm sure there was exactly the same dynamic.  Situation:
telecom company with old technology that was still working trying to
decide what to do.

I mean, your phones still worked on that day you were starting out the
window musing about it.  Why not just go to lunch and forget about it?

While you were out to lunch after putting off deciding what to do about
your relay switches around the same period of time the global phone
system was growing at a breakneck speed and the first submarine
transatlantic telephone cable system was getting run.

Some people won't like this story because it is about making business
decisions about technology when you aren't sure of the reasons to either
do or not do something and isn't arguing about some specific concrete
reason to add IPv6 support like: 1) the world has more people than IPv4
addresses or something 2) you work for a big company and would like your
revenue from the Internet to keep growing over the next 10 years
uninterrupted due the risk of not supporting IPv6 and this is too
trivial of a technology decision because the incremental cost is so
small (compared to all the other fires you have burning) to just add
support anyway.  I get where you are coming from.


On 3/31/19 4:19 PM, Matt Hoppes wrote:
> Going to play devils advocate. 
>
> If frontier has a ton of ipv4 addresses, what benefit is there to them
> in rolling out ipv6?
>
> What benefit is there to you?
>
> On Mar 31, 2019, at 7:11 PM, C. A. Fillekes  > wrote:
>
>>
>> Still it's pretty darn good having real broadband on the farm.  One
>> thing at a time. 
>>
>> But, let's start thinking about ways to get Frontier up to speed on
>> the IPv6 thing.
>>
>>
>> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn > > wrote:
>>
>> You're not alone.
>>
>> I talked with my local provider about 4 years ago and they said
>> "We will probably start looking into IPv6 next year".
>> I talked with them last month and they said "Yeah, everyone seems
>> to be offering it.  I guess I'll have to start reading how to
>> implement it".
>>
>> I'm sure 2045 will finally be the year of IPv6 everywhere.
>>
>> -A
>>
>> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes
>> mailto:cfille...@gmail.com>> wrote:
>>
>>
>> So by COB yesterday we now officially have FIOS at our farm. 
>>
>> Went from 3Mbps to around 30 measured average.  Yay. 
>>
>> It's a business account, Frontier.  But...still no IPv6.
>>
>> The new router's capable of it.  What's the hold up? 
>>
>> Customer service's response is "We don't offer that".
>>
>>
>>
>>
>>

Re: NTT-HE earlier today (~10am EDT)

[Mike Leber]

I was thinking that when I posted yesterday.

These were announcements from a peer, not customer routes.

We are lowering our max prefix limits on many peers as a result of this.

We are also going towards more prefix filtering on peers beyond bogons 
and martians.


Mike.

On 6/30/15 2:19 AM, Randy Bush wrote:

NTT's customer Sofia Connect leaked our routes to NTT.  NTT accepted
these routes instead of properly filtering their customer
announcements.  As a network of non-trivial size, announcing over
75,000 customer routes which is nearly 15% of the IPv4 routing table,
we'd expect the common courtesy of having our ASN included in their
customer facing AS-PATH filters, as we extend this same courtesy to
other networks of this size (such as AS2914).

sometimes the goddesses have a sense of humor

At Tue, 30 Jun 2015 10:27:21 +0200, Grzegorz Janoszka wrote:

We have just received alert from bgpmon that AS58587 Fiber @ Home
Limited has hijacked most of our (AS43996) prefixes and Hurricane
Electric gladly accepted them.

randy

Re: NTT-HE earlier today (~10am EDT)

[Mike Leber]

On 6/30/15 3:02 PM, Tore Anderson wrote:

* Mike Leber


I was thinking that when I posted yesterday.

These were announcements from a peer, not customer routes.

We are lowering our max prefix limits on many peers as a result of this.

We are also going towards more prefix filtering on peers beyond bogons
and martians.

Hi Mike,

You're not mentioning RPKI here. Any particular reason why not?

If I understand correctly, in today's leak the origin AS was
changed/reset, so RPKI ought to have saved the day. (At least Grzegorz'
day, considering that 33 of AS43996's prefixes are covered by ROAs.)


Yes, we will incorporate RPKI into how we build our prefix filters for 
peers as we improve our tools.


Currently this will involve some amount of prefix list compression due 
to the limits of current hardware and the need to still have BGP converge.


As Job Snijders said, I would forsee issues if i'd try to add an eleven 
megabyte prefix-list on all devices in the network..


Mike.

Re: NTT-HE earlier today (~10am EDT)

[Mike Leber]

NTT's customer Sofia Connect leaked our routes to NTT.  NTT accepted 
these routes instead of properly filtering their customer 
announcements.  As a network of non-trivial size, announcing over 75,000 
customer routes which is nearly 15% of the IPv4 routing table, we'd 
expect the common courtesy of having our ASN included in their customer 
facing AS-PATH filters, as we extend this same courtesy to other 
networks of this size (such as AS2914).


Mike.

On 6/29/15 2:04 PM, Jim Popovitch wrote:

Hello,

I haven't seen anything to explain this, so I'm asking a larger
audience.  Did anyone notice any unusual NTT or HE routing this AM?

Here's what I saw:


   2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net  0.0%200.8
0.7   0.6   0.9   0.1
   3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net 0.0%204.6
6.2   0.5  13.6   4.8
   4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net 0.0%20   15.3
15.0 13.9 15.8 0.7
   5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net 0.0%20  127.3
106.7  98.5 127.3  11.1
   6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net 0.0%20  126.8
126.0 125.7 126.8   0.2
   7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net 0.0%20  131.1
130.0 128.7 131.4   1.2
   8.|-- 83.217.227.42  80.0%20  148.5
146.0 144.2 148.5   2.0
   9.|-- ip-48-93.sofia-connect.net 90.0%20  184.5
163.8 143.1 184.5  29.3
  10.|-- ???100.0200.0
0.0   0.0   0.0   0.0
  11.|-- 10ge5-4.core1.vie1.he.net  75.0%20  160.7
150.4 143.9 160.7   6.3
  12.|-- 10ge1-4.core1.prg1.he.net  80.0%20  158.4
159.5 157.9 161.1   1.6
  13.|-- 10ge10-12.core1.fra1.he.net75.0%20  154.5
159.2 145.9 174.4  10.7
  14.|-- 100ge5-2.core1.par2.he.net 75.0%20  187.9
172.9 157.1 187.9  11.1
  15.|-- 100ge7-1.core1.nyc4.he.net 78.9%19  147.2
146.2 144.6 147.5   1.4
  16.|-- 100ge7-2.core1.chi1.he.net 78.9%19  165.6
172.1 165.6 183.5   8.0
  17.|-- 10ge15-2.core1.den1.he.net 89.5%19  201.3
204.7 201.3 208.1   4.8


-Jim P.

Re: IPTV providers in IN/Chicago

[Mike Leber]

Because selling transport is really good revenue for facilities based 
carriers everywhere and the revenue per deal is higher than selling the 
same amount of Internet access (even if the bits are going to the other 
side of the planet).


Consider that 1 Gbps metro ethernet layer 2 transport circuit might be 
between $1500 and $3500 per month (wild guess) and the commodity 
residential gige Internet access is is starting look like it's going to 
be between $70 and $350 per month.


A transport sale is good money they can pick up off the ground just by 
saying yes.  I'm sure if you were a sales rep you'd like selling metro 
ethernet loops for the larger commissions and the larger customers that 
it got you involved with.  If you were a regional sales director for a 
carrier you'd especially like how these help your sales group more 
quickly make your numbers.  These deals are priced to pay for extending 
the physical plant as well.


Any carrier that doesn't help a customer with a transport request ends 
up effectively sending that customer to a competitor, with the result 
the customer then pays the competitor to extend their physical plant to 
the customer's location in the original carriers territory.


Mike.

On 4/28/15 5:05 AM, Mike Hammett wrote:

I'm not sure why or that Comcast would enable competition. Maybe I'm wrong. 
Then again, maybe Brandon isn't in a Comcast served area.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



Midwest Internet Exchange
http://www.midwest-ix.com


- Original Message -

From: Frank Bulk frnk...@iname.com
To: Brandon Martin lists.na...@monmotha.net, nanog@nanog.org
Sent: Tuesday, April 28, 2015 12:35:43 AM
Subject: RE: IPTV providers in IN/Chicago

I believe Vubiquity (http://www.vubiquity.com/product-portfolio/livevu/) does, 
as well as Comcast HITS 
(http://www.comcastwholesale.com/products-services/mpeg-2-content-delivery/mpeg-2-delivery-content-providers).

Frank

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brandon Martin
Sent: Monday, April 27, 2015 7:17 PM
To: nanog@nanog.org
Subject: IPTV providers in IN/Chicago

Anyone know of an IPTV provider/wholesaler who I could meet in
Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)?

Direct solicitations are OK out-of-band.

Re: AlbertaIX - no longer a Cybera project?

[Mike Leber]

On 9/5/13 1:47 PM, Theo de Raadt wrote:

The last six months in AlbertaIX saw no discussions (or approval) for
any action plan.  Without votes, nothing can be built.


This is probably the key ideological problem and a good example not to 
follow if you are trying to start an exchange.  Do first, implement 
bureaucracy later, if at all.


I completely respect the people that were on the board and also Cybera.  
FWIW, I have no direct insight into the conversations between the people 
involved.  From a distance it seemed like exactly the right people to be 
involved (with only the minor problem of not enough ethernet switch 
pluggin' in and too much meetin' and discussin').


Facility and parties willing, hopefully there will be a YYCIX switch in 
Cybera.



The entire organization also lacks documents.  The new game plan is to
follow YYCIX because of Hurricane Electric's arrival at the datacenter
which was (originally) the least preffered.


Our criteria for choosing a facility in Calgary was:

* Which facilities have a live ethernet switch for any Internet exchange?

Then given the candidate list of data centers in the area:

* Is there a live ethernet switch in their facility?

* How many IPs are pingable on that switch?

* Does the facility want us in their facility?  (Is there any value for 
them?  Are they happy to have us build in?)


* Does the facility want the exchange to succeed?  (Do they get it?)  
(Sadly sometimes the answer here is either indifference or hostility.)


* Does the facility understand that we need them to encourage more 
networks to build into their facility?


* Is the price for cross connects and power reasonable?

* How many networks are in the building?

* Can we get develop enough revenue to cover our costs to get circuits, 
colo, power, cross connects etc to build out to the site?


(DataHive met all of these requirements and was repeatedly very helpful 
to make things happen.)


There's a magic moment in the beginning of forming data center neutral 
exchanges where the engineers operating the exchange and the facility 
owners need to have a meeting of the minds and view the exchange as 
something they are doing together and then take the immediate actions to 
get it live.  I'm not sure how the magic of this goes down since the 
facility owners may or may not view each other as competitors (and may 
or may not view the exchange as that useful).  Once an exchange has 
critical mass like AMS-IX I suppose this becomes an easy decision for a 
new facility owner.


I am led to understand that there is city fiber in Calgary available at 
reasonable cost, which hopefully would translate to exchange switches in 
multiple buildings eventually in Calgary (if various stages of critical 
mass are achieved).


Mike.

Re: where was my white knight....

[Mike Leber]

We saw an increase in IPv6 traffic which correlated time wise with the 
onset of this IPv4 incident.


Happy eyeballs in action, automatically shifting what it could.

Mike.

On 11/8/11 2:56 AM, bmann...@vacation.karoshi.com wrote:

how would a sidr-enabled routing infrastructure have fared in yesterdays 
routing circus?

/bill

Re: HE.Net 6TO4 relay

[Mike Leber]

On 10/24/11 9:18 AM, Meftah Tayeb wrote:

hello HE.NET
did you drop the 6to4 delegated prefix 192.88.99.0/24 ?
if yes please would you drop it from your BGP routing table anounced ?
thank you
 Meftah Tayeb
IT Consulting


Hi!

For issues like this please email i...@he.net or n...@he.net with IPv4 
and IPv6 traceroutes to the addresses involved.


We are running and announcing 6to4 relays globally.

We did recently turn on IPv6 RPF facing our 6to4 relays.  This was done 
for basic network security reasons.


There has been no change in traffic levels through our 6to4 relays, 
however it does appear to have affected a very limited number of people 
(I know of 1 other we already helped, you would be the second if this is 
your issue) that were using our 6to4 boxes to de-encapsulate packets 
with IPv6 source addresses not in the IPv6 6to4 range.


If this was you, the fix is to either:

1) interconnect natively with us and announce your IPv6 address space to 
us via BGP (and don't use 6to4)
2) use your own already existing native IPv6 connectivity with your 
address space (and don't use 6to4)
3) make packets that you send to our 6to4 relays source from your 6to4 
interface with your IPv6 6to4 address
or 4) request a IPv6 BGP tunnel and run BGP so that you can announce 
your address space to us (and don't use 6to4).


If you email us we can work with you to diagnose your specific situation.

Mike.

Re: How long is reasonable to fix a routing issue in IPv6?

[Mike Leber]

On 7/7/11 6:20 AM, Jared Mauch wrote:

On Jul 7, 2011, at 2:14 AM, Mark Andrews wrote:


3) If end-to-end connectivity works,=20

Workarounds:

the IPv4 only P/PE device should have some sort of IPv6 address placed =
on transit interfaces to allow TTL expired to be sourced from something =
capable (this IP doesn't need to be able to be reached/routed to that =
interface, just exist).

I spent a lot of time looking at a similar problem and it ended up being =
a combination of #1  #2 above.  You will see this problem across The =
ATT and Cogent networks in my experience.

The path is going through ATT.

Yes.  ATT and Cogent are aware of this.  I think there may be an IETF draft 
out there that talks about this as well but don't have a pointer to it.  It is true 
that if an MPLS-LSR/P device does not understand the IPv6 frame you will see no 
response for that TTL.  It's only the P devices that do understand an IPv6 frame, 
but decide to put a mapped-v4 address in the ttl expired message.

The real questions are:

1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these 
packets? (and if they are, are you requesting they make this change?)


We aren't doing loose-rpf on ISC's transit session (for the reason you 
stated and others).



2) is a mapped-v4 address a valid *source* address on the wire even if it's not 
a valid dest?
3) should operators of IPv6 capable equipment be running them in an MPLS-LSR/P 
role be assigning an IPv6 address on interfaces to provide a valid 
source-address even if they are not reachable in return?  Should the vendor 
provide a knob to generate the ttl expiry messages from some other source 
address, obscuring the interface IPs involved (such as a loopback)?

Mark, it may also be valuable to see testing from a server at ISC that doesn't 
transit HE to reach the ATT network.  While you still can't see who is dropping 
your packets, you may find someone who doesn't have loose-rpf enabled and 
observe some of the other behaviors noted.


The problem observed also happens for native IPv6 packets sent to 
2001:1890:1112:1::1e


We can confirm the packets leave our network and are handed off to the 
correct party.


We've sent emails regarding this to the other parties involved with no 
response so far.  I'll make sure people start getting phone calls.


Mike.


- Jared

(BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devices)

future revenue at risk vs near term cost ratio

[Mike Leber]

On 6/19/11 10:47 PM, Paul Vixie wrote:

Date: Sun, 19 Jun 2011 22:32:59 -0700
From: Doug Bartondo...@dougbarton.us

... the highly risk-averse folks who won't unconditionally enable IPv6
on their web sites because it will cause problems for 1/2000 of their
customers.

let me just say that if i was making millions of dollars a day and i had
the choice of reducing that by 1/2000th or not i would not choose to
reduce it.  as much as i love the free interchange of ideas i will point
out that commerce is what's paid the internet's bills all these years.


Fortunately, 1/2000th was just the now proven false boogey man that 
people substituted as a placeholder for the unknown.  Now that we've had 
World IPv6 Day, this has been clearly refuted.  No, 1 out 2000 users did 
not get fatally broken due to deploying IPv6.


That said, lets run with your revenue at risk theme... (well you did say 
you were severely concerned about that 1/2000th of your revenue!)


What if the risk of you not enabling it was that at some later date you 
lose 1/10th of your revenue due to either competitive pressures or the 
inability to provide the next generation service customers want?  (Or if 
you are a non profit, what if it meant that you can't service 10 percent 
of your user base in the way they want.)


Assuming the company is a company that generates all of its revenue from 
the Internet, what if you were an investor with 1 billion invested in 
that company?  What is the discounted future revenue at risk to near 
term cost ratio that you would tolerate due to not actively deploying 
IPv6?  What would the lack of concrete progress in the form of real 
world deployment say about the company's prospects as a cutting edge 
technology company?  (heh, time to diversify that portfolio?)


(I know you actually are running IPv6, just posing these entertaining 
questions since you provided the opening.)


Mike.
ps. not expecting an answer since it's rhetorical and posed for fun.

Re: HE - anyone run into power issues with HE Colo Services?

[Mike Leber]

On 9/12/10 9:04 AM, todd glassey wrote:

Has anyone run into issues with HE's power and the limitations therein?
For instance they seem to want to sell a second rack of space to get any
reasonable amount of power into their enclosures.


Perhaps that was several years ago when we didn't offer custom power or 
recently and we failed to communicate our flexibility, however nowadays 
you can get as much power per cabinet in our facilities as you want to 
buy.  We have customers with 30 amp 120 volt circuits, others with dual 
20 amp 208 volt circuits plus a 15 amp 120 volt circuit, and we even 
have some customers with three phase 30 amp 208 volt electrical circuits.


Since the power delivered to a cabinet is the primary cost of a basic 
cabinet with one electrical circuit, the cost of additional 15 amp 
circuit is the same as a 15 amp cabinet.



The basic 40U Rack only comes with a single source of power which is
limited to 15A meaning it is really difficult to properly build out N+1
type operations.


We can source electrical circuits from different PDUs if you specify it 
at the time of ordering.


Mike.

Re: v6 bgp peer costs?

[Mike Leber]

You can get a free IPv6 BGP tunnel from Hurricane Electric at 
http://tunnelbroker.net


We have tunnel servers spread through out the world, so typically the 
nearest server has reasonably low latency from your location.


Of course our main business is selling wholesale native IPv6 and IPv4 
transit, however you don't have to be a paying customer to use our free 
service.


Mike.

On 7/21/10 12:08 PM, Zaid Ali wrote:

I currently have a v4 BGP session with AS 701 and recently requested a v6
BGP session to which I was told a tunnel session will be provided (Same
circuit would be better but whatever!). Towards the final stage in
discussions I was told that it will cost $1500. I find this quite ridiculous
and it will certainly not motivate people to move to v6 if providers put a
direct price tag on it. I am going through a bandwidth reseller though so I
am not sure who is trying to jack me here. Has anyone here gone through a
similar experience?

Thanks,
Zaid

Re: Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering]

[Mike Leber]

Patrick W. Gilmore wrote:
For the v6 'Net to be used, customers - you know the people who pay for 
those router things and that fiber stuff and all our salaries and such - 
need to feel some comfort around it actually working.  This did not help 
that comfort level.  And I believe it is valid to ask about it.


That is entirely correct and I'm glad you asked that question!  ;)

Let me explain:

(Lots of truisms here, bear with me!)

IPv6 is newer than IPv4.

As IPv6 is newer than IPv4, the equipment to support IPv6 natively is 
newer than legacy equipment already deployed that only supports IPv4.


As the equipment that supports native IPv6 is newer, there are fewer 
core networks that run native IPv6.


As these new IPv6 networks are deployed they are growing and developing.

(Like neurons forming connections, the IPv6 network is.)

Deployment of IPv6 in the core has been growing year to year, with that 
growth accelerating.  In fact, I'd tell trend watchers of business 
econometrics the accelerating growth curve both represents something 
important happening right now and something that is likely to have real 
world implications for Internet infrastructure companies in the future:


http://bgp.potaroo.net/cgi-bin/plot?file=%2fvar%2fdata%2fbgp%2fv6%2fas6447%2fbgp%2dactive%2etxtdescr=Active%20BGP%20entries%20%28FIB%29ylabel=Active%20BGP%20entries%20%28FIB%29with=step

(Short url: http://tiny.cc/An6fl )

If you are in the connectivity business, you can add a caption to this 
graph of your choosing:


Ignore at your own peril.

Or (I like this one):

I see opportunity.

However, the question still stands about the stability, and therefor, 
utility of the v6 'Net.  Is it still some bastard child, some beta test, 
some side project?  


As you know, the IPv4 Internet of today is a product of the hard work of 
people of yore (ok well, more seriously, a large number of the people on 
this list and at networks around the world).


The nature of things is that the coherent shared illusion of a single 
Internet routing table is the result of a rough consensus produced by 
years and years and years of accumulated business relationships and 
network engineer routing policy configurations.


IPv6 is going through that phase right now, at accelerated pace.

Perhaps geometric growth is not good enough for you as a business 
person.  Perhaps where we are on the curve is not good enough for you 
yet.  Perhaps you'd like to retire before working with another protocol.


I hereby apologize to you on behalf of IPv6 that it has not had the same 
three decades of deployment and experimentation as IPv4. ;)


IPv6 is not going to spring into existence as a fully complete global 
network to replace IPv4 on a specific flag day (December 21st 2012?).


IPv6 will grow in deployment at the same time the Internet continues to 
work, at what appears to be on a geometric growth curve, due to some 
reasons a business economist can write a paper about.  Network effect? 
Risk avoidance due to IPv4 run out?  Risk avoidance due to technology 
shift?  Yukon gold rush?  The after the fact result of careful planning 
by thoughtful people started years earlier?  Or perhaps, the projected 
functional economic value of IP addresses?


Or is it ready to have _revenue_producing_ traffic 
put on it?


IPv6 is production for some value of the word production.  We see 
traffic around 1.5 Gbps, peaks at 2 Gbps and growing...


Perhaps this says something about the amount of traffic that will be 
seen when it gets used widely.


1000 times as much?  (Our guess)  What's your guess?

Warning!  If you pick a low number you are saying that IPv6 is in 
widespread production use right now.  :-P


In summary, we have the standard Chicken  Egg problem.  No one cares 
about v6,


speak for yourself (introduce into evidence exhibit 1: the graph linked 
to above, exhibit 2: we note how part of the original poster's problem 
got fixed that day).



so no one puts anything important on v6,


speak for yourself (reference real traffic above).

Once upon a time, something called IPv4 was invented, and some people 
created hardware for it, wrote software for it, tried it out, wrote some 
papers, wrote some RFCs (after writing working code, the way it should 
be done LOL), and then experimented some more.  There were lots of 
problems that got solved, things that worked in real life in spite of 
theoretical problems, and bugs that got fixed.  Some companies got 
created... blah blah blah.


Sad times for the future of the Internet if we all need to use v6 
Real Soon Now.


Or, expect real freaking huge opportunity and dislocation ahead.

Of course, this dislocation may only affect some specific players and 
companies and industries.  For the regular user it could just happen 
transparently that by the time they get their next computer with 
Microsoft Windows 9 or Ubuntu Quick Quagga... it just works.


Imagine, what would it be like if all the core network operators 

Re: IPv6 internet broken, cogent/telia/hurricane not peering

[Mike Leber]

Igor Ybema wrote:

I recently noticed that there seems a peering issue on the ipv6 internet.
As we all know hurricane is currently the largest ipv6 carrier. Other large
carriers are now implementing ipv6 on their networks, like Cogent and Telia.

However, due to some politics it seems that they are not peering with each
other resulting in a broken ipv6 internet currently. I noticed this by using
the looking glasses from telia and hurricane.


I'll spell it out for your entertainment.

Hurricane aggressively tries to solve connectivity problems, IPv4 or IPv6.

In the case of Cogent, they hilariously are trying to reduce peering 
with Hurricane over time.


Hurricane has IPv4 peering with Cogent.  Years ago this was at four 
locations in the world, then this was at three locations in the world, 
then two locations in the world.  Why?  Because over time when a BGP 
session would go down for longer than 30 seconds, Cogent permanently 
shut the session.  Both Cogent and Hurricane have progressively lowered 
the local preference and otherwise filtered the routes we receive from 
each other to prevent the connections from saturating due to the size of 
our networks and the number of prefixes we each announce.


These connections were a combination of OC12s in the US and public 
peering in Europe.  Hurricane repeatedly over the years has pushed to 
replace the OC12s with atleast giges (if not 10GE), on the principle it 
would be cheaper, conform to more of the hardware each of us uses, allow 
us to remove legacy OC12 cards from the network, etc.  Cogent hasn't.


Why?

Because even though they are content heavy and due to the routing tables 
one might infer they don't have settlement free peering with all 
networks, they don't want to help Hurricane in any way.


Ok, fine.  Not everybody choses to operate their network this way, 
usually most are more concerned about their customers, however hey who 
am I to say whatever they view as their core mission isn't being met.


If you've been around long enough, you'd know that normally nobody talks 
about peering publicly like this.  Most of the core network operators 
here could just infer what I told you above.


Then why would I write this post?

Because I want to set the record straight regarding Hurricane Electric's 
IPv6 peering goals, and nothing in Cogent's case seems to get through to 
them.


Oh, BTW, let me describe the special case of irony.  If Cogent wanted to 
ensure they weren't in a subservient role in IPv6 as they are for IPv4 
(and I'm not talking about Hurricane, I'm talking about all the networks 
they've ever had to pay or fight in one way or another), then they would 
be working to have a complete IPv6 table by working with a player like 
Hurricane which reduces their dependency on networks that will be 
difficult with them, that is: be cooperative with them rather than give 
them a huge amount of crap and try to torture them at each turn (i.e. in 
order to get peering you need to buy these local loops, etc etc etc).


BTW, regarding the comments about 6to4, with Hurricane Electric you will 
reach more of the IPv6 Internet, with lower latency than anybody else.



I already asked hurricane about their point of view. They simply just ignore
it because they 'are the biggest one'.


We don't ignore comments about connectivity, in fact quite the opposite. 
 We study each AS and which ASes are behind them.  We work on getting 
peering with the specific AS, in the case that they are unresponsive, 
getting the ASes behind them.


Among the things we do to discuss peering: send email to any relevant 
contacts, call them, contact them on IRC, send people to the relevant 
conferences to seek them out specifically, send people to their offices, 
etc.


So far we stop short of baking cakes, but hey...

Our goal is to provide as much connectivity to as many people as possible.

That might be our goal, however, not everybody's goal on the Internet is 
to provide as much connectivity as possible for their customers.


Mike.

Re: IXP

[Mike Leber]

Leo Bicknell wrote:

In a message written on Fri, Apr 24, 2009 at 01:48:28AM +, Paul Vixie wrote:

i think i saw several folks, not just stephen, say virtual wire was how
they'd do an IXP today if they had to start from scratch.  i know that
for many here, starting from scratch isn't a reachable worldview, and so
i've tagged most of the defenses of shared subnets with that caveat.  the
question i was answering was from someone starting from scratch, and when
starting an IXP from scratch, a shared subnet would be just crazy talk.


I disagree.

Having no shared subnet renders an exchange switching platform
useless to me.  If I have to go to all the work of configuring both
ends in a exchange point operator provisioning system (and undoubtly
being billed for it), assigning a /30, and configuring an interface
on my router then I will follow that procedure and order a hunk of
fiber.  Less points of failure, don't have to deal with how the
exchange operator runs their switch, and I get the bonus of no
shared port issues.

The value of an exchange switch is the shared vlan.  I could see
an argument that switching is no longer necessary; but I can see
no rational argument to both go through all the hassles of per-peer
setup and get all the drawbacks of a shared switch.  Even exchanges
that took the small step of IPv4 and IPv6 on separate VLAN's have
diminished value to me, it makes no sense.

It's the technological equvilient of bringing everyone into a
conference room and then having them use their cell phones to call
each other and talk across the table.  Why are you all in the same
room if you don't want a shared medium?


I second that.

We got to go through all the badness that was the ATM NAPs (AADS, 
PacBell NAP, MAE-WEST ATM).


I think exactly for the reason Leo mentions they failed.  That is, it 
didn't even require people to figure out all the technical reasons they 
were bad (many), they were fundamentally doomed due to increasing the 
difficulty of peering which translated to an economic scaling problem.


i.e. if you make it hard for people to peer then you end up with less 
peers and shared vlan exchanges based on things like ethernet outcompete 
you.


Been there done that.

We've already experienced the result of secure ID cards and the 
PeerMaker tool.  It was like pulling teeth to get sessions setup, and 
most peers plus the exchange operator didn't believe in oversubscription 
(can you say CBR?  I knew you could), so you end up with 2 year old 
bandwidth allocations cast in stone because it was such a pain to get 
the peer to set it up in the first place, and to increase bandwidth to 
you means your peer has to reduce the bandwidth they allocated to 
somebody else.


Mike.

--
+ H U R R I C A N E - E L E C T R I C +
| Mike LeberWholesale IPv4 and IPv6 Transit  510 580 4100 |
| Hurricane Electric   AS6939 |
| mle...@he.net Internet Backbone  Colocation  http://he.net |
+-+

Re: 97.128.0.0/9 allocation to verizon wireless

[Mike Leber]

David Conrad wrote:

On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote:

so if they don't deploy IPv6 then ('extremely high growth period'),
when will they?


Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled?


haha, I went insane for a moment and though you said Freenix top 1000, 
and so I just checked that.  Here is the answer to the question you 
didn't ask:


Top 1000 Usenet Servers in the World
list here: http://news.anthologeek.net/top1000.current.txt
details here: http://news.anthologeek.net

1000 usenet server names
913 are potentially valid hostnames (in usenet news a server name does 
necessarily correspond directly to a hostname)

722 have ipv4 address records (A)
67 have ipv6 address records ()
9.2% of the top 1000 usenet servers have added support for ipv6

I'm sure there are more this took exactly 183 seconds of work. ;)

Here they are:

feeder.erje.net 2001:470:992a::3e19:561
feeder4.cambrium.nl 2a02:58:3:119::4:1
news.dal.ca 2001:410:a010:1:214:5eff:fe0a:4a4e
news.nonexiste.net 2002:6009:93d5::1
nrc-news.nrc.ca 2001:410:9000:2::2
news.z74.net 2001:610:637:4::211
news.kjsl.com 2001:1868:204::104
npeer.de.kpn-eurorings.net 2001:680:0:26::2
feeder6.cambrium.nl 2a02:58:3:119::6:1
feeder3.cambrium.nl 2a02:58:3:119::3:1
news.belnet.be 2001:6a8:3c80::38
feeder2.cambrium.nl 2a02:58:3:119::2:1
feeder5.cambrium.nl 2a02:58:3:119::5:1
syros.belnet.be 2001:6a8:3c80::17
vlad-tepes.bofh.it 2001:1418:13:1::5
news.stack.nl 2001:610:1108:5011:230:48ff:fe12:2794
ikarus.belnet.be 2001:6a8:3c80::38
news.space.net 2001:608::1000:7
feed.news.tnib.de 2001:1b18:f:4::4
newsfeed.velia.net 2a01:7a0:3::254
news.isoc.lu 2001:a18:0:405:0:a0:456:1
ikaria.belnet.be 2001:6a8:3c80::39
newsfeed.teleport-iabg.de 2001:1b10:100::119:1
news.tnib.de 2001:1b18:f:4::2
kanaga.switch.ch 2001:620:0:8::119:2
erode.bofh.it 2001:1418:13:1::3
irazu.switch.ch 2001:620:0:8::119:3
bofh.it 2001:1418:13::42
newsfeed.atman.pl 2001:1a68:0:4::2
news.mb-net.net 2a01:198:292:0:210:dcff:fe67:6b03
news.gnuher.de 2a01:198:293::2
switch.ch 2001:620:0:1b::b
news.k-dsl.de 2a02:7a0:1::5
news.task.gda.pl 2001:4070:1::fafe
news1.tnib.de 2001:1b18:f:4::2
aspen.stu.neva.ru 2001:b08:2:100::96
novso.com 2001:1668:2102:4::4
citadel.nobulus.com 2001:6f8:892:6ff::11:133
feeder.news.heanet.ie 2001:770:18:2::c101:db29
news-zh.switch.ch 2001:620:0:3::119:1
news.szn.dk 2001:1448:89::10:d85d
news.litech.org 2001:440:fff9:100:202:b3ff:fea4:a44e
news.weisnix.org 2001:6f8:892:6ff:213:8fff:febb:bec3
news.panservice.it 2001:40d0:0:4000::e
nntp.eutelia.it 2001:750:2:3::20
bolzen.all.de 2001:bf0::60
newsfeed.esat.net 2001:7c8:3:1::3
news.snarked.org 2607:f350:1::1:4
feed1.news.be.easynet.net 2001:6f8:200:2::5:46
aotearoa.belnet.be 2001:6a8:3c80::58
news.babsi.de 2a01:198:292:0:230:48ff:fe51:a68c
news.muc.de 2001:608:1000::2
newsfeed.carnet.hr 2001:b68:e160::3
news.nask.pl 2001:a10:1:::3:c9a2
news.linuxfan.it 2001:4c90:2::6
texta.sil.at 2001:858:2:1::2
news.stupi.se 2001:440:1880:5::10
news.supermedia.pl 2001:4c30:0:3::12
news.trigofacile.com 2001:41d0:1:6d44::1
nuzba.szn.dk 2001:6f8:1232::263:8546
geiz-ist-geil.priv.at 2001:858:666:f001::57
newsfeed.sunet.se 2001:6b0:7:88::101
news.pimp.lart.info 2001:6f8:9ed::1
glou.fr.eu.org 2001:838:30b::1
news.germany.com 2001:4068:101:119:1::77
feeder.z74.net 2001:610:637:4::211
news.nask.org.pl 2001:a10:1:::3:c9a2

Mike.

--
+ H U R R I C A N E - E L E C T R I C +
| Mike LeberWholesale IPv4 and IPv6 Transit  510 580 4100 |
| Hurricane Electric   AS6939 |
| mle...@he.net Internet Backbone  Colocation  http://he.net |
+-+

Re: IPv6 routing /48s

[Mike Leber]

Christopher Morrow wrote:
Jack Bates wrote:

A good example is that traceroutes through my he.net tunnel using 6to4
source addresses do not get replies through he.net's network, presumably due
to their routers not being 6to4 aware and having no route to respond.


can you explain this a little more? is it possible your v6 packets hit
something like 6pe inside HE and exit to NTT without hitting a


(Chris thank you for automatically going into customer service mode :)

A bunch of background first, then some questions to help diagnose this 
specific case.


We don't filter 6to4 in any way.

We don't run 6PE.

We don't operate any 6to4 gateways.

We've been considering it carefully, and haven't taken the plunge. 
There is sort of a routing the whole Internet for free aspect that 
will occur as v6 takes off and it's not clear how one manages that (i.e. 
If you do it in the beginning until people depend on it and traffic 
grows to 100 Gbps and you no longer can afford to do it for free, do you 
stop?  What about all the IPv4 traffic traveling directly between 6to4 
gateways on IPv4?  abuse, security, man in the middle by definition, etc).


This means any 6to4 gateway action is happening on somebody's 6to4 
gateway not operated by us.


There are people that are using 6to4 on our network that works just 
fine.  You can reach several 6to4 gateways on both IPv4 and IPv6 via our 
network.


However, what is likely happening is a random 6to4 gateway operator may 
have seen fit to rate limit or filter ICMP.


To properly diagnose 6to4 problems you potentially need as many as 4 
traceroutes, IPv6 traceroutes from the source and destination endpoints 
and a IPv4 traceroutes to the 6to4 gateway addresses from the source and 
destination endpoint.  There a few other tips I'm forgetting at the 
moment, however if you send us email (to [EMAIL PROTECTED]) we will make sure 
to research it thoroughly.


Because 6to4 gateways are *anycast* the gateways you use in any part of 
the world in any part of a specific network may be different.


This makes debugging it interesting.


Responses pick up again after picking up a network such as NTT that is 6to4
aware. My 2001:: addressing works just fine the entire route.


'6to4 aware' doesn't compute...


Jack, it seems you are saying traffic passes end to end just fine, you 
just don't get ICMP responses from some of the hops in the middle.  Is 
this correct?


If you would like, please send email to [EMAIL PROTECTED] with the detail 
regarding what you are seeing with all of the endpoint information and 
the traceroutes and we will work from our side to see where the 
interesting 6to4 gateway is that is affecting your traceroute.  We 
will probably also need you to have access to the destination side as well.


Mike.

--
+ H U R R I C A N E - E L E C T R I C +
| Mike LeberWholesale IPv4 and IPv6 Transit  510 580 4100 |
| Hurricane Electric   AS6939 |
| [EMAIL PROTECTED] Internet Backbone  Colocation  http://he.net |
+-+

Re: IPv6 nameserver glue chez netsol

[Mike Leber]

We tried getting Network Solutions to add an  glue record by sending
email to various addresses (starting with the one below) with no success,
and then switched to calling.

Their after hours customer service didn't know anything about IPv6 host
records or IPv6 nameserver glue, however their regular business hours
customer service was knowledgeable, professional, and knew exactly what to
do and had  records added for our nameservers that day.

We went with adding  records to ns2,ns3,ns4,ns5.he.net.  We are still
in the process of adding ns4 and ns5 to various domains etc.  We deferred
getting an  host record added for ns1.he.net for the sake of being
conservative because we provide authorative DNS for alot of domain names.  
The nameserver ns1.he.net does have an  record for itself.

The he.net website has been running with an  record for quite a while
and we've yet to get a single call or ticket involving a customer that
couldn't reach it due to misconfigured IPv6.  We get lots of regular
server and router tickets with IPv6 configuration questions.

It would be great if Network Solutions would add IPv6 nameserver glue
support to their web interface so that customers get a consistently
successful experience.

Mike.

On Sat, 26 Jul 2008, Jared wrote:

 Their page for changing DNS servers mentions:
 
 Advanced Users:
 
 To specify your IPv6 name server address (IPv6 glue record), e-mail us 
 the domain name, the host name of the name server(s), and their IPv6 
 address(es).
 
 With the e-mail us being:
 
 [EMAIL PROTECTED]
 
 William Waites wrote:
  Hi all,
  
  Does anyone have a contact or a known administrative path to get  NS 
  glue added to
  domains registered with Network Solutions? Or is the only choice to move 
  the domains in
  question to a different registrar?
  
  (Perhaps more appropriate for dns-operations, but as it is an 
  operational question and my
  subscription request is awaiting moderator approval, I hope nobody will 
  mind my posting
  it here)
  
  Cheers,
  -w
 

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber Wholesale IPv4 and IPv6 Transit   510 580 4100 |
| Hurricane Electric Web Hosting  Colocation AS6939 |
| [EMAIL PROTECTED]   http://he.net |
+---+

Re: Creating demand for IPv6, and saving the planet

[Mike Leber]

On Wed, 3 Oct 2007, Daniel Senie wrote:
 BTW, thanks for bringing this thread back to the question of creating 
 demand for IPv6. There's plenty of anti-NAT activity on other 
 threads. Some constructive discussion over ways to create incentives 
 to deploy IPv6 is worthwhile. The most common argument for deployment 
 of IPv6 is fear, as in the sky is falling. Yeah, we all heard that, 
 and have for a decade. Got it. Now, is there some POSITIVE reason to 
 push IPv6? Fear is not a positive force.

Ok, I'll bite and throw out a wacky idea I've been mulling over.

As the data at http://bgp.he.net/ipv6-progress-report.cgi shows for the
IPv6 and IPv4 nameserver tests, some of the time IPv6 connectivity is
*faster* than IPv4 connectivity (66 out of 264 test cases), because of
network topology differences due to different peering and transit
relationships between IPv4 and IPv6.

So you could write a download accelerator for your browser that checked
IPv6 vs IPv4 connectivity and used whichever was faster.

With only 3 percent of neworks running IPv6 this idea is a little early,
still it would be a hilarious browser plug-in.  You could imagine it might
even have a little IPv6 accelerator icon that shows up in your status
bar when you've switched on the nitro.

(hehehe, shaving off that extra few ms of latency, yo!)

Mike.

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber Wholesale IPv4 and IPv6 Transit   510 580 4100 |
| Hurricane Electric Web Hosting  Colocation AS6939 |
| [EMAIL PROTECTED]   http://he.net |
+---+

Rudimentary IPv6 Progress Report Page

[Mike Leber]

I've been messing around with parsing MRT format IPv6 BGP tables and saw
Randy's posts about deployment progress (or lack thereof), so I threw
together this site:

http://bgp.he.net/ipv6-progress-report.cgi

It gives a rough estimate of the percentage of:

* Networks that run IPv6 (currently 3%).

* IPv6 reverse DNS servers that are reachable via IPv6 (currently 31.6%,
believe it or not, most are only reachable via IPv4).  If you have IPv6
reverse DNS servers, do they have an  record for themselves?

* ISPs on the ipv6tf.org ISP list with IPv6 websites (currently 32.2%).
(I'll be the first to admit that Hurricane has a bunch of sites that need
to be fixed to work with IPv6, we just added an  record for bgp.he.net
before posting this.)

* Alexa 500 websites that are IPv6 enabled (currently 0%).

The site is a work in progress.  Feel free to send me suggestions.

Mike.

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber Wholesale IPv4 and IPv6 Transit   510 580 4100 |
| Hurricane Electric Web Hosting  Colocation AS6939 |
| [EMAIL PROTECTED]   http://he.net |
+---+

Re: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)

[Mike Leber]

 if that is the problem you are
trying to fix.

If somebody helps Bill with his IPv6 config, please remove the 3ffe prefix
announcement as it is still there, we just happen to be filtering it.

Mike.

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber   Direct Internet Connections   Voice 510 580 4100 |
| Hurricane Electric Web Hosting  Colocation   Fax 510 580 4151 |
| [EMAIL PROTECTED]   http://www.he.net |
+---+