Re: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care?

[Ronald F. Guilmette]

In message , John van Oppen  wrote:

>Why does it matter what his position is?

Well, if he was, you know, just the janitor or something, then I think
that we could all safely assume that his opinions are...well.. his opinions,
and that they should not be improperly or unfairly construed as official
statements on behalf of the company.  Wouldn't you agree?

I, for one, certainly don't want to unfairly interpret some personal
comment on the part of some worker bee as being the equivalent of an
official company pronouncement.  Do you?

>Sounds like they had a forged LOA from the customer...

And they provided service for free??  For three months??  All just on the
basis of a sheet of paper that any fool could trivially manufacture in 15
minutes or less at the local Kinkos?  Sorry.  No.  I think not.

Money was paid.  Money changed hands.  Which hands did it come from?  From
the hijacker crook, obviously.  But which one?  (There are so many different
crooks on the Internet these days.)  What was this one's name?  Not the
phony blaoney name that was on the LOA.  That really doesn't matter.  The
name on the check.

>...and that they fixed the issue...

I'm sorry to disagree, but no, actually, it didn't.

As I pointed out in the very message that you are responding to, nothing here
is ``fixed'', nothing here is ``resolved'', and the evidence seems to indi-
cate that the exact same snowshoe spammer who was spamming out of the
hijacked block that was getting connectivity from Circle Internet and also,
indirectly, from Integra Telecom is still very much alive and well and still
operating within the UN-hijacked portion of Circle Internet's IP space.

I understand that now that the _hijacking_ part of this tiny drama has been
terminated, some folks, here and elsewhere, would prefer now to just roll
over and go back to sleep.  That's your choice and you're welcome to it.
I, however, would sort-of still like to see the perp being escorted to the
exit of the entire Internet, along with a swift kick in the ass and an
admonition never to come back again.

That clearly hasn't happened yet, and what with all the corporate CYA going
on it doesn't even look probable any time soon.

>I am not sure you can ask too much more from a network operator

Yea.  Gee, I guess you're right.  Expecting honesty, courtesy, forthrightness,
and enough information to make sure that other networks will not be similarly
tainted in the future is just completely out of the question.

That's apparently far too much care and compassion for one's community and
one's fellow man to expect from any CORPORTATION, after all.

Please excuse me for harboring patently ridiculous hopes and/or expectations.

>the best thing we can hope for are companies that will cancel customers if
>they are abuse sources...

That may be the best that _you_ are capable of hoping for.  Me personally?
I set my sights a little higher.

Maybe someday... perhaps not in my lifetime, but someday... when there is
a lot less corporate CYA and just a little bit more civic responsibility,
then maybe we really could get these kinds of crooks off the Internet in
a way so that they don't just reappear someplace else a month or two down
the road, when things have quieted down.

Look, here's two scenarios.  See if you can fit them both together in a
way that makes sense.  I can't.

If I go into Macy's, charge a pair of shoes on my Macy's credit card, and
then, when I get my monthy charge account bill, I simply don't pay it, then
within 30 days, Equifax, Experian and TransUnion will all know about that,
and they will go around blabbing to every other merchant in the world, and
pretty soon I won't be able to buy even a stick of bubble gum on credit.
(Note that _Macy's_ apparently has no trouble ratting out _it's_ less than
savory customers.)

If however I collude with some friendly and/or greedy ISP/NSP or two on the
Internet, hijack a /16 or two, get caught, and get publically outted, then
I can be reasonably assured that all of the greedy companies, all the way
up and down the entire networking food chain will instantly clam up, you
know, just to avoid having to admit that they profited from my scheme too.
So I can also be reasonably sure, going in, that even if I'm caught,
not only will I not be punished in any way, but better still, I'll be able
to just wait a few weeks and then just go down the street to the next
greedy ISP/NSP and pull the exact same scam all over again.  And nobody
except the companies that I've paid off will ever even know my name.

If this all makes sense to anybody, then please do explain it to me, because
I'm not seeing it.  All I see is a sure-fire recipie for an endless cavalcade
of IP hijacking incidents.  For the perp, there is simply no downside whatso-
ever, even if he gets caught, so he's just gonna do it over and over and
over again.

Which part of this is either non-clear or non-obvious?


Regards,
rfg

Re: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care?

[Rich Kulawiec]

On Fri, Apr 01, 2011 at 01:36:55AM -0400, Atticus wrote:
> Maybe, if you didn't act like a flaming douchebag, and were polite to
> people, they would be more interested in helping you out. 

And were it ten or fifteen years ago, I might agree with you.

But it's not.  By now, everyone knows, or darn well should know, that abuse
of all descriptions has long since passed the threshold of "epidemic" and
is approaching "pervasive".  With that in mind, everyone should also realize
that it's their obligation to do anything/everything they can to assist the
collaborative network community in (a) identifying abusers and (b) denying
them services -- permanently.

Which means that if, for example, an entity is identified as being
involved in network hijacking or phishing or spamming or whatever, that
everything known about them should be published -- including scans of any
paper documents involved.   There is no reason to protect filth like this,
and every reason to out them.  They flourish, in large part, precisely
because that *doesn't* happen.

And while Ron's bedside manner might be a little abrasive from time to
time (and so's mine, so I'm not criticizing), he's a cupcake compared to
kind of sociopaths we're up against.  If you can't handle a few mildly
toasty comments from him, then you're no match at all for them.

So the hell with his prose: focus on the matter at hand.  Let's find out
what happened here and how, who's responsible, and what it'll take to stop
them from doing it again and again.

Because they will.

---rsk

v6 Avian Carriers?

[Sachs, Marcus Hans (Marc)]

I was wondering which April 1st this would happen on.   Now I know.  So if a v6 
carrier swallows a v4 datagram does that count as packet loss or tunneling?

http://datatracker.ietf.org/doc/rfc6214/


