[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Some IPv6LL operational experience

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.

> 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

> ...
> 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.


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 majordomo@sunroof.eng.sun.com