Hi,
The following paragraph was added following my comments to the previous version:
Both IKEv2 peers SHOULD indicate support for the re-direct mechanism
if they support it and are willing to process REDIRECT notification
messages. This is done by including the REDIRECT_SUPPORTED payloa
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Re-direct Mechanism for IKEv2
Author(s) : V. Devarapalli, K. Weniger
Hi,
On Thu, Feb 5, 2009 at 1:04 AM, Yaron Sheffer wrote:
> Also, REDIRECT_SUPPORTED needs to be sent by both peers if we want to enable
> this case. Otherwise, when the initiator wants to redirect its peer, it
> cannot know that the responder actually supports this capability.
Agreed.
Vijay
Hi,
I have posted the interim meeting minutes (with Tero's corrections) on the
wiki: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090203Minutes
Thanks,
Yaron
Email secured by Check Point
___
IPsec mailing list
IPsec@ietf.org
Grewal, Ken writes:
> [Ken] This may be feasible for stateful devices, but does not work
> for stateless devices (QOS/Statistics/auditing functions). Even in
> stateful devices, it requires coupling between observation on flows
> and the associated heuristics cache engine, which creates an
> additi
Hi,
Maybe, an alternative solution could be Mumble
(http://mumble.sourceforge.net/Main_Page) which I use generally now
(from my point of view, the sound on Mumble is clearer than on TS).
BTW, it seems that it is possible to use Mumble with TCP (cf. FAQ).
Hope that helps.
Best regards.
JMC.
200