Marc

Re: v6 Avian Carriers?

[Jeff Walter]

On 4/1/2011 5:41 AM, Sachs, Marcus Hans (Marc) wrote:

I was wondering which April 1st this would happen on.   Now I know.  So if a v6 
carrier swallows a v4 datagram does that count as packet loss or tunneling?

http://datatracker.ietf.org/doc/rfc6214/


Depending on whether or not the packet arrived at its destination 
determines if it is loss or tunneling.  In the event it is tunneled, 
please be certain to filter the packet as de-encapsulation is a bit... 
messy.
<>

Re: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care?

[C. Jon Larsen]

So the hell with his prose: focus on the matter at hand.  Let's find out
what happened here and how, who's responsible, and what it'll take to stop
them from doing it again and again.


Well put.

--
This message has been scanned for viruses and
dangerous content by the Richweb.com outgoing MailScanner
and is believed to be clean.

Re: v6 Avian Carriers?

[Scott Morris]

Mmm...  Good question.  Would it actually come back OUT in a
recognizable (de-encapsulated) manner?

I'll vote with packet loss, 'cause tunneling seems pretty gross.   ;)

Scott


On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote:
> I was wondering which April 1st this would happen on.   Now I know.  So if a 
> v6 carrier swallows a v4 datagram does that count as packet loss or tunneling?
>
> http://datatracker.ietf.org/doc/rfc6214/
>
>
> Marc
>
>
>

Re: v6 Avian Carriers?

[GP Wooden]

I wonder on the carrier would survive a DoS attack ... 

- Reply message -
From: "Scott Morris" 
Date: Fri, Apr 1, 2011 9:01 am
Subject: v6 Avian Carriers?
To: 

Mmm...  Good question.  Would it actually come back OUT in a
recognizable (de-encapsulated) manner?

I'll vote with packet loss, 'cause tunneling seems pretty gross.   ;)

Scott


On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote:
> I was wondering which April 1st this would happen on.   Now I know.  So if a 
> v6 carrier swallows a v4 datagram does that count as packet loss or tunneling?
>
> http://datatracker.ietf.org/doc/rfc6214/
>
>
> Marc
>
>
>

Re: Re: v6 Avian Carriers?

[Valdis . Kletnieks]

On Fri, 01 Apr 2011 09:30:45 CDT, =?utf-8?B?R1AgV29vZGVu?= said:
>  wonder on the carrier would survive a DoS attack ... 

RFC1149 says:

   Avian carriers can provide high delay, low throughput, and low
   altitude service.  The connection topology is limited to a single
   point-to-point path for each carrier, used with standard carriers,
   but many carriers can be used without significant interference with
   each other, outside of early spring.  This is because of the 3D ether
   space available to the carriers, in contrast to the 1D ether used by
   IEEE802.3.  The carriers have an intrinsic collision avoidance
   system, which increases availability.

The carriers are also (over time) self-regenerating in case one gets lost or
corrupted due to collision or interception...





pgpPxXhOi5Abr.pgp
Description: PGP signature

Re: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care?

[Hank Nussbacher]

On Fri, 1 Apr 2011, Rich Kulawiec wrote:


On Fri, Apr 01, 2011 at 01:36:55AM -0400, Atticus wrote:

Maybe, if you didn't act like a flaming douchebag, and were polite to
people, they would be more interested in helping you out.


And were it ten or fifteen years ago, I might agree with you.

But it's not.  By now, everyone knows, or darn well should know, that abuse
of all descriptions has long since passed the threshold of "epidemic" and
is approaching "pervasive".  With that in mind, everyone should also realize
that it's their obligation to do anything/everything they can to assist the
collaborative network community in (a) identifying abusers and (b) denying
them services -- permanently.

Which means that if, for example, an entity is identified as being
involved in network hijacking or phishing or spamming or whatever, that
everything known about them should be published -- including scans of any
paper documents involved.   There is no reason to protect filth like this,
and every reason to out them.  They flourish, in large part, precisely
because that *doesn't* happen.

And while Ron's bedside manner might be a little abrasive from time to
time (and so's mine, so I'm not criticizing), he's a cupcake compared to
kind of sociopaths we're up against.  If you can't handle a few mildly
toasty comments from him, then you're no match at all for them.

So the hell with his prose: focus on the matter at hand.  Let's find out
what happened here and how, who's responsible, and what it'll take to stop
them from doing it again and again.

Because they will.

---rsk


Well put, but falling on deaf ears.  "Oh, we are not the police" mantra is 
either an excuse for being an idiot or too anal to see what should be 
done.  But when gov'ts will step in to make sure this type of issue is 
fixed in thye future, those same talking heads will be crying about how 
the Internet is now ruined.


I've been down this path all too often to know you are tilting at 
windmills.  Live with it.  I do.


-Hank

RE: IPv4 Address Exhaustion Effects on the Earth

[George Bonser]

> From: Joao C. Mendes Ogawa 
> Sent: Thursday, March 31, 2011 6:14 PM
> Subject: Fwd: IPv4 Address Exhaustion Effects on the Earth
> 
> FYI
> 
> --Jonny Ogawa
> 
> - Forwarded message from Stephen H. Inden -
> 

Dang,  I was hoping to see an RFC on Bufferbloat in Avian Carriers and
how tail-drop is a messy solution that is to be avoided.

Oh well.

Re: Re: v6 Avian Carriers?

[Brandon Ross]

On Fri, 1 Apr 2011, GP Wooden wrote:


I wonder on the carrier would survive a DoS attack ...


I'm not sure about that, but we know that, if a Sullenberger unit has been 
installed, a large aircraft can survive a DoS attack perpetrated by the 
avian carrier.


--
Brandon Ross  AIM:  BrandonNRoss
   ICQ:  2269442
   Skype:  brandonross  Yahoo:  BrandonNRoss

HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care?

[Atticus]

Please note, I'm not arguing against fixing the problem. I just think we
should show each other some professional respect, and use some manners.

Re: Re: v6 Avian Carriers?

[Dorn Hetzel]

I was thinking today would be a good day to write an RFC for "fractional
DHCP" where end-users can get issued say 1/64 of an v4 IP, say
155.229.10.20:1024-2047.  Other users on the same DSLAM, etc behind the
carrier NAT would have other shares of the same public IP.   :)

On Fri, Apr 1, 2011 at 12:19 PM, Brandon Ross  wrote:

> On Fri, 1 Apr 2011, GP Wooden wrote:
>
>  I wonder on the carrier would survive a DoS attack ...
>>
>
> I'm not sure about that, but we know that, if a Sullenberger unit has been
> installed, a large aircraft can survive a DoS attack perpetrated by the
> avian carrier.
>
> --
> Brandon Ross  AIM:
>  BrandonNRoss
>   ICQ:  2269442
>   Skype:  brandonross  Yahoo:  BrandonNRoss
>
>

Re: Re: v6 Avian Carriers?

[Justin M. Streiner]

On Fri, 1 Apr 2011, Dorn Hetzel wrote:


I was thinking today would be a good day to write an RFC for "fractional
DHCP" where end-users can get issued say 1/64 of an v4 IP, say
155.229.10.20:1024-2047.  Other users on the same DSLAM, etc behind the
carrier NAT would have other shares of the same public IP.   :)


Would the end-user get both the TCP and UDP ports from their assigned 
range?  Also, how would you handle ICMP/ESP/etc... or would those be 
'free with the purchase of..."?


jms

Re: Re: v6 Avian Carriers?

[Dorn Hetzel]

I'm thinking both TCP and UDP, and for ICMP don't NAT's use the sequence
number field to keep them separate ?

On Fri, Apr 1, 2011 at 1:08 PM, Justin M. Streiner
wrote:

> On Fri, 1 Apr 2011, Dorn Hetzel wrote:
>
>  I was thinking today would be a good day to write an RFC for "fractional
>> DHCP" where end-users can get issued say 1/64 of an v4 IP, say
>> 155.229.10.20:1024-2047.  Other users on the same DSLAM, etc behind the
>> carrier NAT would have other shares of the same public IP.   :)
>>
>
> Would the end-user get both the TCP and UDP ports from their assigned
> range?  Also, how would you handle ICMP/ESP/etc... or would those be 'free
> with the purchase of..."?
>
> jms
>
>

Re: v6 Avian Carriers?

[Andy Davidson]

On 1 Apr 2011, at 17:47, Dorn Hetzel wrote:

> I was thinking today would be a good day to write an RFC for "fractional 
> DHCP" where end-users can get issued say 1/64 of an v4 IP, say 
> 155.229.10.20:1024-2047.  Other users on the same DSLAM, etc behind the 
> carrier NAT would have other shares of the same public IP.   :)

Hi,

I'm not sure if this is an attempt at a continuation of the April Fools meme, 
or a serious idea, but this has kind already been thought of. :-)

https://mice.cs.columbia.edu/getTechreport.php?techreportID=560

It's a nice illustration that the only idea which doesn't suck post 
exhaustion[0], is IPv6.  

Andy




[0] i.e., now.

Re: v6 Avian Carriers?

[Steven Bellovin]

On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote:

> I was wondering which April 1st this would happen on.   Now I know.  So if a 
> v6 carrier swallows a v4 datagram does that count as packet loss or tunneling?
> 
> http://datatracker.ietf.org/doc/rfc6214/
> 

I was disappointed in this RFC -- Section 3.1 didn't include the proper 
discussion of the difference between African and European avian carriers, and 
we know what happens if that question is asked at the wrong time.
> 


--Steve Bellovin, https://www.cs.columbia.edu/~smb

WiMAX Multihost CPE/MS MTU enforcement

[Eric Morin]

Hi

Anyone out there deploying multihost CPE/MS with 16e WiMAX? 

Do your CPEs enforce a specific MTU (1400) for upstream traffic? 

I would like to hear from anyone (offline) that is dealing with MTU
challenges with mulithost 16e deployments.

 

 

Thanks!

 

Eric Morin

 

Re: v6 Avian Carriers?

[Antonio Querubin]

On Fri, 1 Apr 2011, Steven Bellovin wrote:

I was disappointed in this RFC -- Section 3.1 didn't include the proper 
discussion of the difference between African and European avian 
carriers, and we know what happens if that question is asked at the 
wrong time.


That discussion would be out of scope for the document's purpose as I 
believe African and European carriers are currently IP version agnostic. 
However, rapid genetic changes arising from the increased environmental 
radiation in the northern hemisphere vs that in the southern hemisphere 
due to the global circulation of the Japanese radioactive plume may 
require we revisit this issue in a few years.


Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.com

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 02 Apr, 2011

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  351604
Prefixes after maximum aggregation:  159727
Deaggregation factor:  2.20
Unique aggregates announced to Internet: 174049
Total ASes present in the Internet Routing Table: 37146
Prefixes per ASN:  9.47
Origin-only ASes present in the Internet Routing Table:   31182
Origin ASes announcing only one prefix:   15020
Transit ASes present in the Internet Routing Table:5019
Transit-only ASes present in the Internet Routing Table:133
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  24
Max AS path prepend of ASN (36992)   22
Prefixes from unregistered ASNs in the Routing Table:   516
Unregistered ASNs in the Routing Table: 226
Number of 32-bit ASNs allocated by the RIRs:   1247
Number of 32-bit ASNs visible in the Routing Table: 945
Prefixes from 32-bit ASNs in the Routing Table:2086
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:194
Number of addresses announced to Internet:   2393096992
Equivalent to 142 /8s, 163 /16s and 195 /24s
Percentage of available address space announced:   64.6
Percentage of allocated address space announced:   64.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   90.1
Total number of prefixes smaller than registry allocations:  145654

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:87503
Total APNIC prefixes after maximum aggregation:   29875
APNIC Deaggregation factor:2.93
Prefixes being announced from the APNIC address blocks:   84414
Unique aggregates announced from the APNIC address blocks:36682
APNIC Region origin ASes present in the Internet Routing Table:4385
APNIC Prefixes per ASN:   19.25
APNIC Region origin ASes announcing only one prefix:   1219
APNIC Region transit ASes present in the Internet Routing Table:696
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 20
Number of APNIC region 32-bit ASNs visible in the Routing Table: 45
Number of APNIC addresses announced to Internet:  601819680
Equivalent to 35 /8s, 223 /16s and 10 /24s
Percentage of available APNIC address space announced: 76.3

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
   55296-56319, 131072-132095
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
   182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
   219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:138612
Total ARIN prefixes after maximum aggregation:70802
ARIN Deaggregation factor: 1.96
Prefixes being announced from the ARIN address blocks:   13
Unique aggregates announced from the ARIN address blocks: 45000
ARIN Region origin ASes present in the Internet Routing Table:14282
ARIN Prefixes per ASN: 7.78
ARIN Region origin ASes announcing only one prefix:5446
ARIN Region transit ASes present in the 

Re: v6 Avian Carriers?

[Dave Edelman]

I believe that the Sullenberger unit effected the loss of the avian carriers 
requiring regeneration and retransmission. 

Dave Edelman


On Apr 1, 2011, at 12:19, Brandon Ross  wrote:

> On Fri, 1 Apr 2011, GP Wooden wrote:
> 
>> I wonder on the carrier would survive a DoS attack ...
> 
> I'm not sure about that, but we know that, if a Sullenberger unit has been 
> installed, a large aircraft can survive a DoS attack perpetrated by the avian 
> carrier.
> 
> -- 
> Brandon Ross  AIM:  BrandonNRoss
>   ICQ:  2269442
>   Skype:  brandonross  Yahoo:  BrandonNRoss
> 

Re: v6 Avian Carriers?

[Cutler James R]

On Apr 1, 2011, at 1:28 PM, Dorn Hetzel wrote:

> I'm thinking both TCP and UDP, and for ICMP don't NAT's use the sequence
> number field to keep them separate ?
> 

In my experience, the Avian Carriers usually eat the NATs.

James R. Cutler
james.cut...@consultant.com

Re: Re: v6 Avian Carriers?

[Richard Barnes]

Be careful what you wish for:



On Fri, Apr 1, 2011 at 6:47 PM, Dorn Hetzel  wrote:
> I was thinking today would be a good day to write an RFC for "fractional
> DHCP" where end-users can get issued say 1/64 of an v4 IP, say
> 155.229.10.20:1024-2047.  Other users on the same DSLAM, etc behind the
> carrier NAT would have other shares of the same public IP.   :)
>
> On Fri, Apr 1, 2011 at 12:19 PM, Brandon Ross  wrote:
>
>> On Fri, 1 Apr 2011, GP Wooden wrote:
>>
>>  I wonder on the carrier would survive a DoS attack ...
>>>
>>
>> I'm not sure about that, but we know that, if a Sullenberger unit has been
>> installed, a large aircraft can survive a DoS attack perpetrated by the
>> avian carrier.
>>
>> --
>> Brandon Ross                                              AIM:
>>  BrandonNRoss
>>                                                               ICQ:  2269442
>>                                   Skype:  brandonross  Yahoo:  BrandonNRoss
>>
>>
>

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 24-Mar-11 -to- 31-Mar-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS19743   34999  1.7%4999.9 -- 
 2 - AS982926736  1.3%  26.6 -- BSNL-NIB National Internet 
Backbone
 3 - AS423026664  1.3% 410.2 -- Embratel
 4 - AS11492   20928  1.0%  15.7 -- CABLEONE - CABLE ONE, INC.
 5 - AS178519164  0.9%  10.6 -- AS-PAETEC-NET - PaeTec 
Communications, Inc.
 6 - AS32528   18507  0.9%2313.4 -- ABBOTT Abbot Labs
 7 - AS35931   13922  0.7%2320.3 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 8 - AS27738   13691  0.7%  40.4 -- Ecuadortelecom S.A.
 9 - AS44609   13408  0.7%4469.3 -- FNA Fars News Agency Cultural 
Arts Institute
10 - AS17974   12580  0.6%   8.5 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
11 - AS638911461  0.6%   3.1 -- BELLSOUTH-NET-BLK - 
BellSouth.net Inc.
12 - AS949810309  0.5%  13.1 -- BBIL-AP BHARTI Airtel Ltd.
13 - AS25220   10035  0.5% 716.8 -- GLOBALNOC-AS Averbo GmbH
14 - AS201159533  0.5%   6.0 -- CHARTER-NET-HKY-NC - Charter 
Communications
15 - AS4583 9329  0.5% 345.5 -- WESTPUB-A - West Publishing 
Corporation
16 - AS285198906  0.4%2968.7 -- Universidad Autonoma de 
Guadalajara, A.C.
17 - AS7491 8762  0.4%  94.2 -- PI-PH-AS-AP PI-PHILIPINES
18 - AS311488457  0.4%  22.8 -- FREENET-AS FreeNet ISP
19 - AS121758294  0.4% 202.3 -- YELMNET - Yelm Telephone Company
20 - AS334757989  0.4%  37.2 -- RSN-1 - RockSolid Network, Inc.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS512806055  0.3%6055.0 -- AS51280 Parsian Electronic 
Commerce Company
 2 - AS19743   34999  1.7%4999.9 -- 
 3 - AS44609   13408  0.7%4469.3 -- FNA Fars News Agency Cultural 
