Re: possibly related draft

I am concerned about the use of some of this inferred information from 
the link layer or transport layer to decide connectivity at the network 
layer.

Notably, failure of TCP to make forward progress - e.g., lack of ACKs - 
is not an indication of a network layer connectivity failure. It can be 
a deliberate decision of the TCP implementation to limit processing 
associated with a connection, or can represent a security firewall being 
enabled.

Similarly, we've had related dicussions in TCPM regarding the use of 
ICMP unreachable messages to tickle more rapid attempts to use alternate 
addresses, e.g., for v4/v6 selection. Unfortunately, these messages, as 
noted, are not secure, and so relying on them presents a DOS 
opportunity; it is not clear that there is a significant benefit in 
'believing' these messages that is not undermined by this lack of security.

Although it may be useful to consider direct evidence of connectivity, 
e.g., linkup/linkdown interface notification via an API, it is not clear 
yet that there is a protocol-related variant that can be appropriately 
applied, IMO.

Joe

Jari Arkko wrote:
> 
> Hi,
> 
> Francis' e-mail reminded me that I may need to point
> also other folks to a possibly related draft.
> 
> One of the issues that we have been discussing is the
> way how MOBIKE gets to know that it needs to use a new
> address from a lower layer and how it can detect whether
> a pair of addresses actually works or not.
> 
> This is not something that only we are looking at. SCTP
> has specified its own way for this and HIP and MULTI6
> protocols need solutions like that as well. As a member
> of the MULTI6 design team I wrote some thoughts on the
> matter from the point of view of MULTI6. If you take
> a look it may give you some ideas for the MOBIKE space
> too. I don't know about the solutions presented in the
> draft, but I'm hoping that the draft might be helpful
> at least in defining a few terms so that we can discuss
> this matter more precisely.
> 
> Here's the draft:
> 
>   
> http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt 
> 
> 
> --Jari
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike

_______________________________________________
Mobike mailing list
[email protected]
https://www.machshav.com/mailman/listinfo.cgi/mobike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgXJbE5f5cImnZrsRAgUkAKD9aLKEv1bbUgG3j554AGuJPwSR2ACghxYP
MLslxnDH+VYsNkEqOCVQBO4=
=qmON
-----END PGP SIGNATURE-----