Re: iabelle francois

[John Palmer (NANOG Acct)]

- Original Message - 
From: "Ted Cooper" 

To: 
Sent: Thursday, April 22, 2010 11:33 PM
Subject: Re: iabelle francois




Posting so many URLs which either are or should be listed in domain
block lists to a list with as many subscribers as this is probably not
wise. I'm guessing you just caused a wonderful bounce storm as the NANOG
servers attempted to send that out, depending of course on how many
people whitelist NANOG to URI filtering.
 ...
The analysis of the domain is solid though, so good work there. Perhaps
NANOG is not the correct forum though? Spam-L seems like a better fit.


Spam-watch.com is the proper place for it.

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/22/2010 22:18, Matthew Kaufman wrote:
> Owen DeLong wrote:
>> On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
>>
>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> On 4/22/2010 05:34, Simon Perreault wrote:
>>>
 On 2010-04-22 07:18, William Herrin wrote:

> On the other hand, I could swear I've seen a draft where
> the PC picks up random unused addresses in the lower 64 for
> each new outbound connection for anonymity purposes.
>
 That's probably RFC 4941. It's available in pretty much all
 operating systems. I don't think there's any IPR issue to be
 afraid of.

 Simon

>>> I think this is different.  They're talking about using a new
>>> IPv6 for each connection.  RFC4941 just changes it over time
>>> IIRC.  IMHO that's still pretty good privacy, at least on par
>>> with a NATed IPv4 from the outside perspective, especially if
>>> you rotated through temporary IPv6s fairly frequently.
>>>
>>
>> 4941 specified changing over time as one possibility.  It does
>> allow for per flow or any other host based determination of when
>> it needs a new address.
>>
>> Owen
>>
>>
>>
> But none of this does what NAT does for a big enterprise, which is
> to *hide internal topology*. Yes, addressing the privacy concerns
> that come from using lower-64-bits-derived-from-MAC-address is
> required, but it is also necessary (for some organizations) to
> make it impossible to tell that this host is on the same subnet as
> that other host, as that would expose information like which host
> you might want to attack in order to get access to the financial
> or medical records, as well as whether or not the executive floor
> is where these interesting website hits came from.
>
> Matthew Kaufman
Yeh that information leak is one reason I can think of for supporting
NAT for IPv6.  One of the inherent security issues with unique
addresses I suppose.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvRMCsACgkQ2fXFxl4S7sShwACgpZEd1rQD+/+dxonkOVpwPaUj
oBIAoOJ78A5Yvftfz+JPjGWWQoVhb6F8
=oQHv
-END PGP SIGNATURE-

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/22/2010 22:00, Owen DeLong wrote:
>
> On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 4/22/2010 05:34, Simon Perreault wrote:
>>> On 2010-04-22 07:18, William Herrin wrote:
 On the other hand, I could swear I've seen a draft where the
 PC picks up random unused addresses in the lower 64 for each
 new outbound connection for anonymity purposes.
>>>
>>> That's probably RFC 4941. It's available in pretty much all
>>> operating systems. I don't think there's any IPR issue to be
>>> afraid of.
>>>
>>> Simon
>> I think this is different.  They're talking about using a new
>> IPv6 for each connection.  RFC4941 just changes it over time
>> IIRC.  IMHO that's still pretty good privacy, at least on par
>> with a NATed IPv4 from the outside perspective, especially if you
>> rotated through temporary IPv6s fairly frequently.
>
> 4941 specified changing over time as one possibility.  It does
> allow for per flow or any other host based determination of when it
> needs a new address.
>
> Owen
K.  Can't say I've read the RFC all the way through (skimmed it).
Current implementations do the time thing.  XP, Vista, and 7 seem to
have it turned on by default.  *nix has support via the
"net.ipv6.conf.all.use_tempaddr=2" variable, typically not on by default.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvRLkUACgkQ2fXFxl4S7sQ2YgCg3uSkp1GNxcgjCDVc1jxnDv7s
DtoAniXH8nND7+r6xEFJXGHrRJ77CBkZ
=eSHI
-END PGP SIGNATURE-

Re: Rate of growth on IPv6 not fast enough?

[Matthew Kaufman]

Owen DeLong wrote:

On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:

  

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4/22/2010 05:34, Simon Perreault wrote:


On 2010-04-22 07:18, William Herrin wrote:
  

On the other hand, I could swear I've seen a draft where the PC
picks up random unused addresses in the lower 64 for each new
outbound connection for anonymity purposes.


