Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

[Mark Smith <[e-mail]>]

On Mon, 9 Dec 2019, 17:03 Lorenzo Colitti, <lorenzo=
[e-mail]> wrote:

> On Mon, Dec 9, 2019 at 9:54 AM Jen Linkova <[e-mail]> wrote:
>
>> I'm fine with it. I'll remove the reference to a dedicated address to
>> return.
>> So just to summarise the discussion: we have a number of options on the
>> table:
>> a) let server just return *an* address from the pool, assuming that as
>> the host would not accept the offer anyway, the address will be made
>> available again soon;
>>    pros:
>>       --- no changes on the server side;
>>       --- it would look normal to smart middle boxes
>>    cons:
>>       --- might lead to higher pool utilisation
>> b) return some bogus address (0.0.0.0 or smth else)
>>     pros:
>>        --- client would not be able to assign it (hmm..theoretically)
>>       --- optimized pool usage
>>    cons:
>>       --- requires changes on the server
>>       --- might trigger unexpected behaviour on smart middle boxes
>> (==> slowing down the adoption)
>>
>> c) do not offer anything, do smth esle instead (what exactly?)
>>
>> After writing it down like that I do agree that we shall probably choose
>> a) ;)
>>
>
> I would change b) "return 0.0.0.0" and add:
>


A possible idea related to this:

- issue a unique IPv4 link local addresses i.e. from within 169.254.0.0/16

- specify a subnet mask for the address of 255.255.255.255

- don't provide a default router


It is legitimate to reuse 169.254.0.0/16 on many different links.

A subnet mask of 255.255.255.255 says to the host that all destinations are
reachable via the default router, and that there are no reachable
destinations directly on the link.

However, as there is no default router to forward to, the host itself would
generate a destination unreachable message and give it to the sending
application.

(A multi-homed host is likely to have a default route out one of its other
interfaces. Source address selection should choose that other interface's
IPv4 address rather than the 169.254.0.0/16 address. The 169.254.0.0/16
interface wouldn't be used.)


Regards,
Mark.







> d) configure a specific address from the pool for all IPv6-only-capable
> clients
>     pros:
>        --- most efficiently preserves IPv4 addresses. Always works even if
> all clients ask for an address at the same time.
>    cons:
>       --- requires changes on the server
>       --- client cannot actually get the address, so if it sends a
> request, things won't go well.
>
> In that sense I think b) is a non-starter, and I don't think c) is
> feasible either: we do need to return something to the client, otherwise it
> can't know that IPv6-only will work, and I don't think there's anything
> other than OFFER that the server respond with (I don't think NAK is
> typically sent in response to DISCOVER).
>
> So I think we're down to a) offer a regular address from the pool, and d)
> offer a bogus address. The draft attempts to do both right now. I wonder if
> we could leave d) in the text, but make it clear that it's just a possible
> optimization?
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>