Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS
RFC 7216

Note: This ballot was opened for revision 07 and is now closed.

(Joel Jaeggli; former steering group member) Yes

Yes (2013-12-02 for -07)
No email
send info
cleared my previous dicuss on 5 so I think I can llive with it as written

(Richard Barnes; former steering group member) Yes

Yes ( for -07)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2013-12-04 for -07)
No email
send info
Thanks for Section 6. I find it addresses the Discuss I would have entered.

(Barry Leiba; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection (2013-12-02 for -07)
No email
send info
I am balloting No-Obj based on the premise that the -07 version resolves the DISCUSS points I raised against the -05 version.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2013-12-02)
No email
send info
Peter Yee's Gen-ART review comments were addressed. Thanks!

(Martin Stiemerling; former steering group member) No Objection

No Objection (2013-12-03 for -07)
No email
send info
Jari is holding the discuss about the change of the status after the IETF LC. The doc is saying standards track but the LC announcement was is saying it is Informational. 

Do we need to re-run the IETF LC?

(Pete Resnick; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2014-01-24)
No email
send info
Discussion of my discuss I think resolved down to the point that 
a client doing this will send out a DNS query that e.g. includes
10.99.67.33. If the n/w owner (say a tin-foil hat person) wanted
that their choice within 10/8 not be well known, they might 
consider that doing that would be a (very very) slightly higher
risk. Not sure what you'd do about it, but might be worth a 
mention.

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Ted Lemon; former steering group member) (was Discuss) No Objection

No Objection (2014-01-05)
No email
send info
The document authors have updated the document to clarify the main point I was concerned about, and have further explained why they think STUN works here.   I am not in a position to argue the latter point, and am satisfied with the response on the former, so I'm clearing.   I've left both my DISCUSS and comment points below for the record, but expect no further action from the authors.

Former DISCUSS points:

(1) This specification relies on home gateways not following RFC 6303.   Some of the advice given in the spec will simply fail if RFC 6303 is implemented by the HG.   It would be better to assume RFC6303 is being followed by the DNS proxy/resolver in the HG, and write the spec so that it prefers a solution that doesn't rely on successful resolution of names in in-addr.arpa or ip6.arpa for RFC1918 address spaces.   I've suggested a way to do this in the comments, and would be happy to work with the authors to fully flesh out this solution if it seems plausible to them.   My understanding of how a LIS operates is not very good, though, so I may be assuming capabilities that a typical LIS doesn't actually have.

(2) The document assumes that a device that is implementing this discovery mechanism will be able to distinguish between a VPN and a non-VPN connection.   How this is done is not discussed.   I am skeptical that this is possible.   I would like to see the document go into this in more detail if the authors actually know how to make this happen.   A similar problem exists for non-VPN tunnels, as I have mentioned in the comments.   Unfortunately, I don't see any obvious way to distinguish between location-bound IP addresses and tunneled IP addresses.

I think the way to address point 2 is simply to recommend best practices for setting up LIS configurations in these situations.   Generally speaking providers will have control of the reverse tree for these tunnels.  It would be helpful if there were a way for the DNS response to include a record in addition to the NAPTR (or as part of the NAPTR if possible) that indicates that if an alternate LIS is available, it should be preferred.   Is it possible that this is documented elsewhere?    Or is there a way for the LIS itself to provide this advice based on the source address of the query?

(3) for the responsible AD: What's the IETF consensus status of this document?   It's set to Unknown.

Former comments:

In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887.   Given that PCP is the only protocol in this genre that has an IETF standard written to describe it, it should be mentioned for completeness, even though UPnP and NAT-PMP are more widely deployed.

It's also worth noting that at least in principle PCP supports the ability to get edge information from the PCP server that's actually at the final transition from NATted addresses to global addresses, so this doesn't have the limitations that you are ascribing to UPnP and NAT-PMP. This is worth mentioning not only because it might be helpful, but also because if the operator has populated the reverse tree for their private address space, the outer global address isn't going to refer to the customer.

Another point about global addresses versus NATted addresses at the CPE-PE edge is that protocols such as Dual-stack Light, Lightweight 4over6 and MAP will produce weird results for location determination and are only available on networks with native IPv6 capability, so LIS results obtained over IPv4 when these tunneling mechanisms are in use should be treated in a similar manner to LIS results obtained over a VPN connection.   It is _possible_ with lw4over6 and MAP (and maybe DS-Lite) to use the address+port range to specifically identify the customer endpoint, but given that it's much easier to do with IPv6, this seems pointless.   A similar issue exists for 6RD and other tunneled delivery of IPv6.

In 4.3, given that LIS discovery is a fairly infrequent operation, is there really any point in restricting the set of prefix masks at which LIS records can be placed?   It seems to me that the number of queries you'd get by starting at /64 and going one nybble at a time up the tree would be perfectly reasonable for an operation that happens infrequently. It would add latency if you are trying to locate a LIS as a prelude to making an emergency call, however.

Also, why bother looking up the IPv6 address? It seems to me that there is no chance that a LIS server is going to be configured on a per-IP-address basis, particularly since IPv6 addresses will not be allocated to end users. Are you attempting to account for the possibility that the provider might NAT the customer down to a single IPv6 address? If the purpose of this is to locate handsets on a mobile network, where the handset might well have been given a /128 by the provider, it might be worth mentioning that.

In 4.5, this whole mechanism is likely to fail for resolvers that implement RFC 6303.

In the last paragraph of 4.5, the outcome described seems bad enough to beg for mitigation.   Presumably in the scenario shown in figure 2, it's a bad outcome for the host to use STUN to get the public IP address corresponding to the outer edge of the NAT, and similarly a bad outcome for the CPE to query DNS A rather than DNS B.

The right way to solve this problem, presuming for the moment that the ISP cares about providing accurate LIS service, would be to publish a global IP address belonging to the ISP in the global DNS for the LIS corresponding to the ISP's external address pool.   This global IP address would however be configured on a host _inside the NAT_, and of course routing inside the NAT would have to reach that host without crossing the NAT, so that packets reach the LIS with the CPE's NATted IP address as the source address.   This can then be used to provide accurate location information, because the CPE's IP address can be directly associated with the customer.

This protocol relies heavily on STUN, but STUN server address discovery is problematic, and is not discussed.   In reading up on this, I've encountered several assertions that STUN works well with existing home gateways, but no document explaining how it works.   If your belief that STUN will address this problem is based on such documentation, a reference to it would be helpful.