Subject: RE: Questions about geographical dependent addresses

From: [email-masked]
Date: Thu, 2 Dec 2004 10:21:20 +0200

Achim,

You might want to review these drafts:

http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-07.txt

http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-07.txt

and the discussions in this WG on this topic.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Achim Marikar
> Sent: 01 December, 2004 17:08
> To: [email-masked]
> Subject: Questions about geographical dependent addresses
> 
> 
> 
> Hello,
> 
> I am writing my diploma thesis in information engineering at the
> university of applied sciences in Cologne. One of the subjects of my
> thesis is to develop an IPv6 address format which provides 
> geographical
> localisation capabilities to VoIP and other applications. 
> 
> A localisation seems to be necessary for the Internet, 
> otherwise so many
> people would not work on a localisation for Internet users
> (geopriv,ecrit, etc.). In my opinion it would be necessary to assign a
> user to an area code (or to an emergency call centre.)
> 
> As the IPv6 addresses have enough space to map an area code, I don't
> understand why it is never be implemented. In my opinion the 64 bits
> interface ID is too long. If stateful autoconfiguration, static
> addresses or the privacy extension are used, it is not possible to get
> the MAC-address of the interface through the interface ID. A duplicate
> address detection is still necessary. So it would be possible 
> to reduce
> the interface ID to clear space for the area code.
> 
> Wouldn't it be the easiest way to map a reliable area code which is
> validated by the provider? 
> Also Nomadic users could be located through their care of address.
> 
> Thanks for comments,
> 
> Achim Marikar 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Dec 2004 13:50:46 +0100

Achim,

>>(geopriv,ecrit, etc.). 

No, this doesn't follow. The fact that there are commercial
motivations for geolocation or possible invasions of privacy
using geolocation doesn't mean it's *necessary*. In fact, in
many cases it may be highly undesirable. Preventing any
possibility of geolocation might be more desirable than
allowing it, depending on circumstances.

...
>>understand why it is never be implemented. 

Because IP routing works by topology, not by geography. There is no
particular reason why logically adjacent address blocks would be
geographically adjacent. Therefore, the concept of "area code"
is simply meaningless in the IP context.

     Brian

---

From: John Day <[email-masked]>
Date: Thu, 2 Dec 2004 16:53:04 -0500

Geographical is a possible topology according to all of my topology 
books. As every map projection illustrates by constructing a topology 
between the map and the physical world.  Whether that topology and a 
particular graph have a topological relation is a different matter. 
A network in and of itself has no topology.

At 13:50 +0100 12/2/04, Brian E Carpenter wrote:
>Achim,
>
>>>A localisation seems to be necessary for the Internet, otherwise so many

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Dec 2004 09:11:44 +0100

Sure John but the Internet's toplogy is determined by ISP
interconnection and distribution topology; there is some
correlation with geography of course, but it isn't intrinsic.

    Brian

John Day wrote:
> particular graph have a topological relation is a different matter. A 
> network in and of itself has no topology.
> 
> 
>