Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

[Alexandru Petrescu <[e-mail]>]

Le 26/07/2015 03:21, George, Wes a écrit :
>
>
> On 7/15/15, 11:07 AM, "v6ops on behalf of Alexandru Petrescu"
> <[e-mail] on behalf of [e-mail]>
> wrote:
>
>> One problem I see is when operators deliver a single global /64
>> prefix, and that /64 is understood as a single IPv6 global
>> address.
>>
>> Forming multiple IPv6 addresses out of a single /64 is possible
>> for multiple apps running on that device, so that may not be a
>> problem. There may be some privacy concerns though, in that an
>> attacker can identify there is a single device there (the /64 is
>> unique).
>
> WG] that is not a privacy consideration that is unique to this
> document, and as such I recommend that we stay away from it, as it
> just distracts from the main point by essentially asking for rolling
> /64 assignments or multiple /64s. We need to keep the scope of this
> document fairly tight.
>
>>
>> But 'sharing' these IPv6 addresses with some other devices
>> (64share) has more serious drawbacks, typically in the number of
>> subnets - only one subnet is possible.
>
> WG] I fully expect implementations of the type that this draft
> discusses to get by with bridging if they need to share a /64 such as
> for mobile device tethering. If they truly need multiple subnets,
> there is no way to get around supporting DHCP_PD with some sane
> configuration around sending and accepting hints for larger prefixes,
> because that doesn't work for SLACC either. That probably needs to be
> another document, with those specific use cases documented, because
> "always support multiple subnets" is a more significant request than
> "always support multiple addresses"

Makes sense to me.  This document should either say "always support
multiple addresses and always support multiple prefixes" or may we write
another document for the prefixes requirement part.

Alex

>
>
> Thanks,
>
> Wes
>
>
> Anything below this line has been added by my company’s mail server,
> I have no control over it. -----------
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>