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

["Thomson, Martin" <[e-mail]>]

Hi Richard,

I know this is probably less motivated than I'm going to imply, but I have to pick on you for this:

> Barbara's "unmodified gateway/CPE" requirement.

If we persist on labelling the use case as belonging to Barbara, then we are purposefully disregarding its seriousness.  I understand how this is requirement poses a very difficult problem, but all this does is give the impression that you are reluctant to solve the problem.

Barbara just happens to be the one who raised the problem.  We could pretend that this is limited to the few that access the Internet through her employer's network, but that doesn't work.  

I personally have such a device.  I can't see a manufacturer adding features to a device that they no longer sell.  And I've got better things to do with my money than replacing working equipment.

I'm of the opinion that we can't rely on option 15 to solve the hard problem.  If you could rely on option 15, it would be reasonable to say that the LIS URI option could work.  If we are talking about modified routers, this is the "right" way to solve the problem.

Cheers,
Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Richard Barnes
> Sent: Friday, 12 December 2008 8:36 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [Geopriv] Proposal for LIS discovery (DNS)
> 
> 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

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv