Re: [v6ops] RFC7934

[Ted Lemon <[e-mail]>]

What would you state as the reason for giving a host all of these?

On Jul 19, 2017 9:20 AM, "Alexandre Petrescu" <[e-mail]>
wrote:

> Maybe a better recommendation, in no particular order, is to give a Host
> DHCP-PD, many-DHCP-Address, and RA with A bit.  Again, in no particular
> order and potentially all at the same time.
>
> Le 18/07/2017 à 23:01, Ted Lemon a écrit :
>
>> If a host gets a /64, it can allocate addresses out of it.   If the
>> prefix allows autoconfiguration, it can allocate its own addresses
>> using SLAAC.
>>
>
> Alex
>
>
>> On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu <
>> [e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>
>>
>> Le 18/07/2017 à 21:28, Ted Lemon a écrit :
>>
>> Alexandre, it's a really important recommendation of the document
>> that the host be allowed to allocate /its own/ addresses,
>>
>>
>> I dont understand how a host can allocate its own addresses.  Or do
>> you mean IID?
>>
>> (we are very far from Host deciding an address, suggesting it to the
>> network, and the network update the routes - but I think you dont
>> mean that either.)
>>
>> Alex
>>
>> 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] <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[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] <mailto:[e-mail]> <mailto:[e-mail]
>> <mailto:[e-mail]>> https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops> <
>> https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops>>
>>
>>
>>
>>