I have to commend the approach you are using. I always hoped that this is how discovery would be implemented.
--Martin
On 2011-01-14 at 15:47:58, Richard L. Barnes wrote:
> One additional note: Our client is not technically compliant with RFC
> 5986, since it doesn't validate the URI with a HELD request:
> "
> A Device that discovers a LIS URI MUST attempt to verify that the
> LIS
> is able to provide location information. For the HELD protocol, the
> Device verifies the URI by making a location request to the LIS.
> "
>
> --Richard
>
>
> On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote:
>
> > Hey all,
> >
> > Just wanted to share some impressions of the LIS discovery process,
> including NAT traversal, based on our experience implementing this
> function in the igtk project [1]. (Note: The techniques here haven't
> yet been merged into the sourceforge version.)
> >
> > The basic flow-chart in RFC 5986 is pretty easy to implement,
> although it wasn't really clear what to do for step (3), "Check URI",
> beyond verifying that it's a well-formed URI. In pseudo-code, we ended
> up with something like this:
> >
> > foreach (NetworkInterface iface) {
> > DomainIterator it(iface);
> > while (it.hasNext()) {
> > string lisUri = performDdds(it.next());
> > if (valid(lisUri)) { return lisUri; }
> > }
> > }
> >
> > Here the DomainIterator supplies the following domains, if they are
> available:
> > 1. Option 213 [NB: Not DHCPv6 capable]
> > 2. Option 15
> >
> > The DomainIterator construct also allows us to easily extend the
> process to support NAT traversal. If neither of the above options
> works, the DomainIterator looks at the IP address for the interface,
> and if it's private (any of the IANA reserved ranges [2]), then it does
> a STUN request to find a public address. Using either the interface
> address or the STUN address, it then provides the following domains:
> > 3. The reverse domain
> > 4. The reverse domain with the first label dropped
> > 5. The reverse domain with the first two labels dropped
> >
> > The entire LIS discovery service, which listens for network interface
> changes and emits alerts when it finds a new LIS URI, required 584
> lines of C++. A very basic STUN client was another 293.
> >
> > So in a nutshell, extending a client from RFC 5986 to draft-thomson-
> geopriv-res-gw-lis-discovery was pretty trivial, just a matter of
> adding a few domains to the search list. We hope to have the code
> posted to the igtk site soon; if you're interested in an advance copy,
> let me know and I can send you an interim snapshot.
> >
> > --Richard
> >
> >
> > [1] <http://igtk.sourceforge.net/>
> > [2] <http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
> space.xml>
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
