Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 20 Apr 2005 19:13:00 -0400

Henning,

Thanks.  This is the sort of detail that I was hoping to stir up.  

So, the first hop network needs to be the source of location
information.  In my house that is my home network/router, which would
seem to imply that it needs to acquire location into it somehow.  The
router in turn pretends to be a PC and talks through the cable/DSL modem
to an upstream server to get IP addresses and such.  Will my home router
store and relay location information in the access SP?  This assumes
that the location is provisioned into the cable/DSL system.

If I also remember some security mechanisms correctly, DHCP-spoofing is
prevented by not allowing such traffic to go very far.  I wouldn't think
that DHCP gets put into VPN tunnels, but I could be wrong.

Seems like there are several interfaces X protocol choices to work out
here.

Thanks,
Mike

>-----Original Message-----
>From: Henning Schulzrinne [mailto:[email-masked]] 
>Sent: Wednesday, April 20, 2005 3:59 PM
>To: Michael Hammer (mhammer)
>Cc: Brian Rosen; [email-masked]; GEOPRIV WG; 
>[email-masked]
>Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint 
>GEOPRIV/ECRIT InterimMeeting
>
>The basic problem for the end system is
>
>"Get the physically closest box that knows to tell me where I am"
>
>The core requirement is zero client configuration.
>
>L2 and DHCP mechanisms have the advantage that they usually 
>are as close as you're going to get. You can make this 
>indirect, i.e., have DHCP, PPP or L2 tell the client where to 
>get its address.

Or where to go to get location information via a L7 protocol?

>
>L2 (LLDP-MED) has the advantage that the physical structure 
>ensures that I get the correct answer, without doing mappings. 
>Mappings are always subject to being out-of-date or ambiguous 
>or not have the right lookup-key information (e.g., real MAC 
>address, lost on its way through a router or MAC-spoofing 
>bridge). (This is even true for DHCP, where the DHCP server 
>may have to derive from switch port tracing where a device is, 
>which is subject to a variety of failure modes.)
>
>
>Michael Hammer (mhammer) wrote:
>> Brian,
>> 
>> You describe the NENA phase i2 options, ESQK etc.  Your 
>routing element, I assume is doing session routing.
>> 
>> The elements you detail are all (or would appear to be) 
>application-layer entities and the signaling hops are likewise 
>application-layer hops, not L2 hops (except for maybe the LIS-->EP). 
>> 
>> So, where is the L2 "dependency" coming from?
>> 
>> I understand that a network node that is immediately 
>adjacent to the endpoint is most likely to know where the 
>other end of the link terminates, but does that force the 
>delivery protocol aspects of this to be a L2 issue?
>> 
>> Each of the myriad link types carry IP packets, no?  And IP 
>packets can carry an application packet, no?  So, wouldn't the 
>application-layer solution be the more general one?  I thought 
>that was in line with IETF principles.
>> 
>> You are probably just laying out the options, not promoting a 
>> particular one.  I would be interested in seeing what the 
>champions of 
>> one approach or another have to say.  (I did a search on 
>LLDP-MED and 
>> drew a blank.)
>> 
>> Mike
>> 
>

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Apr 2005 21:14:07 -0400

Yeah, you have the basic picture.

The issues are somewhat different for cable and DSL, but it's true that the
home router supplies DHCP, and would have to determine location from the
upstream network and relay it to downstream clients like a VoIP phone.

With cable, they really use DHCP, so the router, when it gets it's IP
address from the cablemodem can get location at the same time.
With cable, it's likely to map the cablemodem MAC address to the service
location.  The cable modem and home router would have to be updated to relay
location.

DSL doesn't use DHCP between the router/DSL modem and the DSL network to get
IP address, and they don't want to use DHCP for location.  They could use
any mechanism they would like to between the DSL modem/router and the DSL
network, if they would then use DHCP (which is how the clients get IP
address from the router) for location.  This requires an update to installed
DSL modem/routers.  They have a small, and decreasing number of cases where
the DSL modem is directly tied (via Ethernet) to PC.  In that case, they
have to supply special code for the PC to get an IP address.  They would
have to update this code with location reporting code.

Brian

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2005 7:13 PM
> To: Henning Schulzrinne
> Cc: Brian Rosen; [email-masked]; GEOPRIV WG; [email-masked]
> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> InterimMeeting
> 
> Henning,
>