Subject: AW: [Ecrit] Getting location behind NAT

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 20 Apr 2006 13:59:18 +0200

Hi Francois,

we are currently discussing this aspect in the Geopriv working group. 
A design team was created to look at this aspect. The Geopriv is the right place to discuss this topic. 
 
You might want to take a look at http://zeke.ecotroph.net/pipermail/geopriv-l7/ to see whether the scenario you have in mind is actually the same as the one we are currently investigating. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Francois D. Menard [mailto:[email-masked]] 
> Gesendet: Donnerstag, 20. April 2006 13:40
> An: 'Hannes Tschofenig'; 'Eric Turcotte (QC/EMC)'
> Cc: [email-masked]
> Betreff: RE: [Ecrit] Getting location behind NAT
> 
> Has anybody standardized the process of grabbing location 
> from the outside
> nat interface to regurgitate on the inside?  If the outside 
> is PPPoE like on
> DSL networks?
> 
> 
> F. 
> 
> 
> --
> François D. Ménard
> Chargé de projet
> Xit télécom inc.
> 1350 rue Royale #800
> Trois-Rivières, QC, G9A 4J4
> Canada
> [email-masked]
> Tel: (819) 374-2556 ext. 268
> Fax: (819) 374-0395
> Cell: (819) 692-1383
>  
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 20 avril 2006 04:16
> To: Eric Turcotte (QC/EMC)
> Cc: [email-masked]
> Subject: Re: [Ecrit] Getting location behind NAT
> 
> Hi Eric,
> 
> you raise an interesting question. Could you describe your deployment
> environment a little bit more. For example, are you talking 
> about a DSL
> environment?
> 
> Ciao
> Hannes
> 
> Eric Turcotte (QC/EMC) wrote:

> > Hi,
> > I was wondering how a UAC gets its location from a DHCP 
> Server behind 
> > a NAT. Is this addressed in the current GEO  RFC or CIVIC drafts?
> > 
> > 
> _http://tools.ietf.org/html?rfc=&draft=draft-ietf-geopriv-dhcp-civil-0
> > 9&submit=Submit_ 
> > 
> <http://tools.ietf.org/html?rfc=&draft=draft-ietf-geopriv-dhcp-civil-0
> > 9&submit=Submit>
> > 
> > _http://tools.ietf.org/html/rfc3825_
> > Thanks,
> > Eric.
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: "Eric Turcotte \(QC/EMC\)" <[email-masked]>
Date: Thu, 20 Apr 2006 10:09:42 -0400

Hi Hannes,
Yes, it is for fixed access. I think the issue is similar, whether it is
DSL or cable access.
Regards,
Eric.

> Sent: Thursday, April 20, 2006 4:16 AM
> you raise an interesting question. Could you describe your 
> deployment environment a little bit more. For example, are 
> you talking about a DSL environment?
> 
> Ciao
> Hannes
>

---

From: "Eric Turcotte \(QC/EMC\)" <[email-masked]>
Date: Thu, 20 Apr 2006 10:05:39 -0400

Hi Brian,
Some comments below.
Regards,
Eric. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, April 20, 2006 9:09 AM
> Lets walk through this, because I think you will find it 
> works pretty well with one exception:
> 
> A device, say a hard SIP Phone sits behind a NAT.  It has an 
> internal address.  The device makes a DHCP query to a DHCP 
> server that sits beyond the NAT.

My assumption was that the SIP phone got its IP address from a "local"
DHCP server, i.e. DHCP server not behind the NAT. However, we would like
to get the UAC location from the DHCP server beyond the NAT. I think
this bring the issue you point out below.

> 
> The DHCP request is relayed by the NAT.  It changes the from 
> IP address to its external address.
> 
> The DHCP server gets the request, and processes it.  It 
> returns the location associated with the subscriber/user, 
> whether it uses the MAC address, the IP address, or a DHCP 
> relay circuit ID to the external address (which is the NAT).
> 
> The NAT gets the DHCP reply, changes the To address and 
> relays the response to the SIP Phone.
> 
> So, as long as its correct that all devices behind the NAT 
> are at the same location, it works.

