Re: about draft-arkko-multi6dt-failure-detection-00.txt

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   Hi Francis and thanks for your input! A few responses
   below:
   
   >  - in 3.1 link-local IPv6 addresses, private (RFC 1918) IPv4 addresses,
   >    etc, are excluded. IMHO this is a too strong constraint: only
   >    ambiguous zone limited addresses should be excluded (note that
   >    one (only) address cannot be ambiguous).
   
   I'm open to doing this either way. I guess the issue is
   accidentally attempting to connect to someone else's
   10.0.0.1 address. I've heard that protocols in the
   multimedia space already can run into this, however,
   so this may not be a new problem.
   
=> IMHO there are three issues with zoned addresses:
 - zone IDs are local (so I can't designate a zone to a peer)
 - an unclothed zoned address is likely ambiguous (API issue)
 - is the peer zoned address in the same zone? (perhaps your concern).
I tried to solve these issues in my address management for IKEv2,
and in fact IMHO the only reasonnable scenario is to use only at most
one zoned address and from the beginning.
This is not an unlikely scenario and don't forget than the RFC 3484
rule 8 on destination addresses is "Prefer smaller scope"...

Thanks

Francis.Dupont@enst-bretagne.fr