Re: about draft-arkko-multi6dt-failure-detection-00.txt
Francis Dupont <[email protected]> Thu, 28 Oct 2004 19:09:04 +0200
| Newsgroups | gmane.ietf.multi6 |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected]