Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model

[Alexandru Petrescu <alexandru.petrescu at gmail.com>]

Charles E. Perkins a écrit :
> Hello Ronald,
>
> As I understand, you and several other people feel that the current 
> document is too negative regarding the use of link-local addresses. I
> have tried to create some text for the document which is a little 
> more specific about the situations when link-local addresses can be 
> useful, which are (tautologically) the same situations when 
> leaf-level subnets can be useful.
>
> If this text is more acceptable, maybe the document authors can use 
> it to replace Section 4:
>
> =====================================================
>
> 4.  IP Subnet Prefix Configuration
>
> Some network interfaces obey certain configuration directives which 
> enable useful assumptions about address uniqueness, or otherwise 
> enable communications onto physical media which exhibit certain 
> useful characteristics enabling address aggregation.  Links 
> connecting computers with such network interfaces are likely to 
> support link-local communications reaching multiple computers whose 
> addresses can be aggregated into subnet ranges.  For such links, the 
> known characteristics of the link SHOULD be considered when 
> configuring IP subnet prefixes, and the corresponding interfaces 
> configured with the same subnet prefix.

I agree.  This section starts now with the right thing.

> Such subnet prefix assignment is outside the scope of this document, 
> since it depends on the specific characteristics of the physical 
> links and network interfaces.

That sounds as if you are going to be concerned (inscope of this
document) with prefix assignment which does not depend on the specific
characteristics of the physical links and network interfaces.  DO you
think it is possible to even send a message on a physical link and
network interface without knowing its MTU, for example?

> If, on the other hand, the link to which an interface connects 
> enables no such assumptions of connectivity to other interfaces, the 
> only addresses which can be assumed "on link", are the address(es) of
>  that interface itself.

You are mixing interface scope with link scope.  This should be kept
disambiguated, scopes 2 and 1.

An address "on link" assumes there is a real link out there.

An address "off link" is an address absent from the node and from all
the nodes on that link.

An address on-interface (not sure the terminology exists) can't go on
the link on which that interface attaches, because its scope is solely
that interface (scope 2 in rfc4291, which does exist).

It sounds as a need to define undefinable links.

Let's copypaste here some relevant and recent definitions of link, if 
you wish.  I could help.

> Subnet prefix configuration on such interfaces, SHOULD NOT make any 
> promises in terms of direct (one hop) IP connectivity to IP addresses
I believe it's 0th hop.

> other than that of the interface itself.  This suggests the following
> principle:

Yes, the principle is that you want to define an on-interface scope. 
The problem with it is that it doesn't go out on a link.

> o  two distinct such interfaces in the network SHOULD NOT be 
> configured with the same subnet prefix.
>
> In all cases, when L2 communication is enabled between a pair of 
> interfaces, IP packet exchange is enabled regardless of the IP subnet
>  configuration on each of these interfaces.

This sounds ok to me, it is very well said.  Moreover, IP can run on 
links which have no MAC at all.

> I'd also be willing to go through the rest of the document text 
> making similar revisions.
>
> Another alternative would be to strip link-locals out of the document
>  entirely, or put all such discussion in an Appendix.

Entirely out of the document - I would agree with that.  Don't
mention the word link-local or link-local address anywhere throughout -
I agree.

> This would, however, make the document seem more mysterious and
> arbitrary, since the fundamental reasoning and understanding leading
> to the recommendations would be absent.

I don't believe there is a coherent understanding of the link-local 
addresses.  You simply use them to say that because most of them rely on 
probably-not-unique MAC, and because they are not forwarded across links 
 - then use /128... it's completely illogic.

BEtter don't mention them at all.  I would agree with such a direction.

> I also used "SHOULD" and "SHOULD NOT" instead of "MUSTs", since it 
> seems to me that systems can clearly be built that do not adhere to 
> the recommendations.  Nevertheless, in the absence of system-specific
>  assumptions, the general recommendations are expected to be
> followed. This last sentence is merely a regurgitation of the
> definition of "SHOULD".

I agree with this direction in general, when things are to be explored. 
 In the case of LLs things are widely used already, tested, 
demonstrated, in a different way that you suggest.  Thus I would suggest 
"MAY" in many places where you say link-local address, and "MAY" where 
you say "/128 prefix".

IMHO,

Alex