Arts Institute
 4 - AS277716726  0.3%3363.0 -- Instituto Venezolano de 
Investigaciones Cientificas
 5 - AS285198906  0.4%2968.7 -- Universidad Autonoma de 
Guadalajara, A.C.
 6 - AS35931   13922  0.7%2320.3 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 7 - AS32528   18507  0.9%2313.4 -- ABBOTT Abbot Labs
 8 - AS496001514  0.1%1514.0 -- LASEDA La Seda de Barcelona, S.A
 9 - AS259111035  0.1%1035.0 -- TALISMAN-CH3 - TALISMAN ENERGY 
INC.
10 - AS13168 871  0.0% 871.0 -- SANOSTRA-AS AS de la Caja de 
ahorros y monte de piedad de las Baleares
11 - AS25220   10035  0.5% 716.8 -- GLOBALNOC-AS Averbo GmbH
12 - AS19984 522  0.0% 522.0 -- VSECU-ASN - Vermont State 
Employees Credit Union
13 - AS22288 507  0.0% 507.0 -- RFBKCORP - Republic First 
Bancorp, Inc.
14 - AS22060 497  0.0% 497.0 -- NETSPECTRUM - Netspectrum 
Wireless Internet Solutions
15 - AS12103 972  0.1% 486.0 -- KEYNOTE - Keynote Systems, Inc.
16 - AS275822711  0.1% 451.8 -- PTC-OKC-ASN - Perimeter 
Technology Center, LLC
17 - AS325141806  0.1% 451.5 -- COMEDCOM - CoMedia 
Communications, Inc.
18 - AS200941296  0.1% 432.0 -- MIDWEST-TEL - Midwest Telnet
19 - AS51983 862  0.0% 431.0 -- PROEVOLUTION PROEVOLUTION SRL
20 - AS27573 423  0.0% 423.0 -- OSLA-AS-1 - OKLAHOMA STUDENT 
LOAN AUTHORITY


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 85.197.100.0/229977  0.5%   AS25220 -- GLOBALNOC-AS Averbo GmbH
 2 - 130.36.34.0/24 9245  0.4%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.35.0/24 9245  0.4%   AS32528 -- ABBOTT Abbot Labs
 4 - 63.211.68.0/22 8037  0.4%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 5 - 221.121.96.0/196906  0.3%   AS7491  -- PI-PH-AS-AP PI-PHILIPINES
 6 - 178.22.79.0/24 6779  0.3%   AS44609 -- FNA Fars News Agency Cultural 
Arts Institute
 7 - 65.122.196.0/246654  0.3%   AS19743 -- 
 8 - 178.22.72.0/21 6618  0.3%   AS44609 -- FNA Fars News Agency Cultural 
Arts Institute
 9 - 212.80.25.0/24 6055  0.3%   AS51280 -- AS51280 Parsian Electronic 
Commerce Company
10 - 72.164.144.0/245684  0.3%   AS19743 -- 
11 - 65.162.204.0/245665  0.3%   AS19743 -- 
12 - 65.163.182.0/245665  0.3%   AS19743 -- 
13 - 66.238.91.0/24 5665  0.3%   AS19743 -- 
14 - 66.89.98.0/24  5665  0.3%   AS19743 -- 
15 - 198.140.43.0/245575  0.3%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
16 - 202.92.235.0/245286  0.2%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
17 - 68.65.152.0/22 3653  0.2%   AS11915 -- TELWEST-NETWORK-SVCS-STATIC - 
TEL WEST COMMUNICATIONS LLC
18 - 202.153.174.0/24   3566  0.2%   AS17408 -- ABOVE-AS-AP AboveNet 
C

The Cidr Report

[cidr-report]

This report has been generated at Fri Apr  1 21:12:20 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
25-03-11354537  207782
26-03-11354465  207768
27-03-11354472  207904
28-03-11354508  208231
29-03-11354730  208127
30-03-11354720  207889
31-03-11355112  208078
01-04-11354967  207765


AS Summary
 37242  Number of ASes in routing system
 15683  Number of ASes announcing only one prefix
  3669  Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
  109515264  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 01Apr11 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 354805   207776   14702941.4%   All ASes

AS6389  3669  262 340792.9%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  2545  400 214584.3%   TWTC - tw telecom holdings,
   inc.
AS4766  2431  917 151462.3%   KIXS-AS-KR Korea Telecom
AS6478  1591  183 140888.5%   ATT-INTERNET3 - AT&T Services,
   Inc.
AS22773 1292   93 119992.8%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS19262 1489  303 118679.7%   VZGNI-TRANSIT - Verizon Online
   LLC
AS10620 1405  289 111679.4%   Telmex Colombia S.A.
AS4755  1437  358 107975.1%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS1785  1790  768 102257.1%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS18566 1606  628  97860.9%   COVAD - Covad Communications
   Co.
AS28573 1263  325  93874.3%   NET Servicos de Comunicao S.A.
AS6503  1117  324  79371.0%   Axtel, S.A.B. de C.V.
AS24560 1135  346  78969.5%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS7545  1545  760  78550.8%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS18101  935  151  78483.9%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS7303   923  192  73179.2%   Telecom Argentina S.A.
AS4808  1036  325  71168.6%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS8151  1250  540  71056.8%   Uninet S.A. de C.V.
AS3356  1177  488  68958.5%   LEVEL3 Level 3 Communications
AS11492 1325  649  67651.0%   CABLEONE - CABLE ONE, INC.
AS17488  940  290  65069.1%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS17676  659   70  58989.4%   GIGAINFRA Softbank BB Corp.
AS855632   57  57591.0%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS3549   923  383  54058.5%   GBLX Global Crossing Ltd.
AS14420  642  103  53984.0%   CORPORACION NACIONAL DE
   TELECOMUNICACIONES - CNT EP
