Rate of growth on IPv6 not fast enough?

Joel Jaeggli joelja at bogus.com
Sun Apr 25 00:56:17 UTC 2010



On 04/22/2010 10:18 PM, 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.

Does your  nat box reset or non-determisitically rewrite the ttl on the
outgoing packet?

ALGs are dramatically better topology hiding devices...

> Matthew Kaufman
> 




More information about the NANOG mailing list