39.0.0.0/8 on table already ?

[Danny Pinto]

Hi ,

I saw 39.0.0.0/8 from AS273 on global table till last week .Was it a genuine 
advertisement or some tests ongoing with 39.0.0.0/8 or any other previously 
reserved spaces .

I am updating my bogons lists and want to know any experiments happening with 
previous reserved spaces.

Thanks,
Dan

Re: Ranges announced by Level3 without permitions.

[Network Department]

Hi!

1) RIPE NCC policy requires all routes must be present at the RIPE DB
and RIPE IPs could be officially announced outside RIPE Region.

2) Resources owners don't know anything about these routes.. so it
means that ranges were announces without permission by third party
company.

On Thu, Mar 3, 2011 at 9:05 AM, Owen DeLong  wrote:
>
> On Mar 2, 2011, at 11:55 PM, Alfa Telecom wrote:
>
>> Hello All!
>>
>> Maybe somebody could help me with some issue:
>>
>> Ranges below are announced by Level3
>>
>> 79.110.224.0/20    *[BGP/170] 08:23:34, MED 0, localpref 150, from 
>> 213.248.64.245
>>                      AS path: 3356
>> 79.110.64.0/20     *[BGP/170] 08:25:07, MED 0, localpref 150, from 
>> 213.248.64.245
>>                      AS path: 3356
>>
>> Both ranges are from RIPE region and couldn't be announced from ARIN ASN at 
>> all. We're sponsored LIR for both companies, I sent several emails to Level3 
>> noc, made several calls but they still announce these ranges.
>> --
>> Andrew
>
> Why can't they be announced from ARIN ASN?  Many network ranges issued by RIPE
> are held by companies with operations in north america and are announced in
> North America from North American ASNs.
>
> If you are saying that the announcement from Level 3 is not on behalf of the 
> companies
> for whom you are the sponsoring LIR, then, perhaps the registered customers 
> (to whom
> the addresses are listed in whois) should contact Level 3 directly so that 
> they can
> validate the resource registrants properly before removing the routes.
>
> If I misunderstand what you are attempting to say, I apologize, but, your 
> message is
> hard to understand.
>
> Owen
>
>



-- 
Network Department
Alfa Telecom s.r.o.
http://www.alfatelecom.cz
email: r...@alfatelecom.cz
phone: +420 226 020 362

Re: [v6z] 39.0.0.0/8 on table already ?

[Scott Howard]

39/8 was assigned to APNIC in January, and realistically should have been
removed from any bogon lists at that time.

At this stage it appears they are still doing "Resource Quality Assessment"
on it and haven't actually carried out any assignments, but that in itself
is enough of a reason to make sure that it's reachable.
http://www.apnic.net/services/services-apnic-provides/registration-services/resource-quality-assurance

  Scott.


On Thu, Mar 3, 2011 at 12:07 AM, Danny Pinto  wrote:

> Hi ,
>
> I saw 39.0.0.0/8 from AS273 on global table till last week .Was it a
> genuine advertisement or some tests ongoing with 39.0.0.0/8 or any other
> previously reserved spaces .
>
> I am updating my bogons lists and want to know any experiments happening
> with previous reserved spaces.
>
> Thanks,
> Dan
>
>
>
>
>
>
>

Re: Postfix spam

[Robert Bonomi]

> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org  Wed Mar  2 02:53:14 
> 2011
> Date: Wed, 02 Mar 2011 10:46:03 +0200
> From: Peter Rudasingwa 
> To: nanog@nanog.org
> Subject: Postfix spam
>
> Hello,
>
> I am being attacked by a lot of spams on my postfix box. What is the best 
> way to block them and fix this for good?
>
> It is so bad some of my IPs have been black listed.
>
> Thanks for your help.
>

1) Hire a professional, as staff or as a contractor, to secure your systems.

2) Find the 'off' switch on the postfix box, and _use_ it.

[BEWARE] David J. Moore

[Leon Kaiser]

This is the man who poisoned DroneBL. He is a bad man. Keep your
children safe.
http://raged.tittybang.org/

Leon

Leon Kaiser  - Head of GNAA Public Relations -
litera...@gnaa.eu || litera...@goatse.fr
   http://gnaa.eu || http://security.goatse.fr
  7BEECD8D FCBED526 F7960173 459111CE F01F9923
"The mask of anonymity is not intensely constructive."
   -- Andrew "weev" Auernheimer

Re: [BEWARE] David J. Moore

[Leon Kaiser]

This is the man who poisoned DroneBL. He is a bad man. Keep your
children safe.

> http://raged.tittybang.org/
> 
> Leon
> 
> Leon Kaiser  - Head of GNAA Public Relations -
> litera...@gnaa.eu || litera...@goatse.fr
>http://gnaa.eu || http://security.goatse.fr
>   7BEECD8D FCBED526 F7960173 459111CE F01F9923
> "The mask of anonymity is not intensely constructive."
>-- Andrew "weev" Auernheimer
> 


kunwon1: what a bad man

``kunwon1'' aka David J. Moore is a mentally unstable chatter found on
irc.freenode.net ##politics, where he frequently promotes racism,
bigotry, and his own extremist political views. He is a violent felon, a
pedophile, and a drug addict. Keep this sick, sick man away from your
children at all costs.

In addition to being a violent sex offender, he is a devout Muslim and
deeply closeted homosexual.

kunwon1: confirmed sex offender
If you let David J. Moore anywhere near your children, there is no doubt
in my mind that your child will soon become a rape victim. This is a
very sick man who belongs in prison, not on IRC.

Quick Facts about David J. Moore: Violent Sex Fiend
* David J. Moore is responsible for 88% of all 'Amber Alerts.
* There are literally hundreds of reported instances of Moore molesting
children.
* Authorities suspect that Moore keeps over 30 children locked in his
basement, based on the screams neighbors frequently report to the
police.
* Moore was once described as calling a 4-year-old girl "very
molestable", and a 7-month-old boy as "a hot piece of ass".
* It is rumored that he is responsible for 45% of all child abuse in his
county, and that 40% of all child pornography on the Internet can be
traced back to him.
* There is not a second in the day where David J. Moore does not lust
after children.

kunwon1: Junkie
Labeled a pedophile and shunned by neighbors and peers alike, David J.
Moore turned to drugs for companionship. After years of injecting Heroin
and other opiates into his veins, it began to get harder to find a
"good" vein to shoot up in. Moore was forced to turn to other drugs to
fill the void in his life that Heroin once did.

Drugs that David J. Moore is addicted to
* Crack Cocaine
* Marijuana
* Morphine
* LSD
* Speed
* Crystal Meth
* Vicodin
* Heroin
* DXM
* Ketamine
* Steroids
* Peyote
* Salvia
* Ecstacy
* Shrooms
* Oxycodone
* Klonopin
* Methadone
* Ayahuasca
* Adrenochrome
Moore has also been known to huff "raid" from time to time.

kunwon1: soft chatter
Warning! The text that follows may be disturbing and thus unsuitable for
younger viewers. If you are under the age of 18, or are offended at any
time, please press the ``back'' button on your web browser.

Click here for examples of kunwon1's deviant chatting.

