Re: [v6ops] RFC7934

[Alexandre Petrescu <[e-mail]>]

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