Re: [v6ops] RFC7934

[Ted Lemon <[e-mail]>]

Alexandre, it's a really important recommendation of the document that the
host be allowed to allocate *its own* addresses, rather than having to rely
on the correctness of the DHCP IA_NA implementation.   So the language you
are proposing would completely change that.

On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu <
[e-mail]> wrote:

> I agree that in the past there may have existed a risk of cellular
> networks assigning a single IPv6 address (w/o even a plen) to one UE.
> So one wanted a recommendation against DHCPv6 single address per End node.
>
> However, I still think this RFC is a mis-written recommendation.
>
> It would have been much simpler to RECOMMEND to allocate multiple
> addresses per End node, as many as that End node requires, be them
> individual addresses, or addresses aggregated into prefixes, or multiple
> prefixes.
>
> But the current recommendation as it stands looks weird.
>
> Le 18/07/2017 à 17:23, Jen Linkova a écrit :
>
>> I have read the draft and re-read rfc7934 and now I'm completely
>> confused. First of all, I can not see where rfc7934 says that DHCPv6 is not
>> recommended.
>>
>
> RFC7934:
>
>> In order to avoid the problems described above and preserve the
>> Internet's ability to support new applications that use more than one
>> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
>> multiple IPv6 addresses from each prefix to general-purpose hosts.
>>
>
> What makes one think that some network deployment might block the
> forming of multiple IPv6 addresses from each prefix?
>
> Or maybe the "from each prefix" is superfluous?
>
> Because I dont think there is any method that provides a prefix yet
> restricts the use to just one address in that prefix.
>
> If a Router sends an RA to many Hosts then each of these Hosts may
> configure many addresses within it.
>
> If a Router sends an RA unicast to a Host then that Host may configure
> many addresses within it.
>
> If an address is delivered by a DHCP Server, then that is an address
> without any prefix specified.
>
> If a prefix is delegated by a DHCP Server then a receiving Client may
> configure many addresses within that prefix.
>
> To support future use cases, it is NOT RECOMMENDED to impose a hard limit
>> on the size of the address pool assigned to a host.
>>
>
> What do you mean?  Is that pool a DHCP pool?  What is an example of
> someone imposing a hard limit on the size of that pool?
>
> Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6
>>  address per prefix.
>>
>
> I did not see any place where there is such a restriction.  I wonder
> what is an example where a Host was limited to only one IPv6 address
> formed out of a prefix.
>
> Due to the drawbacks imposed by requiring explicit requests for address
>> space (see Section 4), it is RECOMMENDED that the network give the host the
>> ability to use new addresses without requiring explicit requests.  This can
>> be achieved either by allowing the host
>>  to form new addresses autonomously (e.g., via SLAAC) or by providing
>>  the host with a dedicated /64 prefix.
>>
>
> This "either or" sounds like exclusive or.  But on cellular networks the
> Host is provided a dedicated prefix _and_ forms new addresses autonomously.
>
> This is confusing.
>
> Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
>> multiple addresses when the host connects (e.g., the approximately 30
>> addresses that can fit into a single packet)
>>
>
> ?  is there such a restriction in the DHCP spec?  Is it that DHCP
> Ack/Advertise could carry only 30 addresses?
>
> would accommodate current clients, but it sets a limit on the number of
>> addresses available to hosts when they attach and therefore limits
>> the development of future applications.
>>
>
> Yes, it would set a limit _if_ DHCP had such a limit.  Do you think DHCP
> has a limit in the number of addresses it could assign in an Ack or
> Advertise?
>
> The maximum number of IPv6 addresses that can be provided in a single
>> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is
>> approximately 30.
>>
>
> Do we have a packet dump showing this?  I am asking because 30 addresses
> make for 480bytes...
>
> Jen said:
>
>> I had to use all my imagination and still not sure how the phrase 'it
>> is RECOMMENDED that the network give the host the ability to use new
>> addresses without requiring explicit requests.' can be read as 'DHCPv6 is
>> not recommended'.
>>
>
> Because SLAAC does not obtain addresses by using Requests.  That's DHCP
> who uses Requests to obtain addresses.
>
> That RECOMMENDation is clearly written by someone who has some deep
> disapproval of DHCP.
>
> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot
>> use new addresses without requesting them from a DHCPv6 server
>> on the network.' does not seem to be accurate.  As this statement
>> appears to be the key point of your document, I believe it needs to
>> be fixed before we can proceed.
>>
>
> On my side, I can agree.  But that is your discussion.
>
> Alex
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>