On Mar 24, 2009, at 14:10, Cullen Jennings wrote:
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.
I probably failed to grasp the context of draft-matthews-p2psip-
bootstrap-mechanisms, section 2.2 Bootstrap Server Mechanism: "A
P2PSIP Bootstrap Server is a SIP registrar and proxy, typically
located in the public Internet, that acts as an intermediary to
introduce the joining peer to a bootstrap peer..."
I also probably failed to remember that the thing I was thinking about
is called the enrollment server, not the bootstrap service. The
enrollment service is probably implemented with an HTTPS server in
most cases, and the XML document that it returns for requests to
enroll includes a list of bootstrap peers by their IP address. It's
*those* IP address that I'm concerned with, as they are address
referrals.
How does the enrollment client and the enrollment server negotiate for
address realm differences? I suspect I know how this is done for
IPv4, i.e. it isn't; the enrollment server and the bootstrap peers are
all assumed to have addresses in the same address realm, usually the
public realm, for the purpose of the overlay. Therefore, if the
enrollment server is reachable from more than one realm through
translators, then the bootstrap peers in the enrollment response must
all have the same addresses in every realm or the overlay doesn't
work. This isn't an IPv6-specific thing.
The complication NAT66 presents for P2PSIP is that we don't even have
the moral equivalent of RFC 1918 space for IPv6. We don't have any
helpful hint, looking at any particular global-scope IP address,
whether it's in the same address realm as us or not. At least, with
IPv4, when you see RFC 1918 addresses, then you know they're not the
public address realm, and that can sometimes help, i.e. an enrollment
server that knows it's running in the public address realm can make
sure it never designates a bootstrap peer with an RFC 1918 address.
The IPv6 case isn't as simple.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
