On Tue, 2006-09-12 at 12:07 +0200, Jeroen Massar wrote:
> Pars Mutaf wrote:
> > On Mon, 2006-09-11 at 23:42 +0200, Jeroen Massar wrote:
> >> Pars Mutaf wrote:
> >>> Hello, 
> >>>
> >>> I have updated my HUMID internet draft entitled:
> >>>
> >>> "Human-regenerable IPv6 interface identifiers and addresses"
> >>>
> >>> Until it appears at the IETF site, you can find it at the
> >>> following address if you're interested:
> >>>
> >>> http://www.freewebs.com/pmutaf/draft-mutaf-ipv6humid-01.txt
> >> [don't read this as an overly negative reply...]
> > 
> > 
> > Hi Jeroen,
> > 
> > 
> >> Why don't you: ping6 ff02::1
> > 
> > 
> > Because when you do that, you got a lot replies. You don't
> > know who is who. 
> 
> Thus your DNS server is down, even though you have a lot of hosts?
> Are all these hosts using hard-coded address then, as that is what your 
> HUMID proposal will end up being used for, unless you patch all the 
> hosts to have a fake DNS resolver that actually does the HUMID calculation.
> >> and then ssh into the server that has your DNS server running and fix it 
> >> up? Or, why not use mDNS (http://www.multicastdns.org/) or SMB/CIFS 
> >> nameresolution? Without DNS you have no network nowadays anyway.
> > 
> > 
> > I believe the DNS server may be down (routing is independent). But 
> > if you don't agree, there are a lot of other things that may go 
> > wrong. Take the MIPv6 home agent, it may be unreachable. You can't 
> > get the destination's care-of-address. Only the home agent knows 
> > it, and it is unreachable.
>  >
> > Or, simply, there is no internet infrastructure in range. 
> > 
> > (please let me know when you finish reading the draft ;-)
> 
> I read the draft and indeed it contained almost exactly what you write 
> above, but that has nothing to do with what I wrote. That I don't 
> comment on certain parts of the draft is not because I didn't read them 
> but because those parts where not the main parts to address in the first 
> place.

Jeroen, I appreciate your comments. But it seems to me that we have
a logical problem here.  I'm trying to present N different potential
motivations. You are dropping N-1 of them (you are not commenting on
them), and say that the last one is not enough.

Ok let's talk about the last one; the DNS. 

I remember having entered IPv4 addresses by heart to reach some 
servers because the DNS was down, in the past. I don't remember why. 
I wouldn't be surprised if the DNS server was down. Or, may be
there was a power cut. Now you will say, if there is a power cut,
everything is down all together. With 3 phase circuits this is not 
true. You have electricity in one room, you haven't in another room.
So, my host and the router may well be up, but the DNS server may be
down.

Or, imagine an ad-hoc scenario. Wireless 802.11 interfaces capable of
ad-hoc mode. A lot of them. There is no internet in range (hence no
DNS). You can use HUMID. 

These are not common cases, I agree. My proposal is about uncommon
cases. I don't really care about common cases, in fact (in this draft).


> If you don't have a network in the first place, then you don't need 
> resolving either as there is nothing to be reached.
> 
> If you want to have a network without DNS, then I suggest you look at 
> things like mDNS, SMB/CIFS which already cover this and don't cause any 
> naming problems or anything you have to remember. Also a local DNS 
> server/cache is quite normal nowadays and thus doesn't require any 
> internet infrastructure to be available. Just look at any out of the box 
> "DSL router^WNAT box"
> 
> >> Solving your missing DNS problem by (ab)using a large portion of the 
> >> EUI-64 space is not something I think is very useful. 
> > 
> > 
> > Why do you think I'm (ab)using the EUI-64 space? We already have
> > random addresses. I missed something? 
> 
> As you will need to obtain a valid EUI-64 prefix to actually be using 
> this address space validly. RFC3041 addresses also have a special prefix 
> allocated and so will any local-part of the address.


I'm using the same address construction as CGA (expect that the 
result is not a CGA, I'm saying that explicitely in the draft). 
Someone please tell me if this bad. 


> Your draft also nicely mentions using DAD for dupe detection, what if 
> two resources are named 'router', which is the resulting address that 
> comes forth out of it? Or 'dns' as you want to fix that server but don't 
> know it's address (but can guess the first 64bits...).


I never said that a router must have a humid address 
(nor DNS server). 

I'm proposing that for personal devices. 

In fact, thanks, I will clarify this in the draft.


> >> It is a fun 
> >> approach, but not very useful in common cases.
> > 
> > 
> > I'm glad that you find that funny. But I'm really serious here ;-)
> > It is very useful in uncommon cases.
> 
> In common cases people simply fix their DNS server.


I already replied to that I think. Who fixes the DNS? Is 
he here today? Please don't assume that you are in a 
billion euro company. 

Or, what if there is no internet in range?

(these are not questions to you, because I know that 
they don't have anwsers)


> [..]
> > Frankly I've no problem with typing jean francois le roux.
> > Please note that, you don't have to know all names in the world!
> > I'm sure there are a number of human names that you know
> > typing correctly (family, colleages, friends...). 
> > 
> > In this case, HUMID is useful for you.
> 
> The only 'name' you need to remember is that of the DNS server and the 
> router, the latter is found at <prefix>::/64 (the subnet anycast address).
> 
> >> Or simple case, my own name, 
> >> people tend to even say "jereon" or "jeroem" or "joeren", let alone the 
> >> problem with pronunciation and then how people tend to write it ;)
> >> Then again, only dutch folks seem to be able to pronounce it correctly.
> > 
> > Good for them. Bad for the others. 
> > 
> > In fact, I don't think human is that stupid. We (humans) know in 
> > general that we might have done a mistake somewhere. 
> 
> Technical people know indeed, 


No. Users. They are not stupid. They know "at least" typing the name 
of their friends, etc. They will mostly succeed.


> but technical people also are smart enough 
> to configure their DNS server correctly and/or when broken fix it.
> 
> People use google nowadays for looking up their things, they don't type 
> in hostnames that much any more and they certainly will not start typing 
> 128 bit addresses made up out of hex chars which they need to calculate
> 
> [..]
> > Try to see this like a human scanning protocol. It may find you, 
> > or it may fail. I say it will mostly succeed.
> 
> Do you know anybody who can do SHA-1 from the head? Even with pen and 
> paper most people won't be able to do so as most people don't even know 
> the algorithm. 

And you think that that's what I proposed? Seriously?


> When you say 'but you can install a tool, download it 
> from http://www... then you are using DNS.


Again, you are unfair. You have downloaded the tool, then later (6 days
later) the DNS has gone away. 

In the best case, this will be used in a standard Linux command. You'll
have it at installation time. But I'm trying to see if this breaks
something else. That's why I came to the IETF.

IETF standardization is needed also because otherwise everyone
will use a different hash function, a different collision count 
value, etc.


> I suggest you take a look at mDNS/SMB/CIFS for the needs you describe.

...
> Secondly if you really think this draft has a value, talk to the folks 
> in the dnsop WG what they think of it as they have a big history in name 
> resolution, and that is what you are cooking up.


OK. Thanks for this remark. I'll surely do that (for the DNS part). 
But some parts of the draft need this WG's approval.

Thanks,
pars


> Greets,
>   Jeroen
> 


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

Reply via email to