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

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

Derogatory: not really :)  It's more of a sense that I get (in general) that because the problem is hard, it should be avoided.  Maybe I've become overly sensitive to this after working on the problem for so long.

As for your suggestion, I can't see a vendor being happy about having to run a LIS.  If the only benefit is that they can see a public IP, I'd suggest that we have better tools for that.  The only change I see coming from this is that vendors will stop providing option 15.

Cheers,
Martin

> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]]
> Sent: Friday, 12 December 2008 10:03 AM
> To: Thomson, Martin
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Geopriv] Proposal for LIS discovery (DNS)
> 
> Martin,
> 
> I'm sorry if that sounded derogatory; it certainly wasn't meant to be.
> I definitely agree that it's an important use case to support -- my DSL
> modem/gateway is as dumb as all the rest (and it's on a network that
> Barbara has nothing to do with (AFAIK)).
> 
> I guess part of what I'm saying here is that in this use case, using
> option 15 gives you something of a bootstrap to get to the right place:
> It gives clients a first point of contact that might know something
> about what's going on.
> 
> For example: My home gateway gives out a subdomain of its
> manufacturer's
> domain in option 15, which means that the manufacturer would be the one
> getting my LIS discovery queries.  To answer those queries, the vendor
> still needs to figure out which LIS is responsible for my IP address,
> but he's probably in a much better position to do that than I am (e.g.,
> he probably already sees my public IP address).
> 
> --Richard
> 
> 
> 
> 
> 
> 
> Thomson, Martin wrote:
> > 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]

------------------------------------------------------------------------------------------------
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