Re: [DNA-BOF] Re: [mobile-ip] Announce: BoF Proposal: DetectingNetwork Attachment

[Bernard Aboba <aboba@internaut.com>]

> > I agree that the group should avoid looking at
> > the configuration task itself. But still, aren't DHCPv4,
> > DHCPv6, ZEROCONF, and ND all about configuration?

In this context, the issue is addressing -- because the question is
whether the point of attachment has changed so as to require another
address to be provisioned. This issue comes up independent of the
addressing mechanism -- though each mechanism may require its own
optimizations.

Since IPv4 Link-Local is an addressing scheme of last resort, it's use is
more the residue of failure of other mechanisms than an explicit choice,
in many cases. I'd guess that most of the time when a host provisions an
IPv4 LL address, it is the result of an implementation bug, rather than
detection of a legitimate adhoc network.

> > considering that ZEROCONF appears to do exactly what
> > stateless addresss autoconfiguration does in ND.

No, IPv4 LL is not the same as IPv6 stateless autoconfiguration, because
of the recommendations relating to simultaneous use of IPv4LL and routable
addresses, and also because of the need to support healing of a network
partition (due to the much larger probability of address conflict).
Please take a look at:

http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-08.txt

> > to ZEROCONF, so I'm probably missing something.)

It's a difficult subject, with a lot of subtle pitfalls.

> I think that we're bound in some sense to make
> use of deployed technology to achieve the detection.

Yes, but the existing RFCs have lots of mistakes. RFC 2131 talks about
triggering DHCP on a "link down" event.  That doesn't make sense -- if the
link is down, then it's not possible to send DHCP packets on it :) What
they must have meant is a "link up" event -- but even here, that's still
wrong if link authentication is used, and the link comes "up" before it is
authenticated, sending DHCP packets into the bit bucket once again.
These are the kind of mistakes that result in much of the inappropriate
IPv4 LL address allocation, and so there's a  need for a thoughtful look
at how this stuff really works.

> Similar things
> may not reliably be said for IPv4 Router Advertisements.

Yes, because unlike IPv6 RS/RA, IPv4 Router Advertisements don't handle
addressing, so they aren't typically on the critical path for
network attachment detection.

> redo ZEROCONF if you were doing that, etc.

You'll have to redo "claim and defend", but possibly not address
selection.

> > In fact, you might have been doing DHCPv4 and now you
> > have to go for ND-only. Or you might have been doing
> > ND+DHCPv6 and now you have to do ND without DHCPv6.
> > Also, the ND case is interesting in the sense that
> > since it is not a single monolithic thing like DHCPv4,
> > we might have to redo only parts of it.

Heh. Lots of additional fun cases to look at :)

> What is not clear is if there needs to be a non-configuring
> mechanism in IPv4 which will provide complete
> detection of a new network.

I think that's handled through a combination of ARP (to determine whether
the old gateway is still reachable) and DHCPv4 (to determine whether a new
address is required).