Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

Hello,

Thanks for the post.

I could understand the need to spam block an entire /64 instead (a
single line in a configuration file) rathern than 2^64 lines each
telling an address in that file.

Yes, this is relevant when writing other firewalling rules as well.

In this sense it is good to have an 'overall' number - like a /64 - to
designate one particular link and subnet.

And one may like to use other such overall numbers such as a /65 or a
/63 to designate these links.

And yes, the privacy extensions RFC4941 makes that attacker may use that
overall number /64 to generate addresses, and defender may need to use
same number /64 to comfortably protect against it.  A smarter attacker
would use a /63 and a smarter defender too.

Alex

Le 09/01/2014 18:51, Emmanuel Thierry a écrit :
> Hello,
>
> (first message on these lists, hope it is accurate)
>
> I'm generally thinking that the /64 limit helps to structure the
> address space from the receiver point of view. Let's say i'm running
> a mail server which tries to reduce spam by temporarily blacklisting
> some senders. if i'm facing spammers who use their IPv6 address
> space in a smart way, they will just have to generate RFC 4941
> addresses to exhaust a firewall memory. The pragmatic way to face
> such attacks is to blacklist the whole /64, never a unique /128.
>
> I don't know if it is to be considered as a best practice, but for
> these reasons, as a receiver, i personally consider a /64 to be
> assigned to a unique link, or at least a network managed by a unique
> network administrator. Enforcing this limit in protocol standards
> strengthen this assumption. This might be an additional argument for
> the "please keep /64 for unique links".
>
> As a consequence, subdivide a /64 into several prefixes in order to
> assign it on several networks might create a risk for devices on one
> network to be blacklisted by actions performed by some devices on
> another network, in case the whole /64 have been blacklist by a
> "pragmatic" receiver.
>
> Best regards Emmanuel Thierry
>
> Le 5 janv. 2014 à 23:07, Brian E Carpenter a écrit :
>
>> Hi,
>>
>> A group of us put this together following a discussion some weeks
>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses.
>>  Discussion belongs in 6man, please.
>>
>> This draft is incomplete but we'd welcome input. Let me underline
>> an important comment in the introduction:
>>
>> _The purpose of this document is to analyse the issues around this
>>  question.  We make no proposal for change, but we do analyse the
>> possible effects of a change._
>>
>>
>> Brian + co-authors
>>
>> -------- Original Message -------- Subject: I-D Action:
>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17
>> -0800 From: internet-drafts@ietf.org Reply-To:
>> internet-drafts@ietf.org To: i-d-announce@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title           : Analysis of the 64-bit Boundary in IPv6
>> Addressing Authors         : Brian Carpenter Tim Chown Fernando
>> Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename :
>> draft-carpenter-6man-why64-00.txt Pages           : 14 Date :
>> 2014-01-05
>>
>> Abstract: The IPv6 unicast addressing format includes a separation
>> between the prefix used to route packets to a subnet and the
>> interface identifier used to specify a given interface connected
>> to that subnet. Historically the interface identifier has been
>> defined as 64 bits long, leaving 64 bits for the prefix.  This
>> document discusses the reasons for this fixed boundary and the
>> issues involved in treating it as a variable boundary.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-carpenter-6man-why64-00
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>>
>>
>>
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>