AS7552   636  100  53684.3%   VIETEL-AS-AP Vietel
   Corporation
AS22047  567   31  53694.5%   VTR BANDA ANCHA S.A.
AS22561  861  331  53061.6%   DIGITAL-TELEPORT - Digital
   Teleport Inc.
AS4780   717  210  50770.7%   SEEDNET Digital United Inc.
AS9443   570   74  49687.0%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications

Total  38108 99502815873.9%   Top 

Embratel or GVT contact

[Mark Wall]

Is there anyone from GVT or Embratel with a clue willing to help me with a
BGP route issue we are seeing?

Thanks

Re: v6 Avian Carriers?

[Fred Heutte]

which reminds me



Mr. ENGINEER: (yelling and hitting the send button repeatedly) 'ELLO
NOC! Testing! Testing! Testing! Testing! This is your nine o'clock
customer call!

(Takes RFC 791 out of the binder and thumps it on the counter. Throws it up
in the air and watches it plummet to the floor.)

Mr. ENGINEER: Now that's what I call a dead protocol.

NETWORK OPERATOR FROM HELL: No, no.No, 'e's truncated!

Mr. ENGINEER: TRUNCATED!?

NOFH: Yeah! You truncated him, just as he was bein' refactored!
Datagrams truncate easily, major.

Mr. ENGINEER: Um...now look...now look, mate, I've definitely 'ad
enough of this. That packet is definitely deceased, and when I deployed
it not 'alf an hour ago, you assured me that its total lack of
throughput was due to it bein' tired and shagged out following a
prolonged reroute.

NOFH: Well, he's...he's, ah...probably pining for the big iron.

Mr. ENGINEER: PININ' for the BIG IRON?!?!?!? What kind of talk is
that?, look, why did he fall flat on his back the moment I got 'im
through the router?

NOFH: The 4-byte prefers keepin' on it's back! Remarkable protocol,
id'nit, squire? Lovely octets!

Mr. ENGINEER: Look, I took the liberty of examining that packet when I
dispatched it, and I discovered the only reason that it had been
sitting in its queue in the first place was that it had been SWAPPED
there.

(pause)

NOFH: Well, o'course it was swapped there! If I hadn't swapped that
packet, it would have nuzzled up to that DMZ, bent it apart with its
handshake, and VOOM! Feeweeweewee!

Mr. ENGINEER: "VOOM"?!? Mate, this packet wouldn't "voom" if you put
four million hop counts on it! 'E's bleedin' demised!

NOFH: No no! 'E's pining!

Mr. ENGINEER: 'E's not pinin'! 'E's passed on! This packet is no more!
He has ceased to be! 'E's expired and gone to meet 'is archive! 'E's a
null set! Bereft of destination, 'e rests in /dev/null! If you hadn't
swapped 'im to the top of the queue 'e'd be pushing off the stack! 'Is
traceroutes are now 'istory! 'E's off the wire! 'E's kicked the bit
bucket, 'e's shuffled off the interwebs, run 'init 0' and joined the
bleedin' choir deprecated!! THIS IS AN EX-PACKET!!


-
>
>On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote:
>
>> I was wondering which April 1st this would happen on.   Now I know.  So if a 
>> v6 carrier
swallows a v4 datagram does that count as packet loss or tunneling?
>>
>> http://datatracker.ietf.org/doc/rfc6214/
>>
>
>I was disappointed in this RFC -- Section 3.1 didn't include the proper 
>discussion of the
difference between African and European avian carriers, and we know what 
happens if that
question is asked at the wrong time.
>>
>
>
>   --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>
>
>

Re: v6 Avian Carriers?

[Owen DeLong]

It's also especially sensitive to icing induced packet loss.

Owen

On Apr 1, 2011, at 7:30 AM, GP Wooden wrote:

> I wonder on the carrier would survive a DoS attack ... 
> 
> - Reply message -
> From: "Scott Morris" 
> Date: Fri, Apr 1, 2011 9:01 am
> Subject: v6 Avian Carriers?
> To: 
> 
> Mmm...  Good question.  Would it actually come back OUT in a
> recognizable (de-encapsulated) manner?
> 
> I'll vote with packet loss, 'cause tunneling seems pretty gross.   ;)
> 
> Scott
> 
> 
> On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote:
>> I was wondering which April 1st this would happen on.   Now I know.  So if a 
>> v6 carrier swallows a v4 datagram does that count as packet loss or 
>> tunneling?
>> 
>> http://datatracker.ietf.org/doc/rfc6214/
>> 
>> 
>> Marc
>> 
>> 
>> 
> 
> 

Re: v6 Avian Carriers?

[Michael K. Smith - Adhost]

I thought iced-over fiber was a little bit like muffler-bearings.  Great
excuse if they buy it.

Mike

On 4/1/11 6:07 PM, "Owen DeLong"  wrote:

>It's also especially sensitive to icing induced packet loss.
>
>Owen
>
>On Apr 1, 2011, at 7:30 AM, GP Wooden wrote:
>
>> I wonder on the carrier would survive a DoS attack ...
>> 
>> - Reply message -
>> From: "Scott Morris" 
>> Date: Fri, Apr 1, 2011 9:01 am
>> Subject: v6 Avian Carriers?
>> To: 
>> 
>> Mmm...  Good question.  Would it actually come back OUT in a
>> recognizable (de-encapsulated) manner?
>> 
>> I'll vote with packet loss, 'cause tunneling seems pretty gross.   ;)
>> 
>> Scott
>> 
>> 
>> On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote:
>>> I was wondering which April 1st this would happen on.   Now I know.
>>>So if a v6 carrier swallows a v4 datagram does that count as packet
>>>loss or tunneling?
>>> 
>>> http://datatracker.ietf.org/doc/rfc6214/
>>> 
>>> 
>>> Marc
>>> 
>>> 
>>> 
>> 
>> 
>
>

Re: v6 Avian Carriers?

[Owen DeLong]

On Apr 1, 2011, at 9:19 AM, Brandon Ross wrote:

> On Fri, 1 Apr 2011, GP Wooden wrote:
> 
>> I wonder on the carrier would survive a DoS attack ...
> 
> I'm not sure about that, but we know that, if a Sullenberger unit has been 
> installed, a large aircraft can survive a DoS attack perpetrated by the avian 
> carrier.
> 
> -- 
> Brandon Ross  AIM:  BrandonNRoss
>   ICQ:  2269442
>   Skype:  brandonross  Yahoo:  BrandonNRoss

Not true.

The occupants of the aircraft survived. The aircraft did not.

Owen

Re: v6 Avian Carriers?

[Owen DeLong]

On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote:

> 
> On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote:
> 
>> I was wondering which April 1st this would happen on.   Now I know.  So if a 
>> v6 carrier swallows a v4 datagram does that count as packet loss or 
>> tunneling?
>> 
>> http://datatracker.ietf.org/doc/rfc6214/
>> 
> 
> I was disappointed in this RFC -- Section 3.1 didn't include the proper 
> discussion of the difference between African and European avian carriers, and 
> we know what happens if that question is asked at the wrong time.
>> 
> 
> 
>   --Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
That applies to swallows. I'm not sure pidgeons pose the same issue. I think in 
general, swallows
provide poor platforms for avian transport of IP datagrams.


Owen

Re: v6 Avian Carriers?

[Chad Dailey]

Swallows have MTU issues.

On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong  wrote:

>
> On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote:
>
> >
> > On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote:
> >
> >> I was wondering which April 1st this would happen on.   Now I know.  So
> if a v6 carrier swallows a v4 datagram does that count as packet loss or
> tunneling?
> >>
> >> http://datatracker.ietf.org/doc/rfc6214/
> >>
> >
> > I was disappointed in this RFC -- Section 3.1 didn't include the proper
> discussion of the difference between African and European avian carriers,
> and we know what happens if that question is asked at the wrong time.
> >>
> >
> >
> >   --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >
> >
> >
> >
> >
> That applies to swallows. I'm not sure pidgeons pose the same issue. I
> think in general, swallows
> provide poor platforms for avian transport of IP datagrams.
>
>
> Owen
>
>
>
>

Re: v6 Avian Carriers?

[Owen DeLong]

Which? African or European Swallows?

(Watches Chad fly over the cliff edge) ;-)


Owen

On Apr 1, 2011, at 6:34 PM, Chad Dailey wrote:

> Swallows have MTU issues.
> 
> On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong  wrote:
> 
> On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote:
> 
> >
> > On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote:
> >
> >> I was wondering which April 1st this would happen on.   Now I know.  So if 
> >> a v6 carrier swallows a v4 datagram does that count as packet loss or 
> >> tunneling?
> >>
> >> http://datatracker.ietf.org/doc/rfc6214/
> >>
> >
> > I was disappointed in this RFC -- Section 3.1 didn't include the proper 
> > discussion of the difference between African and European avian carriers, 
> > and we know what happens if that question is asked at the wrong time.
> >>
> >
> >
> >   --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >
> >
> >
> >
> >
> That applies to swallows. I'm not sure pidgeons pose the same issue. I think 
> in general, swallows
> provide poor platforms for avian transport of IP datagrams.
> 
> 
> Owen
> 
> 
> 
> 

Re: v6 Avian Carriers?

[Brandon Ross]

On Fri, 1 Apr 2011, Owen DeLong wrote:


Not true.

The occupants of the aircraft survived. The aircraft did not.


Hm, in my recollection the payload made it to the destination.  Perhaps 
the route was a bit unexpected though.


--
Brandon Ross  AIM:  BrandonNRoss
   ICQ:  2269442
   Skype:  brandonross  Yahoo:  BrandonNRoss

Re: v6 Avian Carriers?

[Steven Bellovin]

On Apr 1, 2011, at 9:49 PM, Owen DeLong  wrote:

> Which? African or European Swallows?
> 
> (Watches Chad fly over the cliff edge) ;-)


So the RFC needed more text in it's Security Considerations section, too...
> 
> 
> Owen
> 
> On Apr 1, 2011, at 6:34 PM, Chad Dailey wrote:
> 
>> Swallows have MTU issues.
>> 
>> On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong  wrote:
>> 
>> On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote:
>> 
>> >
>> > On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote:
>> >
>> >> I was wondering which April 1st this would happen on.   Now I know.  So 
>> >> if a v6 carrier swallows a v4 datagram does that count as packet loss or 
>> >> tunneling?
>> >>
>> >> http://datatracker.ietf.org/doc/rfc6214/
>> >>
>> >
>> > I was disappointed in this RFC -- Section 3.1 didn't include the proper 
>> > discussion of the difference between African and European avian carriers, 
>> > and we know what happens if that question is asked at the wrong time.
>> >>
>> >
>> >
>> >   --Steve Bellovin, https://www.cs.columbia.edu/~smb
>> >
>> >
>> >
>> >
>> >
>> That applies to swallows. I'm not sure pidgeons pose the same issue. I think 
>> in general, swallows
>> provide poor platforms for avian transport of IP datagrams.
>> 
>> 
>> Owen
>> 
>> 
>> 
>> 
> 

Re: IPv4 Address Exhaustion Effects on the Earth

[Alexander Maassen]

wil,
maybe after all this time you got the router, it gained 7lbs of all the
dust in it ?

