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

[Andrew 👽 Yourtchenko <[e-mail]>]

On 7/7/15, 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.

Lorenzo already commented on the "problem definition" so I will reply
just to this part:

Yes, we both mention them - but I'm arguing the usage of them should
be proactively monitored by the devices themselves. Preferably along
with the tangible benefits provided to the apps when the device is on
a network allowing for more than one address. (Though that is outside
of the "ops" domain).

--a

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