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

[Erik Kline <[e-mail]>]

Some of this could also serve as input to motivate a SAVI document
defining a basic logging protocol.

I still believe that if there where a trivially deployable logging
methodology that captured

    {IP address, timestamp, rfc7039#section-3.2 binding context}

tuples, or even the full data structure entry described in
rfc6620#section-3.1, then the auditing objectives could be well and
truly met.

I think this is still one large unmet need.  (not necessarily a v6ops
matter, perhaps)

On 7 July 2015 at 09:02, Fred Baker (fred) <[e-mail]> wrote:
> 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?".
>
>> 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
>