WIth my P2PSIP individual contributor hat on ....
Interesting question and we should go and check the details on this. I
have no idea where you are getting the idea that the "bootstrap
service is defined as a SIP registrar and proxy" - the RELOAD
bootstrap does not have anything to do with SIP.
The design of RELOAD was such that it would work fine in v4, or v6, or
dual stack, or various nat 4 or 6 related situations. It uses ICE to
set up most the connections and ICE is pretty good at taking a bunch
of addresses and seeing if they work. The bootstrap does not use SIP
registrar so we should dig down on that and make sure there is no
confusion - I apologize in advance for confusing text around this. My
guess is that RELOAD would have no problems with NAT66 or NAT64 but we
should carefully go and check this works.
Cullen <with my individual contributor hat on>
On Mar 23, 2009, at 18:47 , james woodyatt wrote:
On Mar 23, 2009, at 14:26, Fred Baker wrote:
On Mar 23, 2009, at 2:05 PM, Keith Moore wrote:
B thinks its traffic arrived at a ULA, but B presumably can't use
that
ULA as a referral address as it won't work everywhere,
http://tools.ietf.org/html/draft-wing-behave-nat64-referrals
"Referrals Across a NAT64", Dan Wing, 4-Mar-09,
<draft-wing-behave-nat64-referrals-00.txt>
An interesting thing about this document: it doesn't discuss
P2PSIP. I went looking to see how P2PSIP would be affected by
NAT66, and the answer seems to me that P2PSIP uses TURN for doing
NAT traversal (see the highly amusing <http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6
>), but its bootstrap service is defined as a SIP registrar and
proxy, which depends on DNS64 to achieve the referral transparency
described in the draft Fred mentions.
I've a feeling that NAT66 complicates the bootstrap process for
P2PSIP overlays, but I'm not sure how. I don't think I see how
P2PSIP bootstrap servers can be deployed behind NAT66 without
tightly coupled coordination with the NAT, and I wonder about Fred's
ideas about hairpin denial in that case...
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
