"direct endpoint-to-endpoint connectivity may not be possible if both endpoints are NATed"
Why? There are several protocols (SIP/RTP come to mind) that manage endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't IPsec endpoints do this? If this requires some new NAT traversal mechanism, perhaps using a hub gateway in place of the SIP SBC, then this should be part of the requirements. This mechanism is needed even if only one endpoint is NATted, otherwise we're constraining who the initiator has to be. Yoav On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote: > Another issue. Please comment on Suggested Resolution. > > Thanks, > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:t...@tools.ietf.org] > Sent: Tuesday, March 20, 2012 6:58 PM > To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org > Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint > connectivity may not be possible > > #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be > possible > > In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible > if both endpoints are NATed. > > Suggested Resolution: Mention this in section 2.1. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@… | problem@… > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | Keywords: > Resolution: | > -------------------------+------------------------------------------------- > > Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1> > ipsecme <http://tools.ietf.org/ipsecme/> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > IƧ��[�(^rC�{S�֥I�.�+r�^�� _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
