Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC

[Brian E Carpenter <[e-mail]>]

On 23/09/2015 22:38, Lorenzo Colitti wrote:
> On Wed, Sep 23, 2015 at 5:45 AM, Brian E Carpenter <
> [e-mail]> wrote:
> 
>>> These networks
>>> are likely *not* concerned with per-device revenue, but they still
>> provide
>>> a limited number of addresses for other reasons (some of which may be
>>> operational, or even scaling reasons).
>>
>> And I don't think your document will succeed in its purpose unless it
>> explicitly recognises that those operational or scaling reasons may be
>> reasonable and valid. As you know, operators will do what they need to do.
>>
>> Let's see: on a campus with a few tens of thousands of students, mainly
>> connected wirelessly, will we have problems if a few hundred of them run
>> a popular new app that generates a couple of thousand addresses when
>> given a /64 to play with?
>>
> 
> It depends whether there are any stateful devices in the path, and how
> smart those stateful devices are. A university campus with no stateful
> firewall and only IPv6 will never have scaling issues if it assigns a /64
> per device. A campus that uses stateful firewalls might - but note that
> this is a problem even today, and even in IPv4 - a determined attacker can
> attempt to exhaust NAT or firewall state by opening lots of connections to
> lots of different IP addresses, for example.
> 
> Ditto if they catch a Trojan that knows how to have fun with its own /64.
>> How quickly will the whole campus be black-listed?
>>
> 
> Never, because any server that supports IPv6 today needs to survive in the
> presence of residential users with /56 prefixes and spammers / DoSers with
> servers in datacenters that get /48s from tunnel brokers. The content
> providers and CDNs started seeing and dealing with those attacks a long
> time ago.
> 
> 
>> Will the campus have severe legal problems if a couple of thousand students
>> use a new address-agile file sharing app that saturates any form of
>> audit logging, so that offending users can't be identified?
>>
> 
> Not if the campus assigns a /64 per device or per user. They can just pin
> the blame on that /64.

And my whole point: if assigning a /64 does *not* cause scaling, logging
or security problems the draft needs to explain why not, as you and Mikael
and Mark have done. Otherwise, I can pretty much guarantee that those arguments
will be used against it.

(And I forgot to mention ND cache scaling.)

    Brian