Re: [Geopriv] Proposal for LIS discovery (DNS)

[Richard Barnes <[e-mail]>]

Ray,

I'm willing to grant that the local gateway shouldn't pass through 
option 15.  My mistake.

However, I still don't understand why it doesn't make sense for a host 
to use option 12 or option 15 to look for a LIS.  Those domains are 
supposed to label the host (12) or local network (15), so wouldn't it 
make sense to use a query for those names to ask for information on 
those entities?

Perhaps there's a disconnect here because the local network (in the 
sense of the entity that's providing DHC) isn't always the network that 
can sensibly provide a LIS.  We've talked about this being the case when 
the layer-3 provider needs to talk (LIS-to-LIS) with a layer-2 provider. 
  But it can also happen when the local network delegates positioning to 
an upstream provider, as when a home LAN (with its own DHCP) relies on a 
broadband provider for positioning.

Even in these cases, I think it still makes sense for a host to use the 
name of the local network to discover the local (possibly delegated) 
LIS.  It is, however, the responsibility of the local network to enable 
this delegation by redirecting clients appropriately.

There are several ways to effect this delegation, many of which don't 
meet Barbara's "unmodified gateway/CPE" requirement.  One option that 
seems appealing for me is for the gateway to do LIS discovery upstream, 
and use the result to act to answer NAPTR queries for its own domain 
(acting as a DNS proxy).  It's harder when the gateway is completely 
oblivious, especially given that lots of gateway manufacturers set all 
their devices to return the same value in option 15.  In this case, the 
responsibility for delegation is on the gateway vendor to answer NAPTR 
queries to the appropriate domain(s), but they could still use those 
answers to delegate to the appropriate upstream networks (and here those 
NAPTR records in in-addr.arpa might actually be helpful!).

--Richard



[e-mail] wrote:
>> I didn't mean to say "if you use Option 15, then you MUST provision 
>> NAPTR records".  The MUSTs only apply if the access network wants to 
>> enable DNS-based discovery (and maybe they're SHOULDs).
> 
> That's sort of the point.  There is _no_ guaranteed linkage between the 
> access network and the domain names used by the end-user within the LAN. 
> DNS based discovery based on the RDATA of a PTR record could never work 
> reliably.
> 
> Putting NAPTR records directly into in-addr.arpa (looked up based on a 
> STUN/UPnP discovered WAN address) might work better, although there'd 
> still be issues where the customer has a routed CIDR block and the ISP has 
> delegated some part of in-addr.arpa directly to the end-user.
>  
>> Were you thinking about a network that supports DNS-based discovery, but 
> 
>> doesn't use DHCP to distribute the domain name to clients? (I imagine 
>> this is one way you could hack around the "belkin" issue below.)  You're 
> 
>> right that argues for the MUSTs to be SHOULDs (at least the first one).
>>
>> But even in that case, the network operator should be aware that clients 
> 
>> on their network that don't have the static domain configured are still 
>> going to try the domain they get from option 15 first.
> 
> I strongly believe option 15 should not be used.
> 
> 1.  It's an abuse of the option
> 2.  It relies on the incorrect assumption above
> 
>> One other thing that would be helpful to add (maybe in S6) is some 
>> guidance for middle-box makers on how to do better than this.  If the 
>> gateway is provisioned over PPP, maybe you can't do much better, but if 
>> the gateway is getting option 15 on its upstream/public face, then it 
>> MUST pass it through to option 15 on the downstream/private face.
> 
> I've already written a draft about middle-box behaviour 
> (draft-bellis-dnsext-dnsproxy-00) which will be available as 
> draft-ietf-dnsext-proxy-00 any day now.
> 
> Middle boxes absolutely must NOT copy option 15 from WAN DHCP into LAN 
> DHCP.  Option 15 is intended for site-network configuration, not access 
> provider configuration.
> 
> Ray
> 
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv