Subject: Re: [Autoconf] [autoconf-dt] On-link,

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 00:15:42 +0200

Hi Charlie,

I owe you response on DT mail on 7/20 (yes, we have a 20th 
month here in Europe:-)
Here is a first one.

|> RFC4861:
|> => on-link  - an address that is assigned to an interface on a
|> =>            specified link.  A node considers an address to be on-
|> =>            link if:
|> =>            - it is covered by one of the link's prefixes (e.g.,
|> =>              as indicated by the on-link flag in the Prefix
|> =>              Information option), or
|> =>            - a neighboring router specifies the address as the
|> =>              target of a Redirect message, or
|> =>            - a Neighbor Advertisement message is received for
|> =>              the (target) address, or
|> =>            - any Neighbor Discovery message is received from
|> =>              the address
|
|We can try to use this definition, especially for
|_our_ Neighbor Discovery messages.  However, we should
|be very explicit to point out that using the latter
|conditions is going to lead to an understanding of
|"on-link" [and, presumably, link] that is quite at
|variance with the "traditional" Ethernet-inspired
|model of a link.  Not to mention that it is quite
|time-variant.
|
|In this connection, I once proposed that we
|legislate the terminology "on-link" to be understood
|as node-local.  Do you agree with that?

Yes, I agree. 
To be annoying accurate: it is local to [the node and 
the attachment to the link]. 
The MANET nodes are routers and I think an address 
configured on a router interface in an UP state is
on-link.

Another annoying accuracy: the draft uses "on link".
Let's use "on-link".

|> The problem is that a MANET router cannot guarantee
|> that all addresses that are on-link can be reached with a single
|> hop.
|
|Now I am confused.  If they aren't reachable in a single hop
|then they should not be on link.  They do not satisfy any
|of the conditions in the definition you quoted.  If there
|were such a situation for which nodes with the same prefix
|were [effectively] multiple hops away, then the prefix
|would have been assigned incorrectly.

Let's face the non-transitivity characteristic.
A has connectivity with B, B with C. But A not with B.
I say addresses A, B and C are on-link.
Agreed?

If agreed, we can say two on-link addresses configured on 
Interfaces to the same link (in this case MANET communication
facility) says little on connectivity between those. 
My MANET router here in the Netherlands and yours in USA can both
be on-link. But out of range. Maybe we are in range next week.

|> Question: shall ARP support multiple IP (sub)networks on the same
|> link? RFC826 does not prohibit this. But as said: it is not always
|> supported.
|
|Again, my answer would be "no".

Now I have some questions: how to support L2 address resolving on
MANET on 802.11-IBSS ?
I suggest ARP. But when interfaces are configured with /32, 
how does ARP deal with it ? Do we need an ARP enhancement ?

|> |Well it has enough value to, for instance, enable the
|> |solution built by Ryuji and me.  So it's nonzero.  It
|> |has enough value to enable other solutions.
|>
|> Teco:
|> But it doesn't describe practical addressing models for MANETs, with
|> other solutions. Some other solutions are extensions on ND / SLAAC /
|> OSPFv3.
|
|
|Are you saying that the solution built by Ryuji and me
|does not offer a practical addressing model?

I did not intent to (dis)qualify a solution.
I intended to say solutions is something else as an addressing model.

If you had draft-perkins-manet-autoconf-01.txt in mind, this is
configuring IPv4 link-locals, right? Didn't I suggest this at 
last IETF?
Why not using IPv6 link-locals, as it works fine for IPv4?

More comments on this draft: I have little against a MANET_PREFIX.
But why not using ULA?

|> |> My other points were:
|> |>  - describe usage of link locals
|> |
|> |I'd prefer to keep this in solution space.
|>
|> Teco:
|> Then we do not agree. Link-locals is part of the addressing model.
|> We can say we cannot use it in a MANET, or that we can build solutions
|> on it. Not mentioning it makes the document less meaningful.
|
|
|O.K.  Let's mention in the document that we do
|not require use of link-locals, but we do not
|prohibit them as long as the appropriate uniqueness
|conditions are maintained.

Again: what makes uniqueness conditions special for link-locals?
Can we accept duplicates for non link-locals?

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Jul 2009 16:32:28 -0700

Hello Teco,

Here are some comments on your reply.

> I owe you response on DT mail on 7/20 (yes, we have a 20th 

I could myself use a few extra months per year.

> configured on a router interface in an UP state is

O.K.

> Another annoying accuracy: the draft uses "on link".

O.K.
> I say addresses A, B and C are on-link.

I assume you meant "But A not with C" instead of
"But A not with B".

It depends.  If "on-link" is node-local, then A, B, and C are
"on-link" as far as B is concerned.  But, C is not "on-link"
as far as A is concerned.
> be on-link. But out of range. Maybe we are in range next week.

This is too confusing for me.  I'd prefer to have it so that nodes
that are "on-link" are on link.  ... so to speak.

> how does ARP deal with it ? Do we need an ARP enhancement ?

How about scatternets :-)?

More seriously, I'd prefer to keep ARP out of the
discussion about "on-link".

