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

Charles, this is in an interesting point that I just stumbled across in
ROLL too.  I think the minimum sized packet isn't standardized.  One may
think 40bytes but that's no payload at all.  One may think 41bytes but
there's no Protocol number for a payload of only 1 bute.  ETc.

So what would be the minimum packet sized for IPv6?

But that's not the most important point here.

The important point is that the stack must know the MTU before sending a
packet otherwise it may be tempted in sending huge packets, payload
after payload.

If the AUTOCONF link is such undefined such that even the MTU is unknown
then the stack has much problems sending packets on it.

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

:-)

Charles, I gave a long list of links.  That is not specific.  That list
is very heterogeneous.

On one hand I read your text as ideal, which I share (IP runs over
everything), on another hand the programmer has often real links at
hand, not some undefined link.

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

Let's try this ^ text again.

What does it mean?  I can accept for a while MANET link being a link
with no assumption of connectivity.

But then, what does it mean "the only address assumed "on link" is the
address of that interface"?  Do you mean there is nobody else on that
link?  If there is nobody else on that link then it is an "off link",
per rfc4861 def of "off link".

Do you mean that all addresses in MANET link are off-link?

Really, however I struggle to read that phrase I can't parse.

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

Sorry for saying 'you'.

I meant to say that that text says something I can't parse.

Let's have the definitions of "link", "on link", "off link", "link
scope", "interface scope".  These are widely used and implemented and
have their meanings understood as per rfc4861 and addr architecture and
other docs.

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

Any interest in that ^ ?

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

Yes, I think I actually agree with you on that.  I often stumble
between 0 and 1...

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

Well, clearly an "interface-local scope" means it stays on that
interface, not go on link, as per arch doc.  A "link scope" - it stays
on that link, not global, etc.  That "interface-local" scope is for
multicast addresses.

I have never seen an address in that interface-local scope.

When reading the draft-baccelli draft it makes me think of such an
address, because it says it is "on link", it is on interface, there's
nobody else on that link, yet it's not "off link".

Your use of neighbor... is it on purpose(?)... ND?  NHDP?

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

I agree with you on this.

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

Ok let's say there's no common crystal clear understanding of what the
draft says about 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.
>
> 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.

Ha :-)  let's agree that saying "/128" is not saying "/10" - we can
agree on that, right?  I.e. saying "/128" excludes saying "/10".

> > 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 support it too not only as last resort - if Chairs want to decide that 
now - I am all for it - LLs out of the doc, completely, now.

As for the /128 recommendation we can discuss separately, one thread is
not enough.

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

Well, not for the moment.  For the moment let's do this document.

Alex

> Regards, Charlie P.