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

[Emmanuel Thierry <[e-mail]>]

Hello,

Le 15 janv. 2014 à 16:52, Alexandru Petrescu a écrit :

> Hello,
> 
> Just out of curiosity... below...
> 
> Le 10/01/2014 11:57, Emmanuel Thierry a écrit :
>> Hello,
>> 
>> Thanks for your answer.
>> 
>> Le 10 janv. 2014 à 09:53, Alexandru Petrescu a écrit :
>> 
>>> 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.
>> 
>> Definitely. However, as an attacker, having a smaller prefix than a
>> IPv6 /64 to exploit for your attack could correspond in IPv4 to use
>> a smaller prefix than /32. I mean that as a defender, i would use
>> against an attacker who smartly uses its /63 or smaller, the same
>> techniques than an attacker who have access to an IPv4 /31 or
>> smaller: blacklist sequentially all IPv6 /64 that this attacker is
>> using. So anyway, a /64 boundary would at least help to leverage the
>> problem.
>> 
>> This could also be a good hint to network operators or hosters. Some
>> virtual machine providers (for instance) divide their /64 into
>> smaller prefixes (i saw /96),
> 
> When a virtual machine uses a /96 instead of a /64, is that prefix
> present in an RA?

About the hoster i think about, i didn't subscribe to their service (i let you guess why ! ;)).
However, their docs mention two major points:
* How to calculate the IPv6:  2001:db8:1:XXX:XXX:XXX:XXX:YYYY/96 where XXX:XXX:XXX:XXX is the IPv4 address (!!!) and YYYY is a number between 0000 and FFFF
* How to configure the IPv6: (...) in /etc/sysconfig/network add "IPV6_AUTOCONF=no" (...)

So there is likely no RA on their network. It is quite common on hosters networks. In France, i only knows OVH (IIRC) who sends Router Advertisements on its network. In most of cases, server configuration is performed by static manual configuration.

Best regards
Emmanuel Thierry



> And, is there some address auto-configuration involved?  (wondering
> about how is the Interface ID formed, because with Ethernet it must be
> 64bit long).
> 
> (for example, in some non-Ethernet links - like IP/USB, or some
> IP/cellular - there are some particular non-documented mechanisms to
> form Interface IDs; but these are still 64bit length, never 22bit)
> 
> Alex
> 
> 
> which may imply that a bad behavior
>> from one of their clients might influence other servers. I think
>> there should be a clear mention of the consequences it may have.
>> Such a mention may help to promote best practices (TODO: define best
>> practices).
>> 
>> Best regards Emmanuel Thierry
>> 
>> 
>>> 
>>> 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: [e-mail] Reply-To:
>>>>> [e-mail] To: [e-mail]
>>>>> 
>>>>> 
>>>>> 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
>>>>> [e-mail] Administrative Requests:
>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>> 
>>>>> 
>>>>> 
>>>> 
>>>>> 
>>>>> 
> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list [e-mail] Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> 
> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list [e-mail] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>>> 
>>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
>> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------