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

["Charles E. Perkins" <charles.perkins at earthlink.net>]

Hello Alex,

Alexandru Petrescu wrote:
> 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?

Yes, I do.  There are minimal sizes involved as well
as maximal sizes.

And, I think the document should focus on prefix assignment which
does not depend on the specific characteristics of the physical links
and network interfaces.  And, since this is very general, it would
work for all links.

Prefix assignment for specific link classes ought to be in a separate
document.  Those techniques would not work for all links.

> > 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.
Good luck with that!  On balance, the abovementioned text
is quite clear.  I didn't write it, by the way.

> 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.
0th hop doesn't leave the node.  I think the statement above
is correct.

> > 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.
Your second statement is not correct.  The transmission
occurs on the link to the neighbor.

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

I think it is not the best choice, but better than dawdling for even one
more month on these link-local details.

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

Maybe, but I personally feel that my understanding is crystal clear.

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

This statement is wrong in more than one way:
- I didn't use them
- That is not why they are used in the document
- The proportion of them depending on probably-not-unique MAC
   is not evaluated
- The reason for /128 is not as you suggest
- The reason for /128 is not completely illogic
-  illogic is syntactically incorrect (I do not fault you for this one).

That's a pretty impressive score for a single sentence.

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

In my opinion it should the the last resort, and a recognition
that the working group insists on making progress as slowly
as possible.  But still better than zero progress, so I support
it as a last resort.

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


I think you and others should form a design team to
formulate an addressing model for the subnets you
want.  Be sure to explain why you need for the work
you identify to be done within the [autoconf] working
group.  Maybe you will be happy with DHCP and DAD
and won't need to do anything more.

Regards,
Charlie P.