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

["Mukom Akong T." <[e-mail]>]

When you read the entire draft, it makes sense and I'd go with the spirit.
And I agree with Fred that the problem statement needs to be more succinct.


Question to Authors:  For addresses that belong to the same interface, is
there a requirement for them to belong to different prefixes?

If not, then for any address gotten from DHCPv6 IA_NA, perhaps a SLAAC
address (or many) can be generated from that prefix. You’d already get
similar behaviour if you used DHCPv6 and configured an IP address from the
same DHCPv6 scope (but in exclude list) statically on the interface towards
the hosts (assuming the default behaviour of some platforms to send our
PIOs in RAs for any addresses manually configured on them).

On 15 July 2015 at 16:07, Alexandru Petrescu <[e-mail]>
wrote:

>
>
> 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
>>
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 

Mukom Akong T.

http://about.me/perfexcellence |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------