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

[Alexandru Petrescu <[e-mail]>]

Le 07/07/2015 02:02, Fred Baker (fred) a écrit :
> Thanks. One question. Chair hat off.
>
> Section 2 identifies the current deployment model - each interface
> has a link-local address, a SLAAC address, and one or more temporary
> addresses. I haven't heard anyone complaining about that. Section 3
> goes on to discuss virtual machines/containers, which might each have
> additional addresses, and the model Facebook is reportedly using,
> which gives individual addresses to processes. It also mentions
> draft-herbert-nvo3-ila, which is not a stupid model - I still have
> some comments on it in a multi-administration environment or for
> running applications in an "inside" and an "outside" address ("NAT
> has well-known drawbacks"), but it at least gets rid of the random
> encapsulations predominant in data centers today.
>
> In other words, we already assign multiple addresses, by some means,
> to each interface in a network.
>
> You mention SLAAC. Lorenzo mentions that in section 7. He also
> mentions DHCP address and prefix allocation.
>
> The statement that I don't see in the document, which would help me
> personally, is a problem statement. I would guess that the problem
> statement is "we think some networks are limiting host interfaces to
> a single IPv6 address." I'd want a little more detail, but I'll bet
> that's the crux of it.
>
> So my question is: "precisely what problem are we solving here?".

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).

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.

(to that, one should add an explanation of why operators deliver a
single /64 to a device - accounting)

Alex



>
>> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko
>> <[e-mail]> wrote:
>>
>> I read the draft and absolutely agree with the spirit.
>>
>> Unfortunately, I think it won't work:
>>
>> As soon as the devices work "good enough" with a single address,
>> appealing to increase the amount of work by administrators in the
>> name of humanity is going to fall on deaf ears.
>>
>> The only way I see to solve this is to always use SLAAC on the
>> devices: either 'externally' from the prefix received within the
>> RA, or 'internally' from within the prefix received via DHCP-PD,
>> and provide a mandatory registration mechanism for name-to-IP
>> mapping.
>>
>> If neither of the above works, as a backup effort the device can
>> try getting N addresses via DHCP IA_NA and release those that it
>> does not need immediately - and displaying a big yellow warning
>> "This network may restrict IPv6 functionality and eat your
>> kittens, contact your system administrator". Because ND is not
>> going to happen on these 'extra' addresses, forwarding wise there
>> will be no impact, just some more DHCP traffic after attachment
>> (the "limited functionality" of course would need just one address
>> and can start immediately).
>>
>> Those who want tracking can track the upper 64bits or use IA_NA
>> and filter out the addresses that are shortly lived.
>>
>> Of course to avoid being a religious crusade such an effort need
>> to produce something pragmatic - namely, a userland cross-platform
>> API that would allow getting new addresses on demand by application
>> and if needs to - implementing custom transport protocols on top
>> of those on a per-app-per-address basis.
>>
>> The above conjecture however is even less realistic than politely
>> asking the inconveniences away, so the logical conclusion from
>> that is I fully support this draft.
>>
>> --a
>>
>>> On 06 Jul 2015, at 13:47, [e-mail] wrote:
>>>
>>> A new draft has been posted, at
>>> http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability.
>>>
>>>
>>>
>>>
Please take a look at it and comment.
>>>
>>> _______________________________________________ v6ops mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________ v6ops mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>