Re: interface ID from human name how to?

[Brian Haberman]

Hi Pars,



Regards,
Brian

On Jul 11, 2006, at 5:17, Pars Mutaf wrote:

One issue I see with this is string internationalization. Defining the format of a name is not trivial given the current work to internationalize names, strings, etc. to support languages that do not use a Latin-based alphabet. For example, how would one format a name in a double-byte language is well outside the scope of the IPv6 WG.

On Mon, 2006-07-10 at 17:04 -0700, Peter Sherbin wrote:

Pars,


whatever you want.

Why would you need IETF to tell you which human name format to use. Technically any and all bits to the right of the network boundary are yours and you can do with them

Hi,

That's right, we can do whatever we want. However:

If my host configures an interface ID from 64bithash(pars mutaf),
but someone tries to reach me at 64bithash(parsmutaf),
this won't work.. A standard human name format is needed.

(is this off-topic?)

pars

Thanks,

Peter

--- Pars MUTAF <[EMAIL PROTECTED]> wrote:

Hello,

For example, we are in the same campus. The campus is covered
by a single subnet with several wireless access points. I need
to call you. But there is a problem and I can't get the IPv6 address
of your cellular phone (DNS, or MIPv6 home agent failure).

But, I suspect
that you are probably in the campus (because you work here).
Since we are in the same campus (and, in this example, in the same

I know your subnet prefix. I also know your name, then
I can construct your HUMID (interface ID based on HUMan name).
It is: 64bithash(Bob Hinden). Then, I can reach you (if you're really
in the campus).

Now, imagine a different campus. This campus is covered by 5
subnets. I work in this
campus. In the past I visited different
parts of the campus, and my phone recorded all of the subnet prefixes
that it received from the routers (in the recent past). My phone
has now the list of subnets that cover the subnet (more or less).

I suspect that you're currently in the campus. But I am
not sure which part of it. I know your name. I can construct
your HUMID. My phone has a list of 5 locations (subnets) where you
(and your phone) is likely to be found. It sends a packet to the
IPv6 addresses:

subnet_prefix1 | 64bithash(Bob Hinden)
subnet_prefix2 | 64bithash(Bob Hinden)
subnet_prefix3 | 64bithash(Bob Hinden)
subnet_prefix4 | 64bithash(Bob Hinden)
subnet_prefix5 | 64bithash(Bob Hinden)

If you are really in the campus, I can reach you
even if DNS or your MIPv6 home agent is down.

We can replace the word "campus" with building, or village or city if
we wish.


currently in this city. I may even know in which part of Paris

for example). I have to reach you but your MIPv6 home
agent is unreachable. There are two possibilities:
First, my phone may have learned the subnet prefixes that cover


subnet_prefix1 | hash(Bob Hinden)
subnet_prefix2 | hash(Bob Hinden)
...
subnet_prefixn | hash(Bob Hinden)

Secondly, I can ask Google.
Google has a map of the world, and all information that comes along.
In the new world of wireless IPv6 internet, Google will probably have

will tell me.

So since you're unreachable using existing techniques, my phone
asks me:

Want to search Bob Hinden? (I say yes).
Enter location: (I say Paris, or choose a more precise location
in a map on the screen of my phone).

My phone downloads the lists of subnets that cover your location
from Google and starts searching you.

Searching Bob Hinden. This will take a while...

I take my coffee. 5 minutes later my phone beeps and says:

Located Bob Hinden, calling him..

I'm happy because, I could reach you although your home agent is
down (or another problem).

===


are also possible (why not?).

Please recall that all the IETF needs to do is to answer:

John Smith
johnsmith
john smith
etc.

which human name format should be used to construct a HUMID??

The rest is application layer software work, making the phones
more intelligent etc.. This is not too difficult.

And, perhaps, your phone will more likely be connecting people ;-)

Thanks!

pars




Selon Bob Hinden <[EMAIL PROTECTED]>:

subnet), we are receiving the same router advertisements. Consequently, Now, imagine that we are in Paris. I suspect (or I am sure) that you're you're currently located (this is the case for my friends who live here Paris (as I traveled in Paris... more or less). I can send packets to: the map of wireless IPv6 subnet prefixes that covers the world. What is the quality of service in that subnet, how much it will cost? etc.. Google The above examples may or may not convince you. But the first one at least (with single subnet) is really easy to do. In my personal opinion, the others

Pars,

Ignoring for now if this is good or bad idea, but you might look at

http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-

lookups-15.txt

However, I couldn't understand why I would use a side protocol
(i.e. an ICMP protocol).

My proposal uses basic IPv6. BTW, the draft is now available at
the IETF site:
http://www.ietf.org/internet-drafts/draft-mutaf-ipv6humid-00.txt

It looks like ICMP name lookups can also be used to do the same thing.

My suggestion was to look at the mechanisms in this document.  It a
lot more specific than just saying "hash(John Smith)".

There is a mechanism there to create multicast addresses based on a

host name that might be a starting point.

I would like to configure an interface ID
hash(ParsMutaf| 1) and if it collides
hash(ParsMutaf| 2) etc..

You can try reach or locate me
by sending a packet to (please do not
hesitate):

subnetprefix | hash(ParsMutaf| 1) or
subnetprefix | hash(ParsMutaf| 2)

be to find you.

The big usage problem here is that without knowing your "subnetprfix" it won't be very useful. That leads me to wonder how useful it would

If we are in the same subnet (same building, campus, village, city,
etc), we already know the destination's subnet prefix.

I don't understand how knowing the building, campus, etc., helps to
know the subnet prefix.  Please explain.

Also, see the above referenced ID. It's not too hard to do this on a single link, but trying to scale this to the Internet gets very hard

very fast.

In fact, it doesn't have to scale to the Internet. We may

have a list of subnet prefixes that cover the target zone where
the destination user lives.
(obtained from Google for example, or another service like that).

know the whereabouts of the destination node. In other words, we may

How does google help with this?

If one of the single point of failures (e.g. DNS, or Mobile IPv6 home

agent) is unreachable, I can search the destination node by sending
packets to its HUMID at different subnets where it is likely to be
found.

I understand your intent, but for this to be useful, there has to be
a way to learn the subnet prefix.  For example, you know my name.

What is my current subnet prefix (without looking in the email headers)?

It is probably better for the earthquake scenario you
describe to do this at a higher level (e.g., have a website called
"i-

people to search people they are trying to find out about).

am-alive.org" and make it easy for people to leave messages and for

The "i-am-alive.org" approach may suffer from the same problems.
I.e. it may be unreachable. In addition, who will maintain such a
web site... Nobody cares until the disaster actually happens.

In fact, the disaster scenario is not the only motivation IMO.
For example, I want to install an IPv6 testbed with 'n' machines.
I'm not installing DNS and I'm not configuring the /etc/hosts
files (because n times (n-1) entries would be needed).

too.

Bob

Seems to me if routing and forwarding is working, then DNS is working

Using HUMID, I can give IPv6 addresses based
on imaginary human names to the machines (during installation).
Human name is easy to remember. No need to configure stateful
name->address mappings. I can start to ping right away.

=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

smime.p7s
Description: S/MIME cryptographic signature

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------