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

From: Richard Barnes ^lt;>
Date: Thu Dec 11 2008 - 16:35:41 EST


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 might actually be helpful!).

--Richard 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 (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 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
Received on Thu, 11 Dec 2008 16:35:41 -0500

This archive was generated by hypermail 2.1.8 : Thu Dec 11 2008 - 16:36:10 EST