Re: [Geopriv] What to do about DHCP and the ever changing PIDF aswell as HELD features

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Thu Jul 17 2008 - 19:06:59 EDT

Hi Marc,

The use case and deployment scenario is articulated below.

Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Thu 7/17/2008 4:31 PM
To: Winterbottom, James
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] What to do about DHCP and the ever changing PIDF aswell as HELD features
 
James,

You obviously have a deployment model in your mind that you are not sharing.
It would be helpful if you articled such when you make statements about what
a particular protocol will/won't support. Please explain what you are
trying to accomplish.

-Marc-

On 7/17/08 5:19 PM, "Winterbottom, James" <James.Winterbottom@andrew.com>
wrote:

> Marc,
>
> So your ISP knows about ever single host inside your NAT at home does it?
> I am most surprised.
>
> Cheers
> James
>
>
>
> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Thu 7/17/2008 7:56 AM
> To: Winterbottom, James
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] What to do about DHCP and the ever changing PIDF aswell
> as HELD features
>
> James,
>
> First, I understand the big picture, but my understanding is not anchored in
> a product solution.
>
> Second, you made assertions about DHCP that are false. I am correcting
> those assertions.
>
> Fact: The DHCP protocol set has the ability to uniquely identify all hosts
> requesting configuration options (yes, civic, geo, and uri options) without
> regard to the location of the DHCP server.
>
> If you, James W., stop and think for a minute, if this weren't true, how
> would a DHCP server assign a unique and correct IP address to each host?
>
> In addition, DHCP delivers the level of privacy and security on all
> requests/offers that is agreed to by the working group to meet the guiding
> principles.
>
> -Marc-
>
>
> On 7/16/08 7:54 PM, "Winterbottom, James" <James.Winterbottom@andrew.com>
> wrote:
>
>> Hi Marc,
>>
>>
>>
>> You comments below actually highlight several things.
>>
>> Firstly that the DHCP location URI solution isn't a total solution, it
>>
>> is a fragment that does not include the larger picture, and secondly I
>>
>> suspect that you don't really see what the larger picture is.
>>
>>
>>
>> In order for a reference to be useful, it needs to reference something.
>>
>> More importantly, when something asks for a reference, that reference
>>
>> should only be applicable to the thing actually asking for it.
>>
>> Consequently regardless of whether two people are in the same house,
>>
>> with an internal network, behind a NAT that is connected to the same
>>
>> ISP, I expect each host to ask for, and be given independent URIs. I can
>>
>> do this with HELD, I don't see how I can do this with DHCP unless I
>>
>> modify the home-router somehow.
>>
>>
>>
>> This is a real deployment use case, and it requires a real deployment
>>
>> solution.
>>
>>
>>
>> The second case is the VPN use-case, that I believe you largely bring up
>>
>> time and time again. My modem establishes, unbeknownst to me, a VPN to
>>
>> my enterprise in Chicago. I connect my host inside my home network, and
>>
>> it does all its DHCP stuff, the DHCP server I cam talking to is in
>>
>> Chicago, so any location Uri request will go to their. The DHCP solution
>>
>> being described is just as vulnerable to this setup as any application
>>
>> layer protocol. Since we were forced to discuss these issues in the HELD
>>
>> draft so to must they be discussed in the DHCP draft.
>>
>>
>>
>> I believe that the realm of applicability for a DHCP location URI is
>>
>> very restrictive, and I would like to see some of those restrictions
>>
>> included in the draft before we move it to a last call.
>>
>>
>>
>> Cheers
>>
>> James
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>
>>> From: Marc Linsner [mailto:mlinsner@cisco.com]
>>
>>> Sent: Wednesday, 16 July 2008 10:49 PM
>>
>>> To: Winterbottom, James
>>
>>> Cc: geopriv@ietf.org
>>
>>> Subject: Re: [Geopriv] What to do about DHCP and the ever changing
>>
>> PIDF
>>
>>> aswell as HELD features
>>
>>>
>>
>>> James W.,
>>
>>>
>>
>>> I'm confused about your assertions on how DHCP works behind/through a
>>
>> NAT.
>>
>>> The DHCP protocol itself is agnostic to NATs in the same way it is to
>>
>>> layer
>>
>>> 3 routers. DHCP is broadcast based, meaning the discover packet does
>>
>> not
>>
>>> transverse a layer 3 (NAT or router) element without the aid of a dhcp
>>
>>> relay
>>
>>> agent. There is nothing to prevent a dhcp relay agent from being co-
>>
>>> located
>>
>>> with a NAT, but this deployment model would seem odd as NATs are
>>
>> typically
>>
>>> utilized to 'hide' the inside network from the outside network.
>>
>> Typical
>>
>>> deployment is for a DHCP server to reside on the inside network. If,
>>
>> in
>>
>>> fact, a deployment utilized a DHCP server on the outside network for
>>
>>> configuration of hosts on the inside network (DHCP traffic crossing a
>>
>> NAT
>>
>>> device), the DHCP server could receive the same option 82 and giaddr
>>
>>> attributes which are used to uniquely identify the host/network on the
>>
>>> inside. Of course this requires dhcp relay agent(s) on the inside
>>
>> network,
>>
>>> the same as when a layer 3 router is between the host and DHCP server.
>>
>>>
>>
>>> Hence, from a protocol perspective, NATs don't add any more complexity
>>
>> to
>>
>>> the LCP DHCP model than routers. It's a simple case that NATs
>>
>> typically
>>
>>> are
>>
>>> deployed at admin boundaries such that DHCP servers used for host
>>
>>> configuration on the inside network reside on the inside network.
>>
>>>
>>
>>> I also don't understand how a location URI delivered to a host via
>>
>> DHCP
>>
>>> has
>>
>>> any bearing on whether the URI is treated as 'possession model' or
>>
>>> 'authorization model' when dereferenced at the LIS.
>>
>>>
>>
>>> -Marc-
>>
>>>
>>
>>>
>>
>>> On 7/15/08 5:31 PM, "Winterbottom, James"
>>
>> <James.Winterbottom@andrew.com>
>>
>>> wrote:
>>
>>>
>>
>>>> James,
>>
>>>>
>>
>>>> Let us be extremely clear about the difference a HELD location URI
>>
>> and a
>>
>>> DHCP
>>
>>>> location URI and in particular what the difference means when you
>>
>> are
>>
>>> behind a
>>
>>>> NAT!
>>
>>>>
>>
>>>> If you are using DHCP to acquire the URI then you cannot be behind a
>>
>> NAT
>>
>>> no
>>
>>>> way any how as it means that you don not have a URI per user, you
>>
>> have a
>>
>>> URI
>>
>>>> per household. The URI in DHCP does not allow the possession model,
>>
>>> which
>>
>>>> means that the owner of the URI HAS TO provide rules to the LIS
>>
>> (though
>>
>>> they
>>
>>>> have no way to find the LIS to publish the rules to is specified).
>>
>>>>
>>
>>>> I will add now also, that when we talked about HELD there was a lot
>>
>> of
>>
>>>> discussion about VPNs etc, and it was pointed out that most of this
>>
>> was
>>
>>>> equally applicable to a DHCP location solution. There was some
>>
>> banter,
>>
>>> but it
>>
>>>> was decided that we would not update the existing DHCP location
>>
>>>> specifications. However, this is a new draft, and it needs to
>>
>> address
>>
>>> the VPN
>>
>>>> aspects and how to avoid these pitfalls, or not use this
>>
>> specification
>>
>>> when
>>
>>>> the conditions can be detected.
>>
>>>>
>>
>>>> I also think that it is very unfair to single Barbara out on this, I
>>
>>> think you
>>
>>>> will find that a sizable majority of operators were, and still are
>>
>> in
>>
>>> favour
>>
>>>> of a HELD location solution in their networks over a DHCP one.
>>
>>>>
>>
>>>> Cheers
>>
>>>> James
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>> -----Original Message-----
>>
>>>> From: geopriv-bounces@ietf.org on behalf of James M. Polk
>>
>>>> Sent: Tue 7/15/2008 4:19 PM
>>
>>>> To: Rosen, Brian; Hannes Tschofenig; Romascanu, Dan (Dan)
>>
>>>> Cc: geopriv@ietf.org; John Schnizlein
>>
>>>> Subject: Re: [Geopriv] What to do about DHCP and the ever changing
>>
>> PIDF
>>
>>> aswell
>>
>>>> as HELD features
>>
>>>>
>>
>>>> Brian
>>
>>>>
>>
>>>> in-line
>>
>>>>
>>
>>>> At 03:04 PM 7/15/2008, Rosen, Brian wrote:
>>
>>>>> I think this is unfair.
>>
>>>>>
>>
>>>>> The original HELD proposal had nearly all of the capability now
>>
>>> proposed
>>
>>>>> in the sum of the drafts.
>>
>>>>
>>
>>>> and it didn't go anywhere, for many many meetings it went nowhere
>>
>>>>
>>
>>>>> The work group desired to start with the basic LCP and go from
>>
>>>>> there, which the authors did.
>>
>>>>
>>
>>>> this was based on 2 reasons:
>>
>>>>
>>
>>>> #1 - DT submitted a PDF with the business decision that it was not
>>
>>>> going to let anyone know their location without the ability to
>>
>> charge
>>
>>>> for it, and then only give that information out for their own
>>
>>>> subscribers, to be inserted by some server, and not the endpoint.
>>
>>>>
>>
>>>> #2 - because Barbara Stark had the charter to persuade the WG that
>>
>>>> BellSouth wouldn't be upgrading any of their DSL equipment and yet
>>
>>>> still wanted the capability of this new information.
>>
>>>>
>>
>>>> What hasn't been talked about is that the DSL Forum, now called the
>>
>>>> Broadband Forum adopted DHCP as the protocol of choice in their
>>
>> specs.
>>
>>>>
>>
>>>>> They are now
>>
>>>>> bringing back individual features from the original concept, and
>>
>> the
>>
>>>>> work group is considering each feature. Nothing wrong with that.
>>
>>>>>
>>
>>>>> I think it's questionable if DHCP should be giving out an LbyR. If
>>
>> a
>>
>>>>> LIS is getting into the LbyR business, perhaps it ought to be
>>
>> thinking
>>
>>>>> about HELD.
>>
>>>>
>>
>>>> what if a customer runs DHCP now and doesn't want to run another
>>
>>> protocol?
>>
>>>>
>>
>>>> DHCP has been around for quite a while now. Why shouldn't it be
>>
>>>> allowed to be extended to provide a URI?
>>
>>>>
>>
>>>> Why should vendors and customers require a new protocol just to get
>>
>> a
>>
>>> URI?
>>
>>>>
>>
>>>> Isn't it simpler just to extend an existing protocol, than to create
>>
>>>> and force the implementation and knowledge of a new one? To me, the
>>
>>>> latter sounds crazy.
>>
>>>>
>>
>>>>> My question is: what would DHCP LbyR get you that HELD LbyR would
>>
>> not?
>>
>>>>
>>
>>>> a simpler implementation for one. Fewer protocols to configure for
>>
>>>> another. How about less to manage, for a third.
>>
>>>>
>>
>>>>> Why would an implementer choose DHCP when LbyR was used?
>>
>>>>
>>
>>>> I don't know - because they probably already run DHCP?
>>
>>>>
>>
>>>> Question for you: Why are you wanting to mandate a new protocol on
>>
>> an
>>
>>>> implementer just to carry a locationURI, when DHCP can so easily do
>>
>>>> this if extended?
>>
>>>>
>>
>>>>
>>
>>>>> I think we have a reasonable answer for when DHCP is a reasonable
>>
>> LCP
>>
>>>>> when civic is given. I think the argument is slightly less strong,
>>
>> but
>>
>>>>> at least reasonable when geos are given. I'm having trouble with
>>
>> DHCP
>>
>>>>> and lbyr.
>>
>>>>>
>>
>>>>> Why?
>>
>>>>
>>
>>>> does your laptop run HELD today?
>>
>>>>
>>
>>>> It runs DHCP already. A simple service pack (if you run windows -
>>
>>>> which 95% of the planet runs also) could add this Option.
>>
>>>>
>>
>>>> The same issues exist for a DHCP server on the backend when getting
>>
>> a
>>
>>>> wired Ethernet jack or AP its location. There will be some
>>
>>>> communication as to which jack is being asked for, and which
>>
>> location
>>
>>>> record is associated with port or AP, for example.
>>
>>>>
>>
>>>> Couple the capability of a layer 2.5 delivery protocol with that of
>>
>> a
>>
>>>> layer 2 discovery/determination method (802.11 triangulation - which
>>
>>>> has existed for some time now), and all that's necessary is for the
>>
>>>> Location Server of the Access network to populate the location
>>
>>>> records with the changing location of the target, identified by the
>>
>>>> locationURI that's given to the DHCP client by its DHCP server - and
>>
>>>> the client (which is a target (and maybe an LG), and what more is
>>
>>> needed?
>>
>>>>
>>
>>>> DHCP is a data dump delivery system. HELD is more complex.
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>>>> -----Original Message-----
>>
>>>>>> From: James M. Polk [mailto:jmpolk@cisco.com]
>>
>>>>>> Sent: Tuesday, July 15, 2008 3:42 PM
>>
>>>>>> To: Hannes Tschofenig; Romascanu, Dan (Dan)
>>
>>>>>> Cc: geopriv@ietf.org; Rosen, Brian; John Schnizlein
>>
>>>>>> Subject: Re: [Geopriv] What to do about DHCP and the ever changing
>>
>>>>> PIDF
>>
>>>>>> aswell as HELD features
>>
>>>>>>
>>
>>>>>> Perhaps all this excitement about whether or not DHCP gets into an
>>
>>>>>> arms race with HELD needs to be looked at from the opposite point
>>
>> of
>>
>>>>>> view, which is one no one has mentioned to date. Perhaps the
>>
>>>>>> argument that DHCP remains very simple (supply geo, civic and lbyr
>>
>>>>>> and that's it) should be the model for all LCPs, one HELD should
>>
>> be
>>
>>>>>> limited to as well. Which LCP is creating the arms race?
>>
>>>>>>
>>
>>>>>> An observation that can be seen by a blind man is that HELD is
>>
>> taking
>>
>>>>>> on an awful lot of capabilities and features and mechanisms and no
>>
>>>>>> one defines HELD the same way, because there are so many optional
>>
>>>>>> capabilities being proposed vs accepted into the WG.
>>
>>>>>>
>>
>>>>>> DHCP should never be used to obtain GPS assistance data; but to
>>
>>>>>> obtain a single, simple locationURI -- I'm amazed that's getting
>>
>> any
>>
>>>>>> resistance, even as a passing comment.
>>
>>>>>>
>>
>>>>>> At 12:05 PM 7/15/2008, Hannes Tschofenig wrote:
>>
>>>>>>> John,
>>
>>>>>>>
>>
>>>>>>> my pointer to deployment relates to Brian's mail entitled as:
>>
>> "What
>>
>>>>>>> to do about DHCP and the ever changing PIDF aswell as HELD
>>
>> features"
>>
>>>>>>>
>>
>>>>>>> There are problably a few additional features for DHCP to arrive
>>
>> but
>>
>>>>>>> I have some doubts that there are too many of them.
>>
>>>>>>> For example, I doubt that it makes sense to obtain GPS assistance
>>
>>>>>>> data via DHCP.
>>
>>>>>>>
>>
>>>>>>> On the additional issue you raised: I know that the format is
>>
>> also
>>
>>>>>>> used by LLDP-MED but the IEEE in the future with their work on
>>
>> the
>>
>>>>>>> LLDP-MED revision will need to make an assessment what feature to
>>
>>>>>>> add. Additionally, I don't know about the deployment of LLDP-MED
>>
>>>>>>> location mechanisms either. Maybe you know more.
>>
>>>>>>>
>>
>>>>>>> Ciao
>>
>>>>>>> Hannes
>>
>>>>>>>
>>
>>>>>>> Romascanu, Dan (Dan) wrote:
>>
>>>>>>>> Yes, with the observation that LLDP-MED is not an IEEE 802.1
>>
>>>>> standard,
>>
>>>>>>>> but rather a TIA 41.4 standard, also known as ANSI-TIA 1057.
>>
>>>>>>>>
>>
>>>>>>>> Dan
>>
>>>>>>>>
>>
>>>>>>>>
>>
>>>>>>>>
>>
>>>>>>>>> -----Original Message-----
>>
>>>>>>>>> From: geopriv-bounces@ietf.org
>>
>> [mailto:geopriv-bounces@ietf.org]
>>
>>>>>>>>> On Behalf Of John Schnizlein
>>
>>>>>>>>> Sent: Tuesday, July 15, 2008 6:59 PM
>>
>>>>>>>>> To: Hannes Tschofenig
>>
>>>>>>>>> Cc: geopriv@ietf.org; Rosen, Brian
>>
>>>>>>>>> Subject: Re: [Geopriv] What to do about DHCP and the ever
>>
>> changing
>>
>>>>>>>>> PIDF aswell as HELD features
>>
>>>>>>>>>
>>
>>>>>>>>> Hannes,
>>
>>>>>>>>>
>>
>>>>>>>>> Do you really not know that the IEEE 802.1 Committee has
>>
>> adopted
>>
>>>>>>>>> the format from RFC 3825 in their definition of LLDP-MED?
>>
>>>>>>>>>
>>
>>>>>>>>> The broad fact that many specifications of the IETF are never
>>
>>>>>>>>> deployed seems a poor reason to question the utility of the
>>
>> DHCP
>>
>>>>>>>>> options for location configuration information.
>>
>>>>>>>>>
>>
>>>>>>>>> John
>>
>>>>>>>>>
>>
>>>>>>>>> On 2008Jul15, at 11:38 AM, Hannes Tschofenig wrote:
>>
>>>>>>>>>
>>
>>>>>>>>>
>>
>>>>>>>>>> Maybe we could ask these guys whether they are already
>>
>>>>>>>>> happy with the
>>
>>>>>>>>>> functionality being available since years or what other
>>
>>>>>>>>> functionality
>>
>>>>>>>>>> they need.
>>
>>>>>>>>>>
>>
>>>>>>>>>> I would like to avoid ending up like some other IETF groups
>>
>> where
>>
>>>>>>>>>> researchers come up with ideas on what customers could
>>
>>>>>>>>> eventually find
>>
>>>>>>>>>> useful and then there is the big surprise many, many years
>>
>>>>>>>>> later that
>>
>>>>>>>>>> they actually want something different.
>>
>>>>>>>>>>
>>
>>>>>>>>>> Ciao
>>
>>>>>>>>>> Hannes
>>
>>>>>>>>>>
>>
>>>>>>>>>>
>>
>>>>>>>>>>
>>
>>>>>>>>>> Rosen, Brian wrote:
>>
>>>>>>>>>>
>>
>>>>>>>>>>> There is no deployment of anything yet, but I do
>>
>>>>>>>>> understand there are
>>
>>>>>>>>>>> plans for some DHCP deployment in some cable systems and
>>
>>>>>>>>> enterprises.
>>
>>>>>>>>>
>>
>>>>>>>>>>> You will have to wait another year, or maybe more, to use
>>
>>>>>>>>> deployment
>>
>>>>>>>>>>> as a guide.
>>
>>>>>>>>>>>
>>
>>>>>>>>>>> Brian
>>
>>>>>>>>>>>
>>
>>>>>>>>>>>
>>
>>>>>>>>>>>
>>
>>>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>
>>>>>>>>>>>> ...
>>
>>>>>>>>>>>>
>>
>>>>>>>>>>>> I am actually more concerned about the lack of deployment of
>>
>>>>>>>>>>>> the DHCP based mechanisms given that they have been finished
>>
>>>>>>>>>>>> already some time ago.
>>
>>>>>>>>>>>>
>>
>>>>>>>>>>>> Wouldn't it be interesting to know what is deployed and why
>>
>>>>>>>>>>>> some stuff isn't deployed? To some extend that relates to
>>
>> the
>>
>>>>>>>>> discussion
>>
>>>>>>>>>>>> around fixing DHCP-geo.
>>
>>>>>>>>>>>>
>>
>>>>>>>>>>>>
>>
>>>>>>>>>>>>
>>
>>>>>>>>> _______________________________________________
>>
>>>>>>>>> Geopriv mailing list
>>
>>>>>>>>> Geopriv@ietf.org
>>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>>>>>>>>>
>>
>>>>>>>>>
>>
>>>>>>>
>>
>>>>>>> _______________________________________________
>>
>>>>>>> Geopriv mailing list
>>
>>>>>>> Geopriv@ietf.org
>>
>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>>>>
>>
>>>> _______________________________________________
>>
>>>> Geopriv mailing list
>>
>>>> Geopriv@ietf.org
>>
>>>> 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
>>
>>>> Geopriv@ietf.org
>>
>>>> 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
> Geopriv@ietf.org
> 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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Thu, 17 Jul 2008 18:06:59 -0500

This archive was generated by hypermail 2.1.8 : Thu Jul 17 2008 - 19:08:03 EDT