15:39:49 ,---Whois--< kunwon1 [~kunwon1@unaffiliated/kunwon1]
15:39:49 |gecos : Specialization is for Insects
15:39:50 | channels : #freenode @##child_pic_swap ##politics
@##narco_trade ##politics-outcast +##infant-sex-workers ##gaydads4sons
@#child_porn_dungeon
15:39:50 |   server : brown.freenode.net (Madison, WI, US)
15:39:50 |  : is using a secure connection
15:39:50 | idle : 0 days 0 hours 2 mins 40 secs (signon: Mon Feb 28
15:09:52 2011)
15:39:50 |  account : kunwon1
15:39:50 `--<

download speed very fast.

[Deric Kwok]

Hi all

Do you know about sppedboost?

Why it can suddenly burst to higher transfer rate from first 10M

Can you share what equipment behinds to make it work?

eg: cisco, juniper?

Thank you so much

Re: Ranges announced by Level3 without permitions.

[Brandon Ross]

On Thu, 3 Mar 2011, Alfa Telecom wrote:

Both ranges are from RIPE region and couldn't be announced from ARIN ASN at 
all.


Your premise is incorrect.  Any block from any RIR can be announced by any 
ASN.


We're sponsored LIR for both companies, I sent several emails to Level3 
noc, made several calls but they still announce these ranges.


Why should they stop announcing them?  Do you believe they have been 
hijacked?  If these companies have decided to contract with another 
transit provider, you cannot stop them from doing so in this way.


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

Re: Ranges announced by Level3 without permitions.

[Alfa Telecom]

On 03/03/2011 03:25 PM, Brandon Ross wrote:

On Thu, 3 Mar 2011, Alfa Telecom wrote:

Both ranges are from RIPE region and couldn't be announced from ARIN 
ASN at all.


Your premise is incorrect.  Any block from any RIR can be announced by 
any ASN.
1) All routing data must be present at the RIPE DB. If you work with 
RIPE DB you could see that webtools don't allow you to create route to 
ASN not from RIPE region.

2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE region.




We're sponsored LIR for both companies, I sent several emails to 
Level3 noc, made several calls but they still announce these ranges.


Why should they stop announcing them?  Do you believe they have been 
hijacked?  If these companies have decided to contract with another 
transit provider, you cannot stop them from doing so in this way.


IPs are announced by Level3... I respect this company but looks like 
Level3 is scammed and currently announce without necessary permissions.

Re: Ranges announced by Level3 without permitions.

[Patrick W. Gilmore]

On Mar 3, 2011, at 9:34 AM, Alfa Telecom wrote:
> On 03/03/2011 03:25 PM, Brandon Ross wrote:
>> On Thu, 3 Mar 2011, Alfa Telecom wrote:
>> 
>>> Both ranges are from RIPE region and couldn't be announced from ARIN ASN at 
>>> all.
>> 
>> Your premise is incorrect.  Any block from any RIR can be announced by any 
>> ASN.
> 1) All routing data must be present at the RIPE DB. If you work with RIPE DB 
> you could see that webtools don't allow you to create route to ASN not from 
> RIPE region.
> 2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE region.

You are confused.


>>> We're sponsored LIR for both companies, I sent several emails to Level3 
>>> noc, made several calls but they still announce these ranges.
>> 
>> Why should they stop announcing them?  Do you believe they have been 
>> hijacked?  If these companies have decided to contract with another transit 
>> provider, you cannot stop them from doing so in this way.
>> 
> IPs are announced by Level3... I respect this company but looks like Level3 
> is scammed and currently announce without necessary permissions.

You will need more than a baseless accusation to make others change.  
Especially after you have shown ignorance of some basic facts on how networks 
announce & accept prefixes.

-- 
TTFN,
patrick

Re: Ranges announced by Level3 without permitions.

[Brandon Ross]

On Thu, 3 Mar 2011, Alfa Telecom wrote:


On 03/03/2011 03:25 PM, Brandon Ross wrote:

On Thu, 3 Mar 2011, Alfa Telecom wrote:

Both ranges are from RIPE region and couldn't be announced from ARIN ASN 
at all.


Your premise is incorrect.  Any block from any RIR can be announced by any 
ASN.
1) All routing data must be present at the RIPE DB. If you work with RIPE DB 
you could see that webtools don't allow you to create route to ASN not from 
RIPE region.

2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE region.


Your premise is still wrong.  Only networks that use the RIPE DB care 
about what's in the RIPE DB.  There is no requirement for Level 3 to use 
it.  There is no law that says they have to.


We're sponsored LIR for both companies, I sent several emails to Level3 
noc, made several calls but they still announce these ranges.


Why should they stop announcing them?  Do you believe they have been 
hijacked?  If these companies have decided to contract with another transit 
provider, you cannot stop them from doing so in this way.


IPs are announced by Level3... I respect this company but looks like Level3 
is scammed and currently announce without necessary permissions.


Again, do you believe these networks are hijacked?  If they are in 
legitimate use by the companies that they are allocated to in whois, then 
there is no scam.


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

Re: Ranges announced by Level3 without permitions.

[Christopher Morrow]

On Thu, Mar 3, 2011 at 9:39 AM, Brandon Ross  wrote:
> On Thu, 3 Mar 2011, Alfa Telecom wrote:
>
>> On 03/03/2011 03:25 PM, Brandon Ross wrote:
>>>
>>> On Thu, 3 Mar 2011, Alfa Telecom wrote:
>>>
 Both ranges are from RIPE region and couldn't be announced from ARIN ASN
 at all.

netblocks in question:
79.110.224.0/20
79.110.64.0/20

I'd note both of these blocks seem to route to a L3 customer in SJC:
16  ae-3-80.edge8.SanJose1.Level3.net (4.69.152.148)  63.993 ms
63.770 ms ae-1-60.edge8.SanJose1.Level3.net (4.69.152.20)  63.421 ms
17  BANDCON.edge8.SanJose1.Level3.net (4.53.30.42)  93.556 ms  60.929
ms  60.376 ms
18  79.110.64.10 (79.110.64.10)  65.057 ms  64.949 ms  64.960 ms

maybe it's better to ask them:
OrgName:Bandcon
OrgId:  BANDC
Address:151 Kalmus Drive
Address:Suite M-2
City:   Costa Mesa
StateProv:  CA
PostalCode: 92926
Country:US
RegDate:2002-11-08
Updated:2009-02-11
Ref:http://whois.arin.net/rest/org/BANDC

TechHandle: NOC2402-ARIN
TechName:   Network Operation Center
TechPhone:  +1-888-253-8353
TechEmail:  arin...@bandcon.com
TechRef:http://whois.arin.net/rest/poc/NOC2402-ARIN

AdminHandle: NOC2402-ARIN
AdminName:   Network Operation Center
AdminPhone:  +1-888-253-8353
AdminEmail:  arin...@bandcon.com
AdminRef:http://whois.arin.net/rest/poc/NOC2402-ARIN

What's going on?

(shouting on public mailing-lists ain't gonna fix this I bet)

-Chris

Re: Ranges announced by Level3 without permitions.

[Suresh Ramasubramanian]

On Thu, Mar 3, 2011 at 8:09 PM, Brandon Ross  wrote:
>> IPs are announced by Level3... I respect this company but looks like
>> Level3 is scammed and currently announce without necessary permissions.
>
> Again, do you believe these networks are hijacked?  If they are in

Hmm - so who should announce it?  And who owns the netblock?

The whois etc lookups below could put this either in the US or in
Eastern Europe / Russia or in Italy.

$ whois -h whois.radb.net 79.110.224.0/20
route:  79.110.224.0/20
descr:  Avangard
origin: AS50245
mnt-by: SERVEREL-MNT
changed:n...@serverel.com 20110210
source: RIPE
remarks:
remarks:* THIS OBJECT IS NOT VALID
remarks:* Please note that all data that is generally regarded
as personal
remarks:* data has been removed from this object.
remarks:* http://www.ripe.net/whois
remarks:

Has a US address in the whois - which a little googling shows is a maildrop.
http://www.beavertonvalleytimes.com/news/story.php?story_id=118668700663617700

person: Serverel NOC
address:14525 SW Millikan Way # 33735   Beaverton, OR 97005-2343
phone:  +1(877)246 78 63
abuse-mailbox:  ab...@serverel.com

serverel.com
 Name-- Iurii  Salmanov
 EMail-: (doma...@serverel.com)

serverel.net
 name: Andrew Neal
 mail: doma...@serverel.com tel: +1.8772467863
 org: Serverel Corporation

Then ripe whois says the netblock is either owned by someone in the
ukraine or in italy

inetnum:79.110.224.0 - 79.110.239.255
netname:Avangard
descr:  PE "Avangard"
country:UA

person: Karol Wojtula<- named for the late pope john paul
II, I see ..?
address:Bari , Italy , Piazzale Cristoforo Colombo, 1, 70122
<- google that address and its the ferry port in Bari, Italy.
phone:  +39 080 327 8841

And AS50425 - which'd announce it if that RADB object was actually
valid - is in russia, not the czech republic

organisation:   ORG-JS33-RIPE
org-name:   Closed JSC "TV Services"
org-type:   OTHER
address:43, Bolshoy Tishinskiy per., Moscow, Russia,  123557
mnt-ref:TV-SERVICE-MNT
mnt-by: TV-SERVICE-MNT
source: RIPE # Filtered

person: Dolgopolov Alexey
address:Russia
address:Moscow
address:43, Bolshoy Tishinskiy per
phone:  +7 495 9334592
nic-hdl:DA489-RIPE
source: RIPE # Filtered

So - the whois for these is quite confusing - not very easy for any
one entity to establish ownership?

-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Anyone has a contact with IP clue at VerizonBusiness?

[Alex Yuriev]

I know it may be a stretch but is there a remote possibility that someone
knows anyone inside Verizon Business who has an ounce of clue about IPv4
address allocation and routing? 

It seems the panic over IPv4 scarcity is resulting in the most peculiar
ideas bubbling up in the IP provisioning side which must be stomped out of
existence before such ideas create signigicant connectivity issues.


Thanks,
Alex

Interesting google redirects.

[Wil Schultz]

Has anyone else had complaints that www.google.com is occasionally redirecting 
(http 302) to www.google.com.hk this morning?

-wil

Cross connect from Telx to Level 3 @ 111 8th Ave

[Andy Ashley]

Hi,

Does anyone know if it is possible to get a cross connect from Telx 
(room 524) to Level 3 (room 304) at 111 8th Ave?
Neither Telx or L3 can do this without serious complication and 
prohibitive cost.


(contact me off list please)

Thanks.

Regards,
Andy Ashley.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Anyone has a contact with IP clue at VerizonBusiness?

[Valdis . Kletnieks]

On Thu, 03 Mar 2011 10:18:03 EST, Alex Yuriev said:

> It seems the panic over IPv4 scarcity is resulting in the most peculiar
> ideas bubbling up in the IP provisioning side

What peculiar ideas might these be? Inquiring minds want to know (as well as
those who seek amusement, or need to be ready to deal with the aftermath).



pgppL05ppffsD.pgp
Description: PGP signature

RE: Interesting google redirects.

[Skywing]

(Apologies for the top-post.)

I've been experiencing the same.  Seems like their geolocation data is busted 
(since last morning at least), if I had to take a guess.

- S

-Original Message-
From: Wil Schultz 
Sent: Thursday, March 03, 2011 7:25
To: NANOG Operators Group 
Subject: Interesting google redirects.


Has anyone else had complaints that www.google.com is occasionally redirecting 
(http 302) to www.google.com.hk this morning?

-wil

Re: [BEWARE] David J. Moore

[isabel dias]

The only reason why you feel that way is cause you haven't been made aware and 
your network of friends is not "helping you at all" so do speak up and make 
yourself heard!




- Original Message 
From: Leon Kaiser 
To: full-disclos...@lists.grok.org.uk; nanog@nanog.org; 
irc-secur...@lists.irc-unity.org; dronebl-discuss...@dronebl.org
Sent: Thu, March 3, 2011 2:03:18 PM
Subject: [BEWARE] David J. Moore

This is the man who poisoned DroneBL. He is a bad man. Keep your
children safe.
http://raged.tittybang.org/

Leon

Leon Kaiser      - Head of GNAA Public Relations -
        litera...@gnaa.eu || litera...@goatse.fr
      http://gnaa.eu || http://security.goatse.fr
      7BEECD8D FCBED526 F7960173 459111CE F01F9923
"The mask of anonymity is not intensely constructive."
      -- Andrew "weev" Auernheimer

RE: Interesting google redirects.

[Aaron Wendel]

My IPs have been redirecting to google bk for several days.  I thought it  
was just me.


Sent via DROID on Verizon Wireless

-Original message-
From: Skywing 
To: Wil Schultz , nanog 
Sent: Thu, Mar 3, 2011 15:53:36 GMT+00:00
Subject: RE: Interesting google redirects.

(Apologies for the top-post.)

I've been experiencing the same.  Seems like their geolocation data is  
busted (since last morning at least), if I had to take a guess.


- S

-Original Message-
From: Wil Schultz 
Sent: Thursday, March 03, 2011 7:25
To: NANOG Operators Group 
Subject: Interesting google redirects.


Has anyone else had complaints that www.google.com is occasionally  
redirecting (http 302) to www.google.com.hk this morning?


-wil

Re: Interesting google redirects.

[Richard Barnes]

What networks are the affected clients on?


On Thu, Mar 3, 2011 at 10:53 AM, Skywing  wrote:
> (Apologies for the top-post.)
>
> I've been experiencing the same.  Seems like their geolocation data is busted 
> (since last morning at least), if I had to take a guess.
>
> - S
>
> -Original Message-
> From: Wil Schultz 
> Sent: Thursday, March 03, 2011 7:25
> To: NANOG Operators Group 
> Subject: Interesting google redirects.
>
>
> Has anyone else had complaints that www.google.com is occasionally 
> redirecting (http 302) to www.google.com.hk this morning?
>
> -wil
>
>

Re: [BEWARE] David J. Moore

[isabel dias]

If you can't be good be carefull! 


A "relation" is just a relationship between sets of information
What is a relation? A Relation is a group of Functions 


 
- Original Message 
From: isabel dias 
To: litera...@gnaa.eu; full-disclos...@lists.grok.org.uk; nanog@nanog.org; 
irc-secur...@lists.irc-unity.org; dronebl-discuss...@dronebl.org
Sent: Thu, March 3, 2011 4:07:46 PM
Subject: Re: [BEWARE] David J. Moore

The only reason why you feel that way is cause you haven't been made aware and 
your network of friends is not "helping you at all" so do speak up and make 
yourself heard!




- Original Message 
From: Leon Kaiser 
To: full-disclos...@lists.grok.org.uk; nanog@nanog.org; 
irc-secur...@lists.irc-unity.org; dronebl-discuss...@dronebl.org
Sent: Thu, March 3, 2011 2:03:18 PM
Subject: [BEWARE] David J. Moore

This is the man who poisoned DroneBL. He is a bad man. Keep your
children safe.
http://raged.tittybang.org/

Leon

Leon Kaiser      - Head of GNAA Public Relations -
        litera...@gnaa.eu || litera...@goatse.fr
      http://gnaa.eu || http://security.goatse.fr
      7BEECD8D FCBED526 F7960173 459111CE F01F9923
"The mask of anonymity is not intensely constructive."
      -- Andrew "weev" Auernheimer

Re: [BEWARE] David J. Moore

[Lynda]

On 3/3/2011 8:07 AM, isabel dias wrote:

The only reason why you feel that way is cause you haven't been made aware and
your network of friends is not "helping you at all" so do speak up and make
yourself heard!


No, don't speak up. Please don't pollute NANOG any further than it 
already is, and please don't encourage others to do so.


--
Amor fati. Vale. (Seneca)

AT&T via Tata and Level3

[Morgan Miskell]

I've noticed that we have thousands of routes for AT&T via Tata that we
don't have from AT&T through Level3.  I would expect Level3 to have most
of the routes for AT&T that Tata does since they are both directly
peered with AT&T.

This seems to have started around midnight last night.  I have a ticket
open with Level3 to inquire...anyone else notice this or anything
similar around 12-1AM EST this morning?
-- 
Morgan A. Miskell
CaroNet Data Centers
704-643-8330 x206

The information contained in this e-mail is confidential and is intended
only for the named recipient(s). If you are not the intended recipient
you must not copy, distribute, or take any action or reliance on it. If
you have received this e-mail in error, please notify the sender. Any
unauthorized disclosure of the information contained in this e-mail is
strictly prohibited.

Re: download speed very fast.

[Michael Proto]

On Thu, Mar 3, 2011 at 9:11 AM, Deric Kwok  wrote:
> Hi all
>
> Do you know about sppedboost?
>
> Why it can suddenly burst to higher transfer rate from first 10M
>
> Can you share what equipment behinds to make it work?
>
> eg: cisco, juniper?
>
> Thank you so much
>
>

I don't know about hardware, but as I understand it from some
colleagues Speedboost uses a HFSC-based queuing mechanism on the
backside.

http://en.wikipedia.org/wiki/Hierarchical_Fair_Service_Curve


-Proto

RE: download speed very fast.

[Rettke, Brian]

It's essentially a 2 token bucket system. We implement based on the rate plan 
given via our DHCP server for residential customers, but it can be implemented 
using QoS on any router. Most DHCP server platforms offer it, and it is written 
into the configuration file downloaded by a cable modem.

Sincerely,

Brian A . Rettke


-Original Message-
From: Michael Proto [mailto:m...@jellydonut.org]
Sent: Thursday, March 03, 2011 9:20 AM
To: Deric Kwok
Cc: nanog@nanog.org
Subject: Re: download speed very fast.

On Thu, Mar 3, 2011 at 9:11 AM, Deric Kwok  wrote:
> Hi all
>
> Do you know about sppedboost?
>
> Why it can suddenly burst to higher transfer rate from first 10M
>
> Can you share what equipment behinds to make it work?
>
> eg: cisco, juniper?
>
> Thank you so much
>
>

I don't know about hardware, but as I understand it from some
colleagues Speedboost uses a HFSC-based queuing mechanism on the
backside.

http://en.wikipedia.org/wiki/Hierarchical_Fair_Service_Curve


-Proto

Re: download speed very fast.

[Scott Helms]

Deric,

Depending on the kind of access gear being used there are different 
methods for making this work.  This kind of technology is most commonly 
deployed on DOCSIS cable systems, for example Comcast has this 
trademarked as PowerBoost and they have done a ton of marketing around 
it.  You can implement this kind of temporary speed boosting for cable 
systems on several CMTS brands (I know Cisco and Arris) and its probably 
possible for any CMTS that is certified for D2 or better.  I haven't 
found a certified modem that couldn't handle that side of things.


On 3/3/2011 9:11 AM, Deric Kwok wrote:

Hi all

Do you know about sppedboost?

Why it can suddenly burst to higher transfer rate from first 10M

Can you share what equipment behinds to make it work?

eg: cisco, juniper?

Thank you so much





--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

Re: Interesting google redirects.

[Varun]

I have seen some of our APAC  customers getting redirected to
google.com.tw; the internet egress point is in japan.

also some EU customers are getting redirected to .au  domain

On 03-Mar-2011 9:46 PM, "Richard Barnes"  wrote:

What networks are the affected clients on?



On Thu, Mar 3, 2011 at 10:53 AM, Skywing 
wrote:
> (Apologies for the...

Re: Interesting google redirects.

[p8x]

I seem to be getting redirected to Google HK as well for the last week 
to 2 weeks or so (I am in AU).


On 4/03/2011 12:50 AM, Varun wrote:

I have seen some of our APAC  customers getting redirected to
google.com.tw; the internet egress point is in japan.

also some EU customers are getting redirected to .au  domain

Re: Interesting google redirects.

[Wayne Lee]

>> also some EU customers are getting redirected to .au  domain

Mine got redirected to google.be for a while.

Re: Interesting google redirects.

[Paul Thornton]

On 03/03/2011 16:55, p8x wrote:
>> also some EU customers are getting redirected to .au  domain
>>

I was being redirected to .ru earlier this week from UK addresses... 
Has stopped now.

Paul.

RE: download speed very fast.

[Frank Bulk]

In addition to the CMTS configuration, added to the CM configuration file
are a two parameters that describe how much more bandwidth (peak rate) and
how many more bytes (burst size).  More here on Cisco's implementation:
http://www.cisco.com/en/US/docs/ios/cable/configuration/guide/cmts_docsis11_
ps2209_TSD_Products_Configuration_Guide_Chapter.html#wp1278817

Frank

-Original Message-
From: Scott Helms [mailto:khe...@ispalliance.net] 
Sent: Thursday, March 03, 2011 10:40 AM
To: nanog@nanog.org
Subject: Re: download speed very fast.

Deric,

 Depending on the kind of access gear being used there are different 
methods for making this work.  This kind of technology is most commonly 
deployed on DOCSIS cable systems, for example Comcast has this 
trademarked as PowerBoost and they have done a ton of marketing around 
it.  You can implement this kind of temporary speed boosting for cable 
systems on several CMTS brands (I know Cisco and Arris) and its probably 
possible for any CMTS that is certified for D2 or better.  I haven't 
found a certified modem that couldn't handle that side of things.

On 3/3/2011 9:11 AM, Deric Kwok wrote:
> Hi all
>
> Do you know about sppedboost?
>
> Why it can suddenly burst to higher transfer rate from first 10M
>
> Can you share what equipment behinds to make it work?
>
> eg: cisco, juniper?
>
> Thank you so much
>
>


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

icmp question

[ann kok]

Hello

Have you had any experience about icmp from window and linux?

I ping this linux host and they all are same LAN

but Linux (ubuntu) is slow than window to this linux host

Do you know why?

Thank you

Re: icmp question

[FRLinux]

On Thu, Mar 3, 2011 at 7:40 PM, ann kok  wrote:
> Hello
> Have you had any experience about icmp from window and linux?
> I ping this linux host and they all are same LAN
> but Linux (ubuntu) is slow than window to this linux host
> Do you know why?
> Thank you

Hello,

Without posting any inteface output, that might be a bit hard to
diagnose and give an accurate answer :)

Steph

Re: AT&T via Tata and Level3

[Richard A Steenbergen]

On Thu, Mar 03, 2011 at 11:15:51AM -0500, Morgan Miskell wrote:
> I've noticed that we have thousands of routes for AT&T via Tata that 
> we don't have from AT&T through Level3.  I would expect Level3 to have 
> most of the routes for AT&T that Tata does since they are both 
> directly peered with AT&T.

Well, I don't know anything about this specific issue or any policy 
changes that may have been made, but at a high level I can tell you that 
BGP doesn't work like that. BGP is only capable of passing on a single 
best path for each route, and what is considered the best path is 
totally in the eye of the beholder.

First off you must understand that the vast majority of Internet routes 
are multi-homed at some level. As you get into large Tier 1 carriers, 
the amount of overlap is massive (i.e. you'll hear the same route as a 
"customer" from multiple networks), and the question of which path will 
be selected is completely up to the policies of the network doing the 
selecting. Not only does this vary by policy, but it varies by the 
composition of other networks they peer with (or buy from), what other 
networks buy from them, and even their network topology (due to tie 
breaking rules like EBGP > IBGP).

For example, Level 3 is a much larger network with significantly more 
customer routes than Tata. I'm too lazy to do an actual comparison 
between the two, but odds are high that of the AT&T customer routes that 
they announce to their peers, probably somewhere around 30-40% of those 
routes are also Level 3 customer routes as well. A network will ALWAYS 
prefer their customer routes above those learned from peers (or else 
they wouldn't be able to guarantee that they're actually providing full 
transit service), so those routes coming from AT&T will never be 
selected. Meanwhile, Tata is receiving those same routes from both AT&T 
and Level 3 (and potentially other peers and/or customers too), and is 
completely free to make their own best path selections based on their 
own local criteria.

The result is that you should almost never expect to see the same paths 
for the same networks being selected by two different large networks, 
unless the routes in question are single homed and there are no other 
choices (which is a small minority of the routes on the Internet).

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Real World NAT64 deployments

[Elliot Finley]

So as not to re-invent the wheel - if you are currently doing NAT64 in
production and are willing to share:

What software/hardware are you using?

Why?

TIA
Elliot

Re: Real World NAT64 deployments

[Hammer]

I need a cheat sheet.

nat64
6to4nat
6in4nat
etc...


 -Hammer-

"I was a normal American nerd."
-Jack Herer





On Thu, Mar 3, 2011 at 2:31 PM, Elliot Finley wrote:

> So as not to re-invent the wheel - if you are currently doing NAT64 in
> production and are willing to share:
>
> What software/hardware are you using?
>
> Why?
>
> TIA
> Elliot
>

OT: Where are the VoIP clue bats?

[Eric Brunner-Williams]

First, thanks for all the responses to "What vexes VoIP users?"

I'm looking for pointers to sites, like Geoff Huston's potaroo.net, 
that are VoIP clue dense, or mailing lists(*) where the VoIP-full lurk.


Thanks in advance,
Eric

(*) I'm already on the ecrit list, though my real interest in the 
ongoing IETF "emergency services" meme has been a "I'm alive" app, not 
circuit and bandwidth capture by government. I was pleased to see a 
"I'm alive" app fielded by Google last week at Christchurch, NZ.

Re: What vexes VoIP users?

[Alexander O. Yuriev]

> There's no particularly good reason that a VoIP-over-cable system
> shouldn't be able to hand off calls to an arbitrary SIP device.

No, there's no particulary good technological reason why VOIP-over-cable
system shouldn't be able to hand off calls to an arbitrary SIP device. 

The reason is purely business -  it will destroy their own voice service user 
base.

Alex

Re: Postfix spam

[Joshua Klubi]

Get A.S.S.P and integrate it with your postfix box, implement SPF and run 
dkimproxy on your postfix box and bid spams adieu . 

You would be surprised the power of ASSP . It is the best out there that kills 
spam dead on arrival and departure. 

Sent from my iPhone

On Mar 3, 2011, at 10:18, Robert Bonomi  wrote:

>> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org  Wed Mar  2 02:53:14 
>> 2011
>> Date: Wed, 02 Mar 2011 10:46:03 +0200
>> From: Peter Rudasingwa 
>> To: nanog@nanog.org
>> Subject: Postfix spam
>> 
>> Hello,
>> 
>> I am being attacked by a lot of spams on my postfix box. What is the best 
>> way to block them and fix this for good?
>> 
>> It is so bad some of my IPs have been black listed.
>> 
>> Thanks for your help.
>> 
> 
> 1) Hire a professional, as staff or as a contractor, to secure your systems.
> 
> 2) Find the 'off' switch on the postfix box, and _use_ it.
> 
> 
> 

Re: What vexes VoIP users?

[Scott Helms]

On 3/3/2011 3:47 PM, Alexander O. Yuriev wrote:

There's no particularly good reason that a VoIP-over-cable system
shouldn't be able to hand off calls to an arbitrary SIP device.

No, there's no particulary good technological reason why VOIP-over-cable
system shouldn't be able to hand off calls to an arbitrary SIP device.

The reason is purely business -  it will destroy their own voice service user 
base.

Alex




PacketCable pre-dates network neutrality discussions in the US, think 
1999 for version 1.0 
http://www.cablelabs.com/specifications/PKT-SP-TGCP-C01-071129.pdf


So we have a working technology that pre-dated significant direct to 
consumer SIP services.  Vonage went direct to consumer in 2002, before 
that their model was selling to the cable operators.)   Now its true 
there is no technical reason that 3rd party SIP devices couldn't be 
included in the mix, especially since PacketCable 2.0 moves from MGCP to 
SIP.  However, there is a ton of work to build an interoperable protocol 
for signaling call setup, AAA, number ports, etc, etc.  Integrating 3rd 
party SIP into the existing PacketCable standards is certainly possible, 
but who is going to pay for it?  I know of no 3rd party VOIP vendors 
that even want to go down this path.  Vonage's technical folks seem 
quite happy to have a ~60% success rate in my experience troubleshooting 
networks and Skype seems even more disinterested.  I also think you 
greatly over estimate the amount of concern generated by MagicJack, 
Skype, Vonage, et al.



--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

RE: What vexes VoIP users?

[Frank Bulk]

Depends on the network, but we use private IPs on the eMTA side of the CM.

Frank

-Original Message-
From: Alexander O. Yuriev [mailto:alex-lists-na...@yuriev.com] 
Sent: Thursday, March 03, 2011 2:48 PM
To: nanog@nanog.org
Subject: Re: What vexes VoIP users?

> There's no particularly good reason that a VoIP-over-cable system
> shouldn't be able to hand off calls to an arbitrary SIP device.

No, there's no particulary good technological reason why VOIP-over-cable
system shouldn't be able to hand off calls to an arbitrary SIP device. 

The reason is purely business -  it will destroy their own voice service
user base.

Alex

Re: Real World NAT64 deployments

[William Herrin]

On Thu, Mar 3, 2011 at 3:41 PM, Hammer  wrote:
> I need a cheat sheet.
>
> nat64
> 6to4nat
> 6in4nat
> etc...

6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6
nodes to talk to each other via an IPv4 backbone.

nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints.

nat44 is the IPv4 NAT you're used to.
nat444 is carrier NAT (translated once by the customer and once again
by the ISP, get it?)



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Real World NAT64 deployments

[Hammer]

A little better. So what's the difference between 6to4 and 6in4? Isn't 6in4
what HE uses?


 -Hammer-

"I was a normal American nerd."
-Jack Herer





On Thu, Mar 3, 2011 at 3:54 PM, William Herrin  wrote:

> On Thu, Mar 3, 2011 at 3:41 PM, Hammer  wrote:
> > I need a cheat sheet.
> >
> > nat64
> > 6to4nat
> > 6in4nat
> > etc...
>
> 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6
> nodes to talk to each other via an IPv4 backbone.
>
> nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints.
>
> nat44 is the IPv4 NAT you're used to.
> nat444 is carrier NAT (translated once by the customer and once again
> by the ISP, get it?)
>
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>

Re: What vexes VoIP users? - Bufferbloat

[Jim Gettys]

On 03/01/2011 04:32 AM, William Pitcock wrote:



That is the same market Vonage is now targeting in the US, basically.
National calling in the US is basically bundled with most calling plans
now.  I'm not convinced that many people use Vonage in the US - my
experience with it was that it was not as reliable as the VOIP
products offered through the various broadband providers I have had.



Due to bufferbloat in the broadband edge, the broadband carriers have a 
fundamental advantage in providing VOIP, since they do not do so over 
the data service the user has but does not have access to for any 
classification; it is provisioned entirely separately on different channels.


As you can see in the ICSI Netalyzr data you can find in my blog at 
http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/ 
whenever a home connection is saturated for any reason, customers can 
easily experience *seconds* of latency.  (Telephony standards for max 
latency + jitter are in the 150MS range). Even web browsing induces 
transient jitter of order hundred(s) of milliseconds, from some 
experiments I've done, which is a problem for VOIP, much less the bulk 
data transfers which kill you for long periods.


Now that I have mitigated the bufferbloat disaster in my home cable 
service via bandwidth shaping, Skype works sooo much better for me. 
This is what devices such as Ooma are doing.  Unfortunately, it means 
you have to defeat features such as Comcast's PowerBoost.


Note I do not believe bufferbloat was intended by any broadband carrier 
to give them such an advantage.  Right now, they take it in the ear on 
service calls.  And as far as I've been able to tell, just about 
everyone has been making the same generic mistake. I'm sure the 
conspiracy theorists will love to make such claims, however.


If you don't know what bufferbloat is, you can try the talk I gave 
recently in Bell Labs, available at: 
http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ or wade through 
my blog at: http://gettys.wordpress.com/ or come to the transport area 
meeting at the Prague IETF where I will be giving a somewhat abbreviated 
version of the talk.


Best regards,
Jim Gettys
Bell Labs

Re: Real World NAT64 deployments

[JORDI PALET MARTINEZ]

6in4 is IPv6 encapsulated in IPv4 = protocol 41, typically used in manual
tunnelling configuration and also in tunnel brokers and some other type of
tunnels.

6to4 is an automatic transition mechanism that uses 6in4 to automatically
create IPv6 tunnels using a special IPv6 prefix 2002::/16, appending the
IPv4 public address to obtain a /48 for each IPv4 public address. It works
very well for peer-to-peer, but it requires 6to4 relays for connecting to
end-sites using any other kind of IPv6 connectivity (anything not-6to4).

See:

http://www.ipv6tf.org/index.php?page=using/connectivity/6to4

Regards,
Jordi






-Mensaje original-
De: Hammer 
Responder a: 
Fecha: Thu, 3 Mar 2011 16:01:29 -0600
Para: William Herrin 
CC: 
Asunto: Re: Real World NAT64 deployments

>A little better. So what's the difference between 6to4 and 6in4? Isn't
>6in4
>what HE uses?
>
>
> -Hammer-
>
>"I was a normal American nerd."
>-Jack Herer
>
>
>
>
>
>On Thu, Mar 3, 2011 at 3:54 PM, William Herrin  wrote:
>
>> On Thu, Mar 3, 2011 at 3:41 PM, Hammer  wrote:
>> > I need a cheat sheet.
>> >
>> > nat64
>> > 6to4nat
>> > 6in4nat
>> > etc...
>>
>> 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6
>> nodes to talk to each other via an IPv4 backbone.
>>
>> nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4
>>endpoints.
>>
>> nat44 is the IPv4 NAT you're used to.
>> nat444 is carrier NAT (translated once by the customer and once again
>> by the ISP, get it?)
>>
>>
>>
>> --
>> William D. Herrin  her...@dirtside.com  b...@herrin.us
>> 3005 Crane Dr. .. Web: 
>> Falls Church, VA 22042-3004
>>



**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

RE: Real World NAT64 deployments

[George Bonser]

> -Original Message-
> From: Elliot Finley 
> Sent: Thursday, March 03, 2011 12:31 PM
> To: nanog@nanog.org
> Subject: Real World NAT64 deployments
> 
> So as not to re-invent the wheel - if you are currently doing NAT64 in
> production and are willing to share:
> 
> What software/hardware are you using?
> 
> Why?
> 
> TIA
> Elliot

I would be interested in this, too.  Right now I am considering TAYGA
but would be interested in the experience of others.

George

RE: Real World NAT64 deployments

[George Bonser]

> From: Elliot Finley 
> Sent: Thursday, March 03, 2011 12:31 PM
> To: nanog@nanog.org
> Subject: Real World NAT64 deployments
> 
> So as not to re-invent the wheel - if you are currently doing NAT64 in
> production and are willing to share:
> 
> What software/hardware are you using?
> 
> Why?
> 
> TIA
> Elliot

Ok, apparently there is NAT64 and there is NAT64.  I don't believe the
poster was talking about a v6 load balancer VIP with v4 servers.  I
think the OP is talking about the NAT64 portion of NAT64/DNS64 where
native v6 source and destination IPs are NATed to v4 destination and
source IPs for communicating with v4 resources from a v6 host.  

But I might be projecting my own needs here.  So, what kind of NAT64 are
we talking about?

George

Re: What vexes VoIP users?

[Alexander O. Yuriev]

On Thu, Mar 03, 2011 at 04:08:36PM -0500, Scott Helms wrote:

>> No, there's no particulary good technological reason why VOIP-over-cable
>> system shouldn't be able to hand off calls to an arbitrary SIP device.
>>
>> The reason is purely business -  it will destroy their own voice service 
>> user base.
>>
>
> PacketCable pre-dates network neutrality discussions in the US, think 1999 
> for version 1.0 
> http://www.cablelabs.com/specifications/PKT-SP-TGCP-C01-071129.pdf
>
> So we have a working technology that pre-dated significant direct to 
> consumer SIP services.  Vonage went direct to consumer in 2002, before that 
> their model was selling to the cable operators.)   Now its true there is no 
> technical reason that 3rd party SIP devices couldn't be included in the 
> mix, especially since PacketCable 2.0 moves from MGCP to SIP.

This has nothing to do with Vonage and likes that market to consumer - their
devices are locked so the consumer is locked into the services that
Vonage/MagicJack/etc provides. They are not the companies that are going to
eat lunch of cable companies and old school telcos as their business model
is to sell the same servie at a minimum discount to the rates of dominant
carriers.

What the cable companies are afraid of is that when a consumers have SIP
speaking devices used to terminate calls the consumers will find VOIP
providers that charge $1.00 a month for a phone number and another $0.01457
per voice minute with 6, 5, 4, 3, 2 or 1 second billing. After deploying
about nearly a thousand SIP-speaking phones for different folk over last few
months I can tell you that the self-provisioning for the customer's side is
becoming so easy a caveman can do it. 

There goes their $20 or more per month worth of profit per phone number.

Does it mean that they are preventing other SIP devices to work on their
IP network? No, it does not. But what they are doing is preventing SIP
devices from working with their voice network because they do not want it to
be a user-controlled SIP device.

Alex

-- 
Alexander O. YurievProviding and Managing Solutions
CTO, Zubr Communications Hosting, Servers, Applications, Access
   web: http://www.zubrcom.net   tel: 267-298-3232   fax: 267-350-3303  

Windows Live Mail/Hotmail Postmaster Contact?

[Ryan Gelobter]

Can anyone provide me with an alternative contact to someone at Hotmail?
I've tried their support form over at
https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts&st=1&wfxredirect=1which
doesn't seem to ever generate even an auto-reply anymore. Feel free to
contact me off-list.

Re: Real World NAT64 deployments

[William Herrin]

On Thu, Mar 3, 2011 at 5:01 PM, Hammer  wrote:
> A little better. So what's the difference between 6to4 and 6in4? Isn't 6in4
> what HE uses?

I haven't used 6in4 so I couldn't tell you.

6to4 is a stateless tunnelling protocol. You have a dual-stacked
router. It has an IPv4 address, 1.2.3.4. Therefore it supports a 6to4
IPv6 network numbered 2002:0102:0304::/48. Somebody tries to send a
packet to 2002:0102:0304::1, it goes to a 6to4 router which
encapsulates the IPv6 packet in an IPv4 packet and sends it to
1.2.3.4.

6to4 is handy as a toy or for experimenting, but it relies on a loose
network of generous volunteers who, while generous, are neither
generous nor numerous enough to support production traffic.

-Bill


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: AT&T via Tata and Level3

[Robert Bonomi]

> Date: Thu, 3 Mar 2011 14:12:16 -0600
> From: Richard A Steenbergen 
> Subject: Re: AT&T via Tata and Level3
> Cc: nanog@nanog.org
>
> On Thu, Mar 03, 2011 at 11:15:51AM -0500, Morgan Miskell wrote:
> > I've noticed that we have thousands of routes for AT&T via Tata that we 
> > don't have from AT&T through Level3.  I would expect Level3 to have 
> > most of the routes for AT&T that Tata does since they are both directly 
> > peered with AT&T.
>
> Well, I don't know anything about this specific issue or any policy 
> changes that may have been made, but at a high level I can tell you that 
> BGP doesn't work like that. BGP is only capable of passing on a single 
> best path for each route, and what is considered the best path is totally 
> in the eye of the beholder.

[[..  sneck much good stuff  ..]]

While what you say is accurate, it is _irrelevant_ to the situation that
the OP posted about.  Methinks you misunderstood what he said.

He peers with Level3 and TATA.  Both of whom peer with AT&T.

Looking at the -incoming- data from those two peers, he sees "thousands"
of entries for AT&T address-blocks announced to him by TATA that are 
not being announced to him by Level3.

Postulating that AT&T _is_ announcing all its address-blocks to both of 
those direct peers, the 'one-BGP-hop-removed-from-directly-connected' 
network should expect to see all those blocks from any of it's directly 
connected peers that are directly connected to AT&T.  If one of those 
peers sees a 'better' route to one of those AT&T address-blocks, then it
should be announcing that indirect path instead of the direct one.  Ditto
for blocks that AT&D does -not- announce (for whatever reason, traffic
engineering, maybe?) to a directly connected peer.

I would hazard a guess that the "missing routes" _might_ be the result of
supressing 'more specifics', or they _are_ being announced to Level3, but
with a 'community' tag that Level3 interprets as 'use locally, but do not
announce externally'.

Re: Real World NAT64 deployments

[Elliot Finley]

>
> Ok, apparently there is NAT64 and there is NAT64.  I don't believe the
> poster was talking about a v6 load balancer VIP with v4 servers.  I
> think the OP is talking about the NAT64 portion of NAT64/DNS64 where
> native v6 source and destination IPs are NATed to v4 destination and
> source IPs for communicating with v4 resources from a v6 host.
>
> But I might be projecting my own needs here.  So, what kind of NAT64 are
> we talking about?
>
> George
>
>
You are correct.  I'm talking about the NAT64 portion of NAT64/DNS64.

Elliot

Re: Mac OS X 10.7, still no DHCPv6

[Bernhard Schmidt]

Mikael Abrahamsson  wrote:

> On a more serious note, I can on my Ubuntu machine just "apt-get install 
> wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in 
> resolv.conf for dns-over-ipv6 transport, even though the connection 
> manager knows nothing about it, at least dual stack works properly.

This is finally getting fixed now. NetworkManager 0.8.3, to be shipped
in the upcoming Ubuntu 11.04 (Natty) seems to do the right thing,
including using the OtherConfig-Flag in RA to trigger a stateless DHCPv6
request. Haven't tested stateful yet.

Bernhard

Re: Real World NAT64 deployments

[Mark Andrews]

In message , Will
iam Herrin writes:
> On Thu, Mar 3, 2011 at 5:01 PM, Hammer  wrote:
> > A little better. So what's the difference between 6to4 and 6in4?
> Isn't 6in4 what HE uses?
> 
> I haven't used 6in4 so I couldn't tell you.
> 
> 6to4 is a stateless tunnelling protocol. You have a dual-stacked
> router. It has an IPv4 address, 1.2.3.4. Therefore it supports a 6to4
> IPv6 network numbered 2002:0102:0304::/48. Somebody tries to send a
> packet to 2002:0102:0304::1, it goes to a 6to4 router which
> encapsulates the IPv6 packet in an IPv4 packet and sends it to
> 1.2.3.4.
> 
> 6to4 is handy as a toy or for experimenting, but it relies on a loose
> network of generous volunteers who, while generous, are neither
> generous nor numerous enough to support production traffic.

Any ISP that is delivering IPv6 to their clients would be insane
to not run a 6to4 relays for return traffic to 2002::/16.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Real World NAT64 deployments

[TJ]

6in4 == deprecated automatic tunneling mechanism ... HE is an example of
manually configured Protocol41 encaps.

And 6to4 doesn't allow IPv6 to talk to IPv4, contrary to what the name seems
to imply :).

Some poorly chosen names for our tunneling, yes?

Thanks, TJ's Droid2
On Mar 3, 2011 6:27 PM, "William Herrin"  wrote:

Re: Real World NAT64 deployments

[Leo Bicknell]

In a message written on Thu, Mar 03, 2011 at 08:27:18PM -0500, TJ wrote:
> And 6to4 doesn't allow IPv6 to talk to IPv4, contrary to what the name seems
> to imply :).
> 
> Some poorly chosen names for our tunneling, yes?

I think 6automaticallyover4 was determined to be too long. :P

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpdOD44fWFxX.pgp
Description: PGP signature

Re: Postfix spam

[Suresh Ramasubramanian]

The headers this guy sent me offlist = what you suggest just wouldn't
work, sorry.

He most likely had a rootkit on his server that was emitting direct to MX spam.

On Fri, Mar 4, 2011 at 2:38 AM, Joshua Klubi  wrote:
> Get A.S.S.P and integrate it with your postfix box, implement SPF and run 
> dkimproxy on your postfix box and bid spams adieu .
>
> You would be surprised the power of ASSP . It is the best out there that 
> kills spam dead on arrival and departure.



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

RE: Where are the VoIP clue bats?

[Scott Berkman]

http://voip-info.orgGreat general reference

http://voiceops.org Great List  (ok I helped start it so I might be a
little biased)

http://puck.nether.net/mailman/listinfo/cisco-voip  Cisco VOIP specific
list

-Scott

-Original Message-
From: Eric Brunner-Williams [mailto:brun...@nic-naa.net] 
Sent: Thursday, March 03, 2011 3:44 PM
To: NANOG list
Subject: OT: Where are the VoIP clue bats?

First, thanks for all the responses to "What vexes VoIP users?"

I'm looking for pointers to sites, like Geoff Huston's potaroo.net, that are
VoIP clue dense, or mailing lists(*) where the VoIP-full lurk.

Thanks in advance,
Eric

(*) I'm already on the ecrit list, though my real interest in the ongoing
IETF "emergency services" meme has been a "I'm alive" app, not circuit and
bandwidth capture by government. I was pleased to see a "I'm alive" app
fielded by Google last week at Christchurch, NZ.

RE: Real World NAT64 deployments

[Frank Bulk]

There's no assurance that the content provider will use the ISP's 6to4
relay.  In fact, there's a good chance it won't use the ISP's 6to4 relay for
return traffic.

Frank

-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Thursday, March 03, 2011 7:17 PM
To: William Herrin
Cc: nanog@nanog.org
Subject: Re: Real World NAT64 deployments



Any ISP that is delivering IPv6 to their clients would be insane
to not run a 6to4 relays for return traffic to 2002::/16.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Real World NAT64 deployments

[Owen DeLong]

On Mar 3, 2011, at 1:54 PM, William Herrin wrote:

> On Thu, Mar 3, 2011 at 3:41 PM, Hammer  wrote:
>> I need a cheat sheet.
>> 
>> nat64
>> 6to4nat
>> 6in4nat
>> etc...
> 
> 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6
> nodes to talk to each other via an IPv4 backbone.
> 
> nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints.
> 
> nat44 is the IPv4 NAT you're used to.
> nat444 is carrier NAT (translated once by the customer and once again
> by the ISP, get it?)
> 
> 
More accurately:

NAT44 is consumer NAT you're used to.
LSN/CGN is NAT at the carrier level.
DS-LITE is native IPv6 with private IPv4 tunneled over IPv6 to reach
an LSN/CGN for IPv4 connectivity.
NAT444 is NAT44 + LSN/CGN

Owen

Re: Real World NAT64 deployments

[Owen DeLong]

HE uses 6in4. 6in4 is basically the same protocol as 6to4, but, with defined
end-points for point-to-point tunneling packets from multipoint to multipoint.

6to4, conversely, uses anycast to identify the tunnel exit point towards the
IPv6 network or to identify the tunnel entry point towards the IPv4 segment.
It depends on encoding the IPv4 address of the local encapsulating host
sending the packet inside of the IPv6 source address in order to be able
to identify the IPv4 destination after encapsulation. For 6to4, one end is
almost always a single specific host which both generates the packets
and does he IPv4 encapsulation.

Owen

On Mar 3, 2011, at 2:01 PM, Hammer wrote:

> A little better. So what's the difference between 6to4 and 6in4? Isn't 6in4
> what HE uses?
> 
> 
> -Hammer-
> 
> "I was a normal American nerd."
> -Jack Herer
> 
> 
> 
> 
> 
> On Thu, Mar 3, 2011 at 3:54 PM, William Herrin  wrote:
> 
>> On Thu, Mar 3, 2011 at 3:41 PM, Hammer  wrote:
>>> I need a cheat sheet.
>>> 
>>> nat64
>>> 6to4nat
>>> 6in4nat
>>> etc...
>> 
>> 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6
>> nodes to talk to each other via an IPv4 backbone.
>> 
>> nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints.
>> 
>> nat44 is the IPv4 NAT you're used to.
>> nat444 is carrier NAT (translated once by the customer and once again
>> by the ISP, get it?)
>> 
>> 
>> 
>> --
>> William D. Herrin  her...@dirtside.com  b...@herrin.us
>> 3005 Crane Dr. .. Web: 
>> Falls Church, VA 22042-3004
>> 

Re: Interesting google redirects.

[Raymond Macharia]

Noticed the same thing to the .com.hk
Raymond Macharia


On Thu, Mar 3, 2011 at 8:04 PM, Wayne Lee wrote:

> >> also some EU customers are getting redirected to .au  domain
>
> Mine got redirected to google.be for a while.
>
>

Re: Interesting google redirects.

[Mark Keymer]

On this same subject. My techs have been complaining lately about our 
new VPS's we are making going to google.vm. Is there anything I can do 
on my end to get this corrected?


Sincerely,

Mark Keymer


Raymond Macharia wrote:


Noticed the same thing to the .com.hk
Raymond Macharia


On Thu, Mar 3, 2011 at 8:04 PM, Wayne Lee wrote:

 


also some EU customers are getting redirected to .au  domain
   


Mine got redirected to google.be for a while.


   

Re: Postfix spam

[Joshua William Klubi]

Then like Robert Suggest he should implement step 2
and it would solve his problem asap

Joshua

On Fri, Mar 4, 2011 at 2:18 AM, Suresh Ramasubramanian
wrote:

> The headers this guy sent me offlist = what you suggest just wouldn't
> work, sorry.
>
> He most likely had a rootkit on his server that was emitting direct to MX
> spam.
>
> On Fri, Mar 4, 2011 at 2:38 AM, Joshua Klubi 
> wrote:
> > Get A.S.S.P and integrate it with your postfix box, implement SPF and run
> dkimproxy on your postfix box and bid spams adieu .
> >
> > You would be surprised the power of ASSP . It is the best out there that
> kills spam dead on arrival and departure.
>
>
>
> --
> Suresh Ramasubramanian (ops.li...@gmail.com)
>

Re: [v6z] Re: Interesting google redirects.

[Scott Howard]

On Thu, Mar 3, 2011 at 10:13 PM, Mark Keymer  wrote:

> On this same subject. My techs have been complaining lately about our new
> VPS's we are making going to google.vm. Is there anything I can do on my end
> to get this corrected?
>

http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=873

(Hint: the NANOG list archives can often be helpful for this type of stuff!)

  Scott

Re: Real World NAT64 deployments

[Karl Auer]

On Thu, 2011-03-03 at 20:27 -0500, TJ wrote:
> 6in4 == deprecated automatic tunneling mechanism ... HE is an example of
> manually configured Protocol41 encaps.

Deprecated? Do you have a reference...?

Thanks, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156


signature.asc
Description: This is a digitally signed message part

Re: Real World NAT64 deployments

[sthaug]

> > 6to4 is handy as a toy or for experimenting, but it relies on a loose
> > network of generous volunteers who, while generous, are neither
> > generous nor numerous enough to support production traffic.
> 
> Any ISP that is delivering IPv6 to their clients would be insane
> to not run a 6to4 relays for return traffic to 2002::/16.

Given the number of ISPs that will need to turn on IPv6 the next few
years, I believe the only conclusion here is that we'll see a large
number of "insane" ISPs ...

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: Real World NAT64 deployments

[Owen DeLong]

He is mistaken... HE Tunnels are an example of 6in4 and it is not deprecated,
but, some original mechanisms for 6in4 to which he may be referring were
deprecated.

http://en.wikipedia.org/wiki/6in4

Owen

On Mar 3, 2011, at 11:17 PM, Karl Auer wrote:

> On Thu, 2011-03-03 at 20:27 -0500, TJ wrote:
>> 6in4 == deprecated automatic tunneling mechanism ... HE is an example of
>> manually configured Protocol41 encaps.
> 
> Deprecated? Do you have a reference...?
> 
> Thanks, K.
> 
> -- 
> ~~~
> Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/   +61-428-957160 (mob)
> 
> GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
> Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156