That's probably RFC 4941. It's available in pretty much all
operating systems. I don't think there's any IPR issue to be afraid
of.

Simon
  

I think this is different.  They're talking about using a new IPv6 for
each connection.  RFC4941 just changes it over time IIRC.  IMHO that's
still pretty good privacy, at least on par with a NATed IPv4 from the
outside perspective, especially if you rotated through temporary IPv6s
fairly frequently.



4941 specified changing over time as one possibility.  It does allow
for per flow or any other host based determination of when it needs a new
address.

Owen


  
But none of this does what NAT does for a big enterprise, which is to 
*hide internal topology*. Yes, addressing the privacy concerns that come 
from using lower-64-bits-derived-from-MAC-address is required, but it is 
also necessary (for some organizations) to make it impossible to tell 
that this host is on the same subnet as that other host, as that would 
expose information like which host you might want to attack in order to 
get access to the financial or medical records, as well as whether or 
not the executive floor is where these interesting website hits came from.


Matthew Kaufman

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[Owen DeLong]

On Apr 22, 2010, at 9:13 AM, Bill Bogstad wrote:

> On Thu, Apr 22, 2010 at 11:03 AM, David Conrad  wrote:
>> On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote:
 So what happens when you change providers? How are you going to keep
 using globals that now aren't yours?
>>> use pi space, request it from your local friendly RIR.
>> 
>> And don't forget to invest in memory manufacturers and router vendors :-)
> 
> Only required if those addresses are advertised to the Internet.
> Which is apparently NOT
> what people want to do with it.   In addition, it seems like the RIRs
> frown on not publishing your IPv6 PI allocations.  If you go this
> route, be sure to 'justify' as large an allocation as you could ever
> possibly imagine using because you'll only get one bite from that
> apple.
> 
We're working on policy to address that within the ARIN region.  I suspect
it will get addressed elsewhere as well.

The bigger concern (and original intent of the phrases driving that concern)
was that it be advertised as a single prefix and not multiple prefixes hitting
the DFZ.

Owen

Re: Rate of growth on IPv6 not fast enough?

[Owen DeLong]

On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 4/22/2010 05:34, Simon Perreault wrote:
>> On 2010-04-22 07:18, William Herrin wrote:
>>> On the other hand, I could swear I've seen a draft where the PC
>>> picks up random unused addresses in the lower 64 for each new
>>> outbound connection for anonymity purposes.
>> 
>> That's probably RFC 4941. It's available in pretty much all
>> operating systems. I don't think there's any IPR issue to be afraid
>> of.
>> 
>> Simon
> I think this is different.  They're talking about using a new IPv6 for
> each connection.  RFC4941 just changes it over time IIRC.  IMHO that's
> still pretty good privacy, at least on par with a NATed IPv4 from the
> outside perspective, especially if you rotated through temporary IPv6s
> fairly frequently.

4941 specified changing over time as one possibility.  It does allow
for per flow or any other host based determination of when it needs a new
address.

Owen

Re: Rate of growth on IPv6 not fast enough?

[Owen DeLong]

On Apr 22, 2010, at 4:30 AM, bmann...@vacation.karoshi.com wrote:

>> 
>> On the other hand, I could swear I've seen a draft where the PC picks
>> up random unused addresses in the lower 64 for each new outbound
>> connection for anonymity purposes. Even if there is no such draft, it
>> wouldn't exactly be hard to implement. It won't take NAT to anonymize
>> the PCs on a LAN with IPv6.
> 
>   the idea is covered by one or more patents held by cisco.
> 
> --bill
> 
>> Regards,
>> Bill Herrin

It's default behavior in Windows 7 and is specified in an RFC.

Look for IPv6 Privacy Addressing.

Owen

Re: iabelle francois

[Ted Cooper]

On Thu, 2010-04-22 at 23:22 -0400, Eric Carroll wrote:
> On 10-04-21 06:59 PM, Jeroen van Aart wrote:
> > The url redirects to a Canadian med site.
> Just FYI, it's not a real Canadian med site. It is high probability
> not 
> even Canadian.

Posting so many URLs which either are or should be listed in domain
block lists to a list with as many subscribers as this is probably not
wise. I'm guessing you just caused a wonderful bounce storm as the NANOG
servers attempted to send that out, depending of course on how many
people whitelist NANOG to URI filtering.

yourtabletrxhealth[dot]com - URIBL black 2010-04-22 00:07:14 GMT
superstorepills[dot]net - URLBL black 2010-04-21 20:47:31 GMT
bargainpillsstore[dot]net - URLBL black 2010-04-15 20:41:59 GMT
losspillssite[dot]net - URLBL black 2010-04-21 20:45:09 GMT

The analysis of the domain is solid though, so good work there. Perhaps
NANOG is not the correct forum though? Spam-L seems like a better fit.

Re: iabelle francois

[Eric Carroll]

On 10-04-21 06:59 PM, Jeroen van Aart wrote:

The url redirects to a Canadian med site.
Just FYI, it's not a real Canadian med site. It is high probability not 
even Canadian.


The site appears to be a referral round robin over many domain names, 
including:
-  www.yourtabletrxhealth.com/ - traceroute to AS12880 "Data 
communication Company of Iran"

- www.superstorepills.net/ - traceroute to AS9737 TOT Public Company Limited
- www.bargainpillsstore.net - traceroute to AS4134 CHINANET-BACKBONE
-  www.losspillssite.net - traceroute to AS4837 CHINA169-Backbone
etc.

The www.yourtabletrxhealth.com domain name was created April 5 of 2010 
and has Russian contact address information. 
http://whois.domaintools.com/yourtabletrxhealth.com


Parts of the www.yourtabletrxhealth.com web pages are pulled in from all 
over, including AS9486, AS9737.


The "license" at the bottom is fake. The controlling professional body 
in Ontario is the Ontario College of Pharmacists not "College of 
Pharmacists of Ontario".  In Ontario, the language is that Pharmacies 
are accredited, not licensed. Pharmacists are licensed.


The Verisign click-through is fake.

OCP has no record of this company by name, location or number. See 
https://members.ocpinfo.com/ocpsearch/


The CEO is claimed to be affiliated with University of Western Ontario. 
Can't find them.


Feel free to check out Kingston ON in Google street view for added 
amusement.


And its listed in spamwiki.

Regards,

Eric Carroll

sync attack from cox.net

[Ingo Flaschberger]

Hi,

can please someone from cox.net contact me?
I receive now since more tha 24 hours a syn-attack from their network -
and abuse contact does not react.

Kind regards,
ingo flaschberger

geschaeftsleitung

crossip communications gmbh
A-1020 Wien, Sebastian Kneipp Gasse 1
Tel: +43-1-7261522-0
Fax: +43-1-726 15 22-111
www.crossip.net
___
crossip communications gmbh
Sitz der Gesellschaft: 1020 Wien, Oesterreich
Firmenbuchgericht: Handelsgericht Wien, FN 269698 s

Umsatzsteueridentifikationsnummer (UID): ATU62080367

Diese Nachricht ist fuer die crossip communications gmbh rechtsunverbindlich
und ausschliesslich fuer den/die oben bezeichneten Adressaten bestimmt und
enthaelt moeglicherweise vertrauliche Informationen. Sollten Sie nicht der
oben bezeichnete Adressat sein oder diese Nachricht irrtuemlich erhalten
haben, ersuchen wir Sie, diese Nachricht nicht weiterzugeben, zu kopieren
oder im Vertrauen darauf zu handeln, sondern den Absender zu verstaendigen
und diese Nachricht samt allfaelliger Anlagen sofort zu loeschen.
Vielen Dank.

This message is not legally binding upon crossip communications gbmbh and
is intended only for use by the named addressee and may contain privileged
and/or confidential information. If you are not the named addressee, you
should not disseminate, copy, or take any action in reliance on it. If you
have received this message in error, please immediately notify the sender
and delete this message and any attachment.
Thank you.

Re: Mail Submission Protocol

[Dave CROCKER]

On 4/21/2010 8:16 PM, Suresh Ramasubramanian wrote:

The MAAWG BCPs have far more available than one of the worst
maintained blacklists that has ever been in existence.



For example:

   

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[bmanning]

> believe in the ARIN region all you NEED to do is provide a spreadsheet
> showing your utilization, checking for the routes in the 'DFZ'
> (bmanning-summons) isn't relevant for additional requests.

"... all circuits are busy, please call back later..."


> -chris

--bill

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[Christopher Morrow]

On Thu, Apr 22, 2010 at 12:13 PM, Bill Bogstad  wrote:
> On Thu, Apr 22, 2010 at 11:03 AM, David Conrad  wrote:
>> On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote:
 So what happens when you change providers? How are you going to keep
 using globals that now aren't yours?
>>> use pi space, request it from your local friendly RIR.
>>
>> And don't forget to invest in memory manufacturers and router vendors :-)
>
> Only required if those addresses are advertised to the Internet.
> Which is apparently NOT
> what people want to do with it.   In addition, it seems like the RIRs
> frown on not publishing your IPv6 PI allocations.  If you go this

this is commonly held up as a reason that getting allocations is hard,
but the infrastructure micro-allocations are never to be seen in the
global table.

It woudl be super nice if some kind RIR people could comment here, I
believe in the ARIN region all you NEED to do is provide a spreadsheet
showing your utilization, checking for the routes in the 'DFZ'
(bmanning-summons) isn't relevant for additional requests.

> route, be sure to 'justify' as large an allocation as you could ever
> possibly imagine using because you'll only get one bite from that
> apple.

see previous comment, I believe this is a red-herring.

>
> Or maybe someone could offer to advertise these deliberately
> unreachable addresses for a small fee and then null route any stray
> packets that happen to want to get
> there.   Would this satisfy the letter (if not the spirit) for
> justifying PI space?

you still have to provide SWIP, RWHOIS or some other accounting of the
usage (spreadsheet/csvfile seems to be historically acceptable)

-chris

> Bill Bogstad
>
>

Re: Rate of growth on IPv6 not fast enough?

[Scott Weeks]

--- j...@jsbc.cc wrote:
From: Jim Burwell 

I think this is different.  They're talking about using a new IPv6 for
each connection.  RFC4941 just changes it over time IIRC.  IMHO that's
still pretty good privacy, at least on par with a NATed IPv4 from the
outside perspective, especially if you rotated through temporary IPv6s
fairly frequently.

Of course, for browsers, as someone else mentioned, it's somewhat moot
because of cookies.



Manage your cookies.  

preferences => privacy & security => cookies => select "ask for each cookie"

Noisy in the beginning and then settles down after a while.  Surprising, 
though, in what is tracked, so it's worth doing for a while just to observe.  
Oh, yeah, also manage your Flash cookies: 

http://macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html

scott

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[Bill Bogstad]

On Thu, Apr 22, 2010 at 11:03 AM, David Conrad  wrote:
> On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote:
>>> So what happens when you change providers? How are you going to keep
>>> using globals that now aren't yours?
>> use pi space, request it from your local friendly RIR.
>
> And don't forget to invest in memory manufacturers and router vendors :-)

Only required if those addresses are advertised to the Internet.
Which is apparently NOT
what people want to do with it.   In addition, it seems like the RIRs
frown on not publishing your IPv6 PI allocations.  If you go this
route, be sure to 'justify' as large an allocation as you could ever
possibly imagine using because you'll only get one bite from that
apple.

Or maybe someone could offer to advertise these deliberately
unreachable addresses for a small fee and then null route any stray
packets that happen to want to get
there.   Would this satisfy the letter (if not the spirit) for
justifying PI space?

Bill Bogstad

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[David Conrad]

On Apr 21, 2010, at 10:48 PM, Christopher Morrow wrote:
>> So what happens when you change providers? How are you going to keep
>> using globals that now aren't yours?
> use pi space, request it from your local friendly RIR.

And don't forget to invest in memory manufacturers and router vendors :-)

Regards,
-drc

Re: Rate of growth on IPv6 not fast enough?

[Larry Sheldon]

On 4/22/2010 10:17, Charles Mills wrote:
> I think he was actually quoting the movie.  They always called Harvey
> Korman's character "Hedy" and he'd always correct them with "That's
> Hedley" in a most disapproving tone.

Oh.

The only thing I watch less-of than TV is movies.

Saydid they ever make a sequel to "Crocodile Dundee"?
-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Re: Rate of growth on IPv6 not fast enough?

[Marshall Eubanks]

On Apr 22, 2010, at 11:04 AM, John Lightfoot wrote:


That's Hedley.



I believe that he is talking about Hedy Lamarr, the co-inventor of  
frequency hopping spread spectrum.


Regards
Marshall


-Original Message-
From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com 
]

Sent: Thursday, April 22, 2010 10:34 AM
To: Simon Perreault
Cc: nanog@nanog.org
Subject: Re: Rate of growth on IPv6 not fast enough?

On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:

On 2010-04-22 07:18, William Herrin wrote:
On the other hand, I could swear I've seen a draft where the PC  
picks

up random unused addresses in the lower 64 for each new outbound
connection for anonymity purposes.


That's probably RFC 4941. It's available in pretty much all operating
systems. I don't think there's any IPR issue to be afraid of.