> I intended to say solutions is something else as an addressing model.
Well....  O.K.  But still the choice of addressing model has to allow
for useful solutions.

> configuring IPv4 link-locals, right? Didn't I suggest this at 

Our earlier draft was not restricted to link-locals.  In particular, that
design was intended to allow free movement of nodes between different
MANETs, and to allow nodes to leave the MANET cloud and come back
without restriction.

> More comments on this draft: I have little against a MANET_PREFIX.

Either way is fine with me.  When we wrote the draft, I don't
think ULAs were standardized.

> Can we accept duplicates for non link-locals?

What makes link-local special, is that you don't have
multihop protocols for resolving link-local problems.
And it would seem very very weird to design such a
thing.

Or, if you want to extend "link-local" to include nodes that
are not on link but are (by fiat) defined to be "on-link", then
I start to glaze over.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 08:31:47 +0200

Hi Charlie,

|I could myself use a few extra months per year.

Become an accountant. They use month 13, 14 and even more.
Or go for a job here in the Netherlands. Some employers
(used to, crisis...) pay 13th month salary! 

|> Let's face the non-transitivity characteristic.
|> A has connectivity with B, B with C. But A not with B.
|> I say addresses A, B and C are on-link.
|> Agreed?
|>
|
|I assume you meant "But A not with C" instead of
|"But A not with B".

Sorry. 2nd time I made this mistake :-((

|It depends.  If "on-link" is node-local, then A, B, and C are
|"on-link" as far as B is concerned.  But, C is not "on-link"
|as far as A is concerned.

So "on-link" is for a status in the neighbor table. I say we
keep neighbor state in the MANET routing protocol, and leave
L2 address resolving to ARP and ND.
If agreed, we can skip the term "on-link". We use other,
more accurate terms in our hello protocols.

Now, we can say the term "link" in "on-link" has little to do
with "link". It has also little to do with addresses configured
on the router's own interfaces.
Avoid "on-link" in the draft? The following needs rewording:
 If the link to which an interface connects enables no assumptions of
 connectivity to other interfaces, the only addresses which can be
 assumed "on link", are the address(es) of that interface itself.

|> If agreed, we can say two on-link addresses configured on
|> Interfaces to the same link (in this case MANET communication
|> facility) says little on connectivity between those.
|> My MANET router here in the Netherlands and yours in USA can both
|> be on-link. But out of range. Maybe we are in range next week.
|>
|
|This is too confusing for me.  I'd prefer to have it so that nodes
|that are "on-link" are on link.  ... so to speak.

But this is confusing for me.

|> |> Question: shall ARP support multiple IP (sub)networks on the same
|> |> link? RFC826 does not prohibit this. But as said: it is not always
|> |> supported.
|> |
|> |Again, my answer would be "no".
|>
|> Now I have some questions: how to support L2 address resolving on
|> MANET on 802.11-IBSS ?
|> I suggest ARP. But when interfaces are configured with /32,
|> how does ARP deal with it ? Do we need an ARP enhancement ?
|>
|
|How about scatternets :-)?
|
|More seriously, I'd prefer to keep ARP out of the
|discussion about "on-link".

Yes, ARP discussion has nothing to do with "on-link".
My point is, ARP is not specified for handling addresses out
of different subnets. We could come up with this specification
or continue assuming undocumented features are in place.
This is important for me.

|> Again: what makes uniqueness conditions special for link-locals?
|> Can we accept duplicates for non link-locals?
|>
|
|What makes link-local special, is that you don't have
|multihop protocols for resolving link-local problems.
|And it would seem very very weird to design such a
|thing.

Maybe there are no problems....

Teco.

---

From: Rafael Roque <[email-masked]>
Date: Thu, 23 Jul 2009 10:13:39 -0300

Hello Teco,

> But this is confusing for me.

it would be clearer to use words like "same cell" and "in range"?

> This is important for me.

there is an extension of arp dealing with subnets on different interfaces
[RFC 1027].
Moreover, linux comes with a default implementation of this which i already
tested.

-- 
Rafael Roque Aschoff
GPRT/UFPE

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jul 2009 14:38:02 +0100

>  it would be clearer to use words like "same cell" and "in range"?
 
Same cell is definitely bad terminology, there may not be any cells.
 
In range is less bad, as it is probably the most common cause of failed
connections in a MANET. But it is not the only one, so it can't be used
as the general term for why there is no link.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 23 Jul 2009 15:58:38 +0200

Hi Rafael,

Teco:
I dislike "same cell"
I think confusing is caused by not using definitions.
"On link" means to me having an interface to a communication facility,
e.g. "connected to link". This does not imply connectivity.
I think Charlie has a different opinion on what "on link" means.

Teco:
Thanks for this pointer. It clearly shows one cannot assume links with
multiple subnets is supported by ARP.

Teco.

---

From: Rafael Roque <[email-masked]>
Date: Thu, 23 Jul 2009 11:50:59 -0300

Hi Teco,

> I think Charlie has a different opinion on what "on link" means.
thanks for this explanation, by not using definitions is really a problem.