Op 1-4-2011 3:26, Wil Schultz schreef:
> On Mar 31, 2011, at 6:14 PM, "Joao C. Mendes Ogawa"  
> wrote:
>
>> FYI
>>
>> --Jonny Ogawa
>>
>> - Forwarded message from Stephen H. Inden -
>>
>> From: Stephen H. Inden
>> Subject: IPv4 Address Exhaustion Effects on the Earth
>> Date: Fri, 1 Apr 2011 00:19:08 +0200
>> To: Global Environment Watch (GEW) mailing list
>> X-Mailer: Apple Mail (2.1084)
>> X-Mailman-Version: 2.1.9
>> List-Id: "GEW mailing list."
>>
>>
>> IPv4 Address Exhaustion Effects on the Earth
>>
>> By Stephen H. Inden
>> April 1, 2011
>>
>> At a ceremony held on February 3, 2011 the Internet Assigned Numbers
>> Authority (IANA) allocated the remaining last five /8s of IPv4 address
>> space to the Regional Internet Registries (RIRs). With this action,
>> the free pool of available IPv4 addresses was completely depleted.
>>
>> Since then, several scientists have been studying the effects of this
>> massive IPv4 usage (now at its peak) on the Earth.
>>
>> While measuring electromagnetic fields emanating from the world's
>> largest IPv4 Tier-1 backbones, NASA scientists calculated how the IPv4
>> exhaustion is affecting the Earth's rotation, length of day and
>> planet's shape.
>>
>> Dr. Ron F. Stevens, of NASA's Goddard Space Flight Center, said all
>> packet switching based communications have some effect on the Earth's
>> rotation. It's just they are usually barely noticeable. Until now.
>>
>> "Every packet affects the Earth's rotation, from a small ping to a
>> huge multi-terabyte download.  The problem with IPv4 is its variable
>> length header and tiny address space that can cause an electromagnetic
>> unbalance on transmission lines.  The widespread adoption of Network
>> Address Translation (NAT) on IPv4 networks is making the problem even
>> worse, since it concentrates the electromagnetic unbalance.  This
>> problem is not noticeable with IPv6 because of its fixed header size
>> and bigger 128 bits address space", Dr. Stevens said.
>>
>> Over the past few years, Dr. Stevens has been measuring the IPv4
>> growing effects in changing the Earth's rotation in both length of
>> day, as well as gravitational field.  When IPv4 allocation reached its
>> peak, last February, he found out that the length of day decreased by
>> 2.128 microseconds.  The electromagnetic unbalance is also affecting
>> the Earth's shape -- the Earth's oblateness (flattening on the top and
>> bulging at the Equator) is decreasing by a small amount every year
>> because of the increasing IPv4 usage.
>>
>> The researcher concluded that IPv4 usage has reached its peak and is
>> causing harmful effects on the Earth:
>>
>> "IPv4 is, indeed, harmful.  Not only 32 bits for its address space has
>> proven too small and prone to inadequate solutions like NAT, it is now
>> clear that its electromagnetic effects on the Earth are real and
>> measurable."
>>
>> The solution?
>>
>> "I'm convinced that the only permanent solution is to adopt IPv6 as
>> fast as we can", says Dr. Stevens.
>>
>> --
>>
> It's all true. 
>
> Alse I've been weighing my router and it's 7 lbs heavier with the addition of 
> all these new ip addresses in it's routing table. 
>
> -wil



signature.asc
Description: OpenPGP digital signature

Re: v6 Avian Carriers?

[Robert Bonomi]

> Date: Fri, 1 Apr 2011 20:34:52 -0500
> Subject: Re: v6 Avian Carriers?
> From: Chad Dailey 
>
> Swallows have MTU issues.

No swallows?   Oh, spit.

Re: IPv4 Address Exhaustion Effects on the Earth

[Robert Bonomi]

> Date: Sat, 02 Apr 2011 04:18:00 +0200
> From: Alexander Maassen 
> Subject: Re: IPv4 Address Exhaustion Effects on the Earth
>
> wil,
> maybe after all this time you got the router, it gained 7lbs of all the
> dust in it ?

Consider what happens if the carrier encounters a route reflector --
flipping the bird??

Re: v6 Avian Carriers?

[Scott Morris]

Isn't that what the uvula is for?

Oh...   never mind   wrong swallow.   ;)

On 4/2/11 3:34 AM, Chad Dailey wrote:
> Swallows have MTU issues.
>
> On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong  wrote:
>
>> On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote:
>>
>>> On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote:
>>>
 I was wondering which April 1st this would happen on.   Now I know.  So
>> if a v6 carrier swallows a v4 datagram does that count as packet loss or
>> tunneling?
 http://datatracker.ietf.org/doc/rfc6214/

>>> I was disappointed in this RFC -- Section 3.1 didn't include the proper
>> discussion of the difference between African and European avian carriers,
>> and we know what happens if that question is asked at the wrong time.
>>>
>>>   --Steve Bellovin, https://www.cs.columbia.edu/~smb
>>>
>>>
>>>
>>>
>>>
>> That applies to swallows. I'm not sure pidgeons pose the same issue. I
>> think in general, swallows
>> provide poor platforms for avian transport of IP datagrams.
>>
>>
>> Owen
>>
>>
>>
>>
>

Re: v6 Avian Carriers?

[Scott Morris]

   Random re-encapsulation.   Now there's an interesting protocol!


   On 4/2/11 3:53 AM, Brandon Ross wrote:

 On Fri, 1 Apr 2011, Owen DeLong wrote:

 Not true.
 The occupants of the aircraft survived. The aircraft did not.

 Hm, in my recollection the payload made it to the destination.
 Perhaps the route was a bit unexpected though.

comcast dns admin, help needed

[matthew zeier]

Trying to track down someone at Comcast who maintains DNS.  I'm having a number 
of Comcast users who are unable to resolve mozilla.org hosts.

https://bugzilla.mozilla.org/show_bug.cgi?id=647254

Tried using other channels to find contacts but am running dry.  Email offline 
or comment in that bug.

- m...@mozilla.com