I would assume this would cover the majority of cases (that the UACs are
at the same location as the NAT. However, do we have cases where you may
have a WLAN access and the UAC may move to different APs? 

> 
> The thing that doesn't work is if the NAT is not just a NAT, 
> but a router, which supplies DHCP service for all the clients 
> behind the NAT.  Then, the DHCP server that the phone is 
> querying is not the extenal DHCP server, its the one in the 
> router.  It would have to know to ask for location from its 
> DHCP server (the external one) and relay that option to its 
> internal clients.

Yes, this is exacltely the issue I had. It would be nice that this would
work without having the UAC to have prior knowledge of the external DHCP
server. 

> Brian
> http://tools.ietf.org/html?rfc=&draft=draft-ietf-geopriv-dhcp-civil-09
> > &s
> > ubmit=Submit
> > http://tools.ietf.org/html/rfc3825
> > Thanks,
> > Eric.

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 20 Apr 2006 15:20:13 -0500

The problem is the legacy NAT + DHCP Server, that knows nothing about
options for providing location. That's one of the reasons why a number
of service providers have requested that there be an application layer
solution for providing location, that easily traverses NAT. This would
allow location determination mechanisms to work without upgrading or
replacing home and small business routers.

As for the device that moves from AP to AP, one way to handle this is
for the device to request location everytime it established a new AP
connection (assuming it is aware that it has moved to a new AP).
Barbara

> From: Eric Turcotte (QC/EMC) [mailto:[email-masked]]
> Sent: Thursday, April 20, 2006 10:06 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ecrit] Getting location behind NAT
> 
> 
> Hi Brian,
> Some comments below.
> Regards,
> Eric. 
> 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117

---

From: "Eric Turcotte \(QC/EMC\)" <[email-masked]>
Date: Thu, 20 Apr 2006 20:10:41 -0400

Hi Barbara,
Thanks for your reply. Some comments inline.
Regards,
Eric.

> From: Stark, Barbara [mailto:[email-masked]] 
> Sent: Thursday, April 20, 2006 4:20 PM
> To: Eric Turcotte (QC/EMC); [email-masked]
> Cc: [email-masked]
> The problem is the legacy NAT + DHCP Server, that knows 
> nothing about options for providing location. That's one of 
> the reasons why a number of service providers have requested 
> that there be an application layer solution for providing 
> location, that easily traverses NAT. This would allow 
> location determination mechanisms to work without upgrading 
> or replacing home and small business routers.

Yes, I agree that this would be an issue as well. I was not there yet. I
was assuming NAT and DHCP Server that would understand the new options,
and still having the issue. Is there more info available about the
application layer solution?

> 
> As for the device that moves from AP to AP, one way to handle 
> this is for the device to request location everytime it 
> established a new AP connection (assuming it is aware that it 
> has moved to a new AP).

Yes, that would work I think, given that the primary issue of NAT is
resolved.

> > > Lets walk through this, because I think you will find it works 
> > > pretty well with one exception:
> > > 
> > > internal address.  The device makes a DHCP query to a DHCP server 
> > > that sits beyond the NAT.
> > 
> > DHCP server, i.e. DHCP server not behind the NAT. However, we would 
> > like to get the UAC location from the DHCP server beyond the NAT. I 
> > think this bring the issue you point out below.
> > 
> > > 
> > > The DHCP request is relayed by the NAT.  It changes the from IP 
> > > address to its external address.
> > > 
> returns the 
> > > location associated with the subscriber/user, whether it uses the 
> > > MAC address, the IP address, or a DHCP relay circuit ID to the 
> > > external address (which is the NAT).
> > > 
> > > So, as long as its correct that all devices behind the NAT are at 
> > > the same location, it works.
> > 
> > I would assume this would cover the majority of cases (that 
> the UACs 
> > are at the same location as the NAT. However, do we have 
> cases where 
> > you may have a WLAN access and the UAC may move to different APs?
> > 
> > > 
> The information transmitted is intended only for the person 
> or entity to which it is addressed and may contain 
> confidential, proprietary, and/or privileged material. Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is 
> prohibited. If you received this in error, please contact the 
> sender and delete the material from all computers. 117
> 
> 
>