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:
> So what would be the minimum packet sized for IPv6?
You already know the answer to that, and you probably already
know that some device drivers have to run adaptation software
in order to manage transmission over media not supporting
large packets.  And you certainly already know that it is possible
to transmit IPv6 packets with size far less than the minimum MTU.

> But that's not the most important point here.

I thoroughly agree with that.

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

I doubt this, for any sane operating system.

Not everything runs over TCP.


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

Not in my experience.

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

This so thoroughly misses the point I am not sure
just how to respond.

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

Well at least I have finally received a very high compliment.
I rarely suspect that my text might be ideal.

For the rest of your comment, I invite you to consider the
implications of having device drivers with well-defined
interface routines.

> > > > 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".
It means that you don't automatically know the layer-3 addresses
of nodes reachable by that link.

Really, Alex, couldn't you figure this out?

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

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

Try harder.

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

Try!

Don't try to imagine ways that it might be questionable and
argued to infinity in an alternate universe.  Try instead to
understand what it might mean.

That's what I do.

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

Good luck with dancing on that mattress of nails.

> > > Let's copypaste here some relevant and recent definitions of link,
> > > if you wish.  I could help.
>
> Any interest in that ^ ?

No.

> 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?
You ought to know.  If not, then read the previously cited
Baccelli/Perkins document.

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

That is certainly true.

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

I'm not concerned with this, and don't care to
state a position.

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

I really think you ought to get with your colleagues into a
task force.  You are not helping with this document, in my
opinion.

Regards,
Charlie P.