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
