Re: [dhcwg] whether/how to support Confirm with sedhcpv6

Hi:

Good point ... I was thinking that encrypted Confirm (or Rebind) would be fine - if still on same link (or at least server) it would work just fine. Otherwise, client times out and is left to use other mechanisms (RS/RA)?

But using Information-Request is interesting. Wonder if doing both or falling back to Information-Request after short period (note that if client determined it needed new leases, it would do Information-Request anyway).

We can add to discussion at Thursday DHC WG meeting as we hoped to get some issues regarding draft that could use discussion.

- Bernie (from iPhone)

> On Mar 26, 2017, at 9:32 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:
> 
> While reviewing ietf-dhc-sedhcpv6-21, I've realized one thing that
> probably requires a discussion: whether/how to use sedhcpv6 for
> Confirm.  To avoid distraction I'm raising it separately from the full
> review I'm planning to submit later.
> 
> When a client might want to send a Confirm, it should be reasonably
> possible that the client has moved and would be talking to a different
> server.  In that case it doesn't make sense to encrypt the Confirm
> message and encapsulate it in an Encryption-query message; the actual
> server would silently discard it, and the client can't tell whether
> it's because it has moved or the message is simply lost.  So I think
> we need some special case handling here.  A couple of choices I can
> think of are:
> - say sedhcpv6 can't support Confirm (I don't like this option)
> - have the client perform a separate information-request/reply
>  exchange to see if the currently recognized server and its public
>  key are still usable (if not, the client should basically not send
>  the Confirm, following the sense of RFC7844).
> 
> (There may be other options.)
> 
> --
> JINMEI, Tatuya
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg