Ralph Droms wrote: > ... > Certainly some of my problems with IPv4LL have resulted, as > you suggest, from the restriction that an interface have just > one dynamic IPv4 address at a time. I think there's more to > the problem - my experience has been that the IPv4LL address > is configured *silently*, so I have no expectation that the > interface is configured in an unexpected way and that, > because of that configuration, none of my applications will work. > > Perhaps the "configured silently" problem is a UI issue? I'd > also like, as a UI issue I guess, the ability to turn off the > configuration of IPv4LL addresses. Personally, I don't have > any convenient way to use an IPv4LL address, and I'd rather > not have any address configured at all than an IPv4LL > address. (Note that I'm still talking about IPv4 here and > not making any predictions about the availability of > applications that can use IPv6LL > addresses.)
I understand the 'not configured as expected' issue. What I don't understand is why you would rather have no address, unless your stack does not recover and obtain a different IPv4 address when available. If it does recover, I don't see any failure modes that having an IPv4LL creates. If it doesn't recover, I would consider that to be a broken stack.
Well, if I don't have any way to use a LL address, I would rather not have it configured, so that (presumably) I would get an active indication that "sumthin's broke" and, if I know to use ipconfig or the right twisty little maze of control panels, I'll see 0.0.0.0 or 0::0, which is more obviously broken than a LL address. To most people, including myself if I don't look carefully, looks like a valid IP address.
That is, if "the network is not working", and I poke at the IP address and see something vaguely right, then I'll start looking somewhere else for the problem. Which I've done and wasted more time at than I care to think about. So, maybe it's really a UI problem - in any event, that's why I would rather have no address at all than an LL address.
> So, will this problem be solved in IPv6LL addressing? Will I > either get some indication from the stack that "no global > addresses are configured" or will applications work as usual > within the constraints of the network resources that can be > reached on the LL?
This is of course implementation dependent. Personally I believe applications need to work within the constraints of LL on both ends at a minimum. If an app is trying to reach a global, but doesn't have an address of that scope, a UI should complain. I don't know if it should be the app or stack, but in the context of my 'solving the right problem' note, I would rather keep that knowledge contained inside the stack. Actually making the connection between LL & Global is probably best left as a local policy decision, with the default to deny out of scope connections.
> In any event, I should be a little more precise when I say > "applications can't use LL addresses". What I mean here is > that the applications won't work in the way I expect. That > is, I can't use DNS to identify hosts the application should > communicate with, so I have to use an out of band > (shout-down-the-hall?) protocol to ask "What's the address of > your host" so I have an IP address to give to the > application. I don't see where IPv6LL addressing works any > differently in this regard than IPv4LL addressing, so I don't > see how applications will work any better with IPv6LL addresses.
Well to start with, unless your host has a host file, or you happen to be on the same link as a DNS service/proxy, you will never get a DNS response so the whole scenario breaks down. Today if there is no DNS response, people either type in addresses or give up. The yet to be determined 'shout down the hall' protocol provides an alternative for the situations where the nodes happen to share the same link. It doesn't break the primary DNS path, it just adds in to forestall the giving up point. Since typing in IPv6 addresses will really not be feasible, mdns/LLMNR/... really takes that slot.
So do we really not have a complete LL story until mdns/LLMNR/... is standardized and available?
> ... > I may have misunderstood your part of your original message, > in which you > wrote: > > >So you are going to tell the army private that is ducking > the barrage > >of gunfire that he can get the critical info he needs from > the marine > >he just bumped into, if he only types these (what to him are > >pseudo-random) 32 hex characters for both the src & dst. > > Are you describing configuring the interface, configuring the > src and dst in a specific datagram or specifying addresses to > an application?
Anything that would need to be configured. IPv6LL is autoconfigured, so that would not need to be typed in, but if there is a directive that applications can't use LL, then some other address might need to be added. The point was that the situation calls for recognizable strings of characters, therefore some kind of mapping service to whatever addresses are in use. With LLMNR/mdns/... type of service, there is no need to type in literal addresses to the application, or to the stack to make sure there is something other than a LL there.
But there's the rub...we don't have LLMNR/mdns/..., so we don't really have a LL story. I'm all for incremental development like IPv6LL - but it's not a panacea until we have a complete system that lets me use my laptop in exactly the same way on a LL-only network as on the global Internet.
- Ralph
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