not RFC4941... think abt applying Heddy Lamars
patents on spread-spectrum to source address selection.

--bill

Re: Rate of growth on IPv6 not fast enough?

[Charles Mills]

I think he was actually quoting the movie.  They always called Harvey
Korman's character "Hedy" and he'd always correct them with "That's
Hedley" in a most disapproving tone.

You had to have watched that movie way too many times (much to my
wife's chagrin) to catch the subtle joke.
On Thu, Apr 22, 2010 at 11:10 AM, Matthew Huff  wrote:
> Actually, no.
>
> Not from the Mel Brooks movie.
>
> Hedy Lamarr
>
> http://en.wikipedia.org/wiki/Hedy_Lamarr
>
> Hedy Lamarr (November 9, 1914 - January 19, 2000) was an Austrian-born 
> American actress and engineer. Though known primarily for her film career as 
> a major contract star of MGM's "Golden Age", she also co-invented an early 
> form of spread spectrum communications technology, a key to modern wireless 
> communication.[1]
>
>
> 
> Matthew Huff   | One Manhattanville Rd
> OTA Management LLC | Purchase, NY 10577
> http://www.ox.com  | Phone: 914-460-4039
> aim: matthewbhuff  | Fax:   914-460-4139
>
>
>
>> -Original Message-
>> From: John Lightfoot [mailto:jlightf...@gmail.com]
>> Sent: Thursday, April 22, 2010 11:05 AM
>> To: bmann...@vacation.karoshi.com; 'Simon Perreault'
>> Cc: nanog@nanog.org
>> Subject: RE: Rate of growth on IPv6 not fast enough?
>>
>> That's Hedley.
>>
>> -Original Message-
>> From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com]
>> Sent: Thursday, April 22, 2010 10:34 AM
>> To: Simon Perreault
>> Cc: nanog@nanog.org
>> Subject: Re: Rate of growth on IPv6 not fast enough?
>>
>> On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
>> > On 2010-04-22 07:18, William Herrin wrote:
>> > >On the other hand, I could swear I've seen a draft where the PC picks
>> > >up random unused addresses in the lower 64 for each new outbound
>> > >connection for anonymity purposes.
>> >
>> > That's probably RFC 4941. It's available in pretty much all operating
>> > systems. I don't think there's any IPR issue to be afraid of.
>>
>>       not RFC4941... think abt applying Heddy Lamars
>>       patents on spread-spectrum to source address selection.
>>
>> --bill
>>
>>
>
>

Re: Rate of growth on IPv6 not fast enough?

[Larry Sheldon]

On 4/22/2010 10:04, John Lightfoot wrote:
> That's Hedley.
> 
> -Original Message-
> From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com] 
> Sent: Thursday, April 22, 2010 10:34 AM
> To: Simon Perreault
> Cc: nanog@nanog.org
> Subject: Re: Rate of growth on IPv6 not fast enough?
> 
> On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
>> On 2010-04-22 07:18, William Herrin wrote:
>>> On the other hand, I could swear I've seen a draft where the PC picks 
>>> up random unused addresses in the lower 64 for each new outbound 
>>> connection for anonymity purposes.
>>
>> That's probably RFC 4941. It's available in pretty much all operating 
>> systems. I don't think there's any IPR issue to be afraid of.
> 
>   not RFC4941... think abt applying Heddy Lamars 
>   patents on spread-spectrum to source address selection.

Hedwig Eva Maria Kiesler aka Hedy Lamarr


-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

RE: Rate of growth on IPv6 not fast enough?

[Matthew Huff]

Actually, no.

Not from the Mel Brooks movie.

Hedy Lamarr

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

Hedy Lamarr (November 9, 1914 - January 19, 2000) was an Austrian-born American 
actress and engineer. Though known primarily for her film career as a major 
contract star of MGM's "Golden Age", she also co-invented an early form of 
spread spectrum communications technology, a key to modern wireless 
communication.[1]



Matthew Huff   | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com  | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139



> -Original Message-
> From: John Lightfoot [mailto:jlightf...@gmail.com]
> Sent: Thursday, April 22, 2010 11:05 AM
> To: bmann...@vacation.karoshi.com; 'Simon Perreault'
> Cc: nanog@nanog.org
> Subject: RE: Rate of growth on IPv6 not fast enough?
> 
> That's Hedley.
> 
> -Original Message-
> From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com]
> Sent: Thursday, April 22, 2010 10:34 AM
> To: Simon Perreault
> Cc: nanog@nanog.org
> Subject: Re: Rate of growth on IPv6 not fast enough?
> 
> On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
> > On 2010-04-22 07:18, William Herrin wrote:
> > >On the other hand, I could swear I've seen a draft where the PC picks
> > >up random unused addresses in the lower 64 for each new outbound
> > >connection for anonymity purposes.
> >
> > That's probably RFC 4941. It's available in pretty much all operating
> > systems. I don't think there's any IPR issue to be afraid of.
> 
>   not RFC4941... think abt applying Heddy Lamars
>   patents on spread-spectrum to source address selection.
> 
> --bill
> 
> 

<>

RE: Rate of growth on IPv6 not fast enough?

[John Lightfoot]

That's Hedley.

-Original Message-
From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com] 
Sent: Thursday, April 22, 2010 10:34 AM
To: Simon Perreault
Cc: nanog@nanog.org
Subject: Re: Rate of growth on IPv6 not fast enough?

On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
> On 2010-04-22 07:18, William Herrin wrote:
> >On the other hand, I could swear I've seen a draft where the PC picks 
> >up random unused addresses in the lower 64 for each new outbound 
> >connection for anonymity purposes.
> 
> That's probably RFC 4941. It's available in pretty much all operating 
> systems. I don't think there's any IPR issue to be afraid of.

not RFC4941... think abt applying Heddy Lamars 
patents on spread-spectrum to source address selection.

--bill

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[Richard Barnes]

Isn't "global addresses you can take with you when you change
providers" kind of the definition of Provider Independent address
space?  If you want to keep the same addresses when you change
providers, you just need to get a PI allocation.
--Richard

On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith
 wrote:
> On Wed, 21 Apr 2010 09:25:46 -0400
> Christopher Morrow  wrote:
>
>> On Wed, Apr 21, 2010 at 1:29 AM, Owen DeLong  wrote:
>> > While I think this is an improvement, unless the distribution of ULA-C is 
>> > no cheaper
>> > and no easier to get than GUA, I still think there is reason to believe 
>> > that it is likely
>> > ULA-C will become de facto GUA over the long term.
>> >
>> > As such, I still think the current draft is a bad idea absent appropriate 
>> > protections in
>> > RIR policy.
>>
>> I agree with owen, mostly... except I think we should just push RIR's
>> to make GUA accessible to folks that need ipv6 adress space,
>> regardless of connectiivty to thegreater 'internet' (for some
>> definition of that thing).
>>
>> ULA of all types causes headaches on hosts, routers, etc. There is no
>> reason to go down that road, just use GUA (Globally Unique Addresses).
>>
>
> So what happens when you change providers? How are you going to keep
> using globals that now aren't yours?
>
> I'm also curious about these headaches. What are they?
>
>
>> -Chris
>>
>
>

Re: Rate of growth on IPv6 not fast enough?

[bmanning]

On Thu, Apr 22, 2010 at 08:34:20AM -0400, Simon Perreault wrote:
> On 2010-04-22 07:18, William Herrin wrote:
> >On the other hand, I could swear I've seen a draft where the PC picks
> >up random unused addresses in the lower 64 for each new outbound
> >connection for anonymity purposes.
> 
> That's probably RFC 4941. It's available in pretty much all operating 
> systems. I don't think there's any IPR issue to be afraid of.

not RFC4941... think abt applying Heddy Lamars 
patents on spread-spectrum to source address selection.

--bill

Re: Rate of growth on IPv6 not fast enough?

[Mohacsi Janos]

On Thu, 22 Apr 2010, William Herrin wrote:


On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong  wrote:

On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote:

William Herrin wrote:

Not to take issue with either statement in particular, but I think there
needs to be some consideration of what "fail" means.


Fail means that an inexperienced admin drops a router in place of the
firewall to work around a priority problem while the senior engineer
is on vacation. With NAT protecting unroutable addresses, that failure
mode fails closed.


In addition to fail-closed NAT also means:

 * search engines and and connectivity providers cannot (easily)
 differentiate and/or monitor your internal hosts, and


Right, because nobody has figured out Javascript and Cookies.


Having worked for comScore, I can tell you that having a fixed address
in the lower 64 bits would make their jobs oh so much easier. Cookies
and javascript are of very limited utility.

On the other hand, I could swear I've seen a draft where the PC picks
up random unused addresses in the lower 64 for each new outbound
connection for anonymity purposes. Even if there is no such draft, it
wouldn't exactly be hard to implement. It won't take NAT to anonymize
the PCs on a LAN with IPv6.



See RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration 
in IPv6.


Regards,
Janos Mohacsi

Re: Looking for an Admin at the IANA...

[bmanning]

i...@iana.org  or...  310.823.9358


On Thu, Apr 22, 2010 at 05:54:03AM -0700, todd glassey wrote:
> I am looking for a technical contact inside the IANA regarding their
> internal network if anyone knows one.
> 
> Todd Glassey

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/22/2010 05:34, Simon Perreault wrote:
> On 2010-04-22 07:18, William Herrin wrote:
>> On the other hand, I could swear I've seen a draft where the PC
>> picks up random unused addresses in the lower 64 for each new
>> outbound connection for anonymity purposes.
>
> That's probably RFC 4941. It's available in pretty much all
> operating systems. I don't think there's any IPR issue to be afraid
> of.
>
> Simon
I think this is different.  They're talking about using a new IPv6 for
each connection.  RFC4941 just changes it over time IIRC.  IMHO that's
still pretty good privacy, at least on par with a NATed IPv4 from the
outside perspective, especially if you rotated through temporary IPv6s
fairly frequently.

Of course, for browsers, as someone else mentioned, it's somewhat moot
because of cookies.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvQR1IACgkQ2fXFxl4S7sT0agCglqjxX9d2kYuadrreIqPo5+rN
FMAAniW1GodHwArieT/Czd96aMGQTgEF
=xYjP
-END PGP SIGNATURE-

Looking for an Admin at the IANA...

[todd glassey]

I am looking for a technical contact inside the IANA regarding their
internal network if anyone knows one.

Todd Glassey
<>

Re: Rate of growth on IPv6 not fast enough?

[Simon Perreault]

On 2010-04-22 07:18, William Herrin wrote:

On the other hand, I could swear I've seen a draft where the PC picks
up random unused addresses in the lower 64 for each new outbound
connection for anonymity purposes.


That's probably RFC 4941. It's available in pretty much all operating 
systems. I don't think there's any IPR issue to be afraid of.


Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server--> http://numb.viagenie.ca
vCard 4.0   --> http://www.vcarddav.org

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[Florian Weimer]

> a few questions.
>
> IPv6 on your radar?
> Looking at options for addressing your future v6 needs?
>
> Have you looked at the IETF/ID in the subject line?

ULA looks always interesting, but tends to end up in obscurity because
the right folks don't buy in.

Anyway, the proposal brings IPv6 down to about 40 globally routable
bits, compared to 21 to 24 in IPv4.  That's still a lot, though.

A further simplification would replace the Global ID with the AS
number.

A real improvement over IPv4 would embed distinct IDs for location and
identity of any subnet, but that would probably mean that subnets
receive less than 64 bits.

Re: Rate of growth on IPv6 not fast enough?

[bmanning]

On Thu, Apr 22, 2010 at 07:46:50AM -0400, William Herrin wrote:
> On Thu, Apr 22, 2010 at 7:30 AM,   wrote:
> >> On the other hand, I could swear I've seen a draft where the PC picks
> >> up random unused addresses in the lower 64 for each new outbound
> >> connection for anonymity purposes. Even if there is no such draft, it
> >> wouldn't exactly be hard to implement. It won't take NAT to anonymize
> >> the PCs on a LAN with IPv6.
> >
> >the idea is covered by one or more patents held by cisco.
> 
> Won't stop the worms from using it to hide which PC they're living on.
> 
no... but then you just block the /32 and your fine... :)
kind of like how people now block /8s for ranges that are 
"messy"

--bill

Re: Rate of growth on IPv6 not fast enough?

[William Herrin]

On Thu, Apr 22, 2010 at 7:30 AM,   wrote:
>> On the other hand, I could swear I've seen a draft where the PC picks
>> up random unused addresses in the lower 64 for each new outbound
>> connection for anonymity purposes. Even if there is no such draft, it
>> wouldn't exactly be hard to implement. It won't take NAT to anonymize
>> the PCs on a LAN with IPv6.
>
>        the idea is covered by one or more patents held by cisco.

Won't stop the worms from using it to hide which PC they're living on.

-Bill



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

Re: Rate of growth on IPv6 not fast enough?

[bmanning]

> 
> On the other hand, I could swear I've seen a draft where the PC picks
> up random unused addresses in the lower 64 for each new outbound
> connection for anonymity purposes. Even if there is no such draft, it
> wouldn't exactly be hard to implement. It won't take NAT to anonymize
> the PCs on a LAN with IPv6.

the idea is covered by one or more patents held by cisco.

--bill

> Regards,
> Bill Herrin

Re: Mail Submission Protocol

[Raoul Bhatia [IPAX]]

On 22.04.2010 13:07, Tony Finch wrote:

Er, no. TLS-on-connect aka smtps (as opposed to STARTTLS) is only used
to support Microsoft MUAs that are more than a couple of years old. They
only supported STARTTLS on port 25 and insisted on using the deprecated
TLS-on-connect mode on all other ports. This meant they could not
support standard Message Submission on port 587. Therefore you should
treat smtps (TLS-on-connect on port 465) as the special Microsoft
version of RFC 4409 message submission. That is, treat the protocols
exactly the same wrt authentication, authorization, firewalls, address
validation, etc.


i recently had the problem that an lotus notes server insisted on
sending emails to one of our clients via port 465. so having mandatory
authentication there actually broke delivery for an exchange sender.


X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
X-MIMETrack: Serialize by Router on smtp2/x(Release 6.5.4|March 27, 2005) 
.


cheers,
raoul

Re: Rate of growth on IPv6 not fast enough?

[William Herrin]

On Wed, Apr 21, 2010 at 11:31 PM, Owen DeLong  wrote:
> On Apr 21, 2010, at 3:26 PM, Roger Marquis wrote:
>> William Herrin wrote:
 Not to take issue with either statement in particular, but I think there
 needs to be some consideration of what "fail" means.
>>>
>>> Fail means that an inexperienced admin drops a router in place of the
>>> firewall to work around a priority problem while the senior engineer
>>> is on vacation. With NAT protecting unroutable addresses, that failure
>>> mode fails closed.
>>
>> In addition to fail-closed NAT also means:
>>
>>  * search engines and and connectivity providers cannot (easily)
>>  differentiate and/or monitor your internal hosts, and
>>
> Right, because nobody has figured out Javascript and Cookies.

Having worked for comScore, I can tell you that having a fixed address
in the lower 64 bits would make their jobs oh so much easier. Cookies
and javascript are of very limited utility.

On the other hand, I could swear I've seen a draft where the PC picks
up random unused addresses in the lower 64 for each new outbound
connection for anonymity purposes. Even if there is no such draft, it
wouldn't exactly be hard to implement. It won't take NAT to anonymize
the PCs on a LAN with IPv6.


>>  * multiple routes do not have to be announced or otherwise accommodated
>>  by internal re-addressing.
>
> I fail to see how NAT even affects this in a properly structured network.

That's your failure, not Roger's. As delivered, IPv6 is capable of
dynamically assigning addresses from multiple subnets to a PC, but
that's where the support for multiple-PA multihoming stops. PCs don't
do so well at using more than one of those addresses at a time for
outbound connections. As a number of vendors have done with IPv4, an
IPv6 NAT box at the network border can spread outbound connections
between multiply addressed upstream links.


On Thu, Apr 22, 2010 at 2:10 AM, Franck Martin  wrote:
> http://www.ipinc.net/IPv4.GIF
> The energy that people are willing to spend to fix it (NAT, LSN),
> rather than bite the bullet is amazing.

A friend of mine drives a 1976 Cadillac El Dorado. I asked him why
once. He explained that even at 8 miles to the gallon and even after
having to find 1970's parts for it, he can't get anything close to as
luxurious a car from the more modern offerings at anything close to
the comparatively small amount of money he spends.

The thing has plush leather seats that feel like sinking in to a comfy
couch and an engine with more horsepower than my mustang gt. It isn't
hard to see his point.

Regards,
Bill Herrin

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

Re: Mail Submission Protocol

[Tony Finch]

On 22 Apr 2010, at 00:07, Franck Martin  wrote:

Consider also smtps port which should be treated like smtp port and  
not like submission port, or simply do not listen on smtps as TLS is  
available on smtp port via esmtp.


Er, no. TLS-on-connect aka smtps (as opposed to STARTTLS) is only used  
to support Microsoft MUAs that are more than a couple of years old.  
They only supported STARTTLS on port 25 and insisted on using the  
deprecated TLS-on-connect mode on all other ports. This meant they  
could not support standard Message Submission on port 587. Therefore  
you should treat smtps (TLS-on-connect on port 465) as the special  
Microsoft version of RFC 4409 message submission. That is, treat the  
protocols exactly the same wrt authentication, authorization,  
firewalls, address validation, etc.


Tony.
--
f.anthony.n.finchhttp://